[Bug target/40657] allocate local variables with fewer instructions
--- Comment #5 from carrot at google dot com 2009-07-07 06:44 --- Could we do the optimization in function thumb1_expand_prologue? If we find this opportunity in function thumb1_expand_prologue, we can remove the sp manipulations from prologue and epilogue. We also should add extra registers to push/pop operands. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40657
[Bug middle-end/40669] New: [4.3/4.4/4.5 Regression] ICE in gimple_assign_set_rhs1 from eliminate_tail_call
double _Complex
test (int d, int t, double *x, double *y, double *z, int n,
double _Complex (*fnp) (double))
{
int m = n / 2;
double min = y[t], max = z[t], med = x[m * d + t];
double _Complex result = 0.0;
if (n == 0)
return 0.0;
if (min med)
result += test (d, (t + 1) % d, x + (m + 1) * d, y, z, n - m - 1, fnp);
else if (max med)
result += test (d, (t + 1) % d, x, y, z, m, fnp);
else
{
result += fnp (y[0] + x[m]);
result += test (d, (t + 1) % d, x + (m + 1) * d, y, z, n - m - 1, fnp);
}
return result;
}
ICEs at -O2 -ffast-math on x86_64-linux, in 4.4/4.5 with:
x.i: In function 'test':
x.i:22:1: internal compiler error: in gimple_assign_set_rhs1, at gimple.h:1683
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
and in 4.3 with:
x.i: In function 'test':
x.i:4: internal compiler error: in set_ssa_val_to, at tree-ssa-sccvn.c:1071
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Compiles just fine with 4.1 and 4.2.
--
Summary: [4.3/4.4/4.5 Regression] ICE in gimple_assign_set_rhs1
from eliminate_tail_call
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: jakub at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40669
[Bug middle-end/40669] [4.3/4.4/4.5 Regression] ICE in gimple_assign_set_rhs1 from eliminate_tail_call
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40669
[Bug regression/40667] Performance regression: stack frames are generated even with -fomit-frame-pointer
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-07 09:07 --- Why do you limit your stack boundary artificially? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40667
[Bug target/40134] symbols not resolved when building shared libraries (link with -lgcc_s -lgcc?)
--- Comment #2 from debian-gcc at lists dot debian dot org 2009-07-07 09:08 --- proposed patch at http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00322.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40134
[Bug middle-end/40669] [4.3/4.4/4.5 Regression] ICE in gimple_assign_set_rhs1 from eliminate_tail_call
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-07 09:15 --- With my local 4.3 copy it prints t.i: In function test: t.i:22: error: PHI def is not a GIMPLE value add_acc.0_64 = PHI COMPLEX_EXPR 0.0, 0.0(0), add_acc.0_60(7), add_acc.0_64(6), add_acc.0_64(4) COMPLEX_EXPR 0.0, 0.0; t.i:22: error: invalid operand to binary operator add_acc.0_64 t.i:22: error: invalid operand to binary operator add_acc.0_64 t.i:22: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. which is because COMPLEX_EXPR 0.0, 0.0 should be COMPLEX_CST 0.0, 0.0 to be valid. Didn't I fix that lately -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-07 09:15:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40669
[Bug middle-end/40669] [4.3/4.4/4.5 Regression] ICE in gimple_assign_set_rhs1 from eliminate_tail_call
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-07 09:23 --- Yeah, PR40328. Then we are left with t.i: In function test: t.i:22: error: invalid operand to binary operator add_acc.0_64 t.i:22: error: invalid operand to binary operator add_acc.0_64 t.i:22: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. which means the decl doesn't have DECL_GIMPLE_REG_P set. I'll take care of 4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40669
[Bug target/40670] New: Load floating point constant 0 directly
Compile following function with options -Os -mthumb -march=armv5te
float return_zero()
{
return 0;
}
Gcc generates:
ldr r0, .L2
bx lr
.L3:
.align 2
.L2:
.word 0
Floating point 0 is also integer 0. So the function body can be simplified as
mov r0, 0
bx lr
Now we can remove the memory load and constant pool. The result code is smaller
and faster.
The memory load and constant pool is expanded in pass machine_reorg.
--
Summary: Load floating point constant 0 directly
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40670
[Bug target/40670] Load floating point constant 0 directly
--- Comment #1 from carrot at google dot com 2009-07-07 09:38 --- Created an attachment (id=18149) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18149action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40670
[Bug middle-end/40669] [4.3/4.4/4.5 Regression] ICE in gimple_assign_set_rhs1 from eliminate_tail_call
--- Comment #3 from jakub at gcc dot gnu dot org 2009-07-07 09:46 --- Created an attachment (id=18150) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18150action=view) gcc45-pr40669.patch Patch I'm going to bootstrap/regtest. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40669
[Bug middle-end/40669] [4.3/4.4/4.5 Regression] ICE in gimple_assign_set_rhs1 from eliminate_tail_call
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40669
[Bug middle-end/40669] [4.3/4.4/4.5 Regression] ICE in gimple_assign_set_rhs1 from eliminate_tail_call
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-07-07 10:01 --- 4.4 will need a backport of PR40328 as well. Your attached patch is ok. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||40328 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40669
[Bug c/40602] crti.o: No such file
--- Comment #2 from mikpe at it dot uu dot se 2009-07-07 10:18 --- (In reply to comment #1) Now I'm trying to compile gcc-4.4.0 configured as follows: ../gcc-4.4.0/configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --enable-languages=c --disable-multilib make fails with the same error message. crti.o is located at /usr/lib64/crti.o this is the output of cat LOG | grep crti.o | grep ENOENT | grep lib64 after having issued strace -f make 2 LOG: [pid 32046] access(/sources/gcc-build/gcc/../lib/gcc/x86_64-pc-linux-gnu/4.4.0/../../../../x86_64-pc-linux-gnu/lib/../lib64/crti.o, R_OK) = -1 ENOENT (No such file or directory) [pid 32046] access(/sources/gcc-build/gcc/../lib/gcc/x86_64-pc-linux-gnu/4.4.0/../../../../lib64/crti.o, R_OK) = -1 ENOENT (No such file or directory) [pid 32046] access(/lib/../lib64/crti.o, R_OK) = -1 ENOENT (No such file or directory) [pid 32046] access(/usr/lib/../lib64/crti.o, R_OK) = -1 ENOENT (No such file or directory) As you can see it tries to access /usr/lib64/crti.o, but inexplicably it can't find it. Check that /usr/lib/ exists. If it doesn't then /usr/lib/../lib64/ will ENOENT rather than resolve to /usr/lib64/. Also check that /usr/lib isn't a symlink, in which case /usr/lib/.. may not be /usr . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40602
[Bug regression/40665] dereferencing type-punned pointer warnings cannot be disabled
--- Comment #6 from manu at gcc dot gnu dot org 2009-07-07 10:25 --- (In reply to comment #5) Thus code is undefined you have an acess of a char array as a struct. Yes you are only taking the address of an element but it is still considered an acess by the standards. I see that users repeatedly fall for this. Could we detect what type is accessed as what and provide an informative note? Something like: warning: dereferencing type-punned pointer might break strict-aliasing rules note: accessing 'char *' as 'structure *' is undefined Andrew, do you think this would be difficult to implement? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665
[Bug c/40602] crti.o: No such file
--- Comment #3 from pluto at agmk dot net 2009-07-07 10:33 --- sounds like PR36485. -- pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40602
[Bug c/40602] crti.o: No such file
--- Comment #4 from booleandomain at gmail dot com 2009-07-07 10:39 --- I created a symlink from /usr/lib to /usr/lib64 and now gcc is built fine! Thanks a lot! (Probably this bug is going to be marked as invalid...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40602
[Bug debug/40666] [4.4.1 Regression] Ada rts build failure
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-07-07 10:45 --- Did this work with 4.4.0? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-07 10:45:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40666
[Bug debug/40666] [4.4.1 Regression] Ada rts build failure
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-07-07 10:45 --- Fixing. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-07-07 10:45:08 |2009-07-07 10:45:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40666
[Bug debug/40666] [4.4.1 regression] Ada tools build failure
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.4.1 Regression] Ada rts |[4.4.1 regression] Ada tools |build failure |build failure Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40666
[Bug target/40668] 64-bit sparc miscompiles memcpy of argument inside switch
--- Comment #3 from mikpe at it dot uu dot se 2009-07-07 11:35 --- Confirmed, with gcc-4.3-20090705 it works, with gcc-4.4-20090630 it fails. Compiling with -S and comparing the .s files it looks like 4.4 completely mis-schedules the code for put_uint32: put_uint32: .register %g2, #scratch .register %g3, #scratch ldub[%sp+2175], %g1 ldub[%sp+2176], %g3 ldub[%sp+2177], %g2 ldub[%sp+2178], %g4 st %o0, [%sp+2175] stb %g4, [%o1+3] stb %g1, [%o1] stb %g3, [%o1+1] jmp %o7+8 stb%g2, [%o1+2] Notice how the store of %o0 to the four bytes at %sp+2175 comes after the corresponding byte loads, so %g1 to %g4 are loaded with garbage, likely zeroes. In contrast, gcc-4.3 generates the store before the loads: put_uint32: .register %g2, #scratch .register %g3, #scratch st %o0, [%sp+2175] ldub[%sp+2176], %g3 ldub[%sp+2177], %g4 ldub[%sp+2178], %g2 ldub[%sp+2175], %g1 stb %g2, [%o1+3] stb %g1, [%o1] stb %g3, [%o1+1] jmp %o7+8 stb%g4, [%o1+2] -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40668
[Bug middle-end/40669] [4.3/4.4/4.5 Regression] ICE in gimple_assign_set_rhs1 from eliminate_tail_call
--- Comment #5 from jakub at gcc dot gnu dot org 2009-07-07 12:18 --- Subject: Bug 40669 Author: jakub Date: Tue Jul 7 12:18:38 2009 New Revision: 149319 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149319 Log: PR middle-end/40669 * tree-tailcall.c (adjust_return_value_with_ops, create_tailcall_accumulator): Set DECL_GIMPLE_REG_P on the temporary if it has complex or vector type. * gcc.dg/pr40669.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr40669.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-tailcall.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40669
[Bug testsuite/40671] New: [4.5 Regression] internal compiler error: in extract_insn, at recog.c:2089 on powerpc
Probably due to revision 148869 the following tests fail on powerpc-apple-darwin9 with -m32 FAIL: gcc.dg/vect/vect-82_64.c (internal compiler error) FAIL: gcc.dg/vect/vect-83_64.c (internal compiler error) FAIL: gcc.target/powerpc/darwin-misaligned.c (internal compiler error) FAIL: gcc.target/powerpc/macho-lo-sum.c (internal compiler error) FAIL: gcc.target/powerpc/ppc64-double-1.c (internal compiler error) FAIL: gcc.target/powerpc/rs6000-fpint-2.c (internal compiler error) See for instance http://gcc.gnu.org/ml/gcc-regression/2009-06/msg00188.html . With -m64, only ppc64-double-1.c fails. The failures are: [karma] f90/bug% gcc45 -O3 -mpowerpc64 /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/powerpc/darwin-misaligned.c /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/powerpc/darwin-misaligned.c: In function 'main': /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/powerpc/darwin-misaligned.c:25:1: error: unrecognizable insn: (insn 5 4 6 3 /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/powerpc/darwin-misaligned.c:22 (set:DI (reg:DI 121) (plus:DI (reg:DI 31 r31) (high:DI (const:DI (unspec:DI [ (symbol_ref:DI (L_ms$non_lazy_ptr) [flags 0x400] var_decl 0x4150ad20 ms) ] 50) -1 (nil)) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/powerpc/darwin-misaligned.c:25:1: internal compiler error: in extract_insn, at recog.c:2089 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. [karma] f90/bug% gcc45 -O3 -mpowerpc64 /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-82_64.c In file included from /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-82_64.c:6:0: /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/tree-vect.h: In function 'sig_ill_handler': /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/tree-vect.h:11:1: error: unrecognizable insn: (insn/f 14 13 15 2 /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/tree-vect.h:9 (parallel [ (set (mem/c:SI (plus:SI (reg/f:DI 1 r1) (const_int -64 [0xffc0])) [3 S4 A8]) (reg/f:DI 1 r1)) (set (reg/f:DI 1 r1) (plus:SI (reg/f:DI 1 r1) (const_int -64 [0xffc0]))) ]) -1 (expr_list:REG_FRAME_RELATED_EXPR (set (reg/f:DI 1 r1) (plus:DI (reg/f:DI 1 r1) (const_int -64 [0xffc0]))) (nil))) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/tree-vect.h:11:1: internal compiler error: in extract_insn, at recog.c:2089 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. [karma] f90/bug% gcc45 -O3 -mpowerpc64 /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-83_64.c In file included from /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-83_64.c:6:0: /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/tree-vect.h: In function 'sig_ill_handler': /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/tree-vect.h:11:1: error: unrecognizable insn: (insn/f 14 13 15 2 /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/tree-vect.h:9 (parallel [ (set (mem/c:SI (plus:SI (reg/f:DI 1 r1) (const_int -64 [0xffc0])) [3 S4 A8]) (reg/f:DI 1 r1)) (set (reg/f:DI 1 r1) (plus:SI (reg/f:DI 1 r1) (const_int -64 [0xffc0]))) ]) -1 (expr_list:REG_FRAME_RELATED_EXPR (set (reg/f:DI 1 r1) (plus:DI (reg/f:DI 1 r1) (const_int -64 [0xffc0]))) (nil))) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/tree-vect.h:11:1: internal compiler error: in extract_insn, at recog.c:2089 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. [karma] f90/bug% gcc45 -O3 -mpowerpc64 /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/powerpc/darwin-misaligned.c /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/powerpc/darwin-misaligned.c: In function 'main': /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/powerpc/darwin-misaligned.c:25:1: error: unrecognizable insn: (insn 5 4 6 3 /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/powerpc/darwin-misaligned.c:22 (set:DI (reg:DI 121) (plus:DI (reg:DI 31 r31) (high:DI (const:DI (unspec:DI [ (symbol_ref:DI (L_ms$non_lazy_ptr) [flags 0x400] var_decl 0x4150ad20 ms) ] 50) -1 (nil)) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/powerpc/darwin-misaligned.c:25:1: internal compiler error: in extract_insn, at recog.c:2089 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. [karma] f90/bug% gcc45 -O3 -mpowerpc64
[Bug middle-end/40328] [4.5 Regression] internal compiler error: in set_ssa_val_to, at tree-ssa-sccvn.c:1811
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-07-07 12:44 --- Subject: Bug 40328 Author: rguenth Date: Tue Jul 7 12:44:32 2009 New Revision: 149321 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149321 Log: 2009-07-07 Richard Guenther rguent...@suse.de PR middle-end/40328 PR tree-optimization/40669 * tree-tailcall.c (adjust_accumulator_values): Properly set DECL_GIMPLE_REG_P. (adjust_return_value): Likewise. (tree_optimize_tail_calls_1): Likewise. * fold-const.c (fold_convert): Fold the built COMPLEX_EXPR. * gcc.dg/pr40669.c: New testcase. * gcc.dg/torture/pr40328.c: Likewise. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr40669.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr40328.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/fold-const.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/tree-tailcall.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40328
[Bug middle-end/40669] [4.3/4.4/4.5 Regression] ICE in gimple_assign_set_rhs1 from eliminate_tail_call
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-07-07 12:44 --- Subject: Bug 40669 Author: rguenth Date: Tue Jul 7 12:44:32 2009 New Revision: 149321 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149321 Log: 2009-07-07 Richard Guenther rguent...@suse.de PR middle-end/40328 PR tree-optimization/40669 * tree-tailcall.c (adjust_accumulator_values): Properly set DECL_GIMPLE_REG_P. (adjust_return_value): Likewise. (tree_optimize_tail_calls_1): Likewise. * fold-const.c (fold_convert): Fold the built COMPLEX_EXPR. * gcc.dg/pr40669.c: New testcase. * gcc.dg/torture/pr40328.c: Likewise. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr40669.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr40328.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/fold-const.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/tree-tailcall.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40669
[Bug fortran/40551] Wrong code due to missing copy-in/copy-out stried array to assumed-size dummy
--- Comment #12 from burnus at gcc dot gnu dot org 2009-07-07 12:47 --- You were right - contiguous does need initializing. Not for this case but some of the other uses that I referred to. Paul, what is the plan? You had a 4.4 and 4.5 check in, contiguous is not initialized in 4.5. Do you want to fix that? Or can this PR be closed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40551
[Bug debug/40666] [4.4.1 regression] Ada tools build failure
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-07 13:35 --- Subject: Re: [4.4.1 Regression] Ada rts build failure Did this work with 4.4.0? Yes. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40666
[Bug middle-end/40328] [4.5 Regression] internal compiler error: in set_ssa_val_to, at tree-ssa-sccvn.c:1811
--- Comment #10 from jakub at gcc dot gnu dot org 2009-07-07 14:07 --- Subject: Bug 40328 Author: jakub Date: Tue Jul 7 14:07:19 2009 New Revision: 149329 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149329 Log: PR middle-end/40669 * tree-tailcall.c (adjust_return_value_with_ops, create_tailcall_accumulator): Set DECL_GIMPLE_REG_P on the temporary if it has complex or vector type. Backport from mainline: 2009-06-03 Richard Guenther rguent...@suse.de PR middle-end/40328 * fold-const.c (fold_convert): Fold the build COMPLEX_EXPR. * gcc.dg/pr40669.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr40669.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/fold-const.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/tree-tailcall.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40328
[Bug middle-end/40669] [4.3/4.4/4.5 Regression] ICE in gimple_assign_set_rhs1 from eliminate_tail_call
--- Comment #7 from jakub at gcc dot gnu dot org 2009-07-07 14:07 --- Subject: Bug 40669 Author: jakub Date: Tue Jul 7 14:07:19 2009 New Revision: 149329 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149329 Log: PR middle-end/40669 * tree-tailcall.c (adjust_return_value_with_ops, create_tailcall_accumulator): Set DECL_GIMPLE_REG_P on the temporary if it has complex or vector type. Backport from mainline: 2009-06-03 Richard Guenther rguent...@suse.de PR middle-end/40328 * fold-const.c (fold_convert): Fold the build COMPLEX_EXPR. * gcc.dg/pr40669.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr40669.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/fold-const.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/tree-tailcall.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40669
[Bug middle-end/40669] [4.3/4.4/4.5 Regression] ICE in gimple_assign_set_rhs1 from eliminate_tail_call
--- Comment #8 from jakub at gcc dot gnu dot org 2009-07-07 14:09 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|4.3.4 4.5.0 |4.3.4 4.4.1 4.5.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40669
[Bug middle-end/40669] [4.3/4.4/4.5 Regression] ICE in gimple_assign_set_rhs1 from eliminate_tail_call
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.3 4.4.0 Known to work||4.3.4 4.5.0 Target Milestone|4.4.1 |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40669
[Bug regression/40667] Performance regression: stack frames are generated even with -fomit-frame-pointer
--- Comment #2 from hjl dot tools at gmail dot com 2009-07-07 14:41 --- I think it is related to PR 39137. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40667
[Bug target/40672] New: constant address loads moved into loop unnecessarily
The testcase below:
typedef unsigned char uint8_t;
#define UART3_LSR (*(volatile uint8_t *)(0x4902+20))
#define UART3_RBR (*(volatile uint8_t *)(0x4902+0))
int IsSerialBufferFull(void)
{
return (UART3_LSR 0x20) == 0;
}
void SendSerialByte(uint8_t byte)
{
while (IsSerialBufferFull())
;
UART3_RBR = byte;
}
when compiled with arm-none-eabi-gcc -O2 results in suboptimal code for
SendSerialByte:
SendSerialByte:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov r3, #1224736768
add r3, r3, #131072
.L3:
ldrbr2, [r3, #20] @ zero_extendqisi2
tst r2, #32
mov r2, #1224736768
add r2, r2, #131072
beq .L3
strbr0, [r2, #0]
bx lr
.size SendSerialByte, .-SendSerialByte
The load of the constant for UART3_RBR (mov r2/add r2) should not be moved into
the loop, since it's not needed until after the loop. Furthermore, the
necessary value is already available in r3.
The same problem doesn't happen on other platforms, e.g. mips-sde-elf gives:
andi$4,$4,0x00ff
li $2,1224867840 # 0x4902
.L6:
lbu $3,20($2)
andi$3,$3,0x20
beq $3,$0,.L6
nop
sb $4,0($2)
j $31
nop
or powerpc-eabi:
lis 9,0x4902
ori 9,9,20
.L4:
lbz 0,0(9)
andi. 11,0,32
beq+ 0,.L4
lis 9,0x4902
stb 3,0(9)
blr
(which is not quite perfect, but better than the arm-none-eabi code...).
--
Summary: constant address loads moved into loop unnecessarily
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: froydnj at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40672
[Bug target/40672] constant address loads moved into loop unnecessarily
--- Comment #1 from drow at gcc dot gnu dot org 2009-07-07 15:03 --- It looks, roughly speaking, like the two nearby addresses are initially commonized. In the process, the use after the loop ends up sharing a REG with the use in the loop. Then the use in the loop is changed to use a new copy, and the initialization in the loop feeds the out-of-loop copy. And the use in the loop gets materialized above the loop as it should. In a quick look I didn't work out which RTL pass is at fault. -- drow at gcc dot gnu dot org changed: What|Removed |Added CC||drow at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40672
[Bug fortran/40551] Wrong code due to missing copy-in/copy-out stried array to assumed-size dummy
--- Comment #13 from burnus at gcc dot gnu dot org 2009-07-07 15:27 --- (In reply to comment #12) You were right - contiguous does need initializing. Not for this case but some of the other uses that I referred to. Paul, what is the plan? You had a 4.4 and 4.5 check in, contiguous is not initialized in 4.5. Do you want to fix that? I somehow missed that it was checked in as part of PR 40646, http://gcc.gnu.org/viewcvs?view=revrevision=149262. Thus: I think this PR be closed, can it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40551
[Bug target/40648] misaligned store vectorizer patch introduced 10% runtime regression on Polyhedron test_fpu
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-07-07 15:47 --- The issue is likely the sequence load upper half of cache line 1 load lower half of cache line 2 store upper half of cache line 1 store lower half of cache line 2 --- load upper half of cache line 2--- load lower half of cache line 3 ... where the marked lines probably cause internal delays. Not using unaligned stores for this kind of data dependence or peeling for alignment will probably help here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40648
[Bug fortran/40673] New: Lapack-3.2.1 testsuite fails with illegal instruction
Building lapack-3.2.1 results in a testsuite routine that fails with: Testing DOUBLE PRECISION LAPACK linear equation routines ./xlintstd dtest.in dtest.out 21 /bin/sh: line 1: 21385 Illegal instruction (core dumped) ./xlintstd dtest.in dtest.out 21 make[1]: *** [dtest.out] Error 132 I've tried several different optimization combinations, all giving the same result: FORTRAN = gfortran -fimplicit-none #OPTS = -O3 -march=pentium4 -msse2 -mfpmath=sse -funroll-loops -fomit-frame-pointer -floop-interchange -floop-strip-mine -floop-block -Wunused OPTS = -O3 -march=native -funroll-loops -fomit-frame-pointer -floop-interchange -floop-strip-mine -floop-block -Wunused I've also dropped the -floop-interchange -floop-strip-mine -floop-block flags and played with -march (native vs pentium4). I get the same result -- Summary: Lapack-3.2.1 testsuite fails with illegal instruction Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ronis at ronispc dot chem dot mcgill dot ca GCC build triplet: i686-linux-gnu GCC host triplet: i686-linux-gnu GCC target triplet: i686-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40673
[Bug target/40672] constant address loads moved into loop unnecessarily
--- Comment #2 from ramana at gcc dot gnu dot org 2009-07-07 16:07 --- confirmed with trunk revision 149279. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-07 16:07:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40672
[Bug fortran/40673] Lapack-3.2.1 testsuite fails with illegal instruction
-- kargl at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40673
[Bug target/40668] 64-bit sparc miscompiles memcpy of argument inside switch
--- Comment #4 from mikpe at it dot uu dot se 2009-07-07 16:28 --- A reghunt identified Jakub's (added to cc: list) r142481 (PR38367 fix) as the source of this regression. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40668
[Bug regression/40665] dereferencing type-punned pointer warnings cannot be disabled
--- Comment #7 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-07 16:31 ---
extern int c;
int a(void)
{
return *(short *)(void *)c;
}
This is a very bad example of a false positive as you are acessing an
int as a short; that is undefined. I will look at your code later on,
my laptop for home is currently broken.
Whether it is a false positive or not depends on the context.
For example, if I call function a() from function b():
int b(void)
{
c = 0x12345678;
__asm__ volatile (:::memory);
return a();
}
the code is valid and the function b() must return a fixed value depending on
the endianity of the machine. That __asm__ statement works as a barrier that
prevents the compiler from reordering two accesses to c.
So I am not against the warning. The warning is good. The problem is that there
is no way to shut up the warning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665
[Bug regression/40667] Performance regression: stack frames are generated even with -fomit-frame-pointer
--- Comment #3 from mikulas at artax dot karlin dot mff dot cuni dot cz 2009-07-07 16:48 --- Why do you limit your stack boundary artificially? Because if I don't use FP code there is no point in aligning the stack. Aligning the stack wastes stack space and code size and doesn't improve performance of integer code in any way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40667
[Bug regression/40665] dereferencing type-punned pointer warnings cannot be disabled
--- Comment #9 from pinskia at gcc dot gnu dot org 2009-07-07 16:54 --- So you say that converting the char * pointer to struct * pointer is understood as accessing the stored value by the standard? No. Let's look at the code: char buffer[512]; (void *)((struct structure *)(void *)buffer)-x You are accessing a character array via a struct structure and then taking the address. This why it is undefined. Even though it does not look like an access in the assembly as it is a-b is an addition, it is an access according to the C/C++ standard. Also aliasing is not transitive, that is you can access anything via a character type but you cannot access a character by everything (only character types themselves). the code is valid and the function b() must return a fixed value depending on the endianity of the machine. That __asm__ statement works as a barrier that prevents the compiler from reordering two accesses to c. Actually even with the memory barrier is still undefined according to the C/C++ standards, it does not mean we won't do what you expect but it means we don't have to do what you expect it to do. This is why we warn about it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665
[Bug regression/40665] dereferencing type-punned pointer warnings cannot be disabled
--- Comment #8 from mikulas at artax dot karlin dot mff dot cuni dot cz 2009-07-07 16:45 --- Thus code is undefined you have an acess of a char array as a struct. Yes you are only taking the address of an element but it is still considered an acess by the standards. Why is it undefined? An object shall have its store value accessed only by an lvalue that has one of the following types ... * a character type So you say that converting the char * pointer to struct * pointer is understood as accessing the stored value by the standard? The only possible problem could be some hypothetical computer that cannot hold misaligned pointers to structs (common computers allow unaligned pointers and trap only on dereferencing unaligned pointers, not on generating them). But once I know that I have a computer that allows unaligned pointers to structs, there should be a method how to shut the warning up (with (void *) cast). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665
[Bug target/40673] Lapack-3.2.1 testsuite fails with illegal instruction
--- Comment #1 from kargl at gcc dot gnu dot org 2009-07-07 17:28 --- What happens if you compile with only '-O -pipe' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40673
[Bug c++/40674] New: [LTO] 27_io/basic_filebuf/imbue/char/13171-2.cc hangs
On LTO branh, as of revision 149328 27_io/basic_filebuf/imbue/char/13171-2.cc hangs on Linux/ia64. -- Summary: [LTO] 27_io/basic_filebuf/imbue/char/13171-2.cc hangs Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com GCC target triplet: ia64-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40674
[Bug c++/40674] [LTO] 27_io/basic_filebuf/imbue/char/13171-2.cc hangs
--- Comment #1 from hjl dot tools at gmail dot com 2009-07-07 17:31 --- 27_io/basic_filebuf/imbue/wchar_t/14975-2.cc also hangs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40674
[Bug target/40673] Lapack-3.2.1 testsuite fails with illegal instruction
--- Comment #2 from ubizjak at gmail dot com 2009-07-07 17:32 --- Please add (minimized) testcase and all other info, as explained in [1]. Also, please post /proc/cpuid. [1] http://gcc.gnu.org/bugs.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40673
[Bug c++/40639] Cannot parse dependent type for enum-base in C++0x
--- Comment #2 from jason at gcc dot gnu dot org 2009-07-07 17:55 --- Subject: Bug 40639 Author: jason Date: Tue Jul 7 17:55:26 2009 New Revision: 149341 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149341 Log: PR c++/37816 * decl.c (build_enumerator): Don't add enumerators for a scoped enum to the enclosing class. PR c++/40639 * decl.c (start_enum): Allow dependent underlying type. PR c++/40633 * decl.c (finish_enum): Finish scope even in a template. Added: trunk/gcc/testsuite/g++.dg/cpp0x/enum4.C trunk/gcc/testsuite/g++.dg/cpp0x/enum5.C trunk/gcc/testsuite/g++.dg/cpp0x/enum6.C trunk/gcc/testsuite/g++.dg/cpp0x/enum7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40639
[Bug c++/40633] [c++0x] ICE with scoped enum inside a template
--- Comment #1 from jason at gcc dot gnu dot org 2009-07-07 17:55 --- Subject: Bug 40633 Author: jason Date: Tue Jul 7 17:55:26 2009 New Revision: 149341 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149341 Log: PR c++/37816 * decl.c (build_enumerator): Don't add enumerators for a scoped enum to the enclosing class. PR c++/40639 * decl.c (start_enum): Allow dependent underlying type. PR c++/40633 * decl.c (finish_enum): Finish scope even in a template. Added: trunk/gcc/testsuite/g++.dg/cpp0x/enum4.C trunk/gcc/testsuite/g++.dg/cpp0x/enum5.C trunk/gcc/testsuite/g++.dg/cpp0x/enum6.C trunk/gcc/testsuite/g++.dg/cpp0x/enum7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40633
[Bug c++/37816] [c++0x] Invalid handling of scoped enums defined at class scope
--- Comment #2 from jason at gcc dot gnu dot org 2009-07-07 17:55 --- Subject: Bug 37816 Author: jason Date: Tue Jul 7 17:55:26 2009 New Revision: 149341 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149341 Log: PR c++/37816 * decl.c (build_enumerator): Don't add enumerators for a scoped enum to the enclosing class. PR c++/40639 * decl.c (start_enum): Allow dependent underlying type. PR c++/40633 * decl.c (finish_enum): Finish scope even in a template. Added: trunk/gcc/testsuite/g++.dg/cpp0x/enum4.C trunk/gcc/testsuite/g++.dg/cpp0x/enum5.C trunk/gcc/testsuite/g++.dg/cpp0x/enum6.C trunk/gcc/testsuite/g++.dg/cpp0x/enum7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37816
[Bug regression/40665] dereferencing type-punned pointer warnings cannot be disabled
--- Comment #10 from mikulas at artax dot karlin dot mff dot cuni dot cz 2009-07-07 18:07 --- So you mean that that -x operator is invalid and break the standard? Anyway the standard means if you write your code according to the standard = the code will run correctly, but the inverse implication doesn't apply. It is sometimes required to break the C standard. For example, you write unsigned char *framebuffer = vga_getgraphmem(); and now you want to access the framebuffer. According to the standard, you could only do it by bytes. But that means one bus cycle to the videocard for every byte transfered. So people understand that common processors allow aligned accesses to 2, 4 or 8 bytes and that common videocards have their framebuffer base address aligned on same larger boundary --- and they simply cast the pointer to u_int32_t or u_int64_t and access the videoram faster. Each time you watch some video, remember those undefined memory accesses that are hapenning for you to get faster performance :) Another example --- the C standard says how it's not allowed to even produce a pointer that points before the allocated array or more than one entry after the last entry of the array and how it's not allowed to subtract two pointers from different arrays. It is perfectly rational --- unless you are writing the memory allocator itself! Then you inevitably must do some operations that are considered undefined by the standard. Regarding that int * to short * cast --- obviously, the code may run on some computer that has tagged memory and traps if access with invalid type is done. But common computers don't have tagged memory and the programmer should be allowed to do such casts if he understands the implications (for example, if its done only in arch-specific part of an operating system, it is perfectly legal). So there should be a method to silence the warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665
[Bug regression/40665] dereferencing type-punned pointer warnings cannot be disabled
--- Comment #11 from pinskia at gcc dot gnu dot org 2009-07-07 18:18 --- (In reply to comment #10) For example, you write unsigned char *framebuffer = vga_getgraphmem(); and now you want to access the framebuffer. According to the standard, you could only do it by bytes. But that means one bus cycle to the videocard for every byte transfered. So people understand that common processors allow aligned accesses to 2, 4 or 8 bytes and that common videocards have their framebuffer base address aligned on same larger boundary --- and they simply cast the pointer to u_int32_t or u_int64_t and access the videoram faster. Each time you watch some video, remember those undefined memory accesses that are hapenning for you to get faster performance :) Not fully, you missed part of the standard that takes about the effective type. Basically if there is no declared type for an object, the effective type is the type which is used for storing and then only that can be read back with that type or character type or the other cases the standard mentions. The effective type changes when another store happens. In both of original cases in this bug report, there is a declared type which is also the effective type. And it is not about the cast between the pointer types which causes it to be undefined but rather the accesses. -- 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=40665
[Bug target/40673] Lapack-3.2.1 testsuite fails with illegal instruction
--- Comment #3 from ronis at ronispc dot chem dot mcgill dot ca 2009-07-07 18:41 --- As per comment 2, here's my /proc/cupinfo. As to finding a minimized testcase, this is nontrivial as I don't know if the problem is in a lapack routine or in the testsuite routine itself. The package is large but publicly available at: http://www.netlib.org/lapack/lapack.tgz processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 3.00GHz stepping: 9 cpu MHz : 2999.999 cache size : 512 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pebs bts cid xtpr bogomips: 5999.99 clflush size: 64 power management: processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 3.00GHz stepping: 9 cpu MHz : 2999.999 cache size : 512 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 1 apicid : 1 initial apicid : 1 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pebs bts cid xtpr bogomips: 5999.15 clflush size: 64 power management: -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40673
[Bug target/40673] Lapack-3.2.1 testsuite fails with illegal instruction
--- Comment #4 from ronis at ronispc dot chem dot mcgill dot ca 2009-07-07 18:45 --- As per comment #1, I compiled with '-O -pipe' (lapack added -fimplicit-none). I get the same behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40673
[Bug regression/35671] GCC 4.4.x vs. 4.2.x performance regression
--- Comment #9 from t dot artem at mailcity dot com 2009-07-07 18:45 --- Qt 4.5.2 /lib directory (without *.debug files) occupies GCC 4.2.4: 43,649,379 bytes in 107 files GCC 4.4.0: 46,544,895 bytes in 107 files I don't like it at all. Compilation flags are still the same: -march=pentium2 -O2 -pipe -ftree-vectorize I hope GCC 4.5.0 will become sane again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35671
[Bug fortran/40675] New: sign intrinsic fails for value of 0.0
sahp7641 /var/scratch2/gcc4/bin/gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.4.0/configure --prefix=/var/scratch2/gcc4/ --enable-languages=c++,c,fortran --with-mpfr=/var/scratch2 Thread model: posix gcc version 4.4.0 (GCC) The sign intrinsic gives an incorrect value when the second argument is 0.0: program main val = 0.0 test = sign(0.5, val) - sign(0.5, -val) test2 = mysign(0.5, val) if (test .ne. test2) then write (*,*) 'fail' else write (*,*) 'pass' end if stop end real function mysign(a, b) C ...Returns `ABS(A)*s', where s is +1 if `B.GE.0', -1 otherwise. if (b .ge. 0) then s = 1.0 else s = -1.0 end if mysign = abs(a) * s return end The function 'mysign' implements the definition of the sign function listed at http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Sign-Intrinsic.html. When run with gfortran (versions 4.1.2 and 4.4.0 at least), the executable prints 'fail'. When built with g77 or intel fortran, it prints 'pass' as expected. The reason I classified this as a major bug is that old fortran vector codes use the following idiom to detect a zero value: test = sign(0.5, val) + sign(0.5, -val) ratio = value2 / (val + test) If val is zero, then test would be 1.0 and ratio ends up with a defined value. Later on outside the vector loop, error checking is done to catch the potential bad values. -- Summary: sign intrinsic fails for value of 0.0 Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gdsjaar at sandia dot gov GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40675
[Bug target/40673] Lapack-3.2.1 testsuite fails with illegal instruction
--- Comment #5 from ubizjak at gmail dot com 2009-07-07 18:57 --- Unfortunately, it is nearly impossible to debug your problem without the testcase, since the problem can not be analyzed. Can you at least run the breaking case through a gdb? It will show invalid instruction at the point of breakage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40673
[Bug fortran/40675] sign intrinsic fails for value of 0.0
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-07-07 19:02 --- Zeros have sign for FP value. Though I don't know if that is true for Fortran standard ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40675
[Bug target/40668] 64-bit sparc miscompiles memcpy of argument inside switch
--- Comment #5 from jakub at gcc dot gnu dot org 2009-07-07 19:05 --- Created an attachment (id=18151) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18151action=view) gcc44-pr40668.patch Untested patch that fixes this testcase. I believe my commit was correct, but apparently it can be modified later on without adjusting MEM_OFFSET. I don't have a working SPARC box around ATM, so I can't bootstrap/regtest it there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40668
[Bug regression/40665] dereferencing type-punned pointer warnings cannot be disabled
--- Comment #12 from mikulas at artax dot karlin dot mff dot cuni dot cz 2009-07-07 19:40 --- So if there was char *buffer = malloc(512) instead of char buffer[512], would it be correct to cast it to the pointer to structure? And it is not about the cast between the pointer types which causes it to be undefined but rather the accesses. What is considered the access in that code? Is it the - operator? operator? = operator? Cast operator? Or anything else? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665
[Bug fortran/40675] sign intrinsic fails for value of 0.0
--- Comment #2 from kargl at gcc dot gnu dot org 2009-07-07 19:43 --- (In reply to comment #0) sahp7641 /var/scratch2/gcc4/bin/gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.4.0/configure --prefix=/var/scratch2/gcc4/ --enable-languages=c++,c,fortran --with-mpfr=/var/scratch2 Thread model: posix gcc version 4.4.0 (GCC) The sign intrinsic gives an incorrect value when the second argument is 0.0: program main val = 0.0 test = sign(0.5, val) - sign(0.5, -val) test2 = mysign(0.5, val) if (test .ne. test2) then write (*,*) 'fail' else write (*,*) 'pass' end if stop end real function mysign(a, b) C ...Returns `ABS(A)*s', where s is +1 if `B.GE.0', -1 otherwise. if (b .ge. 0) then s = 1.0 else s = -1.0 end if mysign = abs(a) * s return end The function 'mysign' implements the definition of the sign function listed at http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Sign-Intrinsic.html. When run with gfortran (versions 4.1.2 and 4.4.0 at least), the executable prints 'fail'. When built with g77 or intel fortran, it prints 'pass' as expected. The reason I classified this as a major bug is that old fortran vector codes use the following idiom to detect a zero value: test = sign(0.5, val) + sign(0.5, -val) ratio = value2 / (val + test) If val is zero, then test would be 1.0 and ratio ends up with a defined value. Later on outside the vector loop, error checking is done to catch the potential bad values. If you fix your code you will get the expected result, which is 'fail'. You get 'fail' with your broken code by accident. Also note that the g77 documentation is irrelevant. The Fortran 95 standard defines the behavior of SIGN(). In particular, see case (iv). 13.14.98SIGN (A, B) Description. Absolute value of A times the sign of B. Class. Elemental function. Arguments. A shall be of type integer or real. B shall be of the same type and kind type parameter as A. Result Characteristics. Same as A. Result Value. Case (i): If B 0, the value of the result is |A|. Case (ii): If B 0, the value of the result is -|A|. Case (iii): If B is of type integer and B=0, the value of the result is |A|. Case (iv): If B is of type real and is zero, then (a) If the processor cannot distinguish between positive and negative real zero, the value of the result is |A|. (b) If B is positive real zero, the value of the result is |A|. (c) If B is negative real zero, the value of the result is -|A|. Try adding a few PRINT statements to you code. It may help you understand the results. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40675
[Bug target/40673] Lapack-3.2.1 testsuite fails with illegal instruction
--- Comment #6 from ronis at ronispc dot chem dot mcgill dot ca 2009-07-07 19:45 --- Turns out that the problem isn't in lapack/gfortran at all; rather the tests link to blas (here atlas) and one of my blas libs was corrupted. I rebuilt/reinstalled atlas and the problem goes away, even with the more aggressive optimization flags. Thanks for your help. -- ronis at ronispc dot chem dot mcgill dot ca changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40673
[Bug fortran/40675] sign intrinsic fails for value of 0.0
--- Comment #3 from gdsjaar at sandia dot gov 2009-07-07 19:51 --- Subject: Re: sign intrinsic fails for value of 0.0 kargl at gcc dot gnu dot org wrote: --- Comment #2 from kargl at gcc dot gnu dot org 2009-07-07 19:43 --- (In reply to comment #0) sahp7641 /var/scratch2/gcc4/bin/gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.4.0/configure --prefix=/var/scratch2/gcc4/ --enable-languages=c++,c,fortran --with-mpfr=/var/scratch2 Thread model: posix gcc version 4.4.0 (GCC) The sign intrinsic gives an incorrect value when the second argument is 0.0: program main val = 0.0 test = sign(0.5, val) - sign(0.5, -val) test2 = mysign(0.5, val) if (test .ne. test2) then write (*,*) 'fail' else write (*,*) 'pass' end if stop end real function mysign(a, b) C ...Returns `ABS(A)*s', where s is +1 if `B.GE.0', -1 otherwise. if (b .ge. 0) then s = 1.0 else s = -1.0 end if mysign = abs(a) * s return end The function 'mysign' implements the definition of the sign function listed at http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Sign-Intrinsic.html. When run with gfortran (versions 4.1.2 and 4.4.0 at least), the executable prints 'fail'. When built with g77 or intel fortran, it prints 'pass' as expected. The reason I classified this as a major bug is that old fortran vector codes use the following idiom to detect a zero value: test = sign(0.5, val) + sign(0.5, -val) ratio = value2 / (val + test) If val is zero, then test would be 1.0 and ratio ends up with a defined value. Later on outside the vector loop, error checking is done to catch the potential bad values. If you fix your code you will get the expected result, which is 'fail'. You get 'fail' with your broken code by accident. Also note that the g77 documentation is irrelevant. The Fortran 95 standard defines the behavior of SIGN(). In particular, see case (iv). 13.14.98SIGN (A, B) Description. Absolute value of A times the sign of B. Class. Elemental function. Arguments. A shall be of type integer or real. B shall be of the same type and kind type parameter as A. Result Characteristics. Same as A. Result Value. Case (i): If B 0, the value of the result is |A|. Case (ii): If B 0, the value of the result is -|A|. Case (iii): If B is of type integer and B=0, the value of the result is |A|. Case (iv): If B is of type real and is zero, then (a) If the processor cannot distinguish between positive and negative real zero, the value of the result is |A|. (b) If B is positive real zero, the value of the result is |A|. (c) If B is negative real zero, the value of the result is -|A|. Try adding a few PRINT statements to you code. It may help you understand the results. OK, so I should instead be submitting a bug report for intel and g77 and pgi. gfortran is the only correct implementation? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40675
[Bug fortran/40675] sign intrinsic fails for value of 0.0
--- Comment #4 from dominiq at lps dot ens dot fr 2009-07-07 19:53 --- Steven beats me with the f95 standard: sign(0.5,-0.0) shall give -0.5. Note that the code in comment #0 gives 'pass' with ifort but fails with g77. I think the code is invalid since mysign is implicitely typed as integer. In addition I don't understand how it works with ifort: if sign(0.5,0.0) and sign(0.5,-0.0) are expected to give 0.5, then test=0.0 and test2=0.5. May be one could consider to ignore signed zero in SIGN with -std=legacy(?). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40675
[Bug other/40010] Parallel make issue when building man pages
--- Comment #2 from rwild at gcc dot gnu dot org 2009-07-07 19:57 --- Subject: Bug 40010 Author: rwild Date: Tue Jul 7 19:57:15 2009 New Revision: 149345 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149345 Log: gcc/ 2009-06-23 Mark Loeser m...@halcy0n.com PR build/40010 * Makefile.in (gcc.pod): Depend on gcc-vers.texi. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40010
[Bug fortran/40675] sign intrinsic fails for value of 0.0
--- Comment #5 from dominiq at lps dot ens dot fr 2009-07-07 19:59 --- OK, so I should instead be submitting a bug report for intel and g77 and pgi. gfortran is the only correct implementation? The key point is: If the processor cannot distinguish between positive and negative real zero. gfortran can do the distinction, but I would be very surprised that g77 can do the distinction, so its behavior seems standard conforming. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40675
[Bug fortran/40675] sign intrinsic fails for value of 0.0
--- Comment #6 from kargl at gcc dot gnu dot org 2009-07-07 20:05 --- (In reply to comment #3) OK, so I should instead be submitting a bug report for intel and g77 and pgi. gfortran is the only correct implementation? g77 is no longer supported. You can do want you want with bug reports to intel and pgi. But you should fix your code. Here's the output with a few PRINTs added to your original code. REMOVE:kargl[214] ./z 0.5000 -0.5000 1.000 1.05696461E+09 fail Here's the output after I fixed your code. REMOVE:kargl[216] ./z 0.5000 -0.5000 1.000 0.5000 fail Here's the fixed code. program main real, external :: mysign val = 0.0 test = sign(0.5, val) - sign(0.5, -val) test2 = mysign(0.5, val) print *, sign(0.5, val), sign(0.5, -val) print *, test, test2 if (test .ne. test2) then write (*,*) 'fail' else write (*,*) 'pass' end if stop end real function mysign(a, b) C ...Returns `ABS(A)*s', where s is +1 if `B.GE.0', -1 otherwise. if (b .ge. 0) then s = 1.0 else s = -1.0 end if mysign = abs(a) * s return end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40675
[Bug fortran/40675] sign intrinsic fails for value of 0.0
--- Comment #7 from kargl at gcc dot gnu dot org 2009-07-07 20:09 --- (In reply to comment #5) OK, so I should instead be submitting a bug report for intel and g77 and pgi. gfortran is the only correct implementation? The key point is: If the processor cannot distinguish between positive and negative real zero. gfortran can do the distinction, but I would be very surprised that g77 can do the distinction, so its behavior seems standard conforming. For the Fortran 77 standard: 4.1.3 Data Type Properties The mathematical and representation properties for each of the data types are specified in the following sections. For real, double precision, and integer data, the value zero is considered neither positive nor negative. The value of a signed zero is the same as the value of an unsigned zero. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40675
[Bug fortran/40675] sign intrinsic fails for value of 0.0
--- Comment #8 from gdsjaar at sandia dot gov 2009-07-07 20:13 --- Subject: Re: sign intrinsic fails for value of 0.0 OK, sorry for the buggy example code. It illustrates the folly of improving the code after doing the runs. A better fixed code illustrating my point is: program main val = 0.0 test = sign(0.5, val) - sign(0.5, -val) test2 = ysign(0.5, val) - ysign(0.5, -val) if (test .ne. test2) then write (*,*) 'fail' else write (*,*) 'pass' end if stop end real function ysign(a, b) C ...Returns `ABS(A)*s', where s is +1 if `B.GE.0', -1 otherwise. if (b .ge. 0) then s = 1.0 else s = -1.0 end if ysign = abs(a) * s return end kargl at gcc dot gnu dot org wrote: --- Comment #6 from kargl at gcc dot gnu dot org 2009-07-07 20:05 --- (In reply to comment #3) OK, so I should instead be submitting a bug report for intel and g77 and pgi. gfortran is the only correct implementation? g77 is no longer supported. You can do want you want with bug reports to intel and pgi. But you should fix your code. Here's the output with a few PRINTs added to your original code. REMOVE:kargl[214] ./z 0.5000 -0.5000 1.000 1.05696461E+09 fail Here's the output after I fixed your code. REMOVE:kargl[216] ./z 0.5000 -0.5000 1.000 0.5000 fail Here's the fixed code. program main real, external :: mysign val = 0.0 test = sign(0.5, val) - sign(0.5, -val) test2 = mysign(0.5, val) print *, sign(0.5, val), sign(0.5, -val) print *, test, test2 if (test .ne. test2) then write (*,*) 'fail' else write (*,*) 'pass' end if stop end real function mysign(a, b) C ...Returns `ABS(A)*s', where s is +1 if `B.GE.0', -1 otherwise. if (b .ge. 0) then s = 1.0 else s = -1.0 end if mysign = abs(a) * s return end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40675
[Bug c/40676] New: internal compiler error: verify_ssa error: definition in block 5 does not dominate use in block 7
extracted from Wine /home/marcus/projects/gcc.trunk/BIN/bin/gcc -c -O2 dialog.i dialog.i: In function 'xmsi_dialog_create': dialog.i:33:1: error: definition in block 5 does not dominate use in block 7 for SSA_NAME: .MEM_21 in statement: # VUSE .MEM_21 D.2749_15 = *szDialogName_13; dialog.i:33:1: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: internal compiler error: verify_ssa error: definition in block 5 does not dominate use in block 7 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marcus at jet dot franken dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40676
[Bug c/40676] internal compiler error: verify_ssa error: definition in block 5 does not dominate use in block 7
--- Comment #1 from marcus at jet dot franken dot de 2009-07-07 20:14 --- Created an attachment (id=18152) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18152action=view) dialog.i gcc -c -O2 dialog.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40676
[Bug c/40677] New: flag -mmultiple is ignored
The compiler fails to generate lmw/stmw when compiling the attached test case. (no_global_regs_above) never returns true. Obvious fix with attached patch. Note: I have no write privilege. Compiled with: gcc -Os -mcpu=601 -S test.c -- Summary: flag -mmultiple is ignored Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edmar at freescale dot com GCC host triplet: powerpc-unknown-linux-gnu-gcc GCC target triplet: powerpc-unknown-linux-gnu-gcc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40677
[Bug c/40677] flag -mmultiple is ignored
--- Comment #1 from edmar at freescale dot com 2009-07-07 20:21 --- Created an attachment (id=18153) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18153action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40677
[Bug tree-optimization/40676] [4.5 Regression] internal compiler error: verify_ssa error: definition in block 5 does not dominate use in block 7
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c |tree-optimization Keywords||ice-on-valid-code Summary|internal compiler error:|[4.5 Regression] internal |verify_ssa error: definition|compiler error: verify_ssa |in block 5 does not dominate|error: definition in block 5 |use in block 7 |does not dominate use in ||block 7 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40676
[Bug c/40677] flag -mmultiple is ignored
--- Comment #2 from edmar at freescale dot com 2009-07-07 20:22 --- Created an attachment (id=18154) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18154action=view) patch to fix bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40677
[Bug regression/40665] dereferencing type-punned pointer warnings cannot be disabled
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-07-07 20:24 --- (In reply to comment #12) So if there was char *buffer = malloc(512) instead of char buffer[512], would it be correct to cast it to the pointer to structure? Yes. And it is not about the cast between the pointer types which causes it to be undefined but rather the accesses. What is considered the access in that code? Is it the - operator? operator? = operator? Cast operator? Or anything else? The following three operators are causes an access to happen even if is used afterwards: -, ., and * Thanks, Andrew PInski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665
[Bug debug/40666] [4.4.1 regression] Ada tools build failure
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-07-07 20:46 --- Subject: Bug 40666 Author: ebotcazou Date: Tue Jul 7 20:46:06 2009 New Revision: 149346 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149346 Log: PR debug/40666 * dbxout.c (dbxout_symbol) PARM_DECL: Deal with parameters pointing to variables for debugging purposes. Modified: trunk/gcc/ChangeLog trunk/gcc/dbxout.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40666
[Bug debug/40666] [4.4.1 regression] Ada tools build failure
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-07-07 20:46 --- Subject: Bug 40666 Author: ebotcazou Date: Tue Jul 7 20:46:41 2009 New Revision: 149347 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149347 Log: PR debug/40666 * dbxout.c (dbxout_symbol) PARM_DECL: Deal with parameters pointing to variables for debugging purposes. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/dbxout.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40666
[Bug fortran/40675] sign intrinsic fails for value of 0.0
--- Comment #9 from twscofi at sandia dot gov 2009-07-07 20:54 --- (In reply to comment #6) g77 is no longer supported. Per http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gfortran/GNU-Fortran-and-G77.html#GNU-Fortran-and-G77 [Gfrortran] is an entirely new program that has been designed to ..., as well as providing backwards compatibility for Fortran 77 An example of legacy fortran 77 support would be fno-sign-zero does not print the negative sign of zero values for compatibility with F77 A slightly different test: program main val = 0.0 test = sign(0.5, val) - sign(0.5, -val) write (*,*) 'With val = ', val, ' test = ', test if (test .eq. 1) then write(*,*) 'fail' elseif (test .eq. 0) then write(*,*) 'pass' endif stop end gfortran -std=legacy fsign.f ./a.out With val =0.000 test = 1. fail I'm not sure that -std=legacy would be the best way to implement this, but it would work for me. -- twscofi at sandia dot gov changed: What|Removed |Added CC||twscofi at sandia dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40675
[Bug debug/40666] [4.4.1 regression] Ada tools build failure
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2009-07-07 20:57 --- Reopen if not. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40666
[Bug c++/35828] [C++0x] ICE on default template template parameter in template function
--- Comment #8 from jason at gcc dot gnu dot org 2009-07-07 22:04 --- Subject: Bug 35828 Author: jason Date: Tue Jul 7 22:03:42 2009 New Revision: 149351 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149351 Log: PR c++/35828 * pt.c (tsubst_decl): Don't abort if we didn't change anything in a TEMPLATE_DECL's args. Added: trunk/gcc/testsuite/g++.dg/template/defarg12.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35828
[Bug c++/40639] Cannot parse dependent type for enum-base in C++0x
--- Comment #3 from jason at gcc dot gnu dot org 2009-07-07 22:08 ---
Subject: Bug 40639
Author: jason
Date: Tue Jul 7 22:08:01 2009
New Revision: 149352
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149352
Log:
PR c++/37816
* decl.c (build_enumerator): Don't add enumerators for a
scoped enum to the enclosing class.
PR c++/40639
* decl.c (start_enum): Allow dependent underlying type.
PR c++/40633
* decl.c (finish_enum): Finish scope even in a template.
Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/enum4.C
- copied unchanged from r149341, trunk/gcc/testsuite/g++.dg/cpp0x/enum4.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/enum5.C
- copied unchanged from r149341, trunk/gcc/testsuite/g++.dg/cpp0x/enum5.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/enum6.C
- copied unchanged from r149341, trunk/gcc/testsuite/g++.dg/cpp0x/enum6.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/enum7.C
- copied unchanged from r149341, trunk/gcc/testsuite/g++.dg/cpp0x/enum7.C
Modified:
branches/gcc-4_4-branch/gcc/ (props changed)
branches/gcc-4_4-branch/gcc/ChangeLog-2008 (props changed)
branches/gcc-4_4-branch/gcc/cp/ChangeLog
branches/gcc-4_4-branch/gcc/cp/ChangeLog-2007 (props changed)
branches/gcc-4_4-branch/gcc/cp/ChangeLog-2008 (props changed)
branches/gcc-4_4-branch/gcc/cp/decl.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog-2008 (props changed)
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/ (props changed)
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/decltype-38655.C
(props changed)
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr36227.c (props
changed)
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/x86_64/abi/callabi/
(props changed)
Propchange: branches/gcc-4_4-branch/gcc/
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_4-branch/gcc/ChangeLog-2008
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_4-branch/gcc/cp/ChangeLog-2007
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_4-branch/gcc/cp/ChangeLog-2008
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog-2008
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/decltype-38655.C
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr36227.c
('svn:mergeinfo' modified)
Propchange:
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/x86_64/abi/callabi/
('svn:mergeinfo' modified)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40639
[Bug c++/40633] [c++0x] ICE with scoped enum inside a template
--- Comment #2 from jason at gcc dot gnu dot org 2009-07-07 22:08 ---
Subject: Bug 40633
Author: jason
Date: Tue Jul 7 22:08:01 2009
New Revision: 149352
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149352
Log:
PR c++/37816
* decl.c (build_enumerator): Don't add enumerators for a
scoped enum to the enclosing class.
PR c++/40639
* decl.c (start_enum): Allow dependent underlying type.
PR c++/40633
* decl.c (finish_enum): Finish scope even in a template.
Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/enum4.C
- copied unchanged from r149341, trunk/gcc/testsuite/g++.dg/cpp0x/enum4.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/enum5.C
- copied unchanged from r149341, trunk/gcc/testsuite/g++.dg/cpp0x/enum5.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/enum6.C
- copied unchanged from r149341, trunk/gcc/testsuite/g++.dg/cpp0x/enum6.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/enum7.C
- copied unchanged from r149341, trunk/gcc/testsuite/g++.dg/cpp0x/enum7.C
Modified:
branches/gcc-4_4-branch/gcc/ (props changed)
branches/gcc-4_4-branch/gcc/ChangeLog-2008 (props changed)
branches/gcc-4_4-branch/gcc/cp/ChangeLog
branches/gcc-4_4-branch/gcc/cp/ChangeLog-2007 (props changed)
branches/gcc-4_4-branch/gcc/cp/ChangeLog-2008 (props changed)
branches/gcc-4_4-branch/gcc/cp/decl.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog-2008 (props changed)
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/ (props changed)
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/decltype-38655.C
(props changed)
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr36227.c (props
changed)
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/x86_64/abi/callabi/
(props changed)
Propchange: branches/gcc-4_4-branch/gcc/
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_4-branch/gcc/ChangeLog-2008
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_4-branch/gcc/cp/ChangeLog-2007
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_4-branch/gcc/cp/ChangeLog-2008
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog-2008
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/decltype-38655.C
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr36227.c
('svn:mergeinfo' modified)
Propchange:
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/x86_64/abi/callabi/
('svn:mergeinfo' modified)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40633
[Bug c++/37816] [c++0x] Invalid handling of scoped enums defined at class scope
--- Comment #3 from jason at gcc dot gnu dot org 2009-07-07 22:08 ---
Subject: Bug 37816
Author: jason
Date: Tue Jul 7 22:08:01 2009
New Revision: 149352
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149352
Log:
PR c++/37816
* decl.c (build_enumerator): Don't add enumerators for a
scoped enum to the enclosing class.
PR c++/40639
* decl.c (start_enum): Allow dependent underlying type.
PR c++/40633
* decl.c (finish_enum): Finish scope even in a template.
Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/enum4.C
- copied unchanged from r149341, trunk/gcc/testsuite/g++.dg/cpp0x/enum4.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/enum5.C
- copied unchanged from r149341, trunk/gcc/testsuite/g++.dg/cpp0x/enum5.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/enum6.C
- copied unchanged from r149341, trunk/gcc/testsuite/g++.dg/cpp0x/enum6.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/enum7.C
- copied unchanged from r149341, trunk/gcc/testsuite/g++.dg/cpp0x/enum7.C
Modified:
branches/gcc-4_4-branch/gcc/ (props changed)
branches/gcc-4_4-branch/gcc/ChangeLog-2008 (props changed)
branches/gcc-4_4-branch/gcc/cp/ChangeLog
branches/gcc-4_4-branch/gcc/cp/ChangeLog-2007 (props changed)
branches/gcc-4_4-branch/gcc/cp/ChangeLog-2008 (props changed)
branches/gcc-4_4-branch/gcc/cp/decl.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog-2008 (props changed)
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/ (props changed)
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/decltype-38655.C
(props changed)
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr36227.c (props
changed)
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/x86_64/abi/callabi/
(props changed)
Propchange: branches/gcc-4_4-branch/gcc/
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_4-branch/gcc/ChangeLog-2008
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_4-branch/gcc/cp/ChangeLog-2007
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_4-branch/gcc/cp/ChangeLog-2008
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog-2008
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/decltype-38655.C
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr36227.c
('svn:mergeinfo' modified)
Propchange:
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/x86_64/abi/callabi/
('svn:mergeinfo' modified)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37816
[Bug c++/35828] [C++0x] ICE on default template template parameter in template function
--- Comment #9 from jason at gcc dot gnu dot org 2009-07-07 22:11 ---
Subject: Bug 35828
Author: jason
Date: Tue Jul 7 22:11:31 2009
New Revision: 149353
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149353
Log:
PR c++/35828
* pt.c (tsubst_decl): Don't abort if we didn't change anything
in a TEMPLATE_DECL's args.
Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/defarg12.C
- copied unchanged from r149351,
trunk/gcc/testsuite/g++.dg/template/defarg12.C
Modified:
branches/gcc-4_4-branch/gcc/ (props changed)
branches/gcc-4_4-branch/gcc/ChangeLog-2008 (props changed)
branches/gcc-4_4-branch/gcc/cp/ChangeLog
branches/gcc-4_4-branch/gcc/cp/ChangeLog-2007 (props changed)
branches/gcc-4_4-branch/gcc/cp/ChangeLog-2008 (props changed)
branches/gcc-4_4-branch/gcc/cp/pt.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog-2008 (props changed)
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/ (props changed)
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/decltype-38655.C
(props changed)
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr36227.c (props
changed)
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/x86_64/abi/callabi/
(props changed)
Propchange: branches/gcc-4_4-branch/gcc/
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_4-branch/gcc/ChangeLog-2008
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_4-branch/gcc/cp/ChangeLog-2007
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_4-branch/gcc/cp/ChangeLog-2008
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog-2008
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/decltype-38655.C
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr36227.c
('svn:mergeinfo' modified)
Propchange:
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/x86_64/abi/callabi/
('svn:mergeinfo' modified)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35828
[Bug c++/40633] [c++0x] ICE with scoped enum inside a template
--- Comment #3 from jason at gcc dot gnu dot org 2009-07-07 22:12 --- Fixed for 4.4.1. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40633
[Bug c++/37816] [c++0x] Invalid handling of scoped enums defined at class scope
--- Comment #4 from jason at gcc dot gnu dot org 2009-07-07 22:13 --- Fixed for 4.4.1. -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37816
[Bug c++/37946] [c++0x] ICE with enum class
--- Comment #4 from jason at gcc dot gnu dot org 2009-07-07 22:13 --- Done. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37946
[Bug c++/40639] Cannot parse dependent type for enum-base in C++0x
--- Comment #4 from jason at gcc dot gnu dot org 2009-07-07 22:14 --- Fixed for 4.4.1. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40639
[Bug c++/35828] [C++0x] ICE on default template template parameter in template function
--- Comment #10 from jason at gcc dot gnu dot org 2009-07-07 22:16 --- Fixed for 4.4.1. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35828
[Bug c++/31246] -Wunreachable-code warnings for compiler-generated code
--- Comment #29 from manu at gcc dot gnu dot org 2009-07-07 22:18 --- Subject: Bug 31246 Author: manu Date: Tue Jul 7 22:18:35 2009 New Revision: 149354 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149354 Log: 2009-07-08 Manuel López-Ibáñez m...@gcc.gnu.org PR c++/31246 * gimplify.c (gimplify_expr): Propagate no_warning flag when gimplifying. * gimple (gimple_build_call_from_tree): Likewise. * tree-cfg.c (remove_useless_stmts_warn_notreached): Check no_warning flag before warning. cp/ * init.c (build_new_1): Set TREE_NO_WARNING for compiler-generated code. * cp-gimplify.c (genericize_eh_spec_block): Likewise. testsuite/ * g++.dg/warn/pr31246.C: New. * g++.dg/warn/pr31246-2.C: New. Added: trunk/gcc/testsuite/g++.dg/warn/pr31246-2.C trunk/gcc/testsuite/g++.dg/warn/pr31246.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/cp/init.c trunk/gcc/gimple.c trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug c++/31246] -Wunreachable-code warnings for compiler-generated code
--- Comment #30 from manu at gcc dot gnu dot org 2009-07-07 22:20 --- FIXED in GCC 4.5. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug c++/36833] unexpected warning: guard 13936 owner may be used uninitialized in this function
--- Comment #8 from manu at gcc dot gnu dot org 2009-07-07 22:42 --- I cannot reproduce this in GCC 4.4.0 or GCC 4.5 revision 149265. This was probably FIXED at some moment but the testcase is too large for the testsuite. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36833
[Bug fortran/40678] New: ICE on invalid code, gfc_conv_variable
Gfortran does not like me forgetting () on function calls. Simple test code: module ice implicit none contains subroutine in_the logical :: there_is there_is = sunshine ! () are missing! end subroutine function sunshine() logical :: sunshine sunshine = .true. end function end module $ LANG=C gfortran -c -o gccice.o gccice.f90 gccice.f90: In function 'in_the': gccice.f90:17: internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:483 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE on invalid code, gfc_conv_variable Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: thomas dot orgis at awi dot de GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40678
[Bug target/40668] 64-bit sparc miscompiles memcpy of argument inside switch
--- Comment #6 from mikpe at it dot uu dot se 2009-07-07 23:10 --- (In reply to comment #5) Created an attachment (id=18151) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18151action=view) [edit] gcc44-pr40668.patch Untested patch that fixes this testcase. Thanks. This fixes the issue in a cross-compiler to sparc64-linux. I'm currently bootstrapping 4.4-20090630 plus this patch on an Ultra5, I'll follow up once that's complete (it will take quite a while). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40668
[Bug target/40670] Load floating point constant 0 directly
--- Comment #2 from rth at gcc dot gnu dot org 2009-07-07 23:38 --- I'll go farther than that and say that all single-precision fp numbers destined for integer registers should be passed through the normal constant splitting routines. For instance, all positive powers of two satisfy the (0xff lowbit) test. -- rth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-07 23:38:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40670
[Bug fortran/40591] Procedure(interface): Rejected if interface is indirectly hostassociated
--- Comment #2 from pault at gcc dot gnu dot org 2009-07-08 04:38 --- Subject: Bug 40591 Author: pault Date: Wed Jul 8 04:38:06 2009 New Revision: 149362 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149362 Log: 2008-07-08 Paul Thomas pa...@gcc.gnu.org PR fortran/40591 * decl.c (match_procedure_interface): Correct the association or creation of the interface procedure's symbol. 2008-07-08 Paul Thomas pa...@gcc.gnu.org PR fortran/40591 * gfortran.dg/proc_ptr_21.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_21.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40591
[Bug lto/39049] ICE with an empty function
--- Comment #1 from bje at gcc dot gnu dot org 2009-07-08 04:42 --- Working in r149354. -- bje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Summary|ICE with an empty function |ICE with an empty function http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39049
[Bug bootstrap/39022] lto-plugin is built unconditionally
--- Comment #1 from bje at gcc dot gnu dot org 2009-07-08 04:53 --- Confirmed in r149354. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39022
[Bug lto/39016] [LTO] ICE in output_expr_operand because of BLOCK Expressions.
--- Comment #1 from bje at gcc dot gnu dot org 2009-07-08 05:28 --- Working in r149354. -- bje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39016
