[Bug c++/50282] New: pointer-to-member cast works incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50282 Bug #: 50282 Summary: pointer-to-member cast works incorrectly Classification: Unclassified Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: imzh...@vip.qq.com Created attachment 25180 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25180 compile-info (command line, and g++ output), t.cpp (source), t.ii in ISO/IEC 14882 (cpp2003) , chapter 5.2.10 about reinterpret_cast, the rule 9 says: " An rvalue of type “pointer to member of X of type T1” can be explicitly converted to an rvalue of type “pointer to member of Y of type T2” if T1 and T2 are both function types or both object types.66) The null member pointer value (4.11) is converted to the null member pointer value of the destination type. The result of this conversion is unspecified, except in the following cases: — converting an rvalue of type “pointer to member function” to a different pointer to member function type and back to its original type yields the original pointer to member value. — converting an rvalue of type “pointer to data member of X of type T1” to the type “pointer to data member of Y of type T2” (where the alignment requirements of T2 are no stricter than those of T1) and back to its original type yields the original pointer to member value. " but as i tested using G++ 4.1.2 (SUSE LINUX 11) / G++ 4.5.5 (UBUNTU 11.04), this is not exactly implemented. detailed comments are in the attachments. attachment: 1.compile info.txt 2.t.ii /test-case ii file 3.tiny single test-case source-file which includes ONLY c++ standered headers, detailed commented.
[Bug c++/50282] pointer-to-member cast works incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50282 zhuli changed: What|Removed |Added Severity|critical|major
[Bug target/49987] [4.7 Regression] gcc.c-torture/compile/pr34856.c fails on powerpc-darwin9 from r176228
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49987 rsand...@gcc.gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #13 from rsandifo at gcc dot gnu.org 2011-09-03 08:38:41 UTC --- Fixed on trunk. Thanks for the help with the testing.
[Bug fortran/50278] [4.7 Regression] SPEC CPU 2000 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50278 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug debug/50279] [4.7 Regression] ICE while building the go front-end with LTO enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50279 Richard Guenther changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code Target Milestone|--- |4.7.0
[Bug target/50281] result registers are overwritten giving incorrect result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #9 from Richard Guenther 2011-09-03 08:50:27 UTC --- bogus asm
[Bug c++/50282] pointer-to-member cast works incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50282 --- Comment #1 from Jonathan Wakely 2011-09-03 08:55:38 UTC --- uint32_t isn't big enough to hold a pointer-to-member value, and that conversion isn't valid anyway
[Bug c++/50282] pointer-to-member cast works incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50282 Jonathan Wakely changed: What|Removed |Added Severity|major |normal
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 Eric Botcazou changed: What|Removed |Added Summary|[4.7 regression] comparison |[4.7 regression] bootstrap |failure caused by |comparison failure for |HAVE_INITFINI_ARRAY check |libcpp/lex.o Severity|blocker |critical --- Comment #16 from Eric Botcazou 2011-09-03 09:31:22 UTC --- The --disable-initfini-array workaround works fine so downgrading slightly.
[Bug middle-end/50251] [4.7 Regression] Revision 178353 caused many test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #17 from Eric Botcazou 2011-09-03 09:47:08 UTC --- > This patch sets need_drap when a stack_restore is present at expand, which > allows both the 20010209-1.c and the stack-stave-restore.c testcase to > succeed: > ... > Index: src/gcc-mainline/gcc/explow.c > === > --- src/gcc-mainline/gcc/explow.c (revision 178379) > +++ src/gcc-mainline/gcc/explow.c (working copy) > @@ -1062,6 +1062,9 @@ emit_stack_restore (enum save_level save >/* The default is that we use a move insn. */ >rtx (*fcn) (rtx, rtx) = gen_move_insn; > > + if (SUPPORTS_STACK_ALIGNMENT) > +crtl->need_drap = true; > + >/* See if this machine has anything special to do for this kind of save. > */ >switch (save_level) > { > ... Does this force stack realignment, or only the use of the DRAP if we already do stack realignment?
[Bug c++/50282] pointer-to-member cast works incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50282 --- Comment #2 from zhuli 2011-09-03 11:31:57 UTC --- I've never used any unint32_t tu hold any pointer-to-member, I just tested and find out the sizeof (pointer-to-member-function) is 16, then i used a pointer-to-uint32_t four times to dump the value of the pointer-to-member, 32bits by 32bits. According my understanding to the standard, this conversion should be valid, or there must be any valid way . (In reply to comment #1) > uint32_t isn't big enough to hold a pointer-to-member value, and that > conversion isn't valid anyway
[Bug c++/50282] pointer-to-member cast works incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50282 --- Comment #3 from Richard Guenther 2011-09-03 12:00:49 UTC --- (In reply to comment #2) > I've never used any unint32_t tu hold any pointer-to-member, > I just tested and find out the sizeof (pointer-to-member-function) is 16, > then i used a pointer-to-uint32_t four times to dump the value of the > pointer-to-member, 32bits by 32bits. > > According my understanding to the standard, this conversion should be valid, > or > there must be any valid way . The above violates C++ aliasing rules but would be supported by GCC as an extension with -O[01] or -fno-strict-aliasing. The standard only allows accessing the storage via a character type (thus, dump 16 individual bytes via a char * pointer). > (In reply to comment #1) > > uint32_t isn't big enough to hold a pointer-to-member value, and that > > conversion isn't valid anyway
[Bug c++/50282] pointer-to-member cast works incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50282 --- Comment #4 from zhuli 2011-09-03 12:17:35 UTC --- yes, you are right. As an addition, compiling with -O2 might yield an warning, as you metioned. but i checked my env(32-bit) and used default compiler option, so i just simply assumed 4byte-object & 16byte-object share the same alignment. and as this is not the point of the issue, i didnt take much care about that. In fact, i seldom use such code, even to debug. Anyway, you comment is advisable, thanks. (In reply to comment #3) > (In reply to comment #2) > > I've never used any unint32_t tu hold any pointer-to-member, > > I just tested and find out the sizeof (pointer-to-member-function) is 16, > > then i used a pointer-to-uint32_t four times to dump the value of the > > pointer-to-member, 32bits by 32bits. > > > > According my understanding to the standard, this conversion should be > > valid, or > > there must be any valid way . > > The above violates C++ aliasing rules but would be supported by GCC as an > extension with -O[01] or -fno-strict-aliasing. The standard only allows > accessing the storage via a character type (thus, dump 16 individual bytes via > a char * pointer). > > > (In reply to comment #1) > > > uint32_t isn't big enough to hold a pointer-to-member value, and that > > > conversion isn't valid anyway
[Bug target/50256] AVR GCC - several unnecessary register moves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50256 Georg-Johann Lay changed: What|Removed |Added Target|atmel avr |avr CC||gjl at gcc dot gnu.org --- Comment #3 from Georg-Johann Lay 2011-09-03 12:34:49 UTC --- Supported versions of GCC are 4.4 upward at the moment. Your C-code does not show a call to MulU3U3S3 and the constants 167772 resp. 10 occur nowhere. Please follow http://gcc.gnu.org/bugs/#need when reporting bugs. Thanks. Notice that early clobber forces moves. Moreover, some value is passed in r20 but you clobber that register so that register must be freed i.e. that forces a move, too. Maybe you want your function static inline. Also notice that if you have MUL, you always have MOVW. You don't need to save/restore __tmp_reg__. You don't need to save __zero_reg__. It is sufficient to CLR __zero_reg__ after you are done. Last not least, you arithmetic apprears to be wrong because you add at most 3 bytes and lose the carries above.
[Bug middle-end/50251] [4.7 Regression] Revision 178353 caused many test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251 --- Comment #18 from vries at gcc dot gnu.org 2011-09-03 12:40:12 UTC --- > Does this force stack realignment, or only the use of the DRAP if we already > do stack realignment? only the use of the DRAP if we already do stack realignment.
[Bug c++/2316] g++ fails to overload on language linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316 Marc Glisse changed: What|Removed |Added Attachment #25140|0 |1 is obsolete|| --- Comment #32 from Marc Glisse 2011-09-03 13:00:20 UTC --- Created attachment 25181 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25181 remember linkage of a function type (3) This version of the patch, with -fpermissive and without -Werror, bootstraps gcc without requiring any patching. -fpermissive does most of the work of allowing any conversion, I only had to add some code so "&operator new[]" (overloaded) knew which conversion to pick. Obviously the patch needs completing (I am certainly missing many things), cleaning up, and additional work to allow conversions without -fpermissive, and only those that differ only by extern "C" somewhere. In other words it still needs to be (re)written ;-) But I think it is very encouraging that it compiles gcc (including libstdc++) without any patching (but lots of warnings), which means this bug might be fixed without breaking too much user code (we can be more lax than sunpro, which rejects gcc sources in 2 places). And I don't think it introduces too much ambiguity (overloading on linkage still works on a few tests).
[Bug middle-end/50266] [4.6/4.7 Regression] internal compiler error: in decode_addr_const, at varasm.c:2638
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50266 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED CC|ebotcazou at gcc dot| |gnu.org | AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org --- Comment #4 from Eric Botcazou 2011-09-03 13:23:55 UTC --- Looking into it.
[Bug target/50091] [4.5/4.6/4.7 Regression] -fstack-check gives bad assembly on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50091 --- Comment #7 from Eric Botcazou 2011-09-03 13:28:43 UTC --- Created attachment 25182 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25182 Tentative fix Untested as of this writing.
[Bug target/50091] [4.5/4.6/4.7 Regression] -fstack-check gives bad assembly on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50091 --- Comment #8 from Iain Sandoe 2011-09-03 14:17:12 UTC --- (In reply to comment #7) > Created attachment 25182 [details] > Tentative fix > > Untested as of this writing. Thanks, starting bootstrap in a minute .. . ... your patch + this (and some unrelated fixes for powerpc ADA bootstrap): Index: gcc/config/rs6000/rs6000.c === @@ -19303,7 +19308,10 @@ output_asm_insn ("{cal %0,%1(%0)|addi %0,%0,%1}", xops); /* Probe at TEST_ADDR and branch. */ - output_asm_insn ("{st|stw} 0,0(%0)", xops); + if (TARGET_MACHO) +output_asm_insn ("{st|stw} r0,0(%0)", xops); + else +output_asm_insn ("{st|stw} 0,0(%0)", xops); fprintf (asm_out_file, "\tb "); assemble_name_raw (asm_out_file, loop_lab); fputc ('\n', asm_out_file);
[Bug c++/48660] [4.5/4.6/4.7 Regression] ARM ICE in expand_expr_real_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48660 --- Comment #5 from Matthias Klose 2011-09-03 14:18:30 UTC --- works with 4.4.6, not with 4.5/4.6/trunk 20110824
[Bug middle-end/50266] [4.6/4.7 Regression] internal compiler error: in decode_addr_const, at varasm.c:2638
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50266 --- Comment #5 from Eric Botcazou 2011-09-03 14:32:01 UTC --- > and we have a CTOR and not individual initializations because of Erics > const-pool changes I believe. No, we have the constructor with GCC 4.5 as well, my patch only makes it go through tree_output_constant_def. > &p->a is folded to &1241530624B->a even before gimplification (but > &1241530624B->a is "unfolded" - it's an obfuscated constant). > > We ICE from > > #0 fancy_abort ( > file=0x1252a70 "/space/rguenther/src/svn/gcc-4_6-branch/gcc/varasm.c", > line=2638, function=0x1253700 "decode_addr_const") > at /space/rguenther/src/svn/gcc-4_6-branch/gcc/diagnostic.c:893 > #1 0x00ca9016 in decode_addr_const (exp=0x2ceb3fc0, > value=0x7fff9b30) > at /space/rguenther/src/svn/gcc-4_6-branch/gcc/varasm.c:2638 > #2 0x00ca97f0 in const_hash_1 (exp=0x2ceb3fc0) > at /space/rguenther/src/svn/gcc-4_6-branch/gcc/varasm.c:2734 > #3 0x00ca95db in const_hash_1 (exp=0x2cea54e0) > at /space/rguenther/src/svn/gcc-4_6-branch/gcc/varasm.c:2724 > #4 0x00cace7a in tree_output_constant_def (exp=0x2cea54e0) > at /space/rguenther/src/svn/gcc-4_6-branch/gcc/varasm.c:3302 > #5 0x0083a5f4 in gimplify_init_constructor (expr_p=0x7fffb3a8, > pre_p=0x7fffccf8, post_p=0x7fffa928, want_value=0 '\000', > notify_temp_creation=0 '\000') > at /space/rguenther/src/svn/gcc-4_6-branch/gcc/gimplify.c:3833 > > and fold &p->a via c_fully_fold_internal. This is a known issue, namely that tree_output_constant_def rejects offsetof computations. See PR middle-end/44100 for an example with the C++ compiler. I think this should be folded in the front-end - c_fully_fold is kind of a misnomer if it can only partially fold &p->a. It's just a matter of copying the chunk of code present in build_unary_op, no big deal IMO. And this compiles fine in C++ because the folding is done: Starting program: /home/eric/build/gcc/native/gcc/cc1plus -quiet pr50266.c -quiet -mtune=generic -march=x86-64 -Os Breakpoint 1, tree_output_constant_def (exp=0x76edbdf8) at /home/eric/svn/gcc/gcc/varasm.c:3295 3295 key.value = exp; (gdb) p debug_generic_expr(exp) {1241530624B, 1241530628B, 0B}
[Bug target/50091] [4.5/4.6/4.7 Regression] -fstack-check gives bad assembly on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50091 --- Comment #9 from Eric Botcazou 2011-09-03 14:45:01 UTC --- > Thanks, starting bootstrap in a minute .. . > > ... your patch + this (and some unrelated fixes for powerpc ADA bootstrap): > > Index: gcc/config/rs6000/rs6000.c > === > @@ -19303,7 +19308,10 @@ >output_asm_insn ("{cal %0,%1(%0)|addi %0,%0,%1}", xops); > >/* Probe at TEST_ADDR and branch. */ > - output_asm_insn ("{st|stw} 0,0(%0)", xops); > + if (TARGET_MACHO) > +output_asm_insn ("{st|stw} r0,0(%0)", xops); > + else > +output_asm_insn ("{st|stw} 0,0(%0)", xops); >fprintf (asm_out_file, "\tb "); >assemble_name_raw (asm_out_file, loop_lab); >fputc ('\n', asm_out_file); Ah, thanks, I missed this. Something like the to-be-attached patch would be more correct though, I think.
[Bug target/50091] [4.5/4.6/4.7 Regression] -fstack-check gives bad assembly on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50091 Eric Botcazou changed: What|Removed |Added Attachment #25182|0 |1 is obsolete|| --- Comment #10 from Eric Botcazou 2011-09-03 14:46:20 UTC --- Created attachment 25183 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25183 Tentative fix (2) Still untested.
[Bug fortran/49149] Dependency autogeneration with `-M` rendered useless by requiring .mod files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149 --- Comment #14 from Zaak 2011-09-03 14:46:57 UTC --- cricket
[Bug tree-optimization/50052] [4.6/4.7 Regression] FAIL: gcc.dg/ipa/ipa-sra-2.c scan-tree-dump eipa_sra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50052 --- Comment #2 from John David Anglin 2011-09-03 15:29:32 UTC --- Created attachment 25184 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25184 tree dump
[Bug tree-optimization/50052] [4.6/4.7 Regression] FAIL: gcc.dg/ipa/ipa-sra-2.c scan-tree-dump eipa_sra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50052 --- Comment #3 from John David Anglin 2011-09-03 15:31:12 UTC --- Created attachment 25185 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25185 tree dump
[Bug tree-optimization/50052] [4.6/4.7 Regression] FAIL: gcc.dg/ipa/ipa-sra-2.c scan-tree-dump eipa_sra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50052 --- Comment #4 from John David Anglin 2011-09-03 15:33:37 UTC --- Created attachment 25186 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25186 tree dump
[Bug middle-end/50232] [4.7 Regression] reorg.c:3971: undefined reference to `make_return_insns'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50232 --- Comment #6 from John David Anglin 2011-09-03 16:21:38 UTC --- Author: danglin Date: Sat Sep 3 16:21:27 2011 New Revision: 178500 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178500 Log: PR Bug middle-end/50232 * config/pa/pa.md (return): Define "return" insn pattern. (epilogue): Use it when no epilogue is needed. * config/pa/pa.c (pa_can_use_return_insn): New function. * config/pa/pa-protos.h (pa_can_use_return_insn): Declare. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa-protos.h trunk/gcc/config/pa/pa.c trunk/gcc/config/pa/pa.md
[Bug middle-end/50232] [4.7 Regression] reorg.c:3971: undefined reference to `make_return_insns'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50232 --- Comment #7 from John David Anglin 2011-09-03 16:30:42 UTC --- Author: danglin Date: Sat Sep 3 16:30:32 2011 New Revision: 178501 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178501 Log: PR middle-end/50232 Correct log entry for last change. Modified: trunk/gcc/ChangeLog
[Bug target/50091] [4.5/4.6/4.7 Regression] -fstack-check gives bad assembly on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50091 --- Comment #11 from Iain Sandoe 2011-09-03 16:48:18 UTC --- (In reply to comment #10) > Created attachment 25183 [details] > Tentative fix (2) > > Still untested. bootstrapped with your amended change to rs6000.c ./gcc/xgcc -Bgcc ../tests/hello.c -o hc -fstack-check -save-temps -fverbose-asm -fdump-rtl-all ... shows that the stack check is present and correct ... any idea what test would produce the stack range check? (make check is running - but will take some time).
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 H.J. Lu changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-09/msg00223.htm ||l --- Comment #17 from H.J. Lu 2011-09-03 17:16:17 UTC --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00223.html
[Bug target/50091] [4.5/4.6/4.7 Regression] -fstack-check gives bad assembly on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50091 --- Comment #12 from Eric Botcazou 2011-09-03 17:28:32 UTC --- > bootstrapped with your amended change to rs6000.c > ./gcc/xgcc -Bgcc ../tests/hello.c -o hc -fstack-check -save-temps > -fverbose-asm > -fdump-rtl-all > ... shows that the stack check is present and correct ... > any idea what test would produce the stack range check? You'd need to define STACK_CHECK_STATIC_BUILTIN to 1 for PowerPC/Darwin and have a large frame. > (make check is running - but will take some time). Thanks for the testing.
[Bug other/50283] New: [4.7 Regression] FAIL: g++.dg/eh/simd-1.C execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50283 Bug #: 50283 Summary: [4.7 Regression] FAIL: g++.dg/eh/simd-1.C execution test Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org CC: r...@gcc.gnu.org Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../g++ -B/test/gnu/gcc/objdir/gcc/testsuite/g++/../../ /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/eh/simd-1.C -nostdinc++ -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O -Wno-abi -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs -lm -o ./simd-1.exe(timeout = 300) PASS: g++.dg/eh/simd-1.C (test for excess errors) Setting LD_LIBRARY_PATH to .:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs:/test/gnu/gcc/objdir/gcc:.:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs:/test/gnu/gcc/objdir/gcc WARNING: program timed out. FAIL: g++.dg/eh/simd-1.C execution test The throw in f3 results in an infinite unwind loop. Thought at first that this might be caused by stack allocation instruction being placed in call delay slot, but fail also occurs at -O0. Similar fails are: FAIL: g++.dg/eh/simd-2.C execution test FAIL: g++.dg/opt/eh2.C execution test
[Bug other/50283] [4.7 Regression] FAIL: g++.dg/eh/simd-1.C execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50283 --- Comment #1 from John David Anglin 2011-09-03 18:20:58 UTC --- (In reply to comment #0) > Thought at first that this might be caused by stack allocation instruction > being placed in call delay slot, but fail also occurs at -O0. This is wrong. The test doesn't fail at -O0 (I ran the wrong executable). At -O, the CFI labels appear incorrectly placed
[Bug other/50283] [4.7 Regression] FAIL: g++.dg/eh/simd-1.C execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50283 --- Comment #2 from John David Anglin 2011-09-03 18:21:24 UTC --- Created attachment 25187 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25187 .s file
[Bug c/50284] New: possible miscompilation with -fstrict-aliasing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50284 Bug #: 50284 Summary: possible miscompilation with -fstrict-aliasing Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: rafael.espind...@gmail.com I am not sure if the attached program is valid, but I think it is covered by c99 6.5 p7. On irc pinkia points out that it might be invalid. His arguments are * upcast is undefined in general, 6.5 p7 is trying to allow downcasting. * upcasting is defined when the type was originally that type. Two followup observations are that * If we read "z->data.XXX" as an access to the member (an not the full structure), all the access in the program are of the correct type. * On the implementation side, this "bug" show up when main is in a another translation unit too, a case where gcc could not know if "the type was originally that type". Philip Taylor pointed me at http://davmac.wordpress.com/2010/02/26/c99-revisited/ which has an interesting discussion about "Does accessing an object constitute access to the containing object"? This bug is "fixed" on trunk by 160947, but since that is an optimization change, it probably has just deactivated the code path that caused this behavior. For some context, this testcase is a reduction from: http://hg.mozilla.org/mozilla-central/file/a351ae35f2c4/js/src/jscntxtinlines.h#l179
[Bug c/50284] possible miscompilation with -fstrict-aliasing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50284 --- Comment #1 from Rafael Avila de Espindola 2011-09-03 18:53:58 UTC --- Created attachment 25188 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25188 testcase
[Bug c/50284] possible miscompilation with -fstrict-aliasing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50284 --- Comment #2 from Rafael Avila de Espindola 2011-09-03 19:07:54 UTC --- Forgot to mention, this only reproduces with -fPIC. So to reproduce this you need * a linux 32 bit build older than 160947 * run cc1 with: -quiet -fPIC -O2 -std=c99
[Bug java/49847] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847 Thorsten Glaser changed: What|Removed |Added Severity|normal |critical --- Comment #1 from Thorsten Glaser 2011-09-03 19:32:10 UTC --- Raising importance; this bug prevents 4.6 from being switched to in Debian.
[Bug middle-end/49886] [4.6/4.7 Regression] pass_split_functions cannot deal with function type attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49886 Martin Jambor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #5 from Martin Jambor 2011-09-03 19:41:26 UTC --- Fixed on both trunk and the 4.6 branch.
gcc-bugs@gcc.gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50285 Bug #: 50285 Summary: no known conversion for argument 1: 'X' to 'X&' Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: mainm...@chello.at Please tell me I'm misreading the error message. g++ -v -save-temps -DHAVE_CONFIG_H -I. -I../../../../../../trunk/source/gepetto/database/access -I../../../.. -I../../../../../../trunk/source -isystem/home/anubis/CPP/boost-svn/ -O2 -g3 -Wall -Wno-long-long -Wfloat-equal -pedantic -ansi -MT test/test_unit__join-join.tc.o -MD -MP -MF test/.deps/test_unit__join-join.tc.Tpo -c -o test/test_unit__join-join.tc.o `test -f 'test/join.tc.cpp' || echo '../../../../../../trunk/source/gepetto/database/access/'`test/join.tc.cpp Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/src/gcc-4.6-20110819/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --enable-gnu-unique-object --enable-linker-build-id --with-ppl --enable-cloog-backend=isl --enable-lto --enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold --disable-multilib --disable-libssp --disable-libstdcxx-pch --enable-checking=release Thread model: posix gcc version 4.6.1 20110819 (prerelease) (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-D' 'HAVE_CONFIG_H' '-I' '.' '-I' '../../../../../../trunk/source/gepetto/database/access' '-I' '../../../..' '-I' '../../../../../../trunk/source' '-isystem' '/home/anubis/CPP/boost-svn/' '-O2' '-g3' '-Wall' '-Wno-long-long' '-Wfloat-equal' '-pedantic' '-ansi' '-MT' 'test/test_unit__join-join.tc.o' '-MD' '-MP' '-MF' 'test/.deps/test_unit__join-join.tc.Tpo' '-c' '-o' 'test/test_unit__join-join.tc.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/cc1plus -E -quiet -v -I . -I ../../../../../../trunk/source/gepetto/database/access -I ../../../.. -I ../../../../../../trunk/source -MD test/test_unit__join-join.tc.d -MF test/.deps/test_unit__join-join.tc.Tpo -MP -MT test/test_unit__join-join.tc.o -dD -D_GNU_SOURCE -D HAVE_CONFIG_H -isystem /home/anubis/CPP/boost-svn/ ../../../../../../trunk/source/gepetto/database/access/test/join.tc.cpp -mtune=generic -march=x86-64 -ansi -Wall -Wno-long-long -Wfloat-equal -pedantic -g3 -fworking-directory -O2 -fpch-preprocess -o join.tc.ii ignoring nonexistent directory "/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/../../../../x86_64-unknown-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: . ../../../../../../trunk/source/gepetto/database/access ../../../.. ../../../../../../trunk/source /home/anubis/CPP/boost-svn/ /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/../../../../include/c++/4.6.1 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/../../../../include/c++/4.6.1/x86_64-unknown-linux-gnu /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/../../../../include/c++/4.6.1/backward /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/include /usr/local/include /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-D' 'HAVE_CONFIG_H' '-I' '.' '-I' '../../../../../../trunk/source/gepetto/database/access' '-I' '../../../..' '-I' '../../../../../../trunk/source' '-isystem' '/home/anubis/CPP/boost-svn/' '-O2' '-g3' '-Wall' '-Wno-long-long' '-Wfloat-equal' '-pedantic' '-ansi' '-MT' 'test/test_unit__join-join.tc.o' '-MD' '-MP' '-MF' 'test/.deps/test_unit__join-join.tc.Tpo' '-c' '-o' 'test/test_unit__join-join.tc.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/cc1plus -fpreprocessed join.tc.ii -quiet -dumpbase join.tc.cpp -mtune=generic -march=x86-64 -auxbase-strip test/test_unit__join-join.tc.o -g3 -O2 -Wall -Wno-long-long -Wfloat-equal -pedantic -ansi -version -o join.tc.s GNU C++ (GCC) version 4.6.1 20110819 (prerelease) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.1 20110819 (prerelease), GMP version 5.0.2, MPFR version 3.0.1-p4, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++ (GCC) version 4.6.1 20110819 (prerelease) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.1 20110819 (prerelease), GMP version 5.0.2, MPFR version 3.0.1-p4, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 28ab00cbdb55abc964d7174615d645a6
[Bug c/50284] possible miscompilation with -fstrict-aliasing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50284 --- Comment #3 from Richard Guenther 2011-09-03 20:52:49 UTC --- struct Value { struct jsval data; }; ... struct jsval y = t3.array[i]; struct Value *z = (struct Value*)&y; if (z->data.tag == 0xFF85) { that's invalid in GCCs reading of 6.5 p7. jsval is a subset of Value's alias-set but not the other way around. GCC reads z->data.tag as an access to an object of type Value which is invalid. The contorted reasoning is that the pointer conversion invokes undefined behavior. Definitely an interesting blog post ;)
[Bug other/50283] [4.7 Regression] FAIL: g++.dg/eh/simd-1.C execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50283 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug c/50284] possible miscompilation with -fstrict-aliasing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50284 --- Comment #4 from Rafael Avila de Espindola 2011-09-03 22:54:10 UTC --- (In reply to comment #3) > struct Value { > struct jsval data; > }; > ... > struct jsval y = t3.array[i]; > struct Value *z = (struct Value*)&y; > if (z->data.tag == 0xFF85) { > > that's invalid in GCCs reading of 6.5 p7. jsval is a subset of Value's > alias-set > but not the other way around. GCC reads z->data.tag as an access to an > object of type Value which is invalid. So downcast (i.e. casting to a more specialized type) are invalid even if original data type is correct (not that it is in the reduced testcase)? That is really strict :-( > The contorted reasoning is that the pointer conversion invokes undefined > behavior. Definitely an interesting blog post ;) is there any hope that gcc could be made a bit less strict? Either reading the member access as not involving an access to the full object or accepting downcasts (when the original type matches) would work. My preference would be for the second option, as downcasts are fairly common in OO.
[Bug c/50286] New: Missed optimization, fails to propagate bool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50286 Bug #: 50286 Summary: Missed optimization, fails to propagate bool Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: gmaxw...@gmail.com GCC 4.7.0 (and prior) are unable to determine maximum loop counts in code that looks like: #include int main(int argc, char **argv) { int i; const int flag=argc>1; i=0; do{ printf("%d\n",i*i); }while(++i<1+flag); return 0; } and so it doesn't unroll the loop. If 1+flag is changed to 1+!!flag, 1+(bool)flag, or 1+(argc>1) then -O3 unrolls the loop. Interestingly, making flag type bool doesn't fix it and also doesn't unroll in the 1+!!flag case.
[Bug tree-optimization/50287] New: FAIL: gcc.c-torture/execute/builtins/vsnprintf-chk.c compilation, -O2 -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50287 Bug #: 50287 Summary: FAIL: gcc.c-torture/execute/builtins/vsnprintf-chk.c compilation, -O2 -flto Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: kkoj...@gcc.gnu.org Target: arm-eabi sh*-*-* Several gcc.c-torture/execute/builtins/*-chk.c tests fail for ARM and SH with -O2 -flto: gcc/testsuite/gcc.c-torture/execute/builtins/lib/chk.c: In function '__vsnprintf_chk': gcc/testsuite/gcc.c-torture/execute/builtins/lib/chk.c:398:1: error: number of operands and imm-links don't agree in statement # .MEM_57 = VDEF <.MEM_22> ap = ap_18(D); gcc/testsuite/gcc.c-torture/execute/builtins/lib/chk.c:398:1: internal compiler error: verify_ssa failed A reduced testcase for arm-eabi: static char buf[4096]; int __attribute__((format(printf,4,0))) foo (char *str, unsigned int len, unsigned int size, const char *fmt, __builtin_va_list ap); int foo (char *str, unsigned int len, unsigned int size, const char *fmt, __builtin_va_list ap) { if (!size) return 0; if (size < len) bar (str, buf, size + 1); else bar (str, buf, len - 1); return 0; } It has started to fail after revision 178386. It seems that the fix for PR49886 reveals this issue. -fno-partial-inlining makes the ICE go away.
[Bug c/50284] possible miscompilation with -fstrict-aliasing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50284 Rafael Avila de Espindola changed: What|Removed |Added Attachment #25188|0 |1 is obsolete|| --- Comment #5 from Rafael Avila de Espindola 2011-09-04 03:49:59 UTC --- Created attachment 25189 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25189 a better testcase This one allocates the original objects as the "derived class" Value.