[Bug c/28673] New: static reference not optimized, leaving dangling reference
the attached code snippet (from WINE) leaves a dangling reference when compile with debugging info. $ ~/projects/gcc/BIN/bin/gcc -c fci.i -O2 ; nm fci.o $ ~/projects/gcc/BIN/bin/gcc -c fci.i -g -O2 ; nm fci.o U __wine_dbch_cabinet $ -- Summary: static reference not optimized, leaving dangling reference Product: gcc Version: 4.2.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=28673
[Bug c/28673] static reference not optimized, leaving dangling reference
--- Comment #1 from marcus at jet dot franken dot de 2006-08-10 07:33 --- Created an attachment (id=12051) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12051&action=view) fci.i gcc -O2 -g -c fci.c ; nm fci.o should not show undefined -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28673
[Bug debug/28673] static reference not optimized, leaving dangling reference
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-10 07:35 --- *** This bug has been marked as a duplicate of 27657 *** -- 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=28673
[Bug tree-optimization/27657] [4.2 regression] bogus undefined reference error to static var with -g and -O
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-10 07:35 --- *** Bug 28673 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||marcus at jet dot franken ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27657
[Bug tree-optimization/17687] sincos can be folded at the tree level
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-08-10 07:41 --- I implemented the expander to allow the x87 backend using fsincos for it. The problems (TREE_ADDRESSABLE, no real folding, no CSE with previous sin/cos) still exist. I had/have (I don't remember if I submitted them) patches to canonicalize sin/cos/sincos to cexp and expand cexp to sin/cos/sincos dependent on arguments. If this PR was only about x87 using fsincos for sincos this is fixed now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17687
[Bug c++/28674] New: Segmentation fault
when i cross-compile my code file for mips,i got under message: mipsel-linux-g++: Internal error: Segmentation fault (program cc1plus) Please submit a full bug report. See http://gcc.gnu.org/bugs.html> for instructions. make: *** [communicate.o] Error 1 i compile the same code file for x86 never got any error,and run correctly. -- Summary: Segmentation fault Product: gcc Version: 3.3.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: guohongwen at boco dot com dot cn GCC build triplet: Linux 2.4.20-8 #1 (redhat 9) GCC host triplet: Linux 2.4.20-8 #1 (redhat 9) GCC target triplet: mips http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28674
[Bug c++/28674] Segmentation fault
--- Comment #1 from guohongwen at boco dot com dot cn 2006-08-10 07:47 --- Created an attachment (id=12052) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12052&action=view) the temp file the file temp file created by -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28674
[Bug c++/28674] Segmentation fault
--- Comment #2 from guohongwen at boco dot com dot cn 2006-08-10 07:48 --- Created an attachment (id=12053) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12053&action=view) the temp file the file temp file created by -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28674
[Bug c++/28674] Segmentation fault
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-10 07:49 --- Can you try a newer compiler like say 4.0.2? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28674
[Bug fortran/28496] Error during array initialization
--- Comment #4 from paul dot richard dot thomas at cea dot fr 2006-08-10 07:52 --- Created an attachment (id=12054) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12054&action=view) Patch to fix the PR and a testcase This seems to do the trick. I will regtest and submit to the list this evening. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28496
[Bug tree-optimization/17687] sincos can be folded at the tree level
--- Comment #9 from paolo dot bonzini at lu dot unisi dot ch 2006-08-10 08:04 --- Subject: Re: sincos can be folded at the tree level > If this PR was only about x87 using fsincos for sincos this is fixed now. Well, it was mostly about getting rid of TREE_ADDRESSABLE, which you can really do efficiently only on x87, using fsincos. But maybe it's time to change the subject. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17687
[Bug tree-optimization/17687] sincos expansion is suboptimal
--- Comment #10 from bonzini at gnu dot org 2006-08-10 08:08 --- see patch at http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01151.html -- bonzini at gnu dot org changed: What|Removed |Added Summary|sincos can be folded at the |sincos expansion is |tree level |suboptimal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17687
[Bug tree-optimization/17687] sincos expansion is suboptimal
--- Comment #11 from bonzini at gnu dot org 2006-08-10 08:11 --- If all that we care about is TREE_ADDRESSABLE, and not folding together with a previous sin/cos call, we may just change sincos (x, &s, &c); to sincos (x, &t1, &t2); s = t1; c = t2; maybe? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17687
[Bug tree-optimization/17687] sincos expansion is suboptimal
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-08-10 08:16 --- Created an attachment (id=12055) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12055&action=view) patch using cexp Well, then you make t1 and t2 addressable. We could introduce a __builtin_sane_sincos which returns in a vector, but then at expand time we'd have the same problems if we ever want to go back to a sincos libcall. With libgcc-math we could provide one with a sane interface though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17687
[Bug objc/28049] [4.1/4.2 regression] ICE on single + or -
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-10 08:19 --- Mark, is there a reason why this is a P2 when this only affects the Objective-C front-end? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28049
[Bug c++/28674] Segmentation fault
--- Comment #4 from guohongwen at boco dot com dot cn 2006-08-10 08:28 --- (In reply to comment #3) > Can you try a newer compiler like say 4.0.2? i'v resolve it,the problem is i initialize a struct with a static struct,i'm trying it... -- guohongwen at boco dot com dot cn changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28674
[Bug tree-optimization/17687] sincos expansion is suboptimal
--- Comment #13 from bonzini at gnu dot org 2006-08-10 08:32 --- sure, but t1 and t2 die the moment they are assigned back. it would be just a trick to return in memory, but not make s and c addressable all the way down to RA. though i don't remember how big a penalty is if your variable is addressable just for the sake of one or two uses. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17687
[Bug c/28675] New: ICE in extract_insn, at recog.c:2084 (nrecognizable insn) [arm]
We get the following ICE when crosscompiling fbtest from i686-pc-linux-gnu to arm-ep93xx-linux-gnueabi. -O3 breaks, -O2 works [EMAIL PROTECTED]:~/pengutronix/ptxdist/bug]$ arm-ep93xx-linux-gnueabi-gcc -c -Wall -O3 -fomit-frame-pointer -o minimal.o minimal.c -save-temps -v Using built-in specs. Target: arm-ep93xx-linux-gnueabi Configured with: /home/mkl/pengutronix/ptxdist/build/toolchain-arm-ep93xx-linux-gnueabi/build-cross/gcc-4.1.1/configure --host=i686-host-linux-gnu --target=arm-ep93xx-linux-gnueabi --prefix=/opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4 --with-local-prefix=/opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4/sysroot-arm-ep93xx-linux-gnueabi --with-sysroot=/opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4/sysroot-arm-ep93xx-linux-gnueabi --disable-multilib --disable-nls --enable-symvers=gnu --enable-__cxa_atexit --enable-c99 --enable-long-long --enable-shared --enable-threads=posix --enable-languages=c,c++ Thread model: posix gcc version 4.1.1 /opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4/libexec/gcc/arm-ep93xx-linux-gnueabi/4.1.1/cc1 -E -quiet -v minimal.c -Wall -fomit-frame-pointer -O3 -fpch-preprocess -o minimal.i ignoring nonexistent directory "/opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4/sysroot-arm-ep93xx-linux-gnueabi/opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4/sysroot-arm-ep93xx-linux-gnueabi/include" #include "..." search starts here: #include <...> search starts here: /opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4/lib/gcc/arm-ep93xx-linux-gnueabi/4.1.1/include /opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4/lib/gcc/arm-ep93xx-linux-gnueabi/4.1.1/../../../../arm-ep93xx-linux-gnueabi/include /opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4/sysroot-arm-ep93xx-linux-gnueabi/usr/include End of search list. /opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4/libexec/gcc/arm-ep93xx-linux-gnueabi/4.1.1/cc1 -fpreprocessed minimal.i -quiet -dumpbase minimal.c -auxbase-strip minimal.o -O3 -Wall -version -fomit-frame-pointer -o minimal.s GNU C version 4.1.1 (arm-ep93xx-linux-gnueabi) compiled by GNU C version 4.1.2 20060729 (prerelease) (Debian 4.1.1-10). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 770ce336670905d74fe72d7a025d3915 minimal.c: In function 'main': minimal.c:49: error: unrecognizable insn: (insn 284 119 282 13 (set (reg:HI 14 lr) (mem/s:HI (plus:SI (mult:SI (reg/v:SI 1 r1 [orig:122 i ] [122]) (const_int 16 [0x10])) (reg:SI 6 r6 [orig:114 clut.1 ] [114])) [3 .r+0 S4 A32])) -1 (nil) (nil)) minimal.c:49: internal compiler error: in extract_insn, at recog.c:2084 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: ICE in extract_insn, at recog.c:2084 (nrecognizable insn) [arm] Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mkl at pengutronix dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: arm-ep93xx-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28675
[Bug c/28675] ICE in extract_insn, at recog.c:2084 (nrecognizable insn) [arm]
--- Comment #1 from mkl at pengutronix dot de 2006-08-10 09:10 --- Created an attachment (id=12056) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12056&action=view) small testcase to trigger the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28675
[Bug fortran/20886] passing generic name as dummy argument
--- Comment #2 from patchapp at dberlin dot org 2006-08-10 09:55 --- Subject: Bug number PR20886 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00304.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20886
[Bug other/27156] SIGSEGV in operator delete() / wrong-code?
--- Comment #13 from pluto at agmk dot net 2006-08-10 09:58 --- in fact it was a gcc bug. gcc version 4.1.2 20060530 gives wrong code. gcc version 4.1.2 20060712 gives correct code. tree dump shows that gcc-20060530 removes some parts [*] of vector_base initialization and finally crash during freeing invalid pointer. --- ok/bug.cpp.t97.final_cleanup2006-08-10 11:48:19.769723000 +0200 +++ err/bug.cpp.t97.final_cleanup 2006-08-10 11:47:33.802850250 +0200 - l.D.11626._M_node._M_data._M_next = &l.D.11626._M_node._M_data; - l.D.11626._M_node._M_data._M_prev = &l.D.11626._M_node._M_data; - v.D.12155._M_start = 0B; <== [*] - v.D.12155._M_end_of_storage._M_data = 0B; <== [*] - v.D.12155._M_finish = 0B; <== [*] + l.D.11607._M_node._M_data._M_next = &l.D.11607._M_node._M_data; + l.D.11607._M_node._M_data._M_prev = &l.D.11607._M_node._M_data; -- pluto at agmk dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27156
[Bug other/27156] SIGSEGV in operator delete() / wrong-code?
--- Comment #14 from pluto at agmk dot net 2006-08-10 09:58 --- fixed on current 4.1 branch. -- pluto at agmk dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27156
[Bug fortran/28496] Error during array initialization
--- Comment #5 from patchapp at dberlin dot org 2006-08-10 10:15 --- Subject: Bug number PR28496 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00305.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28496
[Bug target/28676] New: [4.2 regression] infinite loop in vt_find_locations
Since r116031 the compiler is running into an infinite loop in vt_find_locations while compiling the C++ runtime. /tmp/cvs/gcc-20060810/Build/./gcc/xgcc -shared-libgcc -B/tmp/cvs/gcc-20060810/Build/./gcc -nostdinc++ -L/tmp/cvs/gcc-20060810/Build/ia64-suse-linux/libstdc++-v3/src -L/tmp/cvs/gcc-20060810/Build/ia64-suse-linux/libstdc++-v3/src/.libs -B/tmp/cvs/gcc-20060810/Build/root/ia64-suse-linux/bin/ -B/tmp/cvs/gcc-20060810/Build/root/ia64-suse-linux/lib/ -isystem /tmp/cvs/gcc-20060810/Build/root/ia64-suse-linux/include -isystem /tmp/cvs/gcc-20060810/Build/root/ia64-suse-linux/sys-include -I/tmp/cvs/gcc-20060810/Build/ia64-suse-linux/libstdc++-v3/include/ia64-suse-linux -I/tmp/cvs/gcc-20060810/Build/ia64-suse-linux/libstdc++-v3/include -I/tmp/cvs/gcc-20060810/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -c ../../../../libstdc++-v3/src/wlocale-inst.cc -fPIC -DPIC -o .libs/wlocale-inst.o #0 0x40b74210 in vt_find_locations () at ../../gcc/var-tracking.c:1737 #1 0x40b752f0 in variable_tracking_main () at ../../gcc/var-tracking.c:2951 #2 0x409c5830 in ia64_reorg () at ../../gcc/config/ia64/ia64.c:8549 #3 0x40b88820 in rest_of_handle_machine_reorg () at ../../gcc/reorg.c:3816 #4 0x4093ceb0 in execute_one_pass (pass=0x60015910) at ../../gcc/passes.c:864 #5 0x4093d220 in execute_pass_list (pass=0x60015910) at ../../gcc/passes.c:911 #6 0x4093d270 in execute_pass_list (pass=0x60014240) at ../../gcc/passes.c:912 #7 0x4093d270 in execute_pass_list (pass=0x600141f8) at ../../gcc/passes.c:912 #8 0x403478f0 in tree_rest_of_compilation (fndecl=0x21fe23e0) at ../../gcc/tree-optimize.c:418 #9 0x401f4d50 in expand_body (fn=0x21fe23e0) at ../../gcc/cp/semantics.c:3072 #10 0x409d2080 in cgraph_expand_function (node=0x223a) at ../../gcc/cgraphunit.c:1194 #11 0x409d9880 in cgraph_optimize () at ../../gcc/cgraphunit.c:1259 #12 0x401280f0 in cp_finish_file () at ../../gcc/cp/decl2.c:3341 #13 0x40003a20 in finish_file () at ../../gcc/cp/cp-lang.c:144 #14 0x402dee50 in c_common_parse_file ( set_yydebug=) at ../../gcc/c-opts.c:1165 #15 0x408c7d20 in toplev_main (argc=, argv=) at ../../gcc/toplev.c:999 #16 0x402ff550 in main (argc=36, argv=0x607fff1c0168) at ../../gcc/main.c:35 -- Summary: [4.2 regression] infinite loop in vt_find_locations Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schwab at suse dot de GCC target triplet: ia64-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28676
[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++
--- Comment #4 from tbm at gcc dot gnu dot org 2006-08-10 11:53 --- *** Bug 28676 has been marked as a duplicate of this bug. *** -- tbm at gcc dot gnu dot org changed: What|Removed |Added CC||schwab at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28672
[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++
-- tbm at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28672
[Bug target/28676] [4.2 regression] infinite loop in vt_find_locations
--- Comment #1 from tbm at gcc dot gnu dot org 2006-08-10 11:53 --- *** This bug has been marked as a duplicate of 28672 *** -- tbm at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28676
[Bug c/28675] ICE in extract_insn, at recog.c:2084 (unrecognizable insn) [arm]
--- Comment #2 from tbm at gcc dot gnu dot org 2006-08-10 12:00 --- -O3 works here while -O2 fails - but, in any case, confirmed. -- tbm at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-10 12:00:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28675
[Bug c/28675] [4.1/4.2 regression] ICE in extract_insn, at recog.c:2084 (unrecognizable insn) [arm]
--- Comment #3 from tbm at gcc dot gnu dot org 2006-08-10 12:02 --- I was on gcc 4.2 btw. -- tbm at gcc dot gnu dot org changed: What|Removed |Added Summary|ICE in extract_insn, at |[4.1/4.2 regression] ICE in |recog.c:2084 (unrecognizable|extract_insn, at |insn) [arm] |recog.c:2084 (unrecognizable ||insn) [arm] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28675
[Bug tree-optimization/26197] [4.2 regression] ICE in is_old_name with vectorizer
--- Comment #19 from dorit at gcc dot gnu dot org 2006-08-10 12:07 --- Subject: Bug 26197 Author: dorit Date: Thu Aug 10 12:07:22 2006 New Revision: 116060 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116060 Log: PR tree-optimization/26197 * tree-ssa-alias.c (new_type_alias): Takes additional argument. Calls get_ref_base_and_extent and overlap_subvar to add only relevant subvars as may-aliases. (add_may_alias_for_new_tag): New function, factored out of new_type_alias. * tree-vect-transform.c (vect_create_data_ref_ptr): Call new_type_alias with additional argument. * tree-flow.h (new_type_alias): Takes additional argument. Added: trunk/gcc/testsuite/g++.dg/vect/param-max-aliased-pr26197.cc Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/vect/vect.exp trunk/gcc/tree-flow.h trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-vect-transform.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26197
[Bug fortran/26106] [meta-bug] Gfortran can't compile tonto correctly
--- Comment #24 from paul dot richard dot thomas at cea dot fr 2006-08-10 12:11 --- (In reply to comment #23) > Tonto failed to build again. HJ Can we close this again? Steve's patch fixed the problem, as far as I know. Regards Paul Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26106
[Bug c++/4131] Why the C++ compiler don't place a const class object to ".rodata" section?
--- Comment #11 from bjoern dot haase at de dot bosch dot com 2006-08-10 12:11 --- Hi, here is a much simpler test case for this issue. Bjoern. #include using namespace std; const complex should_be_in_rodata (42,-42); complex should_be_in_data (42,-42); complex should_be_in_bss; -- bjoern dot haase at de dot bosch dot com changed: What|Removed |Added CC||bjoern dot haase at de dot ||bosch dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
[Bug c++/28677] New: Function prototype in function body crashes compilation
[EMAIL PROTECTED]:~$ gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --with-tune=i686 --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.2 20060729 (prerelease) (Debian 4.1.1-10) I currently use the latest Debian unstable system. [EMAIL PROTECTED] g++ -O3 -g crasher.cpp crasher.cpp: In function 'float betai(float, float, float)': crasher.cpp:43: internal compiler error: in add_AT_specification, at dwarf2out.c:5048 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see . Preprocessed source stored into /tmp/ccH8vLQj.out file, please attach this to your bugreport. the preprocessed source will be attached. -- Summary: Function prototype in function body crashes compilation Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: werner dot van dot belle at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28677
[Bug c++/28677] Function prototype in function body crashes compilation
--- Comment #1 from werner dot van dot belle at gmail dot com 2006-08-10 12:20 --- Created an attachment (id=12057) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12057&action=view) The preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28677
[Bug c++/28677] Function prototype in function body crashes compilation
--- Comment #2 from werner dot van dot belle at gmail dot com 2006-08-10 12:25 --- The bug does not occur without the -g option. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28677
[Bug c/28679] New: #pragma pack(push) malformed
5.47.6 Structure-Packing Pragmas 3. #pragma pack(push[,n]) pushes the current alignment setting on an internal stack and then optionally sets the new alignment. t.c: #pragma pack(1) #pragma pack(push) gcc t.c t.c:2: warning: malformed '#pragma pack(push[, id], )' - ignored It appears #pragma pack(push) is not supported as the documention suggests. Also, the error message indicates there is an undocumented form or #pragma pack that takes a stack identifier. I've been poking around to understand how it works but I'm not sure what #pragma pack(pop) does. It appears to pop all stacks, but what packing is set afterwards if multiple stacks are popped? -- Summary: #pragma pack(push) malformed Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cbowler at ca dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28679
[Bug c++/28681] New: friend declaration visible outside the class scope
Under GCC 4.0.2
This code (friend_bug.cpp)
--
struct A {
friend void func() {}
};
int main() {
func();
}
--
Compiles without any diagnostic.
The system is (uname -a):
Linux andre.localdomain 2.6.11-1.1369_FC4 #1 Thu Jun 2 22:53:35 EDT 2005 i586
i586 i386 GNU/Linux
I compiled this code with:
g++ -v -save-temps -Wall -Wextra --pedantic-errors -std=c++98 -xc++
friend_bug.cpp 2>err_output.txt
Output on stderr of g++ is:
-
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--host=i386-redhat-linux
Thread model: posix
gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)
/usr/libexec/gcc/i386-redhat-linux/4.0.2/cc1plus -E -quiet -v -D_GNU_SOURCE
friend_bug.cpp -std=c++98 -Wall -Wextra -pedantic-errors -fpch-preprocess -o
friend_bug.ii
ignoring nonexistent directory "/usr/lib/gcc/i386-redhat-linux/4.0.0/include"
ignoring duplicate directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../i386-redhat-linux/include"
ignoring duplicate directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include
/usr/local/include
/usr/include/glib-2.0
/usr/include/gtk-2.0/
/usr/include/pango-1.0
/usr/lib/gtk-2.0/
/usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2
/usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/i386-redhat-linux
/usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/backward
/usr/lib/gcc/i386-redhat-linux/4.0.2/include
End of search list.
/usr/libexec/gcc/i386-redhat-linux/4.0.2/cc1plus -fpreprocessed friend_bug.ii
-quiet -dumpbase friend_bug.cpp -auxbase friend_bug -Wall -Wextra
-pedantic-errors -std=c++98 -version -o friend_bug.s
GNU C++ version 4.0.2 20051125 (Red Hat 4.0.2-8) (i386-redhat-linux)
compiled by GNU C version 4.0.2 20051125 (Red Hat 4.0.2-8).
GGC heuristics: --param ggc-min-expand=42 --param ggc-min-heapsize=23863
as -V -Qy -o friend_bug.o friend_bug.s
GNU assembler version 2.16.91.0.6 (i386-redhat-linux) using BFD version
2.16.91.0.6 20060212
/usr/libexec/gcc/i386-redhat-linux/4.0.2/collect2 --eh-frame-hdr -m elf_i386
-dynamic-linker /lib/ld-linux.so.2
/usr/lib/gcc/i386-redhat-linux/4.0.2/../../../crt1.o
/usr/lib/gcc/i386-redhat-linux/4.0.2/../../../crti.o
/usr/lib/gcc/i386-redhat-linux/4.0.2/crtbegin.o
-L/usr/lib/gcc/i386-redhat-linux/4.0.2 -L/usr/lib/gcc/i386-redhat-linux/4.0.2
-L/usr/lib/gcc/i386-redhat-linux/4.0.2/../../.. friend_bug.o -lstdc++ -lm
-lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/i386-redhat-linux/4.0.2/crtend.o
/usr/lib/gcc/i386-redhat-linux/4.0.2/../../../crtn.o
-
The preprocessed output is:
-
# 1 "friend_bug.cpp"
# 1 ""
# 1 ""
# 1 "friend_bug.cpp"
struct A {
friend void func() {}
};
int main() {
func();
}
-
ACTUAL BEHAVIOR:
Compilation without any diagnostic message.
EXPECTED BEHAVIOR:
A diagnostic message is needed.
This code is ill-formed, since the scope of the friend declaration (which is
also a definition) must be limited to the scope of the A structure.
This issue as been discussed on comp.std.c++
And, with -std=c++98 --pedantic-errors I would expect an error.
The comp.std.c++ discussion can be read at:
http://groups.google.com/group/comp.std.c++/browse_thread/thread/3c18fce2a7e57da3
--
Summary: friend declaration visible outside the class scope
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tabkannaz at yahoo dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28681
[Bug fortran/20541] TR 15581: ALLOCATABLE components
--- Comment #16 from howarth at nitro dot med dot uc dot edu 2006-08-10 13:31 --- My first attempt to build with this revised patch was unsuccessful... /sw/src/fink.build/gcc4-4.1.999-20060809/darwin_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc4-4.1.999-20060809/darwin_objdir/./gcc/ -B/sw/lib/gcc4/powerpc-apple-darwin8/bin/ -B/sw/lib/gcc4/powerpc-apple-darwin8/lib/ -isystem /sw/lib/gcc4/powerpc-apple-darwin8/include -isystem /sw/lib/gcc4/powerpc-apple-darwin8/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-4.2-20060809/libgfortran -I. -iquote../../../gcc-4.2-20060809/libgfortran/io -I../../../gcc-4.2-20060809/libgfortran/../gcc -I../../../gcc-4.2-20060809/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -O2 -g -O2 -c ../../../gcc-4.2-20060809/libgfortran/intrinsics/malloc.c -o malloc.o >/dev/null 2>&1 make[3]: *** No rule to make target `intrinsics/move_alloc.c', needed by `move_alloc.lo'. Stop. make[2]: *** [all] Error 2 make[1]: *** [all-target-libgfortran] Error 2 make: *** [all] Error 2 ### execution of /var/tmp/tmp.2.82ybS7 failed, exit code 2 Failed: phase compiling: gcc4-4.1.999-20060809 failed I'll double check that I didn't drop any part of the patch by accident but I do recall any errors when patching. (In reply to comment #15) > Created an attachment (id=12049) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12049&action=view) [edit] > Updated patch > > Fix the problem reported by Jack. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
[Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #60 from whaley at cs dot utsa dot edu 2006-08-10 14:08 --- Paolo, Thanks for the explanation of what -funsafe is presently doing. >You are also confusing -funsafe-math-optimizations with -ffast-math. No, what I'm doing is reading the man page (the closest thing to a contract between gcc and me on what it is doing with my code): | -funsafe-math-optimizations | Allow optimizations for floating-point arithmetic that (a) assume | that arguments and results are valid and (b) may violate IEEE or | ANSI standards. The (b) in this statement prevents me, as a library provider that *must* be able to reassure my users that I have done nothing to violate IEEE fp standard (don't get me wrong, there's plenty of violations of the standard that occur in hardware, but typically in well-understood ways by the scientists of those platforms, and in the less important parts of the standard), from using this flag. I can't even use it after verifying that no optimization has hurt the present code, because an optimization that violates IEEE could be added at a later date, or used on a system that I'm not testing on (eg., on some systems, could cause 3DNow! vectorization). >Rules are determined by the language standards. I believe that C >mandates no reassociation; Fortran allows reassociation unless explicit >parentheses are present in the source, but this is not (yet) implemented >by GCC. My precise point. There are *lots* of C rules that a fp guy could give a crap about (for certain types of fp kernels), but IEEE is pretty much inviolate. Since this flag conflates language violations (don't care) with IEEE (catastrophic) I can't use it. I cannot stress enough just how important IEEE is: it is the only contract that tells us what it means to do a flop, and gives us any way of understanding what our answer will be. Making vectorization depend on a flag that says it is allowed to violate IEEE is therefore a killer for me (and most knowledgable fp guys). This is ironic, since vectorization of sums (as in GEMM) is usually implemented as scalar expansion on the accumulators, and this not only produces an IEEE-compliant answer, but it is *more* accurate for almost all data. Thanks, Clint -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #61 from paolo dot bonzini at lu dot unisi dot ch 2006-08-10 14:28 --- Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3 > Making vectorization depend on a flag that says it is allowed to violate IEEE > is therefore a killer for me (and most knowledgable fp guys). This is ironic, > since vectorization of sums (as in GEMM) is usually implemented as scalar > expansion on the accumulators > In case of GCC, it performs the transformation that Dorit explained. It may not produce an IEEE-compliant answer if there are zeros and you expect to see a particular sign for the zero. > and this not only produces an IEEE-compliant answer > The IEEE standard mandates particular rules for performing operations on infinities, NaNs, signed zeros, denormals, ... The C standard, by mandating no reassociation, ensures that you don't mess with NaNs, infinities, and signed zeros. As soon as you perform reassociation, there is *no way* you can be sure that you get IEEE-compliant math. +Inf + (1 / +0) = Inf, +Inf + (1 / -0) = NaN. > but it is *more* accurate for almost all data. http://citeseer.ist.psu.edu/589698.html is an example of a paper that shows FP code that avoids accuracy problems. Any kind of reassociation will break that code, and lower its accuracy. That's why reassociation is an "unsafe" math optimization. If you want a -freassociate-fp math, open an enhancement PR and somebody might be more than happy to separate reassociation from the other effects of -funsafe-math-optimizations. (Independent of this, you should also open a separate PR for ATLAS vectorization, because that would not be a regression and would not be on x87) :-) Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug ada/28682] New: --enable-languages=c,c++ for cross compiler builds Ada compiler
When I cross compile from Linux/i686 to Linux/ia64 with --enable-languages=c,c++, Ada compiler is enabled. The problem is BOOT_LANGUAGES = c ada in gcc/Makefile. Apparently, it was overriden for native build, but not for cross build. -- Summary: --enable-languages=c,c++ for cross compiler builds Ada compiler Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC host triplet: i686-pc-linux-gnu GCC target triplet: ia64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28682
[Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #62 from whaley at cs dot utsa dot edu 2006-08-10 15:15 --- Paolo, >The IEEE standard mandates particular rules for performing operations on >infinities, NaNs, signed zeros, denormals, ... The C standard, by >mandating no reassociation, ensures that you don't mess with NaNs, >infinities, and signed zeros. As soon as you perform reassociation, >there is *no way* you can be sure that you get IEEE-compliant math. No, again this is a conflation of the issues. You have IEEE-compliant math, but the differing orderings provide different summations of those values. It is a ANSI/ISO C rule being violated, not an IEEE. Each individual operation is IEEE, and therefore both results are IEEE-compliant, but since the C rule requiring order has been broken, some codes will break. However, they break not because of a violation of IEEE, but because of a violation of ANSI/ISO C. I can certify whether my code can take this violation of ANSI/ISO C by examining my code. I cannot certify my code works w/o IEEE by examining it, since that means a+b is now essentially undefined. >http://citeseer.ist.psu.edu/589698.html is an example of a paper that >shows FP code that avoids accuracy problems. Any kind of reassociation >will break that code, and lower its accuracy. That's why reassociation >is an "unsafe" math optimization. Please note I never argued it is was safe. Violating the C usage rules is always unsafe. However, as explained above, I can certify my code for reordering by examination, but nothing helps an IEEE violation. My problem is lumping in IEEE violations (such as 3dNow vectorization, or turning on non-IEEE mode in SSE) with C violations. >If you want a -freassociate-fp math, open an enhancement PR and somebody Ah, you mean like I asked about in end of 2nd paragraph of Comment #56? >might be more than happy to separate reassociation from the other >effects of -funsafe-math-optimizations. What I'm arguing for is not lumping in violations of ISO/ANSI C with IEEE violations, but you are right that this would fix my particular case. From what I see, -funsafe ought to be redefined as violating ANSI/ISO alone, and not mention IEEE at all. >(Independent of this, you should also open a separate PR for ATLAS >vectorization, because that would not be a regression and would not be >on x87) :-) You mean like I pleaded for in the last paragraph of Comment #38, but reluctantly shoved in here because that's what people seemed to want? :) Thanks, Clint -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++
--- Comment #5 from hjl at lucon dot org 2006-08-10 15:21 --- I can reproduce the hang with a cross compiler from Linux/i686 to Linux/ia64. It looks like the compiler is miscompiled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28672
[Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #63 from paolo dot bonzini at lu dot unisi dot ch 2006-08-10 15:22 --- Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3 >> If you want a -freassociate-fp math, open an enhancement PR and somebody >> > Ah, you mean like I asked about in end of 2nd paragraph of Comment #56? >> (Independent of this, you should also open a separate PR for ATLAS >> vectorization, because that would not be a regression and would not be >> on x87) :-) >> > You mean like I pleaded for in the last paragraph of Comment #38 Be bold. Don't ask, just open PRs if you feel an issue is separate. Go ahead now if you wish. Having them closed or marked as duplicate is not a problem, and it is much easier to track than cluttering an existing PRs. All these issues with ATLAS will not be visible to somebody looking for bug fixes "known to fail" in 4.2.0, because the original problem is now fixed in that version, and will soon be in 4.1.1 too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug c++/28683] New: ICE (segfault) when comparing pointers with -O (and higher)
This bug applies to gcc 4.0 and 4.1.
The following code:
--- snip here ---
extern void Assert( const char *file, int linenum, const char *function,
const char *condition, int &ignoreflag);
#define ASSERT(ZZ) \
{ static int ignore = 0; \
if( !ignore && !(ZZ) ) \
Assert( __FILE__, __LINE__, __PRETTY_FUNCTION__,
#ZZ, ignore); }
class foo
{
public:
int x;
};
class bar
{
public:
foo f;
};
bar *
testcase()
{
bar *r = new bar();
foo *f = &r->f;
ASSERT((void *)f == (void *)r);
return r;
}
--- snip here ---
causes a segfault:
$ g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,java
--prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --with-tune=i686
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.4 20060730 (prerelease) (Debian 4.0.3-6)
$ g++ -c -O testcase.C -o testcase.o
distcc[30704] ERROR: compile /home/joe/.ccache/testcase.tmp.barstow.30700.ii on
localhost failed
testcase.C: In function 'bar* testcase()':
testcase.C:20: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
$ g++-4.1 -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-tune=i686
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20060729 (prerelease) (Debian 4.1.1-10)
$ g++-4.1 -c -O testcase.C -o testcase.o
testcase.C: In function 'bar* testcase()':
testcase.C:20: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
Removing the ASSERT, or changing the assert to "if ((void *)f == (void *)r)",
causes the crash to go away.
--
Summary: ICE (segfault) when comparing pointers with -O (and
higher)
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hoserhead at woot dot net
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28683
[Bug c++/28681] friend declaration visible outside the class scope
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-10 16:03 --- This was fixed in 4.1.0. *** This bug has been marked as a duplicate of 7874 *** -- 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=28681
[Bug c++/7874] [3.4/4.0/4.1 regression] g++ finds friend functions defined in class-definition but not declared in the enclosing namespace
--- Comment #22 from pinskia at gcc dot gnu dot org 2006-08-10 16:03 --- *** Bug 28681 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||tabkannaz at yahoo dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7874
[Bug c/28684] New: Imprecise -funsafe-math-optimizations definition
Hi, I'm reporting a definitional problem with the -funsafe-math-optimization flag. This problem was initially discussed in comments 55-63 of bugzilla 27827. I will attempt to summarize that discussion here. Here's the definition of -funsafe-math-optimizations from the manpage: | -funsafe-math-optimizations | Allow optimizations for floating-point arithmetic that (a) assume | that arguments and results are valid and (b) may violate IEEE or | ANSI standards. >From those prior discussions, it seems to me that unsafe does not currently violate any IEEE (by which I mean IEEE 754, the floating point standard) rules (with the exception of use of recipricols, which is handled below). Rather, it violates ANSI/ISO C rules, in particular those involved in enforcing order. This distinction is overwhelmingly important, because I can certify my code to be correct in the face of reordering by examining the code, but nothing I do in the code protects me if IEEE is violated. This is because IEEE is the contract that specifies what it means to do a flop (floating point operation) such as a+b or a*b. If this contract is violated, I have no way of understanding what floating point does, which means theory cannot bound the error in my answer, nor is there a way to find out if exceptional events have occured (examples of transformations that truly violate IEEE are using 3DNow! or turning off IEEE compliance in SSE). People who do general floating point computation must therefore always maintain IEEE compatability, but are often able to allow reorderings. Unfortunately, at the present time, -funsafe is *required* in order to enable vectorization (because vectorization almost always reorders the operations). This means that computational scientists in the main will not be able to use gcc's vectorization, even though vectorization is of key importance to this group. My first suggestion is to redefine unsafe to more fully explain what it does, so that gcc's users can certify it safe for a particular piece of code. Here is a proposed definition that will allow this set of optimizations to be enabled by a computational guy like myself: | -funsafe-math-optimizations | Allow optimizations for floating-point arithmetic that require | reordering floating-point operations and/or the use of recipricols | (eg. a/b --> a*(1/b) or a+b+c --> a+c+b) | NOTE: may reorder or strength reduce floating-point comparisons as | well, and so may not be used when ordered comparisons are required With this definition, I can examine my code, and not throw this flag if my code can't handle it. In the prior one, I cannot certify my code to work with the the flag no matter what I do. I believe from the prior discussions that this definition of the flag will contain all the transformations presently enabled by this flag. I'm sure this is not the best definition, but it is an example that would allow the knowledge to be used by a computational scientist. The less general solution is to have a separate flag for allowing vectorization (or better, all reordering optimizations), which specifies that it can reorder the data, since this would allow vectorization to be used by computational scientists. This is good enough for me, but I believe more usefully defining -funsafe is the best choice because the people most likely to want to throw -funsafe are computational scientists, and the present definitions essei, I'm reporting a definitional problem with the -funsafe-math-optimization flag. This problem was initially discussed in comments 55-63 of bugzilla 27827. I will attempt to summarize that discussion here. Here's the definition of -funsafe-math-optimizations from the manpage: | -funsafe-math-optimizations | Allow optimizations for floating-point arithmetic that (a) assume | that arguments and results are valid and (b) may violate IEEE or | ANSI standards. >From those prior discussions, it seems to me that unsafe does not currently violate any IEEE (by which I mean IEEE 754, the floating point standard) rules (with the exception of use of recipricols, which is handled below). Rather, it violates ANSI/ISO C rules, in particular those involved in enforcing order. This distinction is overwhelmingly important, because I can certify my code to be correct in the face of reordering by examining the code, but nothing I do in the code protects me if IEEE is violated. This is because IEEE is the contract that specifies what it means to do a flop (floating point operation) such as a+b or a*b. If this contract is violated, I have no way of understanding what floating point does, which means theory cannot bound the error in my answer, nor is there a way to find out if exceptional events have occured. People who do general floating point computation must therefore always maintain IEEE compatability, but are often able to allow reorderin
[Bug fortran/26106] [meta-bug] Gfortran can't compile tonto correctly
--- Comment #25 from hjl at lucon dot org 2006-08-10 16:40 --- It is fixed in 4.2 now. -- hjl at lucon dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26106
[Bug middle-end/28684] Imprecise -funsafe-math-optimizations definition
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28684
[Bug middle-end/28651] [4.0/4.1 Regression] signed compare incorrectly false for (int)(U+4)<(int)U where U is unsigned INT_MAX (for optimized x86)
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-08-10 16:44 ---
Here is a testcase which makes this a regression:
extern void abort (void);
int
foo (unsigned int u)
{
unsigned t;
for (t=0;t!=u;t++) ;
return (int)(t + 4) < (int)u;
}
int
main (int argc, char *argv[])
{
unsigned int u;
/* Run with no arguments so u will be MAX_INT and the optimizers
won't know its value. */
if (argc > 1)
u = 1;
else
u = 0x7fff;
if (foo (u) == 0)
abort();
return 0;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|signed compare incorrectly |[4.0/4.1 Regression] signed
|false for (int)(U+4)<(int)U |compare incorrectly false
|where U is unsigned INT_MAX |for (int)(U+4)<(int)U where
|(for optimized x86)|U is unsigned INT_MAX (for
||optimized x86)
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28651
[Bug middle-end/28651] [4.0/4.1 Regression] signed compare incorrectly false for (int)(U+4)<(int)U where U is unsigned INT_MAX (for optimized x86)
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-08-10 16:53 --- (In reply to comment #9) > Here is a testcase which makes this a regression: I forgot to say this testcase worked in 3.4.0 but failed in 4.0.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28651
[Bug c++/4131] Why the C++ compiler don't place a const class object to ".rodata" section?
--- Comment #12 from mrs at apple dot com 2006-08-10 16:54 --- Trivially, one could use turing completeness at compile time to achieve the desired result. :-) Not that I think that is better than `fixing' this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
[Bug c++/4131] The C++ compiler don't place a const class object to ".rodata" section with non trival constructor
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-08-10 17:52
---
Here is a real reduced testcase:
struct f
{
f(int a) { t = a; }
int t;
}
const f(1);
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|Why the C++ compiler don't |The C++ compiler don't place
|place a const class object |a const class object to
|to ".rodata" section? |".rodata" section with non
||trival constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
[Bug middle-end/28685] New: Multiple comparisons are not simplified
These two testcases should produce equivalent code:
int test(int a, int b)
{
int lt = a < b;
int eq = a == b;
return (lt || eq);
}
int test_(int a, int b)
{
return (a < b || a == b);
}
However, the optimized tree code is:
;; Function test (test)
Analyzing Edge Insertions.
test (a, b)
{
:
return (a == b | a < b) != 0;
}
;; Function test_ (test_)
Analyzing Edge Insertions.
test_ (a, b)
{
:
return a <= b;
}
And the resultinh x86_64 asm is unoptimal for test() function:
test:
cmpl%esi, %edi
sete%dl
cmpl%esi, %edi
setl%al
orl %edx, %eax
movzbl %al, %eax
ret
test_:
xorl%eax, %eax
cmpl%esi, %edi
setle %al
ret
--
Summary: Multiple comparisons are not simplified
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28685
[Bug middle-end/28685] Multiple comparisons are not simplified
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-10 18:18 --- This all comes down to a tree combiner. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||15459 Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2006-08-10 18:18:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28685
[Bug c++/28559] [4.2 regression] ICE with friend and __attribute__
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-10 19:03:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28559
[Bug c++/28637] [4.1 regression] ICE on invalid template parameter
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-08-10 19:19 --- Subject: Bug 28637 Author: lmillward Date: Thu Aug 10 19:18:37 2006 New Revision: 116068 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116068 Log: PR c++/28594 PR c++/28637 PR c++/28638 PR c++/28639 PR c++/28640 PR c++/28641 Revert: 2006-07-28 Lee Millward <[EMAIL PROTECTED]> PR c++/27668 PR c++/27962 * pt.c (process_template_parm) Store invalid template parameters as error_mark_node in the paramater list. (push_inline_template_parms_recursive): Handle invalid template parameters. (comp_template_parms): Likewise. (check_default_tmpl_args): Likewise. (coerce_template_template_parms): Likewise. (coerce_template_parms): Likewise. (mangle_class_name_for_template): Likewise. (tsubst_template_parms): Likewise. * error.c (dump_template_argument_list): Likewise. * g++.dg/template/crash54.C: New test. * g++.dg/template/nontype16.C: New test. * g++.dg/template/nontype5.C: Adjust error markers Removed: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/crash54.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/nontype16.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/error.c branches/gcc-4_1-branch/gcc/cp/pt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/nontype5.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28637
[Bug c++/28594] [4.1/4.2 regression] ICE with invalid template parameter
--- Comment #3 from lmillward at gcc dot gnu dot org 2006-08-10 19:19 --- Subject: Bug 28594 Author: lmillward Date: Thu Aug 10 19:18:37 2006 New Revision: 116068 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116068 Log: PR c++/28594 PR c++/28637 PR c++/28638 PR c++/28639 PR c++/28640 PR c++/28641 Revert: 2006-07-28 Lee Millward <[EMAIL PROTECTED]> PR c++/27668 PR c++/27962 * pt.c (process_template_parm) Store invalid template parameters as error_mark_node in the paramater list. (push_inline_template_parms_recursive): Handle invalid template parameters. (comp_template_parms): Likewise. (check_default_tmpl_args): Likewise. (coerce_template_template_parms): Likewise. (coerce_template_parms): Likewise. (mangle_class_name_for_template): Likewise. (tsubst_template_parms): Likewise. * error.c (dump_template_argument_list): Likewise. * g++.dg/template/crash54.C: New test. * g++.dg/template/nontype16.C: New test. * g++.dg/template/nontype5.C: Adjust error markers Removed: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/crash54.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/nontype16.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/error.c branches/gcc-4_1-branch/gcc/cp/pt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/nontype5.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28594
[Bug c++/28638] [4.1 regression] ICE on invalid template parameter
--- Comment #3 from lmillward at gcc dot gnu dot org 2006-08-10 19:19 --- Subject: Bug 28638 Author: lmillward Date: Thu Aug 10 19:18:37 2006 New Revision: 116068 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116068 Log: PR c++/28594 PR c++/28637 PR c++/28638 PR c++/28639 PR c++/28640 PR c++/28641 Revert: 2006-07-28 Lee Millward <[EMAIL PROTECTED]> PR c++/27668 PR c++/27962 * pt.c (process_template_parm) Store invalid template parameters as error_mark_node in the paramater list. (push_inline_template_parms_recursive): Handle invalid template parameters. (comp_template_parms): Likewise. (check_default_tmpl_args): Likewise. (coerce_template_template_parms): Likewise. (coerce_template_parms): Likewise. (mangle_class_name_for_template): Likewise. (tsubst_template_parms): Likewise. * error.c (dump_template_argument_list): Likewise. * g++.dg/template/crash54.C: New test. * g++.dg/template/nontype16.C: New test. * g++.dg/template/nontype5.C: Adjust error markers Removed: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/crash54.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/nontype16.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/error.c branches/gcc-4_1-branch/gcc/cp/pt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/nontype5.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28638
[Bug c++/27962] [4.1 regression] ICE with invalid template parameter in specialization
--- Comment #6 from lmillward at gcc dot gnu dot org 2006-08-10 19:19 --- Subject: Bug 27962 Author: lmillward Date: Thu Aug 10 19:18:37 2006 New Revision: 116068 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116068 Log: PR c++/28594 PR c++/28637 PR c++/28638 PR c++/28639 PR c++/28640 PR c++/28641 Revert: 2006-07-28 Lee Millward <[EMAIL PROTECTED]> PR c++/27668 PR c++/27962 * pt.c (process_template_parm) Store invalid template parameters as error_mark_node in the paramater list. (push_inline_template_parms_recursive): Handle invalid template parameters. (comp_template_parms): Likewise. (check_default_tmpl_args): Likewise. (coerce_template_template_parms): Likewise. (coerce_template_parms): Likewise. (mangle_class_name_for_template): Likewise. (tsubst_template_parms): Likewise. * error.c (dump_template_argument_list): Likewise. * g++.dg/template/crash54.C: New test. * g++.dg/template/nontype16.C: New test. * g++.dg/template/nontype5.C: Adjust error markers Removed: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/crash54.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/nontype16.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/error.c branches/gcc-4_1-branch/gcc/cp/pt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/nontype5.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27962
[Bug c++/27668] [4.0 regression] ICE with invalid template parameter
--- Comment #8 from lmillward at gcc dot gnu dot org 2006-08-10 19:19 --- Subject: Bug 27668 Author: lmillward Date: Thu Aug 10 19:18:37 2006 New Revision: 116068 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116068 Log: PR c++/28594 PR c++/28637 PR c++/28638 PR c++/28639 PR c++/28640 PR c++/28641 Revert: 2006-07-28 Lee Millward <[EMAIL PROTECTED]> PR c++/27668 PR c++/27962 * pt.c (process_template_parm) Store invalid template parameters as error_mark_node in the paramater list. (push_inline_template_parms_recursive): Handle invalid template parameters. (comp_template_parms): Likewise. (check_default_tmpl_args): Likewise. (coerce_template_template_parms): Likewise. (coerce_template_parms): Likewise. (mangle_class_name_for_template): Likewise. (tsubst_template_parms): Likewise. * error.c (dump_template_argument_list): Likewise. * g++.dg/template/crash54.C: New test. * g++.dg/template/nontype16.C: New test. * g++.dg/template/nontype5.C: Adjust error markers Removed: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/crash54.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/nontype16.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/error.c branches/gcc-4_1-branch/gcc/cp/pt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/nontype5.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27668
[Bug c++/28640] [4.1 regression] ICE redeclaring template with invalid parameter
--- Comment #3 from lmillward at gcc dot gnu dot org 2006-08-10 19:19 --- Subject: Bug 28640 Author: lmillward Date: Thu Aug 10 19:18:37 2006 New Revision: 116068 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116068 Log: PR c++/28594 PR c++/28637 PR c++/28638 PR c++/28639 PR c++/28640 PR c++/28641 Revert: 2006-07-28 Lee Millward <[EMAIL PROTECTED]> PR c++/27668 PR c++/27962 * pt.c (process_template_parm) Store invalid template parameters as error_mark_node in the paramater list. (push_inline_template_parms_recursive): Handle invalid template parameters. (comp_template_parms): Likewise. (check_default_tmpl_args): Likewise. (coerce_template_template_parms): Likewise. (coerce_template_parms): Likewise. (mangle_class_name_for_template): Likewise. (tsubst_template_parms): Likewise. * error.c (dump_template_argument_list): Likewise. * g++.dg/template/crash54.C: New test. * g++.dg/template/nontype16.C: New test. * g++.dg/template/nontype5.C: Adjust error markers Removed: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/crash54.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/nontype16.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/error.c branches/gcc-4_1-branch/gcc/cp/pt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/nontype5.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28640
[Bug c++/28639] [4.1/4.2 regression] ICE trying to print error on invalid template parameter
--- Comment #3 from lmillward at gcc dot gnu dot org 2006-08-10 19:19 --- Subject: Bug 28639 Author: lmillward Date: Thu Aug 10 19:18:37 2006 New Revision: 116068 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116068 Log: PR c++/28594 PR c++/28637 PR c++/28638 PR c++/28639 PR c++/28640 PR c++/28641 Revert: 2006-07-28 Lee Millward <[EMAIL PROTECTED]> PR c++/27668 PR c++/27962 * pt.c (process_template_parm) Store invalid template parameters as error_mark_node in the paramater list. (push_inline_template_parms_recursive): Handle invalid template parameters. (comp_template_parms): Likewise. (check_default_tmpl_args): Likewise. (coerce_template_template_parms): Likewise. (coerce_template_parms): Likewise. (mangle_class_name_for_template): Likewise. (tsubst_template_parms): Likewise. * error.c (dump_template_argument_list): Likewise. * g++.dg/template/crash54.C: New test. * g++.dg/template/nontype16.C: New test. * g++.dg/template/nontype5.C: Adjust error markers Removed: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/crash54.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/nontype16.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/error.c branches/gcc-4_1-branch/gcc/cp/pt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/nontype5.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28639
[Bug c++/28641] [4.1/4.2 regression] ICE calling template function with invalid template parameter
--- Comment #3 from lmillward at gcc dot gnu dot org 2006-08-10 19:19 --- Subject: Bug 28641 Author: lmillward Date: Thu Aug 10 19:18:37 2006 New Revision: 116068 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116068 Log: PR c++/28594 PR c++/28637 PR c++/28638 PR c++/28639 PR c++/28640 PR c++/28641 Revert: 2006-07-28 Lee Millward <[EMAIL PROTECTED]> PR c++/27668 PR c++/27962 * pt.c (process_template_parm) Store invalid template parameters as error_mark_node in the paramater list. (push_inline_template_parms_recursive): Handle invalid template parameters. (comp_template_parms): Likewise. (check_default_tmpl_args): Likewise. (coerce_template_template_parms): Likewise. (coerce_template_parms): Likewise. (mangle_class_name_for_template): Likewise. (tsubst_template_parms): Likewise. * error.c (dump_template_argument_list): Likewise. * g++.dg/template/crash54.C: New test. * g++.dg/template/nontype16.C: New test. * g++.dg/template/nontype5.C: Adjust error markers Removed: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/crash54.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/nontype16.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/error.c branches/gcc-4_1-branch/gcc/cp/pt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/nontype5.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28641
[Bug c++/27962] [4.1 regression] ICE with invalid template parameter in specialization
--- Comment #7 from lmillward at gcc dot gnu dot org 2006-08-10 19:20 --- Reopening bug and marking it as depending on PR 27668 as the patch for that bug nas now been reverted on the 4.1 branch. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||27668 Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27962
[Bug c++/27668] [4.0/4.1 regression] ICE with invalid template parameter
--- Comment #9 from lmillward at gcc dot gnu dot org 2006-08-10 19:21 --- The patch for this bug has been reverted on the 4.1 branch so re-adding the 4.1 regression marker. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0 regression] ICE with |[4.0/4.1 regression] ICE |invalid template parameter |with invalid template ||parameter http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27668
[Bug c++/28594] [4.2 regression] ICE with invalid template parameter
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-08-10 19:22 --- Fixed on the 4.1 branch by the reversal of the patch for PR 27668. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2 regression] ICE|[4.2 regression] ICE with |with invalid template |invalid template parameter |parameter | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28594
[Bug c++/28637] [4.1 regression] ICE on invalid template parameter
--- Comment #5 from lmillward at gcc dot gnu dot org 2006-08-10 19:22 --- Fixed on the 4.1 branch by the reversal of the patch for PR 27668. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28637
[Bug c++/28638] [4.1 regression] ICE on invalid template parameter
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-08-10 19:23 --- Fixed on the 4.1 branch by the reversal of the patch for PR 27668. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28638
[Bug c++/28639] [4.2 regression] ICE trying to print error on invalid template parameter
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-08-10 19:24 --- Fixed on the 4.1 branch by the reversal of the patch for PR 27668 so removing the 4.1 regression marker. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2 regression] ICE|[4.2 regression] ICE trying |trying to print error on|to print error on invalid |invalid template parameter |template parameter http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28639
[Bug c++/28640] [4.1 regression] ICE redeclaring template with invalid parameter
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-08-10 19:24 --- Fixed on the 4.1 branch by the reversal of the patch for PR 27668. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28640
[Bug c++/28641] [4.2 regression] ICE calling template function with invalid template parameter
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-08-10 19:25 --- Fixed on the 4.1 branch by the reversal of the patch for PR 27668 so removing the 4.1 regression marker. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2 regression] ICE|[4.2 regression] ICE calling |calling template function |template function with |with invalid template |invalid template parameter |parameter | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28641
[Bug c++/4131] The C++ compiler don't place a const class object to ".rodata" section with non trival constructor
--- Comment #14 from bjoern dot m dot haase at web dot de 2006-08-10 19:33 --- I had already a look at the code in the cp directory. Unfortunately the documentation of the c++ front-end seems to be still worse than the docs on the back-ends (i.e. RTL). Either it is virtually inexisting or, I didn't find any hint on where to find it. Meanwhile I had a look at the tree dumps. Unfortunately, I didn't succeed in finding the initialization data for global "plain old built-in type" variables in the tree dumps. I have so far only seen the constructor code for initialization of class objects. AI'd at least like to have an idea of the complexity of the task. I have the impression that it might be way to difficult for me myself. But at least I'd like to try my very best to fix it before giving up. So any hint on a starting point for code reading and analysis would be appreciated. Bjoern. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
[Bug java/8923] [4.0/4.1/4.2 Regression] ICE when modifying a variable decleared "final static"
--- Comment #9 from aph at gcc dot gnu dot org 2006-08-10 19:35 --- Subject: Bug 8923 Author: aph Date: Thu Aug 10 19:35:07 2006 New Revision: 116069 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116069 Log: 2006-08-10 Simon Martin <[EMAIL PROTECTED]> PR java/8923 * parse.y (build_incdec): Emit an error instead of an ICE if '++' or '--' is used with a constant operand. (java_complete_lhs): When processing a '++' or '--' expression, don't call java_complete_tree but java_complete_lhs, so that a static final variable operand is never replaced by its value. This avoids an ICE later on. (patch_unaryop): Fixed typo in comment. Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/parse.y -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8923
[Bug c++/28683] [4.0/4.1/4.2 regression] ICE (segfault in add_reg_br_prob_note) when comparing pointers with -O (and higher)
--- Comment #1 from tbm at gcc dot gnu dot org 2006-08-10 19:37 --- (gdb) run -O2 tt.cc Starting program: /usr/local/libexec/gcc/i686-pc-linux-gnu/4.2.0/cc1plus -O2 tt.cc bar* testcase() Analyzing compilation unitPerforming intraprocedural optimizations Assembling functions: bar* testcase() Program received signal SIGSEGV, Segmentation fault. 0x08517abc in add_reg_br_prob_note (last=, probability=5347) at gcc/cfgexpand.c:58 58 if (!any_condjump_p (last) (gdb) where #0 0x08517abc in add_reg_br_prob_note (last=, probability=5347) at gcc/cfgexpand.c:58 #1 0x08517fd0 in expand_gimple_basic_block (bb=0x40362900) at gcc/cfgexpand.c:1128 #2 0x0851938c in tree_expand_cfg () at gcc/cfgexpand.c:1634 #3 0x08514c86 in execute_one_pass (pass=0x872e320) at gcc/passes.c:864 #4 0x08514e57 in execute_pass_list (pass=0x872e320) at gcc/passes.c:911 #5 0x081cc676 in tree_rest_of_compilation (fndecl=0x4040fe70) at gcc/tree-optimize.c:418 #6 0x08131c7d in expand_body (fn=0x4040fe70) at gcc/cp/semantics.c:3072 #7 0x08566564 in cgraph_expand_function (node=0x403e2bc8) at gcc/cgraphunit.c:1194 #8 0x0856954a in cgraph_optimize () at gcc/cgraphunit.c:1259 #9 0x080d6aba in cp_finish_file () at gcc/cp/decl2.c:3341 #10 0x0819abef in c_common_parse_file (set_yydebug=0) at gcc/c-opts.c:1165 #11 0x084e0a0d in toplev_main (argc=3, argv=0xb9f4) at gcc/toplev.c:999 #12 0x081a9972 in main (argc=Cannot access memory at address 0x29 ) at gcc/main.c:35 (gdb) -- tbm at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.0.3 4.1.1 4.2.0 Known to work||3.3.6 3.4.6 Last reconfirmed|-00-00 00:00:00 |2006-08-10 19:37:19 date|| Summary|ICE (segfault) when |[4.0/4.1/4.2 regression] ICE |comparing pointers with -O |(segfault in |(and higher)|add_reg_br_prob_note) when ||comparing pointers with -O ||(and higher) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28683
[Bug c++/28677] [4.0/4.1 regression] Function prototype in function body crashes compilation
--- Comment #3 from tbm at gcc dot gnu dot org 2006-08-10 19:42 --- Fails with 4.0 and 4.1, works with 3.4 and 4.2. -- tbm at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.0.4 4.1.1 Known to work||3.4.6 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-08-10 19:42:05 date|| Summary|Function prototype in |[4.0/4.1 regression] |function body crashes |Function prototype in |compilation |function body crashes ||compilation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28677
[Bug inline-asm/28686] New: ebp from clobber list used as operand
#ifndef __PIC__
# define REG "ebx"
#else
# define REG "ebp"
#endif
#ifndef NBEFORE
void some_function_before(){
}
#endif
void test_function (){
long var = 42;
asm volatile(
"inc %0\n#DEBUG %%0=%0, clobber: %%"REG", ..."
:"+rm"(var)
:
:"%"REG"","%ecx","%esi","%edi","%edx","%eax");
}
This little piece of code did several strange things for different flags:
1. #DEBUG %0=%ebp, clobber: %ebp, ...
e.g. -fPIC -fomit-frame-pointer -O2, not -DNBEFORE
This is the core of my bug report. The compiler should never ever use a
register from the clobber list to store an operand. It doesn't do this
for ebx, and it doen't do this if there function containing the asm is
the first in the translation unit.
But for ebp and with another function before, this strange bug occurs.
Another function making a difference looks a bit like bug 28635
2. can't find a register in class 'GENERAL_REGS' while reloading 'asm'
e.g. -O1, not -fomit-frame-pointer
This seems to be a problem of -O1. Probably the compiler decides to use
the r alternative and has problems falling back to m when this does not
work.
Perhaps the rationale is that gcc only looks at how to get the variables
into the asm code with the least number of operations, and it's the
programmer's task to make sure all mentioned operand constraints are
possible on the target architecture. But this would be strange.
If it were -O0 instead of -O1 I'd say it's bug 11203
3. #DEBUG %0=-12(%ebp), clobber: %ebp, ...
e.g. -fPIC -O0, not -fomit-frame-pointer
Seems like clobber lists get completely ignored for -O0. Perhaps this
makes sense, as the compiler doen't have to care about registers being
clobbered if all variables are stored in memory.
Still this is strange behaviour.
This is bug 11807
--
Summary: ebp from clobber list used as operand
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Martin dot vGagern at gmx dot net
GCC build triplet: i686-pc-linux-gnu-gcc
GCC host triplet: i686-pc-linux-gnu-gcc
GCC target triplet: i686-pc-linux-gnu-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28686
[Bug c++/28677] [4.0/4.1 regression] Function prototype in function body crashes compilation
--- Comment #4 from tbm at gcc dot gnu dot org 2006-08-10 19:49 ---
{
__inline double fabs (double __x) throw ()
{
}
typedef struct
{
}
*__locale_t;
extern void exit (int __status) throw () __attribute__ ((__noreturn__));
}
void
nrerror (char error_text[])
{
exit (1);
}
float
betacf (float a, float b, float x)
{
void nrerror (char error_text[]);
float aa, c, d, del, h, qab, qam, qap;
d = 1.0 - qab * x / qap;
if (fabs (d) < 1.0e-30)
h = d;
{
if (fabs (d) < 1.0e-30)
d = 1.0e-30;
}
return h;
}
float
betai (float a, float b, float x)
{
void nrerror (char error_text[]);
nrerror ("Bad x in routine betai");
}
--
tbm at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28677
[Bug inline-asm/28686] ebp from clobber list used as operand
--- Comment #1 from Martin dot vGagern at gmx dot net 2006-08-10 19:49 --- Created an attachment (id=12058) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12058&action=view) Test case including compilation result table This is the above test case, and appended is a table matching compiler flags to error messages or register allocation information. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28686
[Bug middle-end/28683] [4.0/4.1/4.2 regression] ICE (segfault in add_reg_br_prob_note) when comparing pointers with -O (and higher)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |critical Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28683
[Bug c++/26757] C++ front-end producing two DECLs with the same UID
--- Comment #29 from pinskia at gcc dot gnu dot org 2006-08-10 20:15 --- This has now been fixed in 4.2.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26757
[Bug c++/28677] [4.0/4.1 regression] Function prototype in function body crashes compilation
--- Comment #5 from tbm at gcc dot gnu dot org 2006-08-10 20:18 ---
Further reduced:
double fabs (double __x) { }
extern void exit (int __status);
void
nrerror (void)
{
exit(0);
}
float
betacf (float x)
{
void nrerror (void);
float d, h;
d = 1.0 - x;
if (fabs (d) < 1.0e-30)
h = d;
return h;
}
void
betai (void)
{
void nrerror (void);
nrerror ();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28677
[Bug c++/28677] [4.0/4.1 regression] Function prototype in function body crashes compilation
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-10 20:19 --- I bet this was fixed by the patch which fixed PR 26757 finnally (comment #28). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org BugsThisDependsOn||26757 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28677
[Bug c++/28687] New: [4.2.0 regression] dynamic_cast disallowed too rigorously with -fno-rtti
gcc version 4.2.0 20060802 (experimental) i686-pc-linux-gnu Code compiled with -fno-rtti containing a dynamic_cast used to compile and work properly on types with a vtable (the base class can be determined entirely using the vtable without any RTTI information). Bug 10891 changed this behavior to be more strict (too strict). There are additional regressions listed from that bug; I feel that bug 10891 ought to be backed out. This materially affects compilation of Mozilla-based products. Testcase forthwith. -- Summary: [4.2.0 regression] dynamic_cast disallowed too rigorously with -fno-rtti Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: benjamin at smedbergs dot us http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28687
[Bug c++/28687] [4.2.0 regression] dynamic_cast disallowed too rigorously with -fno-rtti
--- Comment #1 from benjamin at smedbergs dot us 2006-08-10 20:22 --- Created an attachment (id=12059) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12059&action=view) preprocessed testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28687
[Bug fortran/20541] TR 15581: ALLOCATABLE components
--- Comment #17 from eedelman at gcc dot gnu dot org 2006-08-10 20:23 --- Created an attachment (id=12060) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12060&action=view) New version. Yup, the previous patch wasn't complete (it lacked libgfortran/intrinsics/move_alloc.c); this one should be better. It also addresses the issue pointed out by Thomas Koenig at 2006-05-09. Thanks for testing! -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Attachment #12049|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
[Bug bootstrap/27774] "make install-info" no longer works
--- Comment #5 from hjl at lucon dot org 2006-08-10 20:26 --- Fixed by http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00365.html -- hjl at lucon dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27774
[Bug c++/28687] [4.2 regression] dynamic_cast disallowed too rigorously with -fno-rtti
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-10 20:32 --- Why are you using dynamic_cast here? dynamic_cast needs RTTI, otherwise you could get a crash. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2.0 regression] |[4.2 regression] |dynamic_cast |dynamic_cast |disallowed too rigorously |disallowed too rigorously |with -fno-rtti |with -fno-rtti http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28687
[Bug c++/28641] [4.2 regression] ICE calling template function with invalid template parameter
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.2 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28641
[Bug c++/28677] [4.0/4.1 regression] Function prototype in function body crashes compilation
--- Comment #7 from tbm at gcc dot gnu dot org 2006-08-10 20:44 --- (In reply to comment #6) > I bet this was fixed by the patch which fixed PR 26757 finnally (comment #28). I can confirm this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28677
[Bug c++/28687] [4.2 regression] dynamic_cast disallowed too rigorously with -fno-rtti
--- Comment #3 from benjamin at smedbergs dot us 2006-08-10 20:46 --- This cast in particular doesn't need RTTI, because the offset to the most derived class is in the vtable. Mozilla uses this cast to determine the concrete type for logging purposes, without needing or wanting RTTI information. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28687
[Bug c++/28677] [4.0/4.1 regression] Function prototype in function body crashes compilation
--- Comment #8 from tbm at gcc dot gnu dot org 2006-08-10 20:51 --- (In reply to comment #7) > (In reply to comment #6) > > I bet this was fixed by the patch which fixed PR 26757 finnally (comment > > #28). > > I can confirm this. Jakub, can you apply your patch for PR 26757 to 4.0 and 4.1? -- tbm at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28677
[Bug target/28623] [4.1/4.2 regression] ICE in extract_insn, at recog.c:2077 (nrecognizable insn) [alpha]
--- Comment #2 from falk at debian dot org 2006-08-10 21:11 ---
Confirmed. This is a smaller test case:
int vformat(char *buffer) {
return buffer[32767];
}
This needs -mcpu=ev45. It is triggered by the synthetization
of the 8-bit load by 64-bit loads. ldb v0, x(a0) is done as
lda a0,x+1(a0)
ldq_u v0,-1(a0)
extqh v0,a0,v0
sra v0,56,v0
and if x=32767, this fails.
(Incidentally, maybe we should do
ldq_u t1,x(a0)
lda a0,x+1(a0)
extqh t1,a0,t1
sra t1,56,v0
and save one cycle at the cost of one extra register.)
--
falk at debian dot org changed:
What|Removed |Added
CC||rth at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28623
[Bug c++/28687] [4.2 regression] dynamic_cast disallowed too rigorously with -fno-rtti
--- Comment #4 from bangerth at dealii dot org 2006-08-10 21:25 --- I may not be the only one wondering whether this dynamic_cast(p) is valid code at all. To this end, it may be worth noting section 5.2.7/1 of the standard: 1 The result of the expression dynamic_cast(v) is the result of converting the expression v to type T. T shall be a pointer or reference to a complete class type, or "pointer to cv void". [...] and in 5.2.7/7: 7 If T is "pointer to cv void," then the result is a pointer to the most derived object pointed to by v. Otherwise, a run-time check is applied to see if the object pointed or referred to by v can be converted to the type pointed or referred to by T. It pretty much follows that, indeed, the conversion to a pointer to the most derived object is supposed to happen without any run-time checks involving RTTI. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28687
[Bug inline-asm/11807] GCC should error out when clobbering the stack pointer and frame pointer
--- Comment #25 from Martin dot vGagern at gmx dot net 2006-08-10 21:48 --- (In reply to comment #8) > 1. No way we can support clobbering both SP and FP. You could in theory by storing one of them to some fixed memory location. But here things get really ugly, so this is more of a philosophical answer. > 2. We could support clobbering the FP by pushing it onto the stack and >restoring it. Doesn't seem worth the trouble, though, since people can >do this themselves in the asm. Not necessarily. For x86 with -fomit-frame-pointer, local variables are usually adressed relative to SP. If you push FP onto the stack, you modify SP, and operands are prehaps no longer accessible. If gcc would store FP on the stack, it could take the offset into account and make things work. By the way, the same is imo true for the x86 PIC register ebx, which I would like to see clobberable and stored by gcc as well. Saving and restoring ebx in asm can be a real pain for the above reason. It would be great if the compiler additionaly would ensure that no other operand is an address relative to ebx. > 3. We could support clobbering the SP by introducing a FP and being very >careful. I cannot see any useful application though, so it doesn't seem >worth the trouble. One useful application would be in the sense of "no clobber register may overlap with any of the other operands". You could place the SP on the clobber list to indicate that you are going to modify it, and gcc could then try to avoid emitting SP-relative operands, e.g. by making them FP-relative or shouting if this is not possible. You might even think of this in the sense of "a clobbered register may contain any data at the end of the asm". That would be asm code that uses the stack, but does not clean up afterwards. You could in many cases restore the SP as a fixed offset from the FP, to allow such asm code. BTW: The test case I just wrote for bug 28686 exhibits this problem here as well, along with two other issues. -- Martin dot vGagern at gmx dot net changed: What|Removed |Added CC||Martin dot vGagern at gmx ||dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11807
[Bug java/8923] [4.0/4.1 Regression] ICE when modifying a variable decleared "final static"
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-08-10 22:02 --- Fixed on the mainline. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|3.0.4 |3.0.4 4.2.0 Summary|[4.0/4.1/4.2 Regression] ICE|[4.0/4.1 Regression] ICE |when modifying a variable |when modifying a variable |decleared "final static"|decleared "final static" http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8923
[Bug c++/28677] [4.0/4.1 regression] Function prototype in function body crashes compilation
--- Comment #9 from janis at gcc dot gnu dot org 2006-08-10 23:15 --- In case Jakub's patch can't be backported easily, this might be useful. A regression hunt on powerpc-linux identified the following patch as the start of failures for the testcase in comment #5: http://gcc.gnu.org/viewcvs?view=rev&rev=83405 r83405 | zack | 2004-06-20 08:34:54 + (Sun, 20 Jun 2004) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28677
[Bug c++/28677] [4.0/4.1 regression] Function prototype in function body crashes compilation
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-08-10 23:25 --- (In reply to comment #9) > http://gcc.gnu.org/viewcvs?view=rev&rev=83405 Not really, it was this part that caused it: * name-lookup.c (pushdecl): When a local extern shadows a file-scope declaration of the same object, give both DECLs the same DECL_UID. Which I was semi expecting. And this is related to PR 16792. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||16792 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28677
[Bug c++/28687] [4.2 regression] dynamic_cast disallowed too rigorously with -fno-rtti
--- Comment #5 from gdr at integrable-solutions dot net 2006-08-11 01:20 --- Subject: Re: New: [4.2.0 regression] dynamic_cast disallowed too rigorously with -fno-rtti "benjamin at smedbergs dot us" <[EMAIL PROTECTED]> writes: | Code compiled with -fno-rtti containing a dynamic_cast used to compile | and work properly on types with a vtable (the base class can be determined | entirely using the vtable without any RTTI information). RTTI is needed to have dynamic_cast works properly. Period. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28687
