[Bug target/52378] Can't build most recent svn version, i.e., trunk 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52378 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-02-25 Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski 2012-02-25 07:46:51 UTC --- >./configure I bet this is just a problem with you building in the src directory. This is not always supported and not always 100% working. Can you try building in an object directory? Also do you have flex since that is required while building from subversion (but not from the release tarballs)?
[Bug target/52378] New: Can't build most recent svn version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52378 Bug #: 52378 Summary: Can't build most recent svn version Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: l...@qtrac.plus.com I did the svn read-only checkout for trunk: : svn info Path: . URL: svn://gcc.gnu.org/svn/gcc/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 184569 Node Kind: directory Schedule: normal Last Changed Author: ian Last Changed Rev: 184569 Last Changed Date: 2012-02-25 02:11:29 + (Sat, 25 Feb 2012) This is into /home/mark/opt/gcc-svn-src I then configured with ./configure --prefix=/home/mark/opt/gcc I then did make: ... make[3]: Entering directory `/home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc' gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/gengtype \ build/gengtype.o build/errors.o build/gengtype-lex.o build/gengtype-parse.o build/gengtype-state.o build/version.o ../../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a gcc -g -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/gencheck \ build/gencheck.o ../../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a build/gengtype.o: In function `create_optional_field_': /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype.c:854: undefined reference to `lexer_line' build/gengtype.o: In function `adjust_field_rtx_def': /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype.c:989: undefined reference to `lexer_line' /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype.c:1045: undefined reference to `lexer_line' /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype.c:1055: undefined reference to `lexer_line' /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype.c:1120: undefined reference to `lexer_line' build/gengtype.o:/home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype.c:1159: more undefined references to `lexer_line' follow build/gengtype-parse.o: In function `token': /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:53: undefined reference to `yylex' build/gengtype-parse.o: In function `parse_error': /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:142: undefined reference to `lexer_line' /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:142: undefined reference to `lexer_line' build/gengtype-parse.o: In function `struct_field_seq': /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:692: undefined reference to `lexer_line' build/gengtype-parse.o: In function `type': /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:726: undefined reference to `lexer_line' /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:758: undefined reference to `lexer_line' build/gengtype-parse.o:/home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:758: more undefined references to `lexer_line' follow build/gengtype-parse.o: In function `parse_file': /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:951: undefined reference to `yybegin' /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:986: undefined reference to `lexer_toplevel_done' /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:991: undefined reference to `yyend' collect2: ld returned 1 exit status make[3]: *** [build/gengtype] Error 1 make[3]: *** Waiting for unfinished jobs make[3]: Leaving directory `/home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/mark/opt/gcc-svn-src' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/mark/opt/gcc-svn-src' make: *** [all] Error 2 I would be happy to try to build a slightly earlier and more stable version but don't know how. (With mercurial I'd do 'hg update _an_earlier_tag' but don't know the svn equivalent if there is one.)
[Bug boehm-gc/48299] [4.7 Regression] FAIL: boehm-gc.c/thread_leak_test.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48299 --- Comment #17 from Jack Howarth 2012-02-25 02:27:14 UTC --- (In reply to comment #16) Note that at r184560 with the back ported thread_leak_test.c changes applied, I am able to run the 64-bit thread_leak_test test repeatedly without failures.
[Bug boehm-gc/48299] [4.7 Regression] FAIL: boehm-gc.c/thread_leak_test.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48299 --- Comment #16 from Jack Howarth 2012-02-25 02:23:06 UTC --- Created attachment 26749 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26749 back port of thread_leak_test.c from ivmai-bdwgc-8b168d0 The random failures in testsuite/boehm-gc.c/thread_leak_test.c on darwin are eliminated if the current structure of tests/thread_leak_test.c in ivmai-bdwgc-8b168d0 is back ported to gcc's boehm-gc. Note that the MS windows specific changes were left out. In particular... #ifdef GC_PTHREADS # include #else # include #endif and #ifdef GC_PTHREADS void * test(void * arg) #else DWORD WINAPI test(LPVOID arg) #endif
[Bug c++/52377] New: C++11 non-static initializers in unions are not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52377 Bug #: 52377 Summary: C++11 non-static initializers in unions are not used Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: kenwayne...@hotmail.com Created attachment 26748 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26748 command-line output and preprocessed file Given the following code #include union Test { int a{4}; }; int main() { Test t; printf("%d", t.a); return 0; } the output is all junk data, unless I specify a -O option, in which case it prints 0. Either way, t.a is not being properly initialized to 4.
[Bug middle-end/52375] [4.7 Regression] internal compiler error: in extract_insn, at recog.c:2123 at -O3 -mfpu=neon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52375 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-24 Ever Confirmed|0 |1
[Bug middle-end/52375] [4.7 Regression] internal compiler error: in extract_insn, at recog.c:2123 at -O3 -mfpu=neon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52375 Bernhard Rosenkränzer changed: What|Removed |Added Known to fail||4.7.0 --- Comment #3 from Bernhard Rosenkränzer 2012-02-24 20:37:45 UTC --- Works here with the Linaro version of 4.6.3 (didn't try stock 4.6.3 yet), ICEs with stock 4.7 from a couple of days ago
[Bug middle-end/52375] [4.7 Regression] internal compiler error: in extract_insn, at recog.c:2123 at -O3 -mfpu=neon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52375 Bernhard Rosenkränzer changed: What|Removed |Added Attachment #26744|0 |1 is obsolete|| --- Comment #2 from Bernhard Rosenkränzer 2012-02-24 20:35:08 UTC --- Created attachment 26747 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26747 Reduced test case Reduced test case
[Bug libstdc++/50349] /usr/bin/ld: warning: wildcard match appears in both version 'GLIBCXX_3.4' and 'CXXABI_1.3' in script
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50349 Benjamin Kosnik changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352 --- Comment #13 from H.J. Lu 2012-02-24 20:03:59 UTC --- (In reply to comment #12) > (In reply to comment #11) > > > I checked a similar fix into hjl/x32/addr32, hjl/x32/gcc-4_6-branch and > > hjl/x32/gcc-4_6-branch+mx32 branches. I also added "I" code to print > > constant address as positive 32bit integer for x32: > > I think we can simply disable these two patterns on x32. > > This is with disabled patterns: > > : >0: b8 00 00 e0 fe mov$0xfee0,%eax >5: 8b 00 mov(%rax),%eax >7: a8 01 test $0x1,%al >9: 74 01 je c >b: 90 nop >c: b8 00 00 e0 fe mov$0xfee0,%eax > 11: 8b 50 08mov0x8(%rax),%edx > 14: 89 50 04mov%edx,0x4(%rax) > 17: c3 retq > > and with enabled patterns: > > : >0: a1 00 00 e0 fe 00 00movabs 0xfee0,%eax >7: 00 00 >9: a8 01 test $0x1,%al >b: 74 01 je e >d: 90 nop >e: a1 08 00 e0 fe 00 00movabs 0xfee8,%eax > 15: 00 00 > 17: a3 04 00 e0 fe 00 00movabs %eax,0xfee4 > 1e: 00 00 > 20: c3 retq > > There is simply no need for movabs from/to mem, since there is no 64bit > addresses. And code size is horrible (and I bet that the former code runs > faster). I think it is a good idea.
[Bug middle-end/52375] [4.7 Regression] internal compiler error: in extract_insn, at recog.c:2123 at -O3 -mfpu=neon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52375 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson 2012-02-24 19:52:14 UTC --- On arm-linux-gnueabi this ICEs gcc 4.7 and 4.6, but not 4.5 or 4.4.
[Bug middle-end/52201] FAIL: 29_atomics/atomic/operators/51811.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52201 --- Comment #4 from Andrew Macleod 2012-02-24 19:47:18 UTC --- Created attachment 26746 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26746 disable tests if no atomic support present That test case really shouldn't be running. To make sure we're on the right track, add the line // { dg-require-atomic-builtins "" } at the top of the test case (patch attached for the 2 you mention) Presumably it won't execute the test case anymore, thus avoiding the failure... Can you give it a try? Are those the only 2 failing? interesting.
[Bug gcov-profile/52376] [4.7 regression] ICE in lto_input_tree_ref, at lto-streamer-in.c:266 while linking LTO-PGO libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52376 --- Comment #1 from Markus Trippelsdorf 2012-02-24 19:42:43 UTC --- Created attachment 26745 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26745 nsXMLContentSink.o
[Bug gcov-profile/52376] New: [4.7 regression] ICE in lto_input_tree_ref, at lto-streamer-in.c:266 while linking LTO-PGO libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52376 Bug #: 52376 Summary: [4.7 regression] ICE in lto_input_tree_ref, at lto-streamer-in.c:266 while linking LTO-PGO libxul Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile AssignedTo: unassig...@gcc.gnu.org ReportedBy: mar...@trippelsdorf.de While linking libxul of a LTO-PGO Firefox build, I get this ICE: ... In member function ‘HandleComment’: lto1: internal compiler error: in lto_input_tree_ref, at lto-streamer-in.c:266 Please submit a full bug report, with preprocessed source if appropriate. Delta reduction points to a single input object file: /var/tmp/mozilla-central/moz-build-dir/content/xml/document/src/nsXMLContentSink.o % c++ -fprofile-use -flto -fno-fat-lto-objects -c -o nsXMLContentSink.o -I../../../../dist/stl_wrappers -I../../../../dist/system_wrappers -include /var/tmp/mozilla-central/config/gcc_hidden.h -DMOZ_GLUE_IN_PROGRAM -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET -DIMPL_THEBES -DSTATIC_EXPORTABLE_JS_API -DOSTYPE=\"Linux3.3\" -DOSARCH=Linux -D_IMPL_NS_LAYOUT -I/var/tmp/mozilla-central/content/xml/document/src -I/var/tmp/mozilla-central/content/xml/document/src/../../../xsl/document/src -I/var/tmp/mozilla-central/content/xml/document/src/../../../html/document/src -I/var/tmp/mozilla-central/content/xml/document/src/../../../../layout/style -I/var/tmp/mozilla-central/content/xml/document/src/../../../base/src -I/var/tmp/mozilla-central/content/xml/document/src/../../../xul/content/src -I/var/tmp/mozilla-central/content/xml/document/src/../../../events/src -I/var/tmp/mozilla-central/content/xml/document/src/../../../../dom/base -I/var/tmp/mozilla-central/content/xml/document/src/../../../../caps/include -I/var/tmp/mozilla-central/xpcom/ds -I/var/tmp/mozilla-central/content/xml/document/src -I. -I../../../../dist/include -I../../../../dist/include/nsprpub -I/var/tmp/mozilla-central/moz-build-dir/dist/include/nspr -I/var/tmp/mozilla-central/moz-build-dir/dist/include/nss -fPIC -fno-rtti -pedantic -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -Wno-long-long -march=native -Wno-delete-non-virtual-dtor -fpermissive -fno-exceptions -fno-strict-aliasing -std=gnu++0x -pthread -ffunction-sections -fdata-sections -pipe -DNDEBUG -DTRIMMED -O3 -fomit-frame-pointer -DMOZILLA_CLIENT -include ../../../../mozilla-config.h -MD -MF .deps/nsXMLContentSink.pp /var/tmp/mozilla-central/content/xml/document/src/nsXMLContentSink.cpp % c++ -flto nsXMLContentSink.o In member function ‘HandleComment’: lto1: internal compiler error: in lto_input_tree_ref, at lto-streamer-in.c:266 Please submit a full bug report, The error above only happens with "-fprofile-use" and "-fno-fat-lto-objects". With "-fprofile-use -flto" I get: ... /var/tmp/mozilla-central/content/xml/document/src/nsXMLContentSink.cpp: In member function ‘nsXMLContentSink::HandleComment(unsigned short const*)’: /var/tmp/mozilla-central/content/xml/document/src/nsXMLContentSink.cpp:1195:54: internal compiler error: in emit_move_insn, at expr.c:3435 But I don't know how to reduce the testcase further, because it depends on nsXMLContentSink.gcda data.
[Bug middle-end/52375] New: [4.7 Regression] internal compiler error: in extract_insn, at recog.c:2123 at -O3 -mfpu=neon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52375 Bug #: 52375 Summary: [4.7 Regression] internal compiler error: in extract_insn, at recog.c:2123 at -O3 -mfpu=neon Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: bernhard.rosenkran...@linaro.org Created attachment 26744 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26744 Preprocessed source (not yet reduced) $ /opt/android-toolchain-4.7/bin/arm-linux-androideabi-g++ -march=armv7-a -mfloat-abi=softfp -mfpu=neon -O3 -o Input.o -c Input.i frameworks/base/libs/ui/Input.cpp: In member function 'void android::VelocityTracker::addMovement(const android::MotionEvent*)': frameworks/base/libs/ui/Input.cpp:866:1: error: unrecognizable insn: (insn 71 70 72 9 (set (reg:V4SI 271) (lshiftrt:V4SI (reg:V4SI 272) (subreg:V4SI (reg:OI 250 [ vect_array.1112 ]) 0))) frameworks/base/include/utils/BitSet.h:36 -1 (nil)) frameworks/base/libs/ui/Input.cpp:866:1: internal compiler error: in extract_insn, at recog.c:2123 Reducing the optimization level to -O2 or omitting -mfpu=neon allows the compile to proceed.
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352 --- Comment #12 from Uros Bizjak 2012-02-24 19:29:20 UTC --- (In reply to comment #11) > I checked a similar fix into hjl/x32/addr32, hjl/x32/gcc-4_6-branch and > hjl/x32/gcc-4_6-branch+mx32 branches. I also added "I" code to print > constant address as positive 32bit integer for x32: I think we can simply disable these two patterns on x32. This is with disabled patterns: : 0: b8 00 00 e0 fe mov$0xfee0,%eax 5: 8b 00 mov(%rax),%eax 7: a8 01 test $0x1,%al 9: 74 01 je c b: 90 nop c: b8 00 00 e0 fe mov$0xfee0,%eax 11: 8b 50 08mov0x8(%rax),%edx 14: 89 50 04mov%edx,0x4(%rax) 17: c3 retq and with enabled patterns: : 0: a1 00 00 e0 fe 00 00movabs 0xfee0,%eax 7: 00 00 9: a8 01 test $0x1,%al b: 74 01 je e d: 90 nop e: a1 08 00 e0 fe 00 00movabs 0xfee8,%eax 15: 00 00 17: a3 04 00 e0 fe 00 00movabs %eax,0xfee4 1e: 00 00 20: c3 retq There is simply no need for movabs from/to mem, since there is no 64bit addresses. And code size is horrible (and I bet that the former code runs faster).
[Bug target/52364] The unnecessary second form in *movabs_[12]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52364 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from H.J. Lu 2012-02-24 19:15:08 UTC --- The second form is needed for -ffixed-rax.
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352 --- Comment #11 from H.J. Lu 2012-02-24 19:14:19 UTC --- (In reply to comment #10) > > > But this is the _address_ that we are talking, see the "MEM" RTX. So, > following > (untested) patch can help - access is in PTR mode, and "a" modifier should > handle this without problems. > > --cut here-- > Index: config/i386/i386.md > === > --- config/i386/i386.md (revision 184560) > +++ config/i386/i386.md (working copy) > @@ -2360,7 +2360,7 @@ > ;; We fake an second form of instruction to force reload to load address > ;; into register when rax is not available > (define_insn "*movabs_1" > - [(set (mem:SWI1248x (match_operand:DI 0 "x86_64_movabs_operand" "i,r")) > + [(set (mem:SWI1248x (match_operand:PTR 0 "x86_64_movabs_operand" "i,r")) > (match_operand:SWI1248x 1 "nonmemory_operand" "a,er"))] >"TARGET_64BIT && ix86_check_movabs (insn, 0)" >"@ > @@ -2375,7 +2375,7 @@ > > (define_insn "*movabs_2" >[(set (match_operand:SWI1248x 0 "register_operand" "=a,r") > -(mem:SWI1248x (match_operand:DI 1 "x86_64_movabs_operand" "i,r")))] > +(mem:SWI1248x (match_operand:PTR 1 "x86_64_movabs_operand" "i,r")))] >"TARGET_64BIT && ix86_check_movabs (insn, 1)" >"@ > movabs{}\t{%P1, %0|%0, %P1} > --cut here-- I checked a similar fix into hjl/x32/addr32, hjl/x32/gcc-4_6-branch and hjl/x32/gcc-4_6-branch+mx32 branches. I also added "I" code to print constant address as positive 32bit integer for x32: http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=c6d9aee05cb3bfbe3c2a1b63f3f842e8d3fcb8e0 I used :P instead of :PTR which will be removed when I submit patches to use SImode for Pmode with x32.
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352 --- Comment #10 from Uros Bizjak 2012-02-24 18:32:56 UTC --- (In reply to comment #9) > It is fixed on hjl/x32/addr32, hjl/x32/gcc-4_6-branch and > hjl/x32/gcc-4_6-branch+mx32 branches. > > The problem is > > ;; Stores and loads of ax to arbitrary constant address. > ;; We fake an second form of instruction to force reload to load address > ;; into register when rax is not available > (define_insn "*movabs_1" > [(set (mem:SWI1248x (match_operand:DI 0 "x86_64_movabs_operand" "i,r")) > (match_operand:SWI1248x 1 "nonmemory_operand" "a,er"))] > "TARGET_64BIT && ix86_check_movabs (insn, 0)" > "@ >movabs{}\t{%1, %P0|%P0, %1} >mov{}\t{%1, %a0|%a0, %1}" > > DImode is incorrect for x32, especially for register operand. > That is where > > movq$-18874360, %rax > movl(%rax), %edx > > comes from. It should be in Pmode. However, the immediate operand > must be in DImode for x86_64_movabs_operand. But this is the _address_ that we are talking, see the "MEM" RTX. So, following (untested) patch can help - access is in PTR mode, and "a" modifier should handle this without problems. --cut here-- Index: config/i386/i386.md === --- config/i386/i386.md (revision 184560) +++ config/i386/i386.md (working copy) @@ -2360,7 +2360,7 @@ ;; We fake an second form of instruction to force reload to load address ;; into register when rax is not available (define_insn "*movabs_1" - [(set (mem:SWI1248x (match_operand:DI 0 "x86_64_movabs_operand" "i,r")) + [(set (mem:SWI1248x (match_operand:PTR 0 "x86_64_movabs_operand" "i,r")) (match_operand:SWI1248x 1 "nonmemory_operand" "a,er"))] "TARGET_64BIT && ix86_check_movabs (insn, 0)" "@ @@ -2375,7 +2375,7 @@ (define_insn "*movabs_2" [(set (match_operand:SWI1248x 0 "register_operand" "=a,r") -(mem:SWI1248x (match_operand:DI 1 "x86_64_movabs_operand" "i,r")))] +(mem:SWI1248x (match_operand:PTR 1 "x86_64_movabs_operand" "i,r")))] "TARGET_64BIT && ix86_check_movabs (insn, 1)" "@ movabs{}\t{%P1, %0|%0, %P1} --cut here--
[Bug c++/52282] [C++0x] ICE / confused by earlier errors with decltype/constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282 --- Comment #2 from andyg1001 at hotmail dot co.uk 2012-02-24 17:42:59 UTC --- Created attachment 26743 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26743 test-case for decltype ICE / incorrect evaluation of constexpr The attached test-case source expands on my previous bug report and shows where the ICE occurs with decltype but also where the compiler fails to detect that a value is actually constexpr (lines marked "incorrect evaluation"). What is interesting is that the incorrect evaluation does not occur for comparable use inside main(). GCC version: g++ (GCC) 4.7.0 20120224 (experimental)
[Bug target/16458] PowerPC - redundant compare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16458 Peter Bergner changed: What|Removed |Added Target Milestone|--- |4.8.0 --- Comment #7 from Peter Bergner 2012-02-24 17:20:18 UTC --- Richi mentioned this isn't suitable for 4.7 stage4, so re-targeting this for 4.8.
[Bug c++/52374] [C++11] Fails to transform id-expression into dependent base member access in lambda expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52374 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-24 Ever Confirmed|0 |1
[Bug c++/41437] No access control for classes in template functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437 Jonathan Wakely changed: What|Removed |Added CC||sylvestre at debian dot org --- Comment #4 from Jonathan Wakely 2012-02-24 16:50:25 UTC --- *** Bug 52373 has been marked as a duplicate of this bug. ***
[Bug c++/52373] template usage drops some checks on the accessibility of a member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52373 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Jonathan Wakely 2012-02-24 16:50:25 UTC --- dup *** This bug has been marked as a duplicate of bug 41437 ***
[Bug c++/52374] New: [C++11] Fails to transform id-expression into dependent base member access in lambda expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52374 Bug #: 52374 Summary: [C++11] Fails to transform id-expression into dependent base member access in lambda expression Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ai.az...@gmail.com Created attachment 26742 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26742 Output of -v option and preprocessed file In the lambda expression's compound statement, id-expressions referring to non-static members should be transformed into class member access expressions by prefixing `(*this).'. However, GCC fails the transformation when id-expressions involved are qualified-ids and refer to dependent base members. A test case is as follows; struct B { int get() const { return 42; } }; template struct D : public X { int get() const { return [this]() -> int { return X::get(); }(); } }; int main() { D d; d.get(); } For the above mentioned well-formed code, 4.7.0 20120218 (experimental) with -std=c++11 complains as follows; main.cpp: In instantiation of 'D::get() const [with X = B]::': main.cpp:10:29: required from 'struct D::get() const [with X = B]::' main.cpp:10:65: required from 'int D::get() const [with X = B]' main.cpp:16:9: required from here main.cpp:10:60: error: cannot call member function 'int B::get() const' without object `X::get' in the lambda expression should be implicitly transformed into `(*this).X::get', and the test case should compile successfully.
[Bug rtl-optimization/37272] [4.5 Regression] IRA has caused ppc64-double-1.c to fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37272 --- Comment #7 from Peter Bergner 2012-02-24 16:42:37 UTC --- This looks to be fixed, probably by Mike's fp convert changes from a while back. I'm now seeing the following src code being generated: fctidz 1,1 fcfid 1,1 blr Can we close this now?
[Bug c++/52373] New: template usage drops some checks on the accessibility of a member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52373 Bug #: 52373 Summary: template usage drops some checks on the accessibility of a member Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: sylves...@debian.org Considering this code: class A { struct st { static void f(); }; }; template void foo() { A::st::f(); } --- g++ accepts it. If I remove "template ", an error is triggered (which is the expected behavior): plop.cpp: In function ‘void foo()’: plop.cpp:4:12: error: ‘struct A::st’ is private plop.cpp:12:5: error: within this context
[Bug target/52372] [4.7 regression] gcc.target/mips/mips16-attributes{,-4}.c SEGV in dwf_regno
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52372 Rainer Orth changed: What|Removed |Added Target Milestone|--- |4.7.0 Summary|gcc.target/mips/mips16-attr |[4.7 regression] |ibutes{,-4}.c SEGV in |gcc.target/mips/mips16-attr |dwf_regno |ibutes{,-4}.c SEGV in ||dwf_regno --- Comment #1 from Rainer Orth 2012-02-24 16:29:38 UTC --- I just see that this is a regression from the 4.6 branch.
[Bug target/52372] New: gcc.target/mips/mips16-attributes{,-4}.c SEGV in dwf_regno
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52372 Bug #: 52372 Summary: gcc.target/mips/mips16-attributes{,-4}.c SEGV in dwf_regno Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: rsand...@gcc.gnu.org Host: mips-sgi-irix6.5 Target: mips-sgi-irix6.5 Build: mips-sgi-irix6.5 The mips16-attributes{, -4}.c tests ICE on IRIX 6: FAIL: gcc.target/mips/mips16-attributes-4.c (internal compiler error) FAIL: gcc.target/mips/mips16-attributes-4.c (test for excess errors) FAIL: gcc.target/mips/mips16-attributes.c (internal compiler error) FAIL: gcc.target/mips/mips16-attributes.c (test for excess errors) In the first case, I find: /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/mips/mips16-attributes-4.c: In function 'bar': /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/mips/mips16-attributes-4.c:9:1: internal compiler error: Segmentation fault The failure boils down to $ cc1 -fpreprocessed mips16-attributes-4.i -quiet -mabi=o64 -mlong32 -mno-synci -o mips16-attributes-4.s In gdb,I see Program received signal SIGSEGV, Segmentation fault. 0x104b4048 in dwf_regno (reg=0x40280b8) at /vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c:912 (gdb) p reg $1 = (const_rtx) 0x40280b8 (gdb) pr (pc) (gdb) where #0 0x104b4048 in dwf_regno (reg=0x40280b8) at /vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c:912 #1 dwarf2out_flush_queued_reg_saves () at /vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c:994 #2 0x104b56d4 in dwarf2out_frame_debug (insn=0x40f05e0) at /vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c:2038 #3 scan_insn_after (insn=insn@entry=0x4033048) at /vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c:2361 #4 0x104b6b74 in scan_trace (trace=) at /vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c:2505 #5 0x104b7e0c in create_cfi_notes () at /vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c:2549 #6 execute_dwarf2_frame () at /vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c:2907 #7 0x104f5bec in execute_one_pass (pass=pass@entry=0x10dc3708) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2081 #8 0x104f6088 in execute_pass_list (pass=0x10dc3708) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2136 #9 0x104f60a4 in execute_pass_list (pass=0x10dc3970) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2137 #10 0x104f60a4 in execute_pass_list (pass=0x10dc39a8) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2137 #11 0x1078c50c in tree_rest_of_compilation (fndecl=0x40b9100) at /vol/gcc/src/hg/trunk/local/gcc/tree-optimize.c:422 #12 0x105d533c in cgraph_expand_function (node=0x40d80a8) at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1837 #13 0x105d7564 in cgraph_output_in_order () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2002 #14 cgraph_optimize () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2213 #15 0x105d792c in cgraph_finalize_compilation_unit () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1344 #16 0x10187cf4 in c_write_global_declarations () at /vol/gcc/src/hg/trunk/local/gcc/c-decl.c:10031 #17 0x10277148 in compile_file () at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:573 #18 do_compile () at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:1938 #19 toplev_main (argc=9, argv=0x7ffb7f04) at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:2014 #20 0x101723f0 in __start () I didn't easily see how to find the equivalent of REGNO(reg) in dwf_regno. Rainer
[Bug target/52261] [avr] Add support for AVR Xmega cores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52261 --- Comment #7 from Georg-Johann Lay 2012-02-24 16:26:46 UTC --- Author: gjl Date: Fri Feb 24 16:26:35 2012 New Revision: 184559 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184559 Log: PR target/52261 * config/avr/avr.c (avr_out_movhi_mr_r_xmega): Use base to test for unusedness in st X addressing. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c
[Bug target/50580] gcc.target/mips/interrupt_handler-[23].c FAIL on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50580 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |NEW URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-02/msg01243.htm ||l Last reconfirmed||2012-02-24 Ever Confirmed|0 |1 --- Comment #2 from Rainer Orth 2012-02-24 15:59:01 UTC --- Analysis in workaround patch.
[Bug target/50580] gcc.target/mips/interrupt_handler-[23].c FAIL on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50580 --- Comment #1 from Rainer Orth 2012-02-24 15:52:09 UTC --- Author: ro Date: Fri Feb 24 15:52:01 2012 New Revision: 184557 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184557 Log: [testsuite] Skip gcc.target/mips/interrupt_handler-[23].c on IRIX (PR target/50580) PR target/50580 * gcc.target/mips/interrupt_handler-2.c: Skip on mips-sgi-irix6*. * gcc.target/mips/interrupt_handler-3.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/mips/interrupt_handler-2.c trunk/gcc/testsuite/gcc.target/mips/interrupt_handler-3.c
[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179 --- Comment #27 from pmarlier at gcc dot gnu.org 2012-02-24 15:21:20 UTC --- Author: pmarlier Date: Fri Feb 24 15:21:12 2012 New Revision: 184555 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184555 Log: 2012-02-23 Patrick Marlier Jack Howarth boehm-gc/ PR boehm-gc/52179 * include/gc_config.h.in: Undefine HAVE_PTHREAD_GET_STACKADDR_NP. * include/private/gcconfig.h (DARWIN): Define STACKBOTTOM with pthread_get_stackaddr_np when available. * configure.ac (THREADS): Check availability of pthread_get_stackaddr_np. * configure: Regenerate. libjava/ PR target/49461 * configure.ac (SYSTEMSPEC): No longer pass -no_pie for darwin11. * configure: Regenerate. Modified: trunk/boehm-gc/ChangeLog trunk/boehm-gc/configure trunk/boehm-gc/configure.ac trunk/boehm-gc/include/gc_config.h.in trunk/boehm-gc/include/private/gcconfig.h trunk/libjava/ChangeLog trunk/libjava/configure trunk/libjava/configure.ac
[Bug target/49461] boehm-gc and gcj incompatible with pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49461 --- Comment #13 from pmarlier at gcc dot gnu.org 2012-02-24 15:21:20 UTC --- Author: pmarlier Date: Fri Feb 24 15:21:12 2012 New Revision: 184555 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184555 Log: 2012-02-23 Patrick Marlier Jack Howarth boehm-gc/ PR boehm-gc/52179 * include/gc_config.h.in: Undefine HAVE_PTHREAD_GET_STACKADDR_NP. * include/private/gcconfig.h (DARWIN): Define STACKBOTTOM with pthread_get_stackaddr_np when available. * configure.ac (THREADS): Check availability of pthread_get_stackaddr_np. * configure: Regenerate. libjava/ PR target/49461 * configure.ac (SYSTEMSPEC): No longer pass -no_pie for darwin11. * configure: Regenerate. Modified: trunk/boehm-gc/ChangeLog trunk/boehm-gc/configure trunk/boehm-gc/configure.ac trunk/boehm-gc/include/gc_config.h.in trunk/boehm-gc/include/private/gcconfig.h trunk/libjava/ChangeLog trunk/libjava/configure trunk/libjava/configure.ac
[Bug c++/52369] Const-qualified non-class base member and defaulted default constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52369 --- Comment #2 from Jonathan Wakely 2012-02-24 14:17:17 UTC --- With 4.6.2 and -Wall gives the same as 4.7.0: l.cc:4:13: warning: non-static const member 'const int B::v_' in class without a constructor [-Wuninitialized] l.cc: In function 'int main()': l.cc:13:5: warning: unused variable 'd' [-Wunused-variable] 4.5.2 gives the same (except doesn't print the [-W...] info after the warnings)
[Bug fortran/52370] Spurious "may be used uninitialized" warning for check of optional argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52370 Tobias Burnus changed: What|Removed |Added Keywords||diagnostic --- Comment #2 from Tobias Burnus 2012-02-24 14:05:32 UTC --- (In reply to comment #1) > The warning is not printed for the last line where one dereferences a pointer > (line 8), but for the "b.0 =" assignment. I have the impression that problem is rather line 8 - i.e. related to the pointer dereference. The warning vanishes if one comments/moves the "a =" line - unless "b" is volatile - or if one makes "a" a VALUE or a function result. I assume that's because it is then simpler to merge the implicitly and the explicitly created "if (present(b))" lines.
[Bug c++/52369] Const-qualified non-class base member and defaulted default constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52369 fabien at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-02-24 CC||fabien at gcc dot gnu.org AssignedTo|unassigned at gcc dot |fabien at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 Known to fail||4.1.2, 4.2.4, 4.3.6, 4.5.3, ||4.7.0 --- Comment #1 from fabien at gcc dot gnu.org 2012-02-24 14:05:19 UTC --- Confirmed. Can someone please test it on 4.6.0 and 4.6.2 ? Thanks.
[Bug c++/52371] [C++11] ICE in noexcept with constexpr conversion function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52371 --- Comment #2 from Ai Azuma 2012-02-24 14:01:41 UTC --- I'm sorry. I forgot to write that this ICE appears with -std=c++11 option.
[Bug c++/52371] [C++11] ICE in noexcept with constexpr conversion function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52371 --- Comment #1 from Ai Azuma 2012-02-24 13:54:18 UTC --- Created attachment 26741 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26741 Output of -v option and preprocessed file
[Bug c++/52371] New: [C++11] ICE in noexcept with constexpr conversion function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52371 Bug #: 52371 Summary: [C++11] ICE in noexcept with constexpr conversion function Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ai.az...@gmail.com The following well-formed code causes ICE on GCC 4.7.0 20120218 (experimental). // template struct integral_constant { typedef T value_type; static constexpr value_type value = v; constexpr operator value_type() { return value; } }; template struct B { B() noexcept(integral_constant()) // <- ICE : v_() {} T v_; }; int main() { B b; } // If I use the static constexpr `value' instread of the constexpr conversion function, the ICE disappears.
[Bug tree-optimization/52361] gcc.dg/pr48141.c times out with checking enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52361 --- Comment #7 from Richard Guenther 2012-02-24 12:48:00 UTC --- Author: rguenth Date: Fri Feb 24 12:47:56 2012 New Revision: 184552 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184552 Log: 2012-02-24 Richard Guenther PR middle-end/52361 * gimple.c (walk_gimple_op): Use predicates with less redundant tests. (is_gimple_reg_type): Move inline ... * gimple.h (is_gimple_reg_type): ... here. Modified: trunk/gcc/ChangeLog trunk/gcc/gimple.c trunk/gcc/gimple.h
[Bug target/46092] Improve constant handling of thumb2 instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46092 Ramana Radhakrishnan changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||ramana at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.7.0 Severity|normal |enhancement --- Comment #4 from Ramana Radhakrishnan 2012-02-24 12:24:04 UTC --- Trunk generates this today. Thus fixed. Ramana tv: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. movwr3, #65520 cmpr0, r3 itthi subhir0, r0, #65280 subhir0, r0, #241 bxlr .sizetv, .-tv .ident"GCC: (GNU) 4.7.0 20120116 (experimental)"
[Bug middle-end/52355] [4.7 regression] address difference between array elements is not considered to be a compile time constant anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52355 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Richard Guenther 2012-02-24 11:56:07 UTC --- Fixed.
[Bug tree-optimization/52361] gcc.dg/pr48141.c times out with checking enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52361 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek 2012-02-24 11:45:37 UTC --- Test taking 17s on x86_64 isn't that unreasonable, nothing close to being a compile time hog, if it is slow even when cross-compiling to sparc, I guess it should be investigated why so much more time is spent there.
[Bug tree-optimization/52361] gcc.dg/pr48141.c times out with checking enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52361 --- Comment #5 from Richard Guenther 2012-02-24 11:38:43 UTC --- Author: rguenth Date: Fri Feb 24 11:38:39 2012 New Revision: 184549 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184549 Log: 2012-02-24 Richard Guenther PR middle-end/52361 * passes.c (execute_function_todo): When verifying SSA form verify gimple form first. * tree-ssa.c (verify_ssa): Do not verify gimple form here. Modified: trunk/gcc/ChangeLog trunk/gcc/passes.c trunk/gcc/tree-ssa.c
[Bug target/52367] Many incorrect thumb insn lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52367 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-24 Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Richard Earnshaw 2012-02-24 11:35:23 UTC --- Over estimating is safe, though potentially sub-optimal. The concern is mainly around under-estimating, which can lead to broken code. Beware, however that if an insn pattern generates more than one assembly language instruction then all the length costs will be associated with one instruction (normally the last). R.
[Bug c++/52369] New: Const-qualified non-class base member and defaulted default constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52369 Bug #: 52369 Summary: Const-qualified non-class base member and defaulted default constructor Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ai.az...@gmail.com Created attachment 26740 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26740 Output of -v option and preprocessed file The following ill-formed code is wrongly accepted by GCC 4.7.0 20120218 (experimental). class B { private: int const v_; }; class D : public B {}; int main() { D d; } B's default constructor is implicitly-declared and has no ctor-initializer. So, B::v_ is not designated by any mem-initializer-id and subject to default-initialization. However, default-initialization of a const-qualified non-class type is ill-formed. Therefore, the use of B's constructor is ill-formed (and it should be defined as deleted in -std=c++11 mode), and the use of D's is also ill-formed. N.B. A similar (but a bit different) problem seems to have been resolved in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29043 .
[Bug fortran/52365] Procedure interface wrongly imported into interface without IMPORT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52365 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus 2012-02-24 11:16:09 UTC --- Note: I think the following variant is valid, where the symbol is in the same interface block. (Correctly accepted.) interface subroutine foo() end subroutine foo subroutine bar(x) procedure(foo) :: x end subroutine bar end interface end While the following variant is also invalid (but accepted): module m interface subroutine bar(x) procedure(foo) :: x end subroutine bar end interface contains subroutine foo() end subroutine foo end Hence, a simple check in decl.c is not possible as it will come too early for the second example. Still, some check should probably added to decl.c's match_procedure_interface - similarly to the gfc_current_ns->proc_name->attr.if_source == IFSRC_IFBODY check in variable_decl. Another check should be done at resolve_procedure_interface - or possibly the only check, if one modifies the way where the decl is declared for IFSRC_IFBODY.
[Bug middle-end/52355] [4.7 regression] address difference between array elements is not considered to be a compile time constant anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52355 --- Comment #6 from Richard Guenther 2012-02-24 11:14:24 UTC --- Author: rguenth Date: Fri Feb 24 11:14:17 2012 New Revision: 184548 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184548 Log: 2012-02-24 Richard Guenther PR middle-end/52355 * fold-const.c (fold_addr_of_array_ref_difference): New function. (fold_binary_loc): Use it to extend the existing &a[i] - &a[j] folding. * gcc.dg/pr52355.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr52355.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/52361] gcc.dg/pr48141.c times out with checking enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52361 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-02-24 10:43:02 UTC --- > --- Comment #3 from Richard Guenther 2012-02-24 > 10:35:32 UTC --- > Actually I have a simple patch that speeds things up a bit, but not > significantly > so. I wonder if the testcase couldn't be reduced a bit, or instead marked with dg-require-effective-target run_expensive_tests I doubt there is much point routinely running such a compile time hog. Rainer
[Bug tree-optimization/52361] gcc.dg/pr48141.c times out with checking enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52361 --- Comment #3 from Richard Guenther 2012-02-24 10:35:32 UTC --- Actually I have a simple patch that speeds things up a bit, but not significantly so.
[Bug middle-end/52355] [4.7 regression] address difference between array elements is not considered to be a compile time constant anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52355 --- Comment #5 from Richard Guenther 2012-02-24 09:47:33 UTC --- We fold end up trying to fold (long int) &(*(a + 256))[0][0] - (long int) &(*a)[0][0] because a is of type char[16][16] *. I have a patch.
[Bug tree-optimization/52361] gcc.dg/pr48141.c times out with checking enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52361 --- Comment #2 from Richard Guenther 2012-02-24 09:16:43 UTC --- Well, that's sort-of expected ...
[Bug rtl-optimization/52060] [4.6 Regression] Invalid constant simplification in combine with parallel result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52060 Richard Guenther changed: What|Removed |Added Target Milestone|4.6.4 |4.6.3
[Bug rtl-optimization/37516] ~(-2 - a) is not being optimized into a + 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37516 --- Comment #5 from rguenther at suse dot de 2012-02-24 08:38:19 UTC --- On Thu, 23 Feb 2012, pinskia at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37516 > > --- Comment #4 from Andrew Pinski 2012-02-23 > 22:15:05 UTC --- > > > Maybe get away with these old-stylish names ('tree' and 'fold') and > > make it match reality, gimple-ssa-combine.c ;) > > That sounds like a good idea. I have done that. > > > > > Still have to have a look at your branch - do you have a brief > > overview documentation, for example on the wiki? What I'd like > > to do is have an interface that I can re-use for VN combining, > > basically replace its simplify_*_expression functions. > > I don't have one yet. But I hope to create one this weekend. > > Right now replacing the VN combining with this new functionality will not work > as it scans the defs itself. Though I am moving all the def scanning to its > own function which should allow for the code to be more modular and allow for > the VN combining to work with it. I think def scanning is ok, but all SSA names should be "valueized" via a hook first. Richard.
[Bug middle-end/39976] [4.5/4.6/4.7 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976 --- Comment #44 from Jiangning Liu 2012-02-24 08:09:25 UTC --- I'm not sure if this kind of bug has been completely fixed, and posted a qeustion in mail list at http://gcc.gnu.org/ml/gcc/2012-02/msg00415.html .