[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) also in n3224(cpp0x), 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 imzhuli at vip dot qq.com 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 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #13 from rsandifo at gcc dot gnu.org 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 rguenth at gcc dot gnu.org 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 rguenth at gcc dot gnu.org 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 rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 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 redi at gcc dot gnu.org 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 redi at gcc dot gnu.org 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 ebotcazou at gcc dot gnu.org 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 ebotcazou at gcc dot gnu.org 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 ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
CC||ebotcazou at gcc dot
||gnu.org
--- Comment #17 from Eric Botcazou ebotcazou at gcc dot gnu.org 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 imzhuli at vip dot qq.com 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 rguenth at gcc dot gnu.org 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 imzhuli at vip dot qq.com 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 gjl at gcc dot gnu.org changed: What|Removed |Added Target|atmel avr |avr CC||gjl at gcc dot gnu.org --- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org 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 marc.glisse at normalesup dot org changed: What|Removed |Added Attachment #25140|0 |1 is obsolete|| --- Comment #32 from Marc Glisse marc.glisse at normalesup dot org 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 ebotcazou at gcc dot gnu.org 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 ebotcazou at gcc dot gnu.org 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 ebotcazou at gcc dot gnu.org 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 iains at gcc dot gnu.org 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 doko at gcc dot gnu.org 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 ebotcazou at gcc dot gnu.org 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 ebotcazou at gcc dot gnu.org 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 ebotcazou at gcc dot gnu.org changed: What|Removed |Added Attachment #25182|0 |1 is obsolete|| --- Comment #10 from Eric Botcazou ebotcazou at gcc dot gnu.org 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 zbeekman at gmail dot com 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 danglin at gcc dot gnu.org 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 danglin at gcc dot gnu.org 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 danglin at gcc dot gnu.org 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 danglin at gcc dot gnu.org 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=gccview=revrev=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 danglin at gcc dot gnu.org 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=gccview=revrev=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 iains at gcc dot gnu.org 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 hjl.tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-09/msg00223.htm ||l --- Comment #17 from H.J. Lu hjl.tools at gmail dot com 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 ebotcazou at gcc dot gnu.org 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 danglin at gcc dot gnu.org 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 danglin at gcc dot gnu.org 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 rafael.espindola at gmail dot com 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 rafael.espindola at gmail dot com 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 tg at mirbsd dot org changed: What|Removed |Added Severity|normal |critical --- Comment #1 from Thorsten Glaser tg at mirbsd dot org 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 jamborm at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org 2011-09-03 19:41:26 UTC --- Fixed on both trunk and the 4.6 branch.
[Bug c++/50285] New: no known conversion for argument 1: 'X' to 'X'
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 In
[Bug c/50284] possible miscompilation with -fstrict-aliasing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50284
--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 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 rguenth at gcc dot gnu.org 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 rafael.espindola at gmail dot
com 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 stdio.h
int main(int argc, char **argv)
{
int i;
const int flag=argc1;
i=0;
do{
printf(%d\n,i*i);
}while(++i1+flag);
return 0;
}
and so it doesn't unroll the loop.
If 1+flag is changed to 1+!!flag, 1+(bool)flag, or 1+(argc1) 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 rafael.espindola at gmail dot com changed: What|Removed |Added Attachment #25188|0 |1 is obsolete|| --- Comment #5 from Rafael Avila de Espindola rafael.espindola at gmail dot com 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.
