It's an interesting system. I wonder if it's powerful enough to express
the rather complicated constraints on objects of type va_list. Warnings
for violations of those constraints would be valuable - there are common
portability errors that could be caught - but it's never been important
enough
On Mon, 3 Apr 2006, Roger Sayle wrote:
On Mon, 3 Apr 2006, Richard Guenther wrote:
|| (TREE_CODE (type) == INTEGER_TYPE
(TREE_CODE (arg1) == INTEGER_CST
|| TYPE_UNSIGNED (type)
|| (flag_wrapv !flag_trapv)))
Does this
Hello,
ISSUE: Facing problem with bit fields, when i am compiling my code with
GCC. It was previously compiled with diab compiler and was working fine.
In our code Union definition is as follows...,
union
{
unsigned_8 indicator;
struct
{
unsigned_8 unused : 6;
unsigned_8 speed :1;
unsigned_8
On 4/5/06, Devendra Mulakkayala [EMAIL PROTECTED] wrote:
2. I know that these bit fields are compiler dependent. Is there any option
in GCC to set the bit fields from top to bottom ( MSB to LSB )
in structure.
3. As per the client requirement we are not supposed to change the code. I
am
Theres an interesting discussion going on as to whether Microchip Inc is
allowed by the GPL to licence linker scripts and some other scripts (their
code, not based on a GPL'ed code) when these scripts are all distributed as
part of the MPLAB C30, which is a C compiler, based on the GNU CC (gcc)
Hi,
Can somebody please explain to me is it reasonable and possible to port gcc
(version 4.xx) to 8 bit cpu architecture.
I would appreciate precise explanation why it is possible or not.
CPU is V8-uRISC.
V8-uRISC Features are:
8-bit ALU
64K byte addressing capability
Accumulator (R0)
On 05 April 2006 13:57, Colm O' Flaherty wrote:
Theres an interesting discussion going on as to whether Microchip Inc is
allowed by the GPL to licence linker scripts and some other scripts (their
code, not based on a GPL'ed code) when these scripts are all distributed as
part of the MPLAB
On 05 April 2006 13:57, Colm O' Flaherty wrote:
Addressing specifically the questions in that post you linked to:
http://www.linuxhacker.org/cgi-bin/ezmlm-cgi/1
It is a clear case of mere aggregation. Putting two things into a zip
file or tarball together does not suddenly turn one
* Dave Korn [EMAIL PROTECTED] [060405 16:19]:
However if Microchip have written their own entirely new linker scripts,
they hold the copyright and may license them however they please.
Unless they are used to compile the derivative of gcc. If they are they are
most likely scripts used to
Yes, I have the source code of this backend. It's based on gcc-3.3.
You can find an URL to download the source code on the GCC mailing, else
I can put it on a FTP server.
PoluX
Hi,
Until now i have only build cross toolchains for linux systems.
Usually i build crossgcc in 2 parts, one is before glibc is built ,
the other is after glibc is built.
Is there any way where i can skip the step glibc and build the whole
gcc compiler.
If yes how do i build the whole gcc
I participated in a port to an 8-bit internet toaster 4 years ago (the Ubicom
IP2k chip).
It's distributed as part of the gcc-3.x releases, but has been dropped from the
gcc-4.x distributions.
The IP2k was a very restrictive environment, and it took a lot of work to get
it to generate really
On 05 April 2006 16:41, Bernhard R. Link wrote:
* Dave Korn [EMAIL PROTECTED] [060405 16:19]:
However if Microchip have written their own entirely new linker scripts,
they hold the copyright and may license them however they please.
Unless they are used to compile the derivative of gcc.
FWIW we did get really great code generation for the IP2k in the end
although it took some rather unpleasant machine-dependent-reorg stuff to
work around the fact almost every instruction used a singe 8-bit
accumulator registerr :-)
Other ports to look at would be the AVR (8-bit RISC with 32
On Apr 5, 2006, at 5:57 AM, Colm O' Flaherty wrote:
Theres an interesting discussion going on as to whether Microchip
Inc is allowed by the GPL
Wrong list. gnu.misc.discuss is the right list.
I have two (maybe dummy) question here:
1) For C programs, gimplification is done in gimplify_function_tree(), which
is called (through several caller layers) from toplev_main().
Can someone explain how gimplification is done for C++?
Maybe another way to ask it is: I understand cc1 is
-
Back to look YOUNGER again with your real Hair
http://www.hairinesscenter.com
* hair loss reduce
* gray hair reduce
* dandruff reduce
and more
http://www.hairinesscenter.com/en
-
Back to look YOUNGER again with your real Hair
http://www.hairinesscenter.com
* hair loss reduce
* gray hair reduce
* dandruff reduce
and more
http://www.hairinesscenter.com/en
--- Comment #3 from mark at gcc dot gnu dot org 2006-04-05 06:38 ---
This might (or might not) be related to bug #24752 although also in that case
it could be argued that the user code is just buggy and should be fixed. See
also bug #24632 which is also similar, but in that case the
--- Comment #10 from paul dot richard dot thomas at cea dot fr 2006-04-05
07:02 ---
program main
call foo (5)
end program main
subroutine foo(n, a)
integer :: n
integer, dimension(5), optional :: a
print *, n
if (present (a)) call abort ()
end subroutine foo
Andrew
--- Comment #4 from rmathew at gcc dot gnu dot org 2006-04-05 07:05 ---
(In reply to comment #2)
The difference between Sun's and Classpath's implementation appears to be that
Classpath will check for Concurrent Modification on both hasNext() and next()
calls, while Sun's
--- Comment #19 from jason at gcc dot gnu dot org 2006-04-05 07:05 ---
Giving an error for this testcase is no longer correct under DR 391:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#391
--
jason at gcc dot gnu dot org changed:
What|Removed
--- Comment #20 from pinskia at gcc dot gnu dot org 2006-04-05 07:10
---
(In reply to comment #19)
Giving an error for this testcase is no longer correct under DR 391:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#391
That would be recorded as PR 25950.
*** This
--- Comment #20 from pinskia at gcc dot gnu dot org 2006-04-05 07:10
---
*** Bug 12226 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from paul dot richard dot thomas at cea dot fr 2006-04-05
07:17 ---
(In reply to comment #7)
I don't think this is defined code:
if (present (a)) call abort ()
call foo_ (a)
If a is not present, you should not be able to use a in any way.
Not quite; as I
--- Comment #3 from c dot lemmen at fz-juelich dot de 2006-04-05 07:25
---
Created an attachment (id=11210)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11210action=view)
Preprocessed source that triggers the ICE
Sorry, I forgot
--
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-04-05 07:25
---
(In reply to comment #11)
(In reply to comment #7)
I don't think this is defined code:
if (present (a)) call abort ()
call foo_ (a)
If a is not present, you should not be able to use a in any way.
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-05 07:25 ---
*** Bug 27035 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-04-05 08:16
---
Subject: Bug 26763
Author: rguenth
Date: Wed Apr 5 08:16:38 2006
New Revision: 112697
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112697
Log:
2006-04-05 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-04-05 08:20
---
Subject: Bug 26763
Author: rguenth
Date: Wed Apr 5 08:20:21 2006
New Revision: 112698
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112698
Log:
2006-04-05 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-04-05 08:22
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-05 08:29 ---
works for me with 20060330 and 20060404
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27022
--- Comment #3 from guillaume dot melquiond at ens-lyon dot fr 2006-04-05
08:59 ---
Since the runtime slowdown between the binaries produced by GCC3 and GCC4 was
not negligible, I did search a bit more for workarounds. It was quite simple in
fact: passing -mno-sse produced assembly
--- Comment #9 from pcarlini at suse dot de 2006-04-05 09:41 ---
(In reply to comment #8)
Here's a fix that seems to work. Agree with Paolo, this should go into
mainline
and gcc-4.1
Juyt assign the PR to yourself... ;) Maybe the copy constructor should copy
_M_used? Or, you could
With the fix for PR 26763, we are unable to determine # of iterations of the
following loop, more precisely, we are unable to determine that it rolls -- for
that, we would need to fold p_4 + 4B p_4 + 8B.
int foo (int *p)
{
int i = 0, *x;
for (x = p; x p + 2; x++)
i++;
return i;
}
--- Comment #4 from aph at gcc dot gnu dot org 2006-04-05 09:53 ---
Subject: Bug 25414
Author: aph
Date: Wed Apr 5 09:53:08 2006
New Revision: 112699
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112699
Log:
2006-04-05 Archit Shah [EMAIL PROTECTED]
PR java/25414
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-05 09:57 ---
Confirmed. That gives us a testcase at least.
Now, back to the folding problem of
PTR +- CST CMP PTR +- CST
where all of PTR / CST are of pointer type naturally and unsigned usually.
The problem was that the
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org
--- Comment #2 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-04-05 10:05 ---
Subject: Re: Unable to determine # of iterations for a simple loop
Confirmed. That gives us a testcase at least.
Now, back to the folding problem of
PTR +- CST CMP PTR +- CST
--- Comment #3 from rguenther at suse dot de 2006-04-05 10:13 ---
Subject: Re: [4.1/4.2 Regression] Unable to
determine # of iterations for a simple loop
On Wed, 5 Apr 2006, rakdver at atrey dot karlin dot mff dot cuni dot cz wrote:
Subject: Re: Unable to determine # of iterations
--- Comment #4 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-04-05 10:20 ---
Subject: Re: [4.1/4.2 Regression] Unable to determine # of iterations for a
simple loop
Confirmed. That gives us a testcase at least.
Now, back to the folding problem of
--- Comment #5 from rguenther at suse dot de 2006-04-05 10:28 ---
Subject: Re: [4.1/4.2 Regression] Unable to
determine # of iterations for a simple loop
On Wed, 5 Apr 2006, rakdver at atrey dot karlin dot mff dot cuni dot cz wrote:
Umm. Correct :/ I guess the only way to fix
--- Comment #6 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-04-05 10:39 ---
Subject: Re: [4.1/4.2 Regression] Unable to determine # of iterations for a
simple loop
would be much better here. The question is of course, if the programmer
is allowed to write
x +
--- Comment #7 from rguenther at suse dot de 2006-04-05 10:47 ---
Subject: Re: [4.1/4.2 Regression] Unable to
determine # of iterations for a simple loop
would be much better here. The question is of course, if the programmer
is allowed to write
x + (size_t)-1
and
--- Comment #2 from spop at gcc dot gnu dot org 2006-04-05 12:33 ---
Subject: Bug 26996
Author: spop
Date: Wed Apr 5 12:33:06 2006
New Revision: 112700
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112700
Log:
PR tree-optimization/26996
* tree-scalar-evolution.c
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-04-05 13:01
---
Reduced testcase, compile with --param inline-call-cost=0
struct A
{
A() {}
};
struct B
{
A a;
B(A, int) {}
};
void foo()
{
B b(A(), 0);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26919
$ ../gcc-4.1.0/configure --prefix=$HOME/opt/gcc-4.1.0.tmp
--enable-languages=ada,c,c++ --with-as=$HOME/opt/binutils-2.16.1/bin/as
--with-gnu-as --with-ld=$HOME/opt/binutils-2.16.1/bin/ld --with-gnu-ld
--enable-bootstrap=no
...
$ make
...
/export/home/lbre/src/gcc-4.1.0.o/./gcc/xgcc
--- Comment #5 from aph at gcc dot gnu dot org 2006-04-05 13:19 ---
I don't think this is a regression.
[EMAIL PROTECTED] ~]$ ~/gcc/install-4.0/bin/gcj -C z.java
z.java: In class 'z':
z.java: In method 'z.main(java.lang.String[])':
z.java:9: internal compiler error: Segmentation fault
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-04-05 13:29
---
I have a fix.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-04-05 13:35
---
As can be seen from the configure options, this is with GNU
binutils 2.16.1.
What's the configure shell? What's the version of GNU make? What's the
bootstrap compiler?
I also tried the Sun assembler and
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-05 13:42 ---
Fixed on the mainline - this problem is latent in 4.1, can you commit this
obviously safe patch there, too (though techically it might not be a
regression)?
--
rguenth at gcc dot gnu dot org changed:
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-05 13:47 ---
This is mine. And I have a patch posted.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ludovic at ludovic-brenta dot org 2006-04-05 13:47
---
$ make --version
GNU Make 3.80
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-04-05 13:48
---
I'm not working on this. Re-closing as WONTFIX.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-04-05 13:49 ---
I'm no longer working on this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from patchapp at dberlin dot org 2006-04-05 13:50 ---
Subject: Bug number PR26898
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00190.html
--
root: gcc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.4 [FreeBSD] 20050518
root: uname -a
FreeBSD ws3-plovdiv.digsys.bg 6.1-PRERELEASE FreeBSD
6.1-PRERELEASE #0: Wed Mar 22 20:44:32 EET 2006
[EMAIL
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-04-05 13:57
---
(that's from GNAT 3.15p, binary distribution from AdaCore; but the
compiler used to build strstream.cc is ./xgcc, i.e. GCC 4.1.0
built in stage1. And, as I said, the same errors occur with
--- Comment #12 from patchapp at dberlin dot org 2006-04-05 14:00 ---
Subject: Bug number PR26565
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00192.html
--
Building on Windows XPSP2, NTFS file system using MSYS 1.0.10.
If I don't specify --with-as to configure, the compilers (all) build well until
stage3. Only when the stage3 compiler starts building the Ada run time system,
it cannot find 'as' anymore:
rm -f ../stamp-gnatlib
touch
--- Comment #6 from aph at gcc dot gnu dot org 2006-04-05 14:12 ---
As far as I can see this bug is in every version of gcj that has ever existed.
There is special code (in merge_string_cste()) to convert an integer constant
to a constant string for concatenation. However, there isn't
In the following code, in the loop at line 381 of jtagmkII.c (line 2586 of the
attached jtagmkII.i), msglen (and l, as I recall) contain incorrect values.
This only happens when optimization is turned on (-O2); it does not happen with
-O1. The code runs correctly when compiled with gcc-3.3 using
--- Comment #1 from ned at bike-nomad dot com 2006-04-05 14:17 ---
Created an attachment (id=11211)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11211action=view)
Preprocessed source demonstrating bug
Bug is at line 2585/2586 of attached file
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-05 14:26 ---
It's hard to verify with this big (non-executable) testcase. Is there a chance
you can strengthen your claim?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27044
c++ is generating incorrect optimized code for xor operations on long long.
Version which is affected is:
g++ (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8)
Following (proper) code is inlined into bad assembly when optimization is
turned on:
namespace __gnu_cxx
{
/**
hash
--- Comment #1 from l_heldt at poczta dot onet dot pl 2006-04-05 15:17
---
Created an attachment (id=11212)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11212action=view)
File containing hash specifications
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27045
--- Comment #2 from l_heldt at poczta dot onet dot pl 2006-04-05 15:17
---
Created an attachment (id=11213)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11213action=view)
Implementation of RequestId
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27045
--- Comment #3 from l_heldt at poczta dot onet dot pl 2006-04-05 15:18
---
After compilation:
g++ test.cpp req.cpp -O0
program works fine. After compilation with:
g++ test.cpp req.cpp -O2
it breaks with SIGABRT.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27045
--- Comment #5 from mckinlay at redhat dot com 2006-04-05 15:19 ---
(In reply to comment #4)
I would argue that Sun's implementation is correct in this case in the
sense that hasNext() doesn't actually modify anything, only next() does.
Yeah, I agree - although you might get a bogus
--
mckinlay at redhat dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mckinlay at redhat dot com
|dot org
--- Comment #4 from ludovic at ludovic-brenta dot org 2006-04-05 15:21
---
--enable-bootstrap=no + make bootstrap cause a successful build:
...
/export/home/lbre/src/gcc-4.1.0.bootstrap/./gcc/xgcc -shared-libgcc
-B/export/home/lbre/src/gcc-4.1.0.bootstrap/./gcc -nostdinc++
--- Comment #6 from mckinlay at redhat dot com 2006-04-05 15:22 ---
*** This bug has been marked as a duplicate of 27028 ***
--
mckinlay at redhat dot com changed:
What|Removed |Added
--- Comment #6 from mckinlay at redhat dot com 2006-04-05 15:22 ---
*** Bug 24632 has been marked as a duplicate of this bug. ***
--
mckinlay at redhat dot com changed:
What|Removed |Added
PRINT* in gfortran 4.2.0 compiled dll's needs CALL FLUSH to perform correctly
when called from gcc (3.4.2, 3.4.5, 4.1) compiled main. Reproducible sample:
$ gfortran -shared -o ftesti.dll ftesti.f90
ftesti.f90:
---
subroutine print_from_gfortran(txt)
implicit none
character :: txt
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-04-05 15:41
---
Subject: Bug 26919
Author: rguenth
Date: Wed Apr 5 15:41:18 2006
New Revision: 112709
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112709
Log:
2006-04-05 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-04-05 15:44
---
Fixed on the mainline. Let's wait if the changed inlining causes regressions
before backporting.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-04-05 15:47
---
The bootstrap then completes successfully.
Wunderbar. :-)
So: make fails, make bootstrap works, but the commands
invoked are identical. Could it be that gcc 2.8.1 silently
miscompiled cc1plus in the case
PRINT* in gfortran 4.2.0 compiled dll's needs CALL FLUSH to perform correctly
when called from gcc (3.4.2, 3.4.5, 4.1) compiled main. Reproducible sample:
$ gfortran -shared -o ftesti.dll ftesti.f90
ftesti.f90:
---
subroutine print_from_gfortran(txt)
implicit none
character :: txt
All,
Not a bug, this is yet another case of type pruning.
Use -fno-strict-aliasing or fix your code.
Graham
--- Comment #4 from graham dot stott at btinternet dot com 2006-04-05
16:00 ---
Subject: Re: c++ is generating incorrect optimized code for xor operations on
long long
All,
Not a bug, this is yet another case of type pruning.
Use -fno-strict-aliasing or fix your code.
Graham
--
All,
Not a bug, this is yet another case of type pruning.
Use -fno-strict-aliasing or fix your code.
Graham
--- Comment #5 from graham dot stott at btinternet dot com 2006-04-05
16:00 ---
Subject: Re: c++ is generating incorrect optimized code for xor operations on
long long
All,
Not a bug, this is yet another case of type pruning.
Use -fno-strict-aliasing or fix your code.
Graham
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-05 16:02 ---
*** This bug has been marked as a duplicate of 27046 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-05 16:02 ---
*** Bug 27047 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27046
--- Comment #20 from rguenth at gcc dot gnu dot org 2006-04-05 16:05
---
Because they are not the same:
(gdb) call debug_generic_expr(0xb7e31c94)
struct noop_tint (*)()D.2008
(gdb) call debug_generic_expr(0xb7e3505c)
struct noop_tint (*)()D.2008
generated by
#0 build1_stat
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-05 16:08 ---
This was fixed for the non windows case for sure.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from rguenth at gcc dot gnu dot org 2006-04-05 16:11
---
The main difference is the TYPE_DEPENDENT_P_VALID valid lang-type flag. So
this looks like a frontend problem.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-05 16:13 ---
*** This bug has been marked as a duplicate of 21920 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #90 from pinskia at gcc dot gnu dot org 2006-04-05 16:13
---
*** Bug 27045 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from spop at gcc dot gnu dot org 2006-04-05 17:25 ---
Subject: Bug 26996
Author: spop
Date: Wed Apr 5 17:25:26 2006
New Revision: 112711
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112711
Log:
PR tree-optimization/26996
* tree-scalar-evolution.c
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-05 17:29 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-05 18:25 ---
This was fixed by the patch which fixed PR 26992 so closing as a dup of that
bug.
*** This bug has been marked as a duplicate of 26992 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-05 18:25 ---
*** Bug 27022 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-05 18:27 ---
Can you try 4.0.3? Otherwise just report this to Apple instead as you are
using Apple's hacked up Compiler.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.1/4.2 Regression] Insane |[4.1/4.2 Regression] Insane
|amount of memory
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-05 18:38 ---
Yes this is a dup of bug 26197.
*** This bug has been marked as a duplicate of 26197 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-04-05 18:38
---
*** Bug 26948 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from bryce at gcc dot gnu dot org 2006-04-05 18:41 ---
Subject: Bug 27028
Author: bryce
Date: Wed Apr 5 18:41:17 2006
New Revision: 112714
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112714
Log:
2006-04-05 Bryce McKinlay [EMAIL PROTECTED]
PR
--- Comment #1 from tromey at gcc dot gnu dot org 2006-04-05 18:43 ---
Subject: Bug 27024
Author: tromey
Date: Wed Apr 5 18:43:15 2006
New Revision: 112715
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112715
Log:
libjava/classpath:
PR libgcj/27024:
*
--- Comment #8 from mckinlay at redhat dot com 2006-04-05 18:43 ---
Fix checked in to Classpath HEAD and gcc-4_1_branch
--
mckinlay at redhat dot com changed:
What|Removed |Added
1 - 100 of 133 matches
Mail list logo
