f77 -finit-local-zero test.f
test.f: In program `test':
In file included from test.f:0:
test.f:2: internal compiler error: Segmentation fault
Test case:
PROGRAM TEST
COMPLEX CZERO(1)
END
>=gcc-4 seems to have this option removed now
--
Summary: ICE in f77 with -f
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2005-12-15
08:29 ---
*** This bug has been marked as a duplicate of 18913 ***
--
toon at moene dot indiv dot nluug dot nl changed:
What|Removed |Added
-
--- Comment #4 from toon at moene dot indiv dot nluug dot nl 2005-12-15
08:29 ---
*** Bug 25424 has been marked as a duplicate of this bug. ***
--
toon at moene dot indiv dot nluug dot nl changed:
What|Removed |Added
--
--- Comment #3 from falk at debian dot org 2005-12-15 08:41 ---
I cannot reproduce this on alphaev68-linux with 4.0.3 20051201 (prerelease),
4.1.0 20051124 (prerelease), or 4.2.0 20051124 (experimental). Could you
perhaps try a newer version (4.0.2) or even better a recent snapshot?
--
It seems that, according to F95, list-directed formatting of zero must behave
as if formatted with the E descriptor (0.0E+00) while F2003 requires an F
format behaviour (0.0). See message
<[EMAIL PROTECTED]> on comp.lang.fortran
("writing formatted zeros with implicit formats", by [EMAIL PROTECTED]
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2005-12-15
09:17 ---
The test case is OK; the variable b is definable, so can be used as an actual
argument for a dummy with intent OUT/INOUT. DF6.0 and Lahey agree with me on
this.
Gfortran does the right thing if the int
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-12-15 09:25
---
Adding a printf into the libgfortran csqrt() code:
re = REALPART (z);
im = IMAGPART (z);
printf ("input: %lg %lg\n", re, im);
shows that it is used in both cases, but the input value is crap in the
dynamic
--- Comment #3 from paolo at gcc dot gnu dot org 2005-12-15 10:11 ---
Subject: Bug 25421
Author: paolo
Date: Thu Dec 15 10:11:03 2005
New Revision: 108565
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108565
Log:
2005-12-15 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #4 from paolo at gcc dot gnu dot org 2005-12-15 10:22 ---
Subject: Bug 25421
Author: paolo
Date: Thu Dec 15 10:22:19 2005
New Revision: 108566
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108566
Log:
2005-12-15 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #5 from paolo at gcc dot gnu dot org 2005-12-15 10:23 ---
Subject: Bug 25421
Author: paolo
Date: Thu Dec 15 10:22:53 2005
New Revision: 108567
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108567
Log:
2005-12-15 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #6 from pcarlini at suse dot de 2005-12-15 10:24 ---
Fixed for 4.0.3.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #23 from jakub at redhat dot com 2005-12-15 10:48 ---
The problem seems to be that strength_reduce -> loop_givs_reduce reduces a giv
that is not always_computable (and as shown on the segfault, it really can't be
computed unconditionally).
p *bl->giv
$16 = {insn = 0x2dc38
--- Comment #2 from d dot ayers at inode dot at 2005-12-15 11:13 ---
Created an attachment (id=10493)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10493&action=view)
documentation patch
After the discussion here:
http://lists.apple.com/archives/objc-language/2004/Mar/msg7.htm
--- Comment #2 from dorit at il dot ibm dot com 2005-12-15 12:41 ---
The problem is that the vectorizer applies loop-peeling in order to align the
data reference *(m->c+i), and peeling only works correctly if the data is
naturally aligned (aligned on it's type size). This is what the vec
--- Comment #12 from hubicka at gcc dot gnu dot org 2005-12-15 12:49
---
Subject: Bug 24969
Author: hubicka
Date: Thu Dec 15 12:49:10 2005
New Revision: 108573
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108573
Log:
PR target/24969
* i386.c (classify_argument
--- Comment #3 from dorit at il dot ibm dot com 2005-12-15 12:50 ---
related discussion: http://gcc.gnu.org/ml/gcc/2005-12/msg00390.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25413
--- Comment #21 from ebotcazou at gcc dot gnu dot org 2005-12-15 13:29
---
Subject: Bug 18659
Author: ebotcazou
Date: Thu Dec 15 13:29:14 2005
New Revision: 108576
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108576
Log:
2005-12-15 Eric Botcazou <[EMAIL PROTECTED]>
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2005-12-15 13:29
---
Subject: Bug 18819
Author: ebotcazou
Date: Thu Dec 15 13:29:14 2005
New Revision: 108576
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108576
Log:
2005-12-15 Eric Botcazou <[EMAIL PROTECTED]>
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
|
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
|
--- Comment #13 from hubicka at gcc dot gnu dot org 2005-12-15 13:48
---
Subject: Bug 24969
Author: hubicka
Date: Thu Dec 15 13:48:22 2005
New Revision: 108577
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108577
Log:
PR target/24969
* i386.c (classify_argument
Can not create a friend function for a class that is in a namespace, if the
function is not in this namespace.
Example:
Command Line:
g++ -save-temps main.cpp
Error:
main.cpp:12: error: std::ostream& operator<<(std::ostream&, S::A&) should
have been declared inside ::
--
Summary
--- Comment #1 from sela_lerer at hotmail dot com 2005-12-15 14:03 ---
Created an attachment (id=10494)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10494&action=view)
The source file that produced the error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25427
--- Comment #2 from sela_lerer at hotmail dot com 2005-12-15 14:05 ---
Created an attachment (id=10495)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10495&action=view)
g++ preprocessed file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25427
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2005-12-15
14:10 ---
Sorry, I goofed; the testcase is not OK - you are right on the righthand side,
so to speak.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18579
--- Comment #7 from bonzini at gnu dot org 2005-12-15 14:43 ---
Created an attachment (id=10496)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10496&action=view)
one more update
This one includes the change to the usage of __extension__ that Andrew pointed
out.
--
bonzini at g
--- Comment #6 from paul dot richard dot thomas at cea dot fr 2005-12-15
14:49 ---
(In reply to comment #5)
> the testcase in comment #1 no longer seg faults.
module funcs
implicit none
contains
function f(x)
character(*), intent(in) :: x
integer f(len(x))
If a little bit more complex interrupt function is required the compiler
genrates wrong code (olny with -O flag set).
Compiler generats:
sub lr, lr, #4
stmfd sp!, {r.., lr}
.
.
.
ldmfd sp!, {r.., lr}
subspc, lr, #4
Here the LR is
--- Comment #1 from th dot r dot klein at web dot de 2005-12-15 14:59
---
Created an attachment (id=10497)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10497&action=view)
except.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25428
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2005-12-15
15:01 ---
(In reply to comment #4)
> These all amount to the same problem. Being a bit more descriptive would also
> make searching for duplicates easier.
I believe that this is a duplicate of 18578 too.
Paul
--- Comment #2 from th dot r dot klein at web dot de 2005-12-15 15:03
---
Created an attachment (id=10498)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10498&action=view)
working result: arm-elf-gcc -save-temps -mthumb-interwork -march=armv4t -Wall
-c except.c
--
http://gcc.
--- Comment #11 from dberlin at gcc dot gnu dot org 2005-12-15 15:04
---
This should be fixed now with the PRE patches committed and the reassocpatches
committed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23619
--- Comment #3 from th dot r dot klein at web dot de 2005-12-15 15:04
---
Created an attachment (id=10499)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10499&action=view)
not working result: arm-elf-gcc -save-temps -mthumb-interwork -O -march=armv4t
-Wall -c except.c
--
http
--- Comment #4 from th dot r dot klein at web dot de 2005-12-15 15:07
---
Created an attachment (id=10500)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10500&action=view)
still working result: arm-elf-gcc -save-temps -mthumb-interwork -march=armv4t
-Wall -c except.c
--
http:
--- Comment #5 from th dot r dot klein at web dot de 2005-12-15 15:08
---
Created an attachment (id=10501)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10501&action=view)
now working result: arm-elf-gcc -save-temps -mthumb-interwork -O -march=armv4t
-Wall -c except.c
--
http
--- Comment #6 from th dot r dot klein at web dot de 2005-12-15 15:10
---
Created an attachment (id=10502)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10502&action=view)
possible patch (used diff -Bbwu)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25428
--- Comment #7 from aph at gcc dot gnu dot org 2005-12-15 15:54 ---
This should now be fixed on trunk and 4.1 branch.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from paul dot richard dot thomas at cea dot fr 2005-12-15
16:21 ---
Jakub,
I believe, but cannot test until tonight, that my patch
http://gcc.gnu.org/ml/fortran/2005-12/msg00259.html cures this problem by
checking for host association of the same use associated derived t
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-15 16:23 ---
This is invalid code, Comeau gives the following error:
"ComeauTest.c", line 12: error: the global scope has no "operator<<"
friend std::ostream & :: operator<<(std::ostream &os,A
&a);
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-12-15 16:24
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
[EMAIL PROTECTED] jdom-1.0]$ gcj4 -C -I src/java
src/java/org/jdom/ContentList.java
src/java/org/jdom/ContentList.java: In class 'C$I':
src/java/org/jdom/ContentList.java: In method 'C$I.f()':
src/java/org/jdom/ContentList.java:7: error: Constant expression required.
case CONST:
--- Comment #1 from aph at gcc dot gnu dot org 2005-12-15 16:30 ---
This is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175569
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25429
--- Comment #2 from aph at gcc dot gnu dot org 2005-12-15 16:32 ---
Created an attachment (id=10503)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10503&action=view)
Patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25429
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-15 16:33 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #4 from sela_lerer at hotmail dot com 2005-12-15 16:36 ---
Ok, but what about an inner class? If A had a public inner class B and the
outer function had to operate on it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25427
--- Comment #5 from sela_lerer at hotmail dot com 2005-12-15 16:38 ---
Ok, but what about an inner class? If A had a public inner class B and the
outer function had to operate on it?
--
sela_lerer at hotmail dot com changed:
What|Removed |Added
---
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-12-15 16:43 ---
(In reply to comment #5)
> Ok, but what about an inner class? If A had a public inner class B and the
> outer function had to operate on it?
The code is still invalid. Just there is no simple work around except sp
--- Comment #3 from ayers at gcc dot gnu dot org 2005-12-15 16:46 ---
Subject: Bug 14382
Author: ayers
Date: Thu Dec 15 16:46:17 2005
New Revision: 108584
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108584
Log:
2005-12-15 David Ayers <[EMAIL PROTECTED]>
PR libobjc/
--- Comment #2 from jakub at gcc dot gnu dot org 2005-12-15 16:47 ---
Yes, your patch fixes this (perhaps you can also add this testcase into your
patch), thanks.
Your patch looks OK to me, but my OK doesn't count.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25391
--- Comment #4 from ayers at gcc dot gnu dot org 2005-12-15 17:23 ---
Subject: Bug 14382
Author: ayers
Date: Thu Dec 15 17:23:10 2005
New Revision: 108587
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108587
Log:
2005-12-15 David Ayers <[EMAIL PROTECTED]>
PR libobjc/
--- Comment #2 from kargl at gcc dot gnu dot org 2005-12-15 17:41 ---
Gfortran will never support a real*16 data type on IA32 hardware.
This would require software emulation of all of basic floating-point
arthimetic as well as implementation/modification of all intrinsic
procedures that
--- Comment #5 from ayers at gcc dot gnu dot org 2005-12-15 18:01 ---
Subject: Bug 14382
Author: ayers
Date: Thu Dec 15 18:01:17 2005
New Revision: 108588
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108588
Log:
2005-12-15 David Ayers <[EMAIL PROTECTED]>
PR libobjc/
The testcase I'm going to attach ICEs at -m64 -O1 on ppc:
A.c: In function 'test':
A.c:129: internal compiler error: in gen_add2_insn, at optabs.c:4126
gen_add2_insn is called with
(mem/u/c/i:DI (plus:DI (reg:DI 2 2)
(const:DI (minus:DI (symbol_ref/u:DI ("*.LC1") [flags 0x2])
--- Comment #1 from jakub at gcc dot gnu dot org 2005-12-15 18:08 ---
Created an attachment (id=10504)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10504&action=view)
A.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25432
--- Comment #6 from ayers at gcc dot gnu dot org 2005-12-15 18:24 ---
Subject: Bug 14382
Author: ayers
Date: Thu Dec 15 18:23:40 2005
New Revision: 108589
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108589
Log:
2005-12-15 David Ayers <[EMAIL PROTECTED]>
PR libobjc/
--- Comment #15 from hubicka at gcc dot gnu dot org 2005-12-15 19:04
---
Subject: Bug 24969
Author: hubicka
Date: Thu Dec 15 19:04:04 2005
New Revision: 108592
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108592
Log:
PR target/24969
* i386.c (classify_argument
--- Comment #3 from schnetter at aei dot mpg dot de 2005-12-15 19:39
---
I was not suggesting to introduce a new datatype for real*16, but that the same
type that is used for long double in C is available as real*16 in Fortran, if
the option -m128bit-long-double is used. This request i
# gcc -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/gcc-4.1.0_beta20051209/work/gcc-4.1-20051209/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.0-beta20051209
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0-beta20051209/include
--d
--- Comment #1 from zlynx at acm dot org 2005-12-15 19:58 ---
Created an attachment (id=10505)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10505&action=view)
source to reproduce ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25433
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-15 20:22 ---
main/texcompress_fxt1.c: In function fxt1_encode:
main/texcompress_fxt1.c:1353: internal compiler error: in
lambda_loopnest_to_gcc_loopnest, at lambda-code.c:1982
Please submit a full bug report,
with preprocessed
--- Comment #4 from kargl at gcc dot gnu dot org 2005-12-15 20:34 ---
(In reply to comment #3)
> I was not suggesting to introduce a new datatype for real*16, but that
> the same type that is used for long double in C is available as real*16
> in Fortran, if the option -m128bit-long-doub
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-15 20:35 ---
*** This bug has been marked as a duplicate of 23820 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-12-15 20:35 ---
*** Bug 25433 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from d dot ayers at inode dot at 2005-12-15 21:20 ---
* README (+load,+initialize): Fix documentation to reflect
intended and implemented semantics for +load and +initialize.
--
d dot ayers at inode dot at changed:
What|Removed
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-15 21:30 ---
I have a way to fix this but I will not get to it until tomorrow as I am
working on fixing PR 25360 first.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18573
--- Comment #5 from schnetter at aei dot mpg dot de 2005-12-15 21:44
---
Subject: Re: Would like to access "long double" equivalent type as real*16
On Dec 15, 2005, at 14:34:47, kargl at gcc dot gnu dot org wrote:
> --- Comment #4 from kargl at gcc dot gnu dot org 2005-12-15
>
--- Comment #3 from jsm28 at gcc dot gnu dot org 2005-12-15 21:50 ---
Subject: Bug 25028
Author: jsm28
Date: Thu Dec 15 21:50:10 2005
New Revision: 108598
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108598
Log:
PR other/25028
* libgcc2.h (SF_SIZE, DF_SIZE, XF_
I used to be able to do
# cd gcc
# make unstage1
# make restage1
But now ./prev-gcc/xgcc is used to rebuild stage 1 compiler, not the
system compiler.
--
Summary: stage build no longer works
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
--- Comment #6 from jsm28 at gcc dot gnu dot org 2005-12-15 22:38 ---
I shouldn't be on the CC list of this PR or recorded as having made changes to
it (that was Jason Molenda, [EMAIL PROTECTED], a distinct user), it shouldn't be
receiving long random commit messages (I suppose something
trunk on revision 108591 fails to bootstrap with Ada on x86-linux (works on
x86_64-linux). Last known bootstrap: revision 10838
../../gnatmake -c -I../rts -I. -I/home/guerby/work/gcc/version-head/gcc/ada
gprmake --GCC="../../xgcc -B../../ -O2 -g -O2 -gnatpg -gnata"
../../xgcc -c -I./ -I../rt
--- Comment #1 from laurent at guerby dot net 2005-12-15 23:27 ---
A bit more:
(gdb) p x
$6 = (struct basic_block_def *) 0x0
(gdb) p xlimit
$7 = (struct basic_block_def *) 0x41cffb40
(gdb) p *$7
$8 = {stmt_list = 0x41cfaa68, preds = 0x41d0c060, succs = 0x41d0c078, aux =
0x0, loop_father
--- Comment #88 from geoffk at gcc dot gnu dot org 2005-12-15 23:41 ---
This patch doesn't solve the vector issue, does it? It doesn't look
like it, I would have expected it to need some C++ frontend changes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-15 23:43 ---
*** This bug has been marked as a duplicate of 24994 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-15 23:43 ---
*** Bug 25436 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-15 23:45 ---
>From the dup bug, this is also reproducible on x86-linux-gnu too.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from hubicka at gcc dot gnu dot org 2005-12-15 23:52 ---
Subject: Bug 25224
Author: hubicka
Date: Thu Dec 15 23:52:16 2005
New Revision: 108606
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108606
Log:
PR rtl-optimization/25224
* tree-ssa-loop-uns
--- Comment #4 from tromey at gcc dot gnu dot org 2005-12-16 00:00 ---
Subject: Bug 25429
Author: tromey
Date: Fri Dec 16 00:00:43 2005
New Revision: 108608
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108608
Log:
gcc/java:
PR java/25429
* parse.y (resolve_expr
--- Comment #5 from tromey at gcc dot gnu dot org 2005-12-16 00:02 ---
I checked in a fix for this on svn trunk.
I will merge to 4.1 (and perhaps 4.0 -- Andrew?) tomorrow,
unless someone else wants to do it first.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25429
On two different architectures for Linux, gcc-4.0.2 appears to produce bad code
when compiling the RC5 crypto test (crypto/rc5 in openssl) when using any level
of optimization. Compiling the testcase with -O1, -O2, or -O3 will trigger the
bug. -O0 allows the test to complete successfully. This i
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
CC||amodra at bigpond dot net
|
--- Comment #1 from kumba at gentoo dot org 2005-12-16 00:42 ---
Created an attachment (id=10506)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10506&action=view)
Expected Results
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25437
--- Comment #2 from kumba at gentoo dot org 2005-12-16 00:42 ---
Created an attachment (id=10507)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10507&action=view)
What Really Happens
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25437
--- Comment #3 from kumba at gentoo dot org 2005-12-16 00:44 ---
Created an attachment (id=10508)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10508&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25437
--- Comment #4 from kumba at gentoo dot org 2005-12-16 00:47 ---
Forgot to add, the failure itself was traceable to the RC5_32_set_key()
function in rc5_skey.c in the original files. In the attached testcase, the
function in question begins on Line #554.
--
http://gcc.gnu.org/bugzi
--- Comment #5 from kumba at gentoo dot org 2005-12-16 00:50 ---
Created an attachment (id=10509)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10509&action=view)
Preprocessed Output of testcase at -O0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25437
--- Comment #6 from kumba at gentoo dot org 2005-12-16 00:51 ---
Created an attachment (id=10510)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10510&action=view)
Preprocessed Output of testcase at -O1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25437
--- Comment #2 from amodra at bigpond dot net dot au 2005-12-16 00:54
---
.lreg dump has
in basic block 2
(insn 561 559 563 2 (set (reg/f:DI 352)
(plus:DI (reg/f:DI 113 sfp)
(const_int 160 [0xa0]))) 79 {*adddi3_internal1} (nil)
(expr_list:REG_EQUIV (plus:DI (reg/
--- Comment #11 from bero at arklinux dot org 2005-12-16 01:01 ---
After adding some debug statements, I can add that the SIGABRT happens in
org.eclipse.jdt.internal.compiler.parser.Parser's readReadableNameTable method.
ResourceBundle.getBundle() succeeds [doesn't throw a MissingResour
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |major
Known to work|3.4.5 |3.4.5 4.0.3
--- Comment #12 from bero at arklinux dot org 2005-12-16 01:17 ---
Created an attachment (id=10511)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10511&action=view)
Small test case
Found a MUCH smaller test case, just a couple of lines.
tar xzf testcase.tar.gz; cd testcase; ./cra
--- Comment #13 from bero at arklinux dot org 2005-12-16 01:24 ---
Created an attachment (id=10512)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10512&action=view)
Another, even smaller, testcase
Attaching another even smaller test case.
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #7 from kumba at gentoo dot org 2005-12-16 01:55 ---
Got a confirmation the issue exists on Linux/Sparc as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25437
--- Comment #3 from amodra at bigpond dot net dot au 2005-12-16 02:36
---
Looks to be a bug in eliminate_regs_in_insn. This function changes the type of
the insn from (set (reg) (reg)) to (set (plus (reg) (const_int))) but doesn't
update INSN_CODE (insn). find_reloads calls extract_in
--- Comment #4 from amodra at bigpond dot net dot au 2005-12-16 02:40
---
And indeed, making that change cures the testcase ICE.
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
-
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
Severity|normal |major
Target Milestone|--- |4.1.0
http:
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-16 06:08 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01234.html
This also includes the libobjc part.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2005-12-16 06:50
---
So, in the end, is this 4.1 or 4.2?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24994
--- Comment #5 from law at redhat dot com 2005-12-16 07:04 ---
Subject: Re: [4.1/4.2 Regression] infinite
loop in dse
On Tue, 2005-12-13 at 00:23 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-13 00:23
> --
--- Comment #6 from law at redhat dot com 2005-12-16 07:06 ---
Fixed by included patch.
--
law at redhat dot com changed:
What|Removed |Added
Status|NEW
bubblestrap no longer works... due to top level bootstrap just introduced I
guess...
make: *** No rule to make target `bubblestrap'. Stop.
--
Summary: make: *** No rule to make target `bubblestrap'. Stop.
Product: gcc
Version: 4.2.0
Status: UNCONFI
1 - 100 of 103 matches
Mail list logo
