[Bug fortran/25424] New: ICE in f77 with -finit-local-zero
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 -finit-local-zero Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: halcy0n at gentoo dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25424
[Bug fortran/25424] ICE in f77 with -finit-local-zero
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25424
[Bug fortran/18913] [3.4 Regression] seg. fault with -finit-local-zero option on complex array of dimension 1
--- 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 CC||halcy0n at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18913
[Bug c++/25411] Optimization with -O2 -finline-functions gives wrong code
--- 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? -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25411
[Bug libfortran/25425] New: F95 and F2003 differ on list-directed output for 0.0
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]).
We currently implement the F2003 behaviour, independently of the -std flag.
$ cat a.f
PROGRAM MAIN
PRINT *, -2.1, -1.2, 0.0, 1.1, 2.2
END
$ gfortran a.f && ./a.out
-2.10 -1.20 0.00 1.10 2.20
$ ifort a.f && ./a.out
-2.10 -1.20 0.000E+00 1.10 2.20
--
Summary: F95 and F2003 differ on list-directed output for 0.0
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25425
[Bug fortran/18579] intent(out) violation is not detected
--- 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 intent is changed to IN. However, if the testcase is modified to call foo (b + 3.0) it still does not give an error and that is a bug because the expression is not definable. I will produce a patch for it. -- paul dot richard dot thomas at cea dot fr changed: What|Removed |Added CC||paulthomas2 at wanadoo dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18579
[Bug libfortran/25370] Bad value for sqrt of double complex
--- 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
dynamically-linked case:
$ ./bin/gfortran -static foo.f90 && ./a.out
( -1.00, 0.00) ( 0.00, 1.00)
input: -1 0
( -1.00 , 0.00 ) ( 0.00 ,
1.00 )
$ ./bin/gfortran foo.f90 && ./a.out
( -1.00, 0.00) ( 0.00, 1.00)
input: 6.64573e-316 1.59098e-314
( -1.00 , 0.00 ) ( 1.397677071793657E-312,
3.756040694101013E-317)
I don't know what happens here!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25370
[Bug libstdc++/25421] [4.0/4.1/4.2 Regression] catching exception from codecvt_byname() segfaults
--- 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 libstdc++/25421 * config/locale/gnu/c_locale.cc (_S_destroy_c_locale): Check for null argument. * testsuite/22_locale/facet/25421.cc: New. Added: trunk/libstdc++-v3/testsuite/22_locale/facet/25421.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/locale/gnu/c_locale.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25421
[Bug libstdc++/25421] [4.0/4.1/4.2 Regression] catching exception from codecvt_byname() segfaults
--- 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 libstdc++/25421 * config/locale/gnu/c_locale.cc (_S_destroy_c_locale): Check for null argument. * testsuite/22_locale/facet/25421.cc: New. Added: branches/gcc-4_1-branch/libstdc++-v3/testsuite/22_locale/facet/25421.cc Modified: branches/gcc-4_1-branch/libstdc++-v3/ChangeLog branches/gcc-4_1-branch/libstdc++-v3/config/locale/gnu/c_locale.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25421
[Bug libstdc++/25421] [4.0/4.1/4.2 Regression] catching exception from codecvt_byname() segfaults
--- 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 libstdc++/25421 * config/locale/gnu/c_locale.cc (_S_destroy_c_locale): Check for null argument. * testsuite/22_locale/facet/25421.cc: New. Added: branches/gcc-4_0-branch/libstdc++-v3/testsuite/22_locale/facet/25421.cc Modified: branches/gcc-4_0-branch/libstdc++-v3/ChangeLog branches/gcc-4_0-branch/libstdc++-v3/config/locale/gnu/c_locale.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25421
[Bug libstdc++/25421] [4.0/4.1/4.2 Regression] catching exception from codecvt_byname() segfaults
--- 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|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25421
[Bug rtl-optimization/24899] [4.1/4.2 Regression] loop.c miscompiles libgnomecanvas
--- 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 = 0x2dc389b0, new_reg = 0x2dc3d3e0, src_reg =
0x2dc30d60, giv_type = DEST_REG,
dest_reg = 0x2dc30da0, location = 0x0, mode = SImode, mem = 0x0, mult_val
= 0x2dc3b2c0, add_val = 0x2da5a400,
benefit = 16, final_value = 0x0, combined_with = 0, replaceable = 0,
not_replaceable = 0, ignore = 0, always_computable = 0,
always_executed = 0, maybe_multiple = 0, cant_derive = 1, maybe_dead = 0,
auto_inc_opt = 0, shared = 0, no_const_addval = 1,
lifetime = 18, derive_adjustment = 0x0, ext_dependent = 0x0, next_iv = 0x0,
same = 0x0, same_insn = 0x0, last_use = 0x0}
p debug_rtx (bl->giv->add_val)
(const_int 0 [0x0])
p debug_rtx (bl->giv->mult_val)
(mem:SI (reg/v/f:DI 67 [ z ]) [2 S4 A32])
I'm not sure though if just adding
if (!v->always_computable)
{
if (loop_dump_stream)
fprintf (loop_dump_stream,
"giv of insn %d: not always computable.\n",
INSN_UID (v->insn));
v->ignore = 1;
bl->all_reduced = 0;
}
to the loop in strength_reduce a few lines above loop_givs_reduce call
wouldn't be a too big hammer for this.
Alternatively check if (!v->always_computable && (may_trap_or_fault_p
(v->add_val) || (may_trap_or_fault_p (v->mult_val)).
BTW, I don't think P3 is the right priority here, IMHO P1 would be more
suitable.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24899
[Bug libobjc/14382] [libobjc] Calling +initialize on a per category basis
--- 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.html I propose the attached patch to close this report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14382
[Bug target/25413] wrong alignment or incorrect address computation in vectorized code on Pentium 4 SSE
--- 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 vectorizer currently blindly assumes, but on the Pentium4 doubles are not necessarily 64bit aligned. Accidentally Devang and I discussed this issue last week, and Devang actually committed a patch to apple-ppc branch that works around the problem ( http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108214). Devang's patch however will not fix this PR - the patch he committed disables vectorization if the vectorizer was able to compute the misalignment, and discovered that it doesn't evenly divide by the type size. In this testcase the misalignment is unknown at compile time. To fix this problem we need to disable loop-peeling in the vectorizer if we can't prove that the data is naturally aligned. Alternatively, if we can't prove either way we can peel the loop but control the number of iterations it will execute using a runtime test (i.e. have the prolog loop iterate the entire loop-count if at runtime we discover that the data is not naturally aligned). -- dorit at il dot ibm dot com changed: What|Removed |Added CC||dorit at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25413
[Bug target/24969] tmpdir-gcc.dg-struct-layout-1/t026 fails execution
--- 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): Properly adjust offset of bitfield for substructures. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24969
[Bug target/25413] wrong alignment or incorrect address computation in vectorized code on Pentium 4 SSE
--- 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
[Bug ada/18659] [4.1/4.2 Regression] ACATS failures c32001e c64105b c95086b
--- 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]> PR ada/18659 PR ada/18819 ada/ * misc.c (tree_sra_requested): New global. (gnat_init_options): Detect -ftree-sra. (gnat_post_options): Enable Tree-SRA only if specifically requested. gcc/ * doc/invoke.texi (Optimize Options): Document that -ftree-sra is not automatically enabled for the Ada compiler. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/ada/ChangeLog branches/gcc-4_1-branch/gcc/ada/misc.c branches/gcc-4_1-branch/gcc/doc/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18659
[Bug ada/18819] [4.1/4.2 Regression] ACATS cdd2a02 fails at runtime
--- 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]> PR ada/18659 PR ada/18819 ada/ * misc.c (tree_sra_requested): New global. (gnat_init_options): Detect -ftree-sra. (gnat_post_options): Enable Tree-SRA only if specifically requested. gcc/ * doc/invoke.texi (Optimize Options): Document that -ftree-sra is not automatically enabled for the Ada compiler. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/ada/ChangeLog branches/gcc-4_1-branch/gcc/ada/misc.c branches/gcc-4_1-branch/gcc/doc/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
[Bug ada/18659] [4.2 Regression] ACATS failures c32001e c64105b c95086b
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org AssignedTo|ebotcazou at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Severity|critical|major Status|ASSIGNED|NEW Summary|[4.1/4.2 Regression] ACATS |[4.2 Regression] ACATS |failures c32001e c64105b|failures c32001e c64105b |c95086b |c95086b Target Milestone|4.1.0 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18659
[Bug ada/18819] [4.2 Regression] ACATS cdd2a02 fails at runtime
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org AssignedTo|ebotcazou at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Severity|critical|major Status|ASSIGNED|NEW Summary|[4.1/4.2 Regression] ACATS |[4.2 Regression] ACATS |cdd2a02 fails at runtime|cdd2a02 fails at runtime Target Milestone|4.1.0 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
[Bug target/24969] tmpdir-gcc.dg-struct-layout-1/t026 fails execution
--- 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): Properly adjust offset of bitfield for substructures. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24969
[Bug c++/25427] New: Impossible to create a friend function for a class in a namespace, outside the namespace.
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: Impossible to create a friend function for a class in a namespace, outside the namespace. Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sela_lerer at hotmail dot com GCC host triplet: i686-pc-Linux-gcc-c++-4.0.2-8.fc4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25427
[Bug c++/25427] Impossible to create a friend function for a class in a namespace, outside the namespace.
--- 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
[Bug c++/25427] Impossible to create a friend function for a class in a namespace, outside the namespace.
--- 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
[Bug fortran/18579] intent(out) violation is not detected
--- 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
[Bug target/25259] bootstrap failures on non-C99 platforms
--- 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 gnu dot org changed: What|Removed |Added Attachment #10417|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25259
[Bug fortran/19574] specification expression failure
--- 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))
integer i
do i=1,len(x)
f(i) = iachar (x(i:i))
end do
end function f
end module funcs
program spec_expr_test
use funcs
implicit none
write(*,*) f('test')
end program spec_expr_test
now compiles and runs correctly, as does my testcase.
I will close this tonight
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19574
[Bug c/25428] New: arm-elf-gcc generating wrong code with -O flag at functions with __attribute__ ((interrupt ("IRQ")))
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 decremented one time too mutch.
Ether first or the second "sub" is wrong.
It should be:
sub lr, lr, #4
stmfd sp!, {r.., lr}
.
.
.
ldmfd sp!, {r.., lr}^
(the last '^' is important)
P.S. Since I can't add any attachments now. I'll try this after 'commit'.
--
Summary: arm-elf-gcc generating wrong code with -O flag at
functions with __attribute__ ((interrupt ("IRQ")))
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: th dot r dot klein at web dot de
GCC host triplet: i386-freebds-elf
GCC target triplet: arm-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25428
[Bug c/25428] arm-elf-gcc generating wrong code with -O flag at functions with __attribute__ ((interrupt ("IRQ")))
--- 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
[Bug fortran/20857] accepts non-variable as actual argument for intent(inout) dummy arg
--- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20857
[Bug c/25428] arm-elf-gcc generating wrong code with -O flag at functions with __attribute__ ((interrupt ("IRQ")))
--- 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.gnu.org/bugzilla/show_bug.cgi?id=25428
[Bug tree-optimization/23619] Missed pre opportunity
--- 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
[Bug c/25428] arm-elf-gcc generating wrong code with -O flag at functions with __attribute__ ((interrupt ("IRQ")))
--- 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://gcc.gnu.org/bugzilla/show_bug.cgi?id=25428
[Bug c/25428] arm-elf-gcc generating wrong code with -O flag at functions with __attribute__ ((interrupt ("IRQ")))
--- 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://gcc.gnu.org/bugzilla/show_bug.cgi?id=25428
[Bug c/25428] arm-elf-gcc generating wrong code with -O flag at functions with __attribute__ ((interrupt ("IRQ")))
--- 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://gcc.gnu.org/bugzilla/show_bug.cgi?id=25428
[Bug c/25428] arm-elf-gcc generating wrong code with -O flag at functions with __attribute__ ((interrupt ("IRQ")))
--- 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
[Bug java/20044] Wrong method call semantics (maybe instanceof/invokespecial)
--- 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 Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20044
[Bug fortran/25391] Module derived type issue
--- 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 type. If the type is available by this route, trans-types(gfc_get_derived_type) uses the existing backend_decl. I will mail you if it does and maybe you would by so good as to OK the patch? Best regards Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25391
[Bug c++/25427] Impossible to create a friend function for a class in a namespace, outside the namespace.
--- 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);
^
GCC's error could be better.
Anyways the way to fix it would to add the following before the namespace S:
namespace S{class A;}
std::ostream &operator<<(std::ostream &os,S::A &a);
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25427
[Bug target/24969] tmpdir-gcc.dg-struct-layout-1/t026 fails execution
--- 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 |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24969
[Bug java/25429] New: can't see private static final int CREATE = 1
[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:
^
src/java/org/jdom/ContentList.java: In class 'C':
src/java/org/jdom/ContentList.java: In method '()':
src/java/org/jdom/ContentList.java:3: error: final field âCONSTâ may not
have
been initialized
src/java/org/jdom/ContentList.java:1: confused by earlier errors, bailing out
class C
{
private static final int CONST = 0;
class I {
public void f () {
switch(0) {
case CONST:
}
}
}
}
--
Summary: can't see private static final int CREATE = 1
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: aph at gcc dot gnu dot org
ReportedBy: aph at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25429
[Bug java/25429] can't see private static final int CREATE = 1
--- 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
[Bug java/25429] can't see private static final int CREATE = 1
--- 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
[Bug java/25429] can't see private static final int CREATE = 1
--- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Known to fail||4.2.0 Last reconfirmed|-00-00 00:00:00 |2005-12-15 16:33:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25429
[Bug c++/25427] Impossible to create a friend function for a class in a namespace, outside the namespace.
--- 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
[Bug c++/25427] Impossible to create a friend function for a class in a namespace, outside the namespace.
--- 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 Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25427
[Bug c++/25427] Impossible to create a friend function for a class in a namespace, outside the namespace.
--- 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 split
the class up like:
namespace S
{
class A {
class B;
methods
};
}
function prototype to friend with;
class S::A::B
{
friend function;
methods;
};
function;
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25427
[Bug libobjc/14382] [libobjc] Calling +initialize on a per category basis
--- 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/14382 * README (+load,+initialize): Fix documentation to reflect intended and implemented semantics for +load and +initialize. Modified: trunk/libobjc/ChangeLog trunk/libobjc/README -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14382
[Bug fortran/25391] Module derived type issue
--- 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
[Bug libobjc/14382] [libobjc] Calling +initialize on a per category basis
--- 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/14382 * README (+load,+initialize): Fix documentation to reflect intended and implemented semantics for +load and +initialize. Modified: branches/gcc-4_0-branch/libobjc/ChangeLog branches/gcc-4_0-branch/libobjc/README -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14382
[Bug fortran/22629] Would like to access "long double" equivalent type as real*16
--- 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 accept real data types and revamping the IO subsystem. I doubt that this will happen in my life time. This PR should be closed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22629
[Bug libobjc/14382] [libobjc] Calling +initialize on a per category basis
--- 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/14382 * README (+load,+initialize): Fix documentation to reflect intended and implemented semantics for +load and +initialize. Modified: branches/gcc-4_1-branch/libobjc/ChangeLog branches/gcc-4_1-branch/libobjc/README -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14382
[Bug rtl-optimization/25432] New: Reload ICE in gen_add2_insn
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])
(symbol_ref:DI ("*.LCTOC1") [0 S8 A64])
as the second argument which doesn't match adddi3's predicate -
reg_or_add_cint_operand.
--
Summary: Reload ICE in gen_add2_insn
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25432
[Bug rtl-optimization/25432] Reload ICE in gen_add2_insn
--- 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
[Bug libobjc/14382] [libobjc] Calling +initialize on a per category basis
--- 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/14382 * README (+load,+initialize): Fix documentation to reflect intended and implemented semantics for +load and +initialize. Modified: branches/gcc-3_4-branch/libobjc/ChangeLog branches/gcc-3_4-branch/libobjc/README -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14382
[Bug target/24969] tmpdir-gcc.dg-struct-layout-1/t026 fails execution
--- 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): Properly adjust offset of bitfield for substructures. Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24969
[Bug fortran/22629] Would like to access "long double" equivalent type as real*16
--- 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 is not outlandish --- there are other compilers that support IEEE's 10 byte type as real*16, introducing 6 bytes of padding. This aligns the data with the cache lines and can increase performance. It is customary in FORTRAN 77 to name data types after the number of bytes that they use. While it is not necessary that GFortran follows this convention, it would simplify porting FORTRAN 77 applications to GFortran, and I would like to see that feature. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22629
[Bug tree-optimization/25433] New: ICE with -ftree-loop-linear
# 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 --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.0-beta20051209 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.0-beta20051209/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.0-beta20051209/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0-beta20051209/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --enable-multilib --disable-libmudflap --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.1.0-beta20051209 (prerelease) # gcc -O1 -ftree-loop-linear texcompress_fxt1.i main/texcompress_fxt1.c: In function 'fxt1_encode': main/texcompress_fxt1.c:1353: internal compiler error: Segmentation fault texcompress_fxt1.i will be attached. -- Summary: ICE with -ftree-loop-linear Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zlynx at acm dot org GCC host triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25433
[Bug tree-optimization/25433] ICE with -ftree-loop-linear
--- 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
[Bug tree-optimization/25433] ICE with -ftree-loop-linear
--- 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 source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25433
[Bug fortran/22629] Would like to access "long double" equivalent type as real*16
--- 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-double is used. C's long double type is mapped to REAL(kind=10) on ia32. You can read the top of trans-type.c to see how kinds are determined and perhaps learn why real*16 will never happen on ia32. > This request is not outlandish --- there are other compilers that > support IEEE's 10 byte type as real*16, introducing 6 bytes of padding. The other compilers have more than 5 unpaid volunteers working full time of said compilers. > It is customary in FORTRAN 77 to name data types after the number of > bytes that they use. "Customary" is not a part of any version of Fortran standard. In fact, REAL*n isn't in any version of the standard. > While it is not necessary that GFortran follows this convention, it > would simplify porting FORTRAN 77 applications to GFortran, and I > would like to see that feature. Porting code involves more than flipping a switch. Assuming REAL*16 means REAL(KIND=10)+6 bytes of padding for all codes that have a REAL*16 is just plain stupid. But, you have the source code and patches to implement the feature are always welcomed. I, however, think you've greatly under estimated the task. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22629
[Bug tree-optimization/25433] ICE with -ftree-loop-linear
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25433
[Bug tree-optimization/23820] ICE in lambda_loopnest_to_gcc_loopnest, at lambda-code.c:1982
--- 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 CC||zlynx at acm dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23820
[Bug libobjc/14382] [libobjc] Calling +initialize on a per category basis
--- 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 |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14382
[Bug libobjc/18573] libobjc abuses posix thread ids
--- 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
[Bug fortran/22629] Would like to access "long double" equivalent type as real*16
--- 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 > 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-double is used. > > C's long double type is mapped to REAL(kind=10) on ia32. I know. > You > can read the top of trans-type.c to see how kinds are determined > and perhaps learn why real*16 will never happen on ia32. That I don't understand. I assume that changing the statement kind = (GET_MODE_PRECISION (mode) + 7) / 8; to something like if (mode == TYPE_MODE(float_mode)) kind = sizeof(float); else if (mode == TYPE_MODE(float_double)) kind = sizeof(double); else if (mode == TYPE_MODE(float_long_double)) kind = sizeof(long double); would do the trick. This obviously changes the intent of the code, which is clearly stated in the comment block above, and it's not up to me to decide whether this should be done. But that change does not seem impossible from a technical point of view. Let me assume for the moment that sizeof(float)==4 and sizeof(double) ==8; most architectures will have this, and if not, one can special- case these non-IEEE platforms. Architectures that don't support real*4 and real*8 will create much Fortran trouble anyway, even if the compiler conforms perfectly to the Fortran standard. The only case in which this new mechanism then fails is if sizeof (double) == sizeof(long double), but long double and double are actually different types. This case can also easily be caught, and one can use a kind different from 8 for the equivalent of long double in this case. >> This request is not outlandish --- there are other compilers that >> support IEEE's 10 byte type as real*16, introducing 6 bytes of >> padding. > > The other compilers have more than 5 unpaid volunteers working > full time of said compilers. Sorry. With "outlandish" I did not mean to imply that someone should implement that; I would never request that. I meant whether the gfortran developers would accept such a patch, which I didn't want to prepare before I know whether there is a chance that it would be accepted. >> It is customary in FORTRAN 77 to name data types after the number of >> bytes that they use. > > "Customary" is not a part of any version of Fortran standard. In > fact, REAL*n isn't in any version of the standard. I know. Nevertheless there exists much code that uses that. This is clearly a case where GFortran has the freedom to choose the kind numbers it assigns to its real types. >> While it is not necessary that GFortran follows this convention, it >> would simplify porting FORTRAN 77 applications to GFortran, and I >> would like to see that feature. > > Porting code involves more than flipping a switch. Assuming > REAL*16 means REAL(KIND=10)+6 bytes of padding for all codes that > have a REAL*16 is just plain stupid. I did not assume that! I would like (I don't assume) to have a 16 byte data type that is called real*16. I only cited the padding because you suggested that real*16 would require software emulation of a new type, which it does not do if one uses padding. > But, you have the source code > and patches to implement the feature are always welcomed. I, however, > think you've greatly under estimated the task. I had somehow assumed that it would be only a matter of changing the kind numbers that are assigned to the real types that gfortran already supports. I assumed that a patch similar to the lines I suggest above would be sufficient. Is there something big that I overlooked? Obviously the suggested change would be improved to ensure to actually use different kind numbers for all supported hardware floating types, and it can also be improved to continue to support real*10 and real*16 at the same time for the same type if that is desired. Thank you for your comments. I do not know much about the internal representation of types in gcc, and your comments seem to indicate that I would encounter a sleeping beast. When I last looked at real*16, there were big problems with the I/O library in gfortran, and I also don't know whether these have been solved in the mean time. I think it just mapped long double to double, which would kind of defeat the purpose of using long double in the first place. -erik -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22629
[Bug other/25028] TImode-to-floating conversions broken
--- 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_SIZE, TF_SIZE): Define. * libgcc2.c (__floatdixf, __floatundixf, __floatditf, __floatunditf): Use #error if type sizes don't match requirements of implementation. (__floatdisf, __floatdidf): Unify. Possibly use XFmode or TFmode as wider floating-point type. Use #error if type sizes don't match requirements of implementation. Avoid overflow in computing Wtype_MAXp1_F * Wtype_MAXp1_F. When special casing conversion, shift one more bit. Cast 1 to DWtype or UDWtype for shifting. (__floatundisf, __floatundidf): Likewise. * config/ia64/hpux.h (XF_SIZE, TF_SIZE): Define. * config/ia64/ia64.c (ia64_init_libfuncs): Use _U_Qfcnvfxt_quad_to_quad and _U_Qfcnvxf_quad_to_quad for TFmode-TImode conversions. * doc/tm.texi (SF_SIZE, DF_SIZE, XF_SIZE, TF_SIZE): Document. testsuite: * gcc.dg/torture/fp-int-convert-timode.c: Only XFAIL for LP64 IA64 HP-UX. Modified: trunk/gcc/ChangeLog trunk/gcc/config/ia64/hpux.h trunk/gcc/config/ia64/ia64.c trunk/gcc/doc/tm.texi trunk/gcc/libgcc2.c trunk/gcc/libgcc2.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25028
[Bug bootstrap/25435] New: stage build no longer works
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 Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25435
[Bug other/1] Test of new GCC GNATS db.
--- 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 in them accidentally looks like a bug number) and commit messages to gcc-cvs and PRs shouldn't include diffs to files anyway; the only diffs sent there should be for changes to revision properties. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added CC|jsm28 at gcc dot gnu dot org| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
[Bug ada/25436] New: Ada bootstrap fail, SEGV in ggc_collect on x86-linux
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../rts -I. -I/home/guerby/work/gcc/version-head/gcc/ada -B../../ -O2 -g -O2 -gnatpg -gnata -I- /home/guerby/work/gcc/version-head/gcc/ada/gprmake.adb ../../xgcc -c -I./ -I../rts -I. -I/home/guerby/work/gcc/version-head/gcc/ada -B../../ -O2 -g -O2 -gnatpg -gnata -I- /home/guerby/work/gcc/version-head/gcc/ada/makegpr.adb raised STORAGE_ERROR : stack overflow (or erroneous memory access) gnatmake: "/home/guerby/work/gcc/version-head/gcc/ada/makegpr.adb" compilation error make[3]: *** [../../gprmake] Error 4 make[3]: Leaving directory `/home/guerby/work/gcc/build/build-head-20051215T203851/stage3-gcc/ada/tools' make[2]: *** [gnattools-native] Error 2 make[2]: Leaving directory `/home/guerby/work/gcc/build/build-head-20051215T203851/gnattools' make[1]: *** [all-gnattools] Error 2 make[1]: Leaving directory `/home/guerby/work/gcc/build/build-head-20051215T203851' make: *** [bootstrap] Error 2 (gdb) r -I./ -I../rts -I. -I/home/guerby/work/gcc/version-head/gcc/ada -I- -quiet -dumpbase makegpr.adb -O2 -O2 -g -gnatpg -gnata -mtune=pentiumpro /home/guerby/work/gcc/version-head/gcc/ada/makegpr.adb -o /tmp/ccK1xuON.s Starting program: /home/guerby/work/gcc/build/build-head-20051215T203851/stage3-gcc/gnat1 -I./ -I../rts -I. -I/home/guerby/work/gcc/version-head/gcc/ada -I- -quiet -dumpbase makegpr.adb -O2 -O2 -g -gnatpg -gnata -mtune=pentiumpro /home/guerby/work/gcc/version-head/gcc/ada/makegpr.adb -o /tmp/ccK1xuON.s Program received signal SIGSEGV, Segmentation fault. gt_ggc_mx_basic_block_def (x_p=0x41cffaa0) at gtype-desc.c:446 446 gt_ggc_m_9tree_node ((*x).stmt_list); (gdb) bt #0 gt_ggc_mx_basic_block_def (x_p=0x41cffaa0) at gtype-desc.c:446 #1 0x08446d39 in gt_ggc_mx_tree_ann_d (x_p=0x41d0223c) at gtype-desc.c:370 #2 0x08068a38 in gt_ggc_mx_lang_tree_node (x_p=0x418fa438) at gtype-ada.h:333 #3 0x08441aaf in gt_ggc_m_P15throw_stmt_node4htab (x_p=0x41cc6280) at gtype-desc.c:1529 #4 0x08446a8c in gt_ggc_mx_function (x_p=0x418d4800) at gtype-desc.c:607 #5 0x080690cc in gt_ggc_mx_lang_tree_node (x_p=0x403dcc80) at gtype-ada.h:279 #6 0x080686c6 in gt_ggc_mx_lang_tree_node (x_p=0x418ff2c0) at gtype-ada.h:166 #7 0x0844198c in gt_ggc_mx_cgraph_varpool_node (x_p=0x41cd0360) at gtype-desc.c:104 #8 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x4198cc18) at gtype-desc.c:105 #9 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x4198cc78) at gtype-desc.c:105 #10 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x41913fa8) at gtype-desc.c:105 #11 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x40216480) at gtype-desc.c:105 #12 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x40210a20) at gtype-desc.c:105 #13 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x40210a50) at gtype-desc.c:105 #14 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x40207a38) at gtype-desc.c:105 #15 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x40207f30) at gtype-desc.c:105 #16 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x40204498) at gtype-desc.c:105 #17 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x401f90a8) at gtype-desc.c:105 #18 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x401f94b0) at gtype-desc.c:105 #19 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x401f94f8) at gtype-desc.c:105 #20 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x40304a98) at gtype-desc.c:105 #21 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x403da690) at gtype-desc.c:105 #22 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x403da828) at gtype-desc.c:105 #23 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x403da840) at gtype-desc.c:105 #24 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x403da870) at gtype-desc.c:105 #25 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x403da960) at gtype-desc.c:105 #26 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x403da990) at gtype-desc.c:105 #27 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x403da9c0) at gtype-desc.c:105 #28 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x403da9d8) at gtype-desc.c:105 #29 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x419c5d20) at gtype-desc.c:105 #30 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x419c5d38) at gtype-desc.c:105 #31 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x419c5d50) at gtype-desc.c:105 #32 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x419c5d68) at gtype-desc.c:105 #33 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x419c5d98) at gtype-desc.c:105 #34 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x419c5db0) at gtype-desc.c:105 #35 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x419c5df8) at gtype-desc.c:105 #36 0x0844199b in gt_ggc_mx_cgraph_varpool_node (x_p=0x41a41228) at gtype-desc.c:105 #37 0
[Bug ada/25436] Ada bootstrap fail, SEGV in ggc_collect on x86-linux
--- 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 = 0x91700d8, dom = {0x0, 0x0}, prev_bb = 0x41acfb90,
next_bb = 0x41cffb90, il = {rtl = 0x41895360}, phi_nodes = 0x0, predictions =
0x0, count = 0, index = 78, loop_depth = 2, frequency = 2396,
flags = 1024}
(gdb) p (tree_opt_pass) 0x8838440
No symbol "tree_opt_pass" in current context.
(gdb) p (tree_opt_pass *) 0x8838440
No symbol "tree_opt_pass" in current context.
(gdb) p (struct tree_opt_pass *) 0x8838440
$9 = (struct tree_opt_pass *) 0x8838440
(gdb) p *$9
$10 = {name = 0x8820855 "sched2", gate = 0x86fd8e0 ,
execute = 0x8701f80 , sub = 0x0, next = 0x88362c0,
static_pass_number = 151, tv_id = 112, properties_required = 264,
properties_provided = 264, properties_destroyed = 0, todo_flags_start = 0,
todo_flags_finish = 3, letter = 82 'R'}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25436
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- 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
[Bug ada/25436] Ada bootstrap fail, SEGV in ggc_collect on x86-linux
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25436
[Bug ada/24994] raised STORAGE_ERROR : stack overflow or erroneous memory access
--- 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 CC||laurent at guerby dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24994
[Bug ada/24994] raised STORAGE_ERROR : stack overflow or erroneous memory access
--- 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 GCC target triplet|hppa*-*-hpux* (32-bit) |hppa*-*-hpux* (32-bit), ||i686-linux-gnu Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24994
[Bug rtl-optimization/25224] [4.1/4.2 Regression] ICE in initialize_original_copy_tables
--- 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-unswitch.c (tree_unswitch_single_loop): Free copy tables. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr25224.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-unswitch.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25224
[Bug java/25429] can't see private static final int CREATE = 1
--- 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_expression_name): Don't generate accessor methods for constant fields. libjava: * testsuite/libjava.compile/rh175833.java: New file. * testsuite/libjava.compile/pr25429.java: New file. Added: trunk/libjava/testsuite/libjava.compile/pr25429.java trunk/libjava/testsuite/libjava.compile/rh175833.java Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/parse.y trunk/libjava/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25429
[Bug java/25429] can't see private static final int CREATE = 1
--- 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
[Bug middle-end/25437] New: gcc-4.0.{1,2} produces bad code for -O2 on OpenSSL RC5 Crypto Test
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 is verified on 0.9.7i
and 0.9.8a on Linux/Mips and Linux/S390. Linux/PPC32, Linux/x86_64,
Linux/i386, and Linux/IA64 appear to be unaffected. Linux/Sparc, Arm, sh and
others were not tested.
The primary testing system/environment was an SGI Octane running a 64bit Linux
kernel on a 32bit userland environment, glibc-2.3.6, binutils-2.16.91.0.2.
There already exists a bug in OpenSSL's bugs database regarding the issue:
http://www.aet.tu-cottbus.de/rt2/Ticket/Display.html?id=1203
(May want a login, use the guest login).
The attached testcase is a trimmed-down version of OpenSSL's RC5 test code used
in the test phase of the build.
--
Summary: gcc-4.0.{1,2} produces bad code for -O2 on OpenSSL RC5
Crypto Test
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kumba at gentoo dot org
GCC build triplet: mips-unknown-linux-gnu
GCC host triplet: mips-unknown-linux-gnu
GCC target triplet: mips-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25437
[Bug rtl-optimization/25432] Reload ICE in gen_add2_insn
-- amodra at bigpond dot net dot au changed: What|Removed |Added CC||amodra at bigpond dot net ||dot au Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-12-16 00:41:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25432
[Bug middle-end/25437] gcc-4.0.{1,2} produces bad code for -O2 on OpenSSL RC5 Crypto Test
--- 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
[Bug middle-end/25437] gcc-4.0.{1,2} produces bad code for -O2 on OpenSSL RC5 Crypto Test
--- 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
[Bug middle-end/25437] gcc-4.0.{1,2} produces bad code for -O2 on OpenSSL RC5 Crypto Test
--- 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
[Bug middle-end/25437] gcc-4.0.{1,2} produces bad code for -O2 on OpenSSL RC5 Crypto Test
--- 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/bugzilla/show_bug.cgi?id=25437
[Bug middle-end/25437] gcc-4.0.{1,2} produces bad code for -O2 on OpenSSL RC5 Crypto Test
--- 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
[Bug middle-end/25437] gcc-4.0.{1,2} produces bad code for -O2 on OpenSSL RC5 Crypto Test
--- 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
[Bug rtl-optimization/25432] Reload ICE in gen_add2_insn
--- 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/f:DI 113 sfp)
(const_int 160 [0xa0]))
(nil)))
in bb 19
(insn 562 560 544 19 (set (reg/f:DI 349)
(reg/f:DI 352)) 341 {*movdi_internal64} (nil)
(nil))
at the ICE, 562 looks like
(gdb) p debug_rtx (insn)
(insn 562 560 544 17 (set (reg/f:DI 59 27 [349])
(plus:DI (reg/f:DI 1 1)
(mem/u/c/i:DI (plus:DI (reg:DI 2 2)
(const:DI (minus:DI (symbol_ref/u:DI ("*.LC1") [flags 0x2])
(symbol_ref:DI ("*.LCTOC1") [0 S8 A64]))) 341
{*movdi_internal64} (nil)
(nil))
so looks like a problem with soft -> hard frame reg elimination. Why is the
offset (only 160) being dumped to memory?
(gdb) p reg_eliminate[1]
$10 = {from = 113, to = 1, initial_offset = 0, can_eliminate = 1,
can_eliminate_previous = 1, offset = 0, previous_offset = 0,
ref_outside_mem = 0, from_rtx = 0x80001e7020, to_rtx = 0x80001e7000}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25432
[Bug java/24698] [4.1/4.2 regression] SIGABRT when trying to read properties files from jars; and CLASSPATH . no longer implied for class specified on the command line
--- 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 MissingResourceException, which is odd because strace clearly shows it looking in the wrong place (.class instead of .properties), but maybe the bundle is indeed found after accessing a nonexistant class file (maybe the lookup order should be changed?)]. A couple of lines later, the line "String n = bundle.getString(name[i]);" triggers the SIGABRT. The code doesn't get past the line, and doesn't enter the MissingResourceException handler either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698
[Bug rtl-optimization/25432] [4.1/4.2 Regression] Reload ICE in gen_add2_insn
-- 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 Summary|Reload ICE in gen_add2_insn |[4.1/4.2 Regression] Reload ||ICE in gen_add2_insn Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25432
[Bug java/24698] [4.1/4.2 regression] SIGABRT when trying to read properties files from jars; and CLASSPATH . no longer implied for class specified on the command line
--- 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; ./crashme triggers the SIGABRT in 21 lines of code. -- bero at arklinux dot org changed: What|Removed |Added Attachment #10460|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698
[Bug java/24698] [4.1/4.2 regression] SIGABRT when trying to read properties files from jars; and CLASSPATH . no longer implied for class specified on the command line
--- 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_bug.cgi?id=24698
[Bug middle-end/25437] gcc-4.0.{1,2} produces bad code for -O2 on OpenSSL RC5 Crypto Test
--- 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
[Bug rtl-optimization/25432] [4.1/4.2 Regression] Reload ICE in gen_add2_insn
--- 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_insn, which calls
recog_memoized, which used the old INSN_CODE. Thus find_reloads is using
invalid recog_data. No wonder reload is confused.
There is even code in eliminate_regs_in_insn to re-recognized the insn but it
is ineffective.
{
int new_icode = recog (PATTERN (insn), insn, 0);
if (new_icode < 0)
INSN_CODE (insn) = icode;
}
I think this should be
{
int new_icode = recog (PATTERN (insn), insn, 0);
if (new_icode >= 0)
INSN_CODE (insn) = new_icode;
}
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
Severity|major |normal
Target Milestone|4.1.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25432
[Bug rtl-optimization/25432] [4.1/4.2 Regression] Reload ICE in gen_add2_insn
--- 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 AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|NEW |ASSIGNED Last reconfirmed|2005-12-16 00:41:08 |2005-12-16 02:40:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25432
[Bug rtl-optimization/25432] [4.1/4.2 Regression] Reload ICE in gen_add2_insn
-- amodra at bigpond dot net dot au changed: What|Removed |Added Severity|normal |major Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25432
[Bug objc/25360] Complex types are not encoded
--- 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 URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||12/msg01234.html Keywords||patch, wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25360
[Bug ada/24994] raised STORAGE_ERROR : stack overflow or erroneous memory access
--- 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
[Bug tree-optimization/23838] [4.1/4.2 Regression] infinite loop in dse
--- 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 > --- > I am going to say this is 4.1 regression as it worked in 4.0.0 when removing > the -fno-tree-copy-prop option but fails on the mainline and 4.1 branche with > it. Somehow or another someone could come up with a testcase which fails also > without any options which turn off optimizations (it is just harder to come up > with one). I've checked in the same fix from the 4.1 branch into the mainline sources. I haven't found a way to trip the bug in the mainline, but the code is clearly wrong by inspection, so I went ahead and fixed it. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23838
[Bug tree-optimization/23838] [4.1/4.2 Regression] infinite loop in dse
--- 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 |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23838
[Bug bootstrap/25438] New: make: *** No rule to make target `bubblestrap'. Stop.
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: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: christian dot joensson at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25438
