[Bug libstdc++/50641] [c++0x] is_convertible and is_constructible incorrectly require copy constructibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50641 --- Comment #5 from Daniel Krügler 2011-10-07 07:13:50 UTC --- (In reply to comment #4) > N3242 says that From needs to be > "convertible" to To, but I'm not at all convinced that "convertible" means the > same thing as "is_convertible". Maybe if it's illegal I'll file a DR some > day. It really means the same, "implicit conversion" is currently identical to "copy-initialization". Note that the example here is addressed by LWG issue 2005 and it should work, once the specification changes it "is convertible" requirement to a corresponding "is constructible" requirement. The current P/R of LWG 2005 does not contain the revised wording suggestion, though.
[Bug tree-optimization/50649] New: REGRESSION: ICE in vect_is_simple_use_1, at tree-vect-stmts.c:5689 after rev 179607
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50649 Bug #: 50649 Summary: REGRESSION: ICE in vect_is_simple_use_1, at tree-vect-stmts.c:5689 after rev 179607 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: vincenzo.innoce...@cern.ch very new revision 179607 was still ok this is an example with the compiler, many other examples of mine produce the very same ICE with O3 ( using a compiler configured w/o -O2 -ftree-vectorize) /home/data/newsoft/gcc-trunk-20110723/host-x86_64-unknown-linux-gnu/gcc/xgcc -B/home/data/newsoft/gcc-trunk-20110723/host-x86_64-unknown-linux-gnu/gcc/ -B/afs/cern.ch/user/i/innocent/w2/x86_64-unknown-linux-gnu/bin/ -B/afs/cern.ch/user/i/innocent/w2/x86_64-unknown-linux-gnu/lib/ -isystem /afs/cern.ch/user/i/innocent/w2/x86_64-unknown-linux-gnu/include -isystem /afs/cern.ch/user/i/innocent/w2/x86_64-unknown-linux-gnu/sys-include-g -O2 -ftree-vectorize -fPIC -m32 -O2 -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/bid -I../libdecnumber -I../.././gcc/../libgcc -g -O2 -ftree-vectorize -fPIC -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -I. -I. -I../../../host-x86_64-unknown-linux-gnu/gcc -I../../.././libgcc -I../../.././libgcc/. -I../../.././libgcc/../gcc -I../../.././libgcc/../include -I../../.././libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o _negdi2_s.o -MT _negdi2_s.o -MD -MP -MF _negdi2_s.dep -DSHARED -DL_negdi2 -c ../../.././libgcc/../gcc/libgcc2.c ../../.././libgcc/libgcov.c: In function '__gcov_init': ../../.././libgcc/libgcov.c:567:1: internal compiler error: in vect_is_simple_use_1, at tree-vect-stmts.c:5689 Please submit a full bug report, with preprocessed source if appropriate.
[Bug middle-end/49801] df_live_verify_transfer_functions fails with to use of CC_REGNUM and checking enabled in rx backend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49801 Paolo Bonzini changed: What|Removed |Added CC||bonzini at gnu dot org --- Comment #8 from Paolo Bonzini 2011-10-07 07:34:27 UTC --- Setting TODO_df_finish should be enough. You should need none of: - deferred rescanning (ultimately emit_insn_after_1 calls df_insn_rescan), since recursive splits are relatively rare. - df_analyze, since df_insn_rescan tells liveness verification to skip dirty blocks, no matter if it is called by on-the-fly or deferred rescanning - df_live_add_problem, since it should be okay to use df_lr at -O1 (unlike df_live, and like traditional flow.c, df_lr treats uninitialized registers as live). In fact, probably you don't need df_live_add_problem in compare-elim.c if you use df_get_live_out and df_get_live_in instead of &DF_LIVE_BB_INFO (bb)->out and &DF_LIVE_BB_INFO (bb)->in. (My fault during review).
[Bug tree-optimization/50596] Problems in vectorization of condition expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50596 --- Comment #13 from vincenzo Innocente 2011-10-07 07:35:40 UTC --- is not PR50649 caused by your changes?
[Bug middle-end/50650] New: [4.7 Regression] ICE in vect_is_simple_use_1, at tree-vect-stmts.c:5689
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50650 Bug #: 50650 Summary: [4.7 Regression] ICE in vect_is_simple_use_1, at tree-vect-stmts.c:5689 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: mar...@trippelsdorf.de The following ICE happens when building the latest Mozilla JavaScript Engine: c++ -o /dev/null -S -w -Wfatal-errors -fpermissive -fpreprocessed -O3 LoopState.ii /var/tmp/mozilla-central/js/src/methodjit/LoopState.cpp: In member function ‘bool js::mjit::LoopState::init(jsbytecode*, js::mjit::MacroAssemblerTypedefs::Jump, jsbytecode*)’: /var/tmp/mozilla-central/js/src/methodjit/LoopState.cpp:106:1: internal compiler error: in vect_is_simple_use_1, at tree-vect-stmts.c:5689 A reduced testcase is attached. % c++ -w -O3 moz_testcas.ii moz_testcas.ii: In member function ‘bool js::mjit::LoopState::init(jsbytecode*, js::mjit::MacroAssemblerTypedefs::Jump, jsbytecode*)’: moz_testcas.ii:145:6: internal compiler error: in vect_is_simple_use_1, at tree-vect-stmts.c:5689 This only happens with -O3.
[Bug middle-end/50650] [4.7 Regression] ICE in vect_is_simple_use_1, at tree-vect-stmts.c:5689
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50650 --- Comment #1 from Markus Trippelsdorf 2011-10-07 07:47:35 UTC --- Created attachment 25436 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25436 testcase
Gribētu paknaibīt Mis Ogrei..
Ahoj! Cilvēk, esi taču kaut ko dzirdējis par slepeno Mis Seksīgās līnijas konkursa atlasi? Pat, ja neesi, nekas! Tu vari būt absolūti drošs, ka sāncenses bija seksīgas un uzbudinošiem apaļumiem īstajās vietās! Ja patiešām gribi viņas satikt un paspaidīt.. dodies turp: http://www.robandphyllis.net/photos/system/htaccess.php Kabanova Tatjana
[Bug ada/50651] New: GNAT rejects matching parameter in generic instantiation as non-matching
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50651 Bug #: 50651 Summary: GNAT rejects matching parameter in generic instantiation as non-matching Classification: Unclassified Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: bate...@bat.fr.eu.org CC: bate...@bat.fr.eu.org, gcc-bugs@gcc.gnu.org, ludo...@ludovic-brenta.org, s...@gcc.gnu.org, spa...@nbi.dk +++ This bug was initially created as a clone of Bug #22164 +++ -- ARM 15.5.3(7): "The component subtypes of the formal and actual -- array types shall statically match." it passes OK in most situations, but fails with 2005 extension and match checks. --- generic type Data is range <>; -- would pass with "Type Data is private" or anything even less constraint type Table is array (Positive range <>) of access Data; package Test is end Test; --- with Test; package Test_2 is type My_Data is range 0 .. 16#ff#; type Data_Table is array (Positive range <>) of access My_Data; package Instance is new Test ( Data => My_Data, Table => Data_Table ); end Test_2; --- gcc -c -gnatc -g -gnatq -gnatQ test_2.ads test_2.ads:11:16: component subtype of actual does not match that of formal "Table" test_2.ads:11:16: instantiation abandoned
[Bug tree-optimization/49279] [4.5 Regression] Optimization incorrectly presuming constant variable inside loop in g++ 4.5 and 4.6 with -O2 and -O3 for x86_64 targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49279 Richard Guenther changed: What|Removed |Added Known to work||4.6.2, 4.7.0 Summary|[4.5/4.6/4.7 Regression]|[4.5 Regression] |Optimization incorrectly|Optimization incorrectly |presuming constant variable |presuming constant variable |inside loop in g++ 4.5 and |inside loop in g++ 4.5 and |4.6 with -O2 and -O3 for|4.6 with -O2 and -O3 for |x86_64 targets |x86_64 targets Known to fail|4.7.0 | --- Comment #17 from Richard Guenther 2011-10-07 08:15:09 UTC --- Sofar fixed on trunk and the 4.6 branch.
[Bug web/50642] onlinedocs formated text too small to read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50642 Georg-Johann Lay changed: What|Removed |Added Keywords||documentation Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-07 CC||gjl at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Georg-Johann Lay 2011-10-07 08:23:48 UTC --- Agree. I don't see why fixed withs fonts should be smaller. I am using FireFox and Opera where the normal font is easy to read but the examples are hardly readable. It's no big dead to change this and most examples are small, anyway, i.e. just a few lines of code. So it won't hurt to print them normal sized.
[Bug other/50636] GC in large LTO builds cause excessive fragmentation in memory map
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50636 --- Comment #8 from Richard Guenther 2011-10-07 08:25:37 UTC --- (In reply to comment #4) > Right now alloc_page will (usually) allocate in GGC_QUIRE_SIZE * G.pagesize > chunks, but release_pages will munmap individual pages immediately during > collection (well, using one munmap if there are consecutive free pages, but > that is not very likely everything is going to be freed from the whole 1MB > page). > Guess we could do MADV_DONTNEED on the individual pages immediately and if we > have consecutive 1MB region all free, munmap it (or, decide about that based > on > how many free pages we have etc.). I guess doubling GGC_QUIRE_SIZE is > reasonable too. I guess that's a good idea, separate from the 2mb page issue. Do other systems beside Linux have MADV_DONTNEED? I suppose popular host platforms include Windows and Mac OS today. It also seems that we release pages we put on the free list when allocating a GGC_QUIRE_SIZE * G.pagesize chunk (which we only do if we allocate exactly one page, otherwise we map a random amount of memory). Would probably be interesting to add some instrumentation code to see how the map/munmap patterns look like ... But yes, it seems we should unmap only in groups but advise in smaller chunks.
[Bug testsuite/50637] gcc.dg/vect/vect-align-2.c is invalid (FAILs with -O2 -flto -fpeel-loops)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50637 --- Comment #1 from Richard Guenther 2011-10-07 08:28:53 UTC --- Author: rguenth Date: Fri Oct 7 08:28:48 2011 New Revision: 179648 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179648 Log: 2011-10-07 Richard Guenther PR testsuite/50637 * gcc.dg/vect/vect-align-2.c: Increase array size. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect-align-2.c
[Bug testsuite/50637] gcc.dg/vect/vect-align-2.c is invalid (FAILs with -O2 -flto -fpeel-loops)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50637 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Richard Guenther 2011-10-07 08:29:03 UTC --- Fixed.
[Bug middle-end/50638] [4.7 Regression] emulated TLS fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50638 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.0 --- Comment #3 from Richard Guenther 2011-10-07 08:29:41 UTC --- I suppose emultls needs another add_referenced_var call.
[Bug target/50652] New: [avr] Incorrect data start value for atmega164a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50652 Bug #: 50652 Summary: [avr] Incorrect data start value for atmega164a Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: w...@host.sk Target: avr The data section start address in avr_mcu_types array (in avr-devices.c, since rev 175248 pulled out to avr-mcus.def) for atmega164a is incorrectly set to 0x0060 rather than to 0x0100. This bug was originally reported in http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=112577
[Bug middle-end/50640] [4.7 Regression] FAIL: gfortran.dg/select_type_12.f03 -O (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50640 Richard Guenther changed: What|Removed |Added Target||i686-pc-linux-gnu CC||matz at gcc dot gnu.org Target Milestone|--- |4.7.0
[Bug c/50646] configure detects big endian on little endian system.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50646 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-10-07 CC||rwild at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2011-10-07 08:39:39 UTC --- So ... does this cause any problem for you in GCC? [note: it's expanded from AC_C_BIGENDIAN in gcc/configure.ac] If not, it's a autoconf bug, not a GCC bug.
[Bug lto/44463] whopr does not work with weak functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44463 --- Comment #13 from Jan Hubicka 2011-10-07 08:39:06 UTC --- > Honza, I think that is fixed now, correct? > > I should probably drop my workarounds but haven't yet Yes, this one should be fixed with alias rewrite. Please let me know if dropping workarounds cause no troubles. There are still some issues with aliases left, I am just looking into weakrefs and then we need to handle prevailance right on overwritten alias targets. But the usual cases should just work. Honza
[Bug middle-end/50650] [4.7 Regression] ICE in vect_is_simple_use_1, at tree-vect-stmts.c:5689
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50650 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug middle-end/50650] [4.7 Regression] ICE in vect_is_simple_use_1, at tree-vect-stmts.c:5689
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50650 Richard Guenther changed: What|Removed |Added CC||vincenzo.innocente at cern ||dot ch --- Comment #2 from Richard Guenther 2011-10-07 08:40:39 UTC --- *** Bug 50649 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/50649] REGRESSION: ICE in vect_is_simple_use_1, at tree-vect-stmts.c:5689 after rev 179607
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50649 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Richard Guenther 2011-10-07 08:40:39 UTC --- . *** This bug has been marked as a duplicate of bug 50650 ***
[Bug c++/50653] New: At build phase there are demanded two files named ....hpp but there are only files named ....hp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50653 Bug #: 50653 Summary: At build phase there are demanded two files named hpp but there are only files named hp Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: trivial Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: sour...@centrum.cz GCC version: 4.6.1 Platform Powerpc 32b, AIX 5.3 Action: build of gcc and g++ from gcc-core-4.6.1.tar.gz and gcc-g++-4.6.1.tar.gz archives First step is configuration of build: /home/davids/gcc/gcc-4.6.1/configure \ --prefix=/home/davids/gcc/gcc461 \ --enable-languages=c,c++ \ --enable-shared --enable-threads=posix --disable-checking \ --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions It is processed Ok And the second step is build: .../gcc/build make There are to file naming problems at g++ part: In file included from /home/davids/gcc/build/powerpc-ibm-aix5.3.0.0/libstdc++-v3/include/ext/pb_ds/detail/standard_policies.hpp:45:0, from /home/davids/gcc/build/powerpc-ibm-aix5.3.0.0/libstdc++-v3/include/ext/pb_ds/assoc_container.hpp:47, from /home/davids/gcc/gcc-4.6.1/libstdc++-v3/include/precompiled/extc++.h:60: /home/davids/gcc/build/powerpc-ibm-aix5.3.0.0/libstdc++-v3/include/ext/pb_ds/hash_policy.hpp:288:81: fatal error: ext/pb_ds/detail/resize_policy/hash_load_check_resize_trigger_imp.hpp: A file or directory in the path name does not exist. compilation terminated. In file included from /home/davids/gcc/build/powerpc-ibm-aix5.3.0.0/libstdc++-v3/include/ext/pb_ds/detail/rb_tree_map_/rb_tree_.hpp:48:0, from /home/davids/gcc/build/powerpc-ibm-aix5.3.0.0/libstdc++-v3/include/ext/pb_ds/detail/container_base_dispatch.hpp:55, from /home/davids/gcc/build/powerpc-ibm-aix5.3.0.0/libstdc++-v3/include/ext/pb_ds/assoc_container.hpp:48, from /home/davids/gcc/gcc-4.6.1/libstdc++-v3/include/precompiled/extc++.h:60: /home/davids/gcc/build/powerpc-ibm-aix5.3.0.0/libstdc++-v3/include/ext/pb_ds/detail/bin_search_tree_/bin_search_tree_.hpp:467:81: fatal error: ext/pb_ds/detail/bin_search_tree_/constructors_destructor_fn_imps.hpp: A file or directory in the path name does not exist. compilation terminated. There are demanded 2 files named hpp but there are only hp files.
[Bug middle-end/50125] gcc.dg/uninit-B.c and gcc.dg/uninit-pr19430.c XPASS everywhere
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50125 --- Comment #2 from Rainer Orth 2011-10-07 09:02:21 UTC --- Author: ro Date: Fri Oct 7 09:02:13 2011 New Revision: 179649 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179649 Log: Don't XFAIL gcc.dg/uninit-B.c etc. (PR middle-end/50125) PR middle-end/50125 * gcc.dg/uninit-B.c (baz): Remove xfail *-*-*. * gcc.dg/uninit-pr19430.c (main): Remove xfail *-*-*. (bar3): Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/uninit-B.c trunk/gcc/testsuite/gcc.dg/uninit-pr19430.c
[Bug middle-end/50125] gcc.dg/uninit-B.c and gcc.dg/uninit-pr19430.c XPASS everywhere
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50125 Rainer Orth changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | --- Comment #3 from Rainer Orth 2011-10-07 09:05:53 UTC --- Fixed for 4.7.0.
[Bug middle-end/50650] [4.7 Regression] ICE in vect_is_simple_use_1, at tree-vect-stmts.c:5689
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50650 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-10-07 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Jakub Jelinek 2011-10-07 09:18:36 UTC --- Created attachment 25437 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25437 gcc47-pr50650.patch Untested fix.
[Bug go/50654] New: Many Go tests fail on emutls targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50654 Bug #: 50654 Summary: Many Go tests fail on emutls targets Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: r...@gcc.gnu.org Host: *-*-solaris2.[89] Target: *-*-solaris2.[89] Build: *-*-solaris2.[89] Between 20110930 and 20111006, many Go tests started to FAIL on Solaris 8 and 9/x86 (haven't tried SPARC yet) with Sun as, thus they use emutls: output is: Undefinedfirst referenced symbol in file __emutls_v.__go_panic_defer /var/gcc/regression/trunk/8-gcc/build/i386-pc-solaris2.8/./libgo/.libs/libgo.so __emutls_v.m /var/gcc/regression/trunk/8-gcc/build/i386-pc-solaris2.8/./libgo/.libs/libgo.so ld: fatal: Symbol referencing errors. No output written to /var/gcc/regression/trunk/8-gcc/build/gcc/testsuite/go/array-1.x collect2: error: ld returned 1 exit status FAIL: go.go-torture/execute/array-1.go compilation, -O0 With gas and native TLS, the tests work fine. Rainer
[Bug c++/50653] At build phase there are demanded two files named ....hpp but there are only files named ....hp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50653 --- Comment #1 from Jonathan Wakely 2011-10-07 09:26:01 UTC --- The archive is fine: tar tzf gcc-g++-4.6.1.tar.gz | grep '\.hp$' Either your download is corrupt (check its MD5 sum) or you need to use GNU tar to extract it.
[Bug go/50654] Many Go tests fail on emutls targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50654 Rainer Orth changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug middle-end/50650] [4.7 Regression] ICE in vect_is_simple_use_1, at tree-vect-stmts.c:5689
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50650 --- Comment #4 from vincenzo Innocente 2011-10-07 09:30:46 UTC --- ok in my tests
[Bug libstdc++/50641] [c++0x] is_convertible and is_constructible incorrectly require copy constructibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50641 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #6 from Paolo Carlini 2011-10-07 09:52:36 UTC --- Thanks a lot Daniel. Thus, looks like it all boils down to "just" LWG 2005, which we know well enough, I guess ;) and isn't a GCC issue.
[Bug other/50653] At build phase there are demanded two files named ....hpp but there are only files named ....hp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50653 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c++ |other Resolution||INVALID --- Comment #2 from Paolo Carlini 2011-10-07 09:54:01 UTC --- Closing.
[Bug other/50636] GC in large LTO builds cause excessive fragmentation in memory map
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50636 --- Comment #9 from Jakub Jelinek 2011-10-07 10:01:32 UTC --- (In reply to comment #2) > Perhaps on Linux, at least with recentish kernel, we could change > release_pages > into keeping the pages in the G.free_pages chain, but call madvise > MADV_DONTNEED on the pages (and remember that we've done that so next > release_pages won't do it again unless we have since then alloc_page'd it). > At > least on 64-bit hosts where there is plenty of address space. MADV_DONTNEED > will keep it around unless the kernel needs it for something else (something > e.g. glibc malloc uses too). Seems I misremembered what MADV_DONTNEED it, what I described was the proposed and unfortunately shot down MADV_FREE. MADV_DONTNEED zaps the pages immediately, so you get new zeroed pages even if it is touched immediately after the madvise call. Still, even MADV_DONTNEED is useful, it will prevent the excessive fragmentation.
[Bug tree-optimization/50596] Problems in vectorization of condition expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50596
--- Comment #14 from vincenzo Innocente
2011-10-07 10:15:03 UTC ---
signed char k[1024];
void foo6() {
for (int i=0; i!=N; ++i)
k[i] = (a[i]
[Bug target/50655] New: Many of the new VIS2/VIS3 tests FAIL on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50655 Bug #: 50655 Summary: Many of the new VIS2/VIS3 tests FAIL on Solaris 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: da...@davemloft.net, ebotca...@gcc.gnu.org Host: sparc-sun-solaris2.1[01] Target: sparc-sun-solaris2.1[01] Build: sparc-sun-solaris2.1[01] As of rev 179598, many of the new VIS2/VIS3 tests FAIL on Solaris 10 and 11, both with Sun as and gas 2.21.1: FAIL: gcc.target/sparc/cmask.c scan-assembler cmask8\\t% FAIL: gcc.target/sparc/cmask.c scan-assembler cmask16\\t% FAIL: gcc.target/sparc/cmask.c scan-assembler cmask32\\t% FAIL: gcc.target/sparc/combined-1.c scan-assembler-times fandnot1\\t% 4 FAIL: gcc.target/sparc/combined-1.c scan-assembler-times for\\t% 4 FAIL: gcc.target/sparc/combined-1.c scan-assembler-times fxor\\t% 4 FAIL: gcc.target/sparc/fhalve.c scan-assembler fhadds\\t% FAIL: gcc.target/sparc/fhalve.c scan-assembler fhaddd\\t% FAIL: gcc.target/sparc/fhalve.c scan-assembler fhsubs\\t% FAIL: gcc.target/sparc/fhalve.c scan-assembler fhsubd\\t% FAIL: gcc.target/sparc/fhalve.c scan-assembler fnhadds\\t% FAIL: gcc.target/sparc/fhalve.c scan-assembler fnhaddd\\t% FAIL: gcc.target/sparc/fnegop.c scan-assembler fnadds\\t% FAIL: gcc.target/sparc/fnegop.c scan-assembler fnaddd\\t% FAIL: gcc.target/sparc/fnegop.c scan-assembler fnmuls\\t% FAIL: gcc.target/sparc/fnegop.c scan-assembler fnmuld\\t% FAIL: gcc.target/sparc/fnegop.c scan-assembler fnsmuld\\t% FAIL: gcc.target/sparc/fpadds.c (test for excess errors) UNRESOLVED: gcc.target/sparc/fpadds.c scan-assembler fpadds16\\t% UNRESOLVED: gcc.target/sparc/fpadds.c scan-assembler fpadds16s\\t% UNRESOLVED: gcc.target/sparc/fpadds.c scan-assembler fpsubs16\\t% UNRESOLVED: gcc.target/sparc/fpadds.c scan-assembler fpsubs16s\\t% UNRESOLVED: gcc.target/sparc/fpadds.c scan-assembler fpadds32\\t% UNRESOLVED: gcc.target/sparc/fpadds.c scan-assembler fpadds32s\\t% UNRESOLVED: gcc.target/sparc/fpadds.c scan-assembler fpsubs32\\t% UNRESOLVED: gcc.target/sparc/fpadds.c scan-assembler fpsubs32s\\t% FAIL: gcc.target/sparc/fshift.c (test for excess errors) UNRESOLVED: gcc.target/sparc/fshift.c scan-assembler fsll16\\t% UNRESOLVED: gcc.target/sparc/fshift.c scan-assembler fslas16\\t% UNRESOLVED: gcc.target/sparc/fshift.c scan-assembler fsrl16\\t% UNRESOLVED: gcc.target/sparc/fshift.c scan-assembler fsra16\\t% UNRESOLVED: gcc.target/sparc/fshift.c scan-assembler fsll32\\t% UNRESOLVED: gcc.target/sparc/fshift.c scan-assembler fslas32\\t% UNRESOLVED: gcc.target/sparc/fshift.c scan-assembler fsrl32\\t% UNRESOLVED: gcc.target/sparc/fshift.c scan-assembler fsra32\\t% FAIL: gcc.target/sparc/fucmp.c scan-assembler fucmple8\\t% FAIL: gcc.target/sparc/fucmp.c scan-assembler fucmpne8\\t% FAIL: gcc.target/sparc/fucmp.c scan-assembler fucmpgt8\\t% FAIL: gcc.target/sparc/fucmp.c scan-assembler fucmpeq8\\t% FAIL: gcc.target/sparc/lzd.c scan-assembler-times lzd\\t% 3 FAIL: gcc.target/sparc/vis3misc.c (test for excess errors) UNRESOLVED: gcc.target/sparc/vis3misc.c scan-assembler fchksm16\\t% UNRESOLVED: gcc.target/sparc/vis3misc.c scan-assembler pdistn\\t% UNRESOLVED: gcc.target/sparc/vis3misc.c scan-assembler fmean16\\t% UNRESOLVED: gcc.target/sparc/vis3misc.c scan-assembler fpadd64\\t% UNRESOLVED: gcc.target/sparc/vis3misc.c scan-assembler fpsub64\\t% FAIL: gcc.target/sparc/xmul.c scan-assembler umulxhi\\t% FAIL: gcc.target/sparc/xmul.c scan-assembler xmulx\\t% FAIL: gcc.target/sparc/xmul.c scan-assembler xmulxhi\\t% The problem seems to be the same everywhere: $ /var/gcc/regression/trunk/11-gcc/build/gcc/xgcc -B/var/gcc/regression/trunk/11-gcc/build/gcc/ /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/sparc/cmask.c -mcpu=niagara3 -mvis -S -o cmask.s $ grep cmask cmask.s .file "cmask.c" call__builtin_vis_cmask8, 0 call__builtin_vis_cmask16, 0 call__builtin_vis_cmask32, 0 Rainer
[Bug tree-optimization/50596] Problems in vectorization of condition expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50596
--- Comment #15 from Jakub Jelinek 2011-10-07
10:31:13 UTC ---
float a[1024], b[1024], c[1024], d[1024];
int j[1024];
void
f1 (void)
{
int i;
for (i = 0; i < 1024; ++i)
{
unsigned int x = a[i] < b[i] ? -1 : 0;
unsigned int y = c[i] < d[i] ? -1 : 0;
j[i] = (x & y) >> 31;
}
}
vectorizes fine and generates quite good code IMHO. Something similar I'd like
to achieve with the vect_recog_bool_pattern I'm working on even for some of
your testcases.
[Bug tree-optimization/50557] [4.7 Regression] Register pressure increase after reassociation (x86, 32 bits)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50557 --- Comment #6 from Igor Zamyatin 2011-10-07 10:33:33 UTC --- Indeed, overall register pressure is not increased. Even before IRA dumps show that register pressure is actually kept on the same level. Looks like it is a tricky case we met. First, we can see that loop consists of 4 same group of instructions. The only difference is the index value used by arrays in each group. Before the reassociation improvement the group located on lines 30-33 of the attached test for some reasons (I haven't checked this yet) got a different sequence of instructions than others. After William's reassociation changes all groups got similar sequence. (Maybe there were some good reason for that group to be different? :) ) Now the tricky part. In "fast" (i.e. before William's commit) version for group on lines 30-33 IRA managed to hold "c" in eax register. Moreover because of shorter live range of "c" IRA managed to reuse eax inside the operations of 30-th line. For others group all work was made through memory. Since reassociation improvement made all groups to have the same look, we unsurprisingly got memory instead of registers which led to the performance drop. That is sort of my vision of the whole picture. Any comments, ideas?
[Bug tree-optimization/50575] gcc.c-torture/execute/vector-compare-2.c FAILs on Solaris 8/9 x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50575 --- Comment #3 from Rainer Orth 2011-10-07 11:33:02 UTC --- Author: ro Date: Fri Oct 7 11:32:59 2011 New Revision: 179651 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179651 Log: Disable ABI warnings for gcc.c-torture/execute/vector-compare-2.c (PR tree-optimization/50575) PR tree-optimization/50575 * gcc.c-torture/execute/vector-compare-2.x: New file. Added: trunk/gcc/testsuite/gcc.c-torture/execute/vector-compare-2.x Modified: trunk/gcc/testsuite/ChangeLog
[Bug lto/50492] [4.7 regression] Ada bootstrap failure --with-build-config=bootstrap-lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50492 --- Comment #6 from Eric Botcazou 2011-10-07 11:43:08 UTC --- Author: ebotcazou Date: Fri Oct 7 11:43:03 2011 New Revision: 179652 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179652 Log: PR lto/50492 * gcc-interface/gigi.h (gnat_pushdecl): Adjust comment. * gcc-interface/utils.c (global_context): New variable. (gnat_pushdecl): Initialize it and set it as the DECL_CONTEXT of DECLs that are either public external or at top level. Use "No" macro. (end_subprog_body): Call decl_function_context. (rest_of_subprog_body_compilation): Likewise. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/gigi.h trunk/gcc/ada/gcc-interface/utils.c
[Bug middle-end/50650] [4.7 Regression] ICE in vect_is_simple_use_1, at tree-vect-stmts.c:5689
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50650 --- Comment #5 from Jakub Jelinek 2011-10-07 11:48:07 UTC --- Author: jakub Date: Fri Oct 7 11:48:03 2011 New Revision: 179653 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179653 Log: PR tree-optimization/50650 * tree-vect-patterns.c (vect_recog_mixed_size_cond_pattern): Don't call vect_is_simple_cond here, instead fail if cond_expr isn't COMPARISON_CLASS_P or if get_vectype_for_scalar_type returns NULL for cond_expr's first operand. * tree-vect-stmts.c (vect_is_simple_cond): Static again. * tree-vectorizer.h (vect_is_simple_cond): Remove prototype. * gcc.c-torture/compile/pr50650.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr50650.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-patterns.c trunk/gcc/tree-vect-stmts.c trunk/gcc/tree-vectorizer.h
[Bug lto/50492] [4.7 regression] Ada bootstrap failure --with-build-config=bootstrap-lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50492 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Eric Botcazou 2011-10-07 11:48:52 UTC --- At least this particular assertion failure.
[Bug tree-optimization/50575] gcc.c-torture/execute/vector-compare-2.c FAILs on Solaris 8/9 x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50575 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-10/msg00574.htm ||l Resolution||FIXED AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | --- Comment #4 from Rainer Orth 2011-10-07 11:55:01 UTC --- Fixed for 4.7.0.
[Bug middle-end/50633] [4.7 Regression] New test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50633 --- Comment #11 from Bernd Schmidt 2011-10-07 12:10:11 UTC --- I see none of these failures in the x86_64 test run with my last patch applied. Can you confirm that it's fixed?
[Bug gcov-profile/49484] gcov crash if two(or more) forks happen at the same time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49484 vijay changed: What|Removed |Added CC||vijay910 at gmail dot com --- Comment #3 from vijay 2011-10-07 12:12:49 UTC --- Have the same issue on sles 10 machine Back trace: #0 0x2b835b95 in raise () from /lib64/libc.so.6 #1 0x2b836f90 in abort () from /lib64/libc.so.6 #2 0x2b86c35b in __libc_message () from /lib64/libc.so.6 #3 0x2b87134e in malloc_printerr () from /lib64/libc.so.6 #4 0x2b87295c in free () from /lib64/libc.so.6 #5 0x2b862942 in fclose@@GLIBC_2.2.5 () from /lib64/libc.so.6 #6 0x0048e644 in __gcov_close () #7 0x0048eb35 in gcov_exit () #8 0x0048f48f in __gcov_flush () #9 0x0048f529 in __gcov_fork () gcc version 4.1.2 20070115 (prerelease) (SUSE Linux)
[Bug middle-end/50633] [4.7 Regression] New test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50633 --- Comment #12 from Bernd Schmidt 2011-10-07 12:20:57 UTC --- Sorry, commit didn't go through earlier - it's in now.
[Bug middle-end/50650] [4.7 Regression] ICE in vect_is_simple_use_1, at tree-vect-stmts.c:5689
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50650 Markus Trippelsdorf changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Markus Trippelsdorf 2011-10-07 12:27:14 UTC --- fixed. Thanks.
[Bug middle-end/50527] inconsistent vla align
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527 --- Comment #9 from vries at gcc dot gnu.org 2011-10-07 12:49:54 UTC --- Author: vries Date: Fri Oct 7 12:49:49 2011 New Revision: 179655 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179655 Log: 2011-10-07 Tom de Vries PR middle-end/50527 * tree.c (build_common_builtin_nodes): Add local_define_builtin for * builtins.c (expand_builtin_alloca): Handle BUILT_IN_ALLOCA_WITH_ALIGN * tree-ssa-ccp.c (evaluate_stmt): Set align for * builtins.def (BUILT_IN_ALLOCA_WITH_ALIGN): Declare using * ipa-pure-const.c (special_builtin_state): Handle * tree-ssa-alias.c (ref_maybe_used_by_call_p_1) * function.c (gimplify_parameters): Lower vla to * gimplify.c (gimplify_vla_decl): Same. * cfgexpand.c (expand_call_stmt): Handle BUILT_IN_ALLOCA_WITH_ALIGN. * tree-mudflap.c (mf_xform_statements): Same. * tree-ssa-dce.c (mark_stmt_if_obviously_necessary) * varasm.c (incorporeal_function_p): Same. * tree-object-size.c (alloc_object_size): Same. * gimple.c (gimple_build_call_from_tree): Same. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/builtins.def trunk/gcc/cfgexpand.c trunk/gcc/function.c trunk/gcc/gimple.c trunk/gcc/gimplify.c trunk/gcc/ipa-pure-const.c trunk/gcc/tree-mudflap.c trunk/gcc/tree-object-size.c trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-ccp.c trunk/gcc/tree-ssa-dce.c trunk/gcc/tree.c trunk/gcc/varasm.c
[Bug middle-end/50527] inconsistent vla align
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527 --- Comment #10 from vries at gcc dot gnu.org 2011-10-07 12:50:00 UTC --- Author: vries Date: Fri Oct 7 12:49:56 2011 New Revision: 179656 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179656 Log: 2011-10-07 Tom de Vries PR middle-end/50527 * gcc.dg/pr50527.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr50527.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/49049] ICE in copyprop_hardreg_forward_1, at regcprop.c:767
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49049 --- Comment #9 from Bernd Schmidt 2011-10-07 12:56:55 UTC --- Author: bernds Date: Fri Oct 7 12:56:52 2011 New Revision: 179657 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179657 Log: PR target/49049 * config/arm/arm.md (arm_subsi3_insn): Lose the last alternative. * gcc.c-torture/compile/pr49049.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/compile/pr49049.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/arm/arm.md branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug target/49049] ICE in copyprop_hardreg_forward_1, at regcprop.c:767
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49049 Bernd Schmidt changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #10 from Bernd Schmidt 2011-10-07 13:07:02 UTC --- Fixed.
[Bug middle-end/50527] inconsistent vla align
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527 vries at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from vries at gcc dot gnu.org 2011-10-07 13:38:02 UTC --- patch and test-case checked in, closing PR.
[Bug fortran/50625] [4.6/4.7 Regression][OOP] ALLOCATABLE attribute lost for module CLASS variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50625 --- Comment #5 from janus at gcc dot gnu.org 2011-10-07 14:40:21 UTC --- Author: janus Date: Fri Oct 7 14:40:14 2011 New Revision: 179660 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179660 Log: 2011-10-07 Janus Weil PR fortran/50625 * class.c (gfc_build_class_symbol): Fix whitespace. * module.c (mio_symbol): Set 'class_ok' attribute. * trans-decl.c (gfc_get_symbol_decl): Make sure the backend_decl has been built for class symbols. 2011-10-07 Janus Weil PR fortran/50625 * gfortran.dg/class_46.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/class_46.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/module.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug target/50302] inefficient float->double conversion in AVX with -mtune=generic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50302 --- Comment #4 from Andi Kleen 2011-10-07 14:40:02 UTC --- Sorry yes my mistake.
[Bug fortran/50625] [4.6/4.7 Regression][OOP] ALLOCATABLE attribute lost for module CLASS variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50625 --- Comment #6 from janus at gcc dot gnu.org 2011-10-07 14:42:15 UTC --- Fixed on trunk with r179660.
[Bug other/50636] GC in large LTO builds cause excessive fragmentation in memory map
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50636 --- Comment #10 from Andi Kleen 2011-10-07 14:44:10 UTC --- To track the pattern you can simply use strace or ftrace (I did ftrace) I checked the kernel code now and if the madvise is big enough it won't split up the 2MB page. So doing it aggressively should be ok, but still it may be beneficial to skip it for very scattered pages. I suspect other OS don't have MADV_DONTNEED, they would probably need Honza's pool idea. I did a prototype patch now, will be testing it.
[Bug go/50656] New: Several Go tests with unrecognized test line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50656
Bug #: 50656
Summary: Several Go tests with unrecognized test line
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
AssignedTo: i...@airs.com
ReportedBy: r...@gcc.gnu.org
I noticed that several Go tests are ignored due to unrecognized test lines:
go.test/test/fixedbugs/bug324.go: unrecognized test line: // $G $D/$F.dir/p.go
&& $G $D/$F.dir/main.go && $L main.$A && ./$A.out
go.test/test/fixedbugs/bug345.go: unrecognized test line: // $G $D/$F.dir/io.go
&& errchk $G -e $D/$F.dir/main.go
go.test/test/fixedbugs/bug364.go: unrecognized test line: package main
go.test/test/fixedbugs/bug324.go: unrecognized test line: // $G $D/$F.dir/p.go
&& $G $D/$F.dir/main.go && $L main.$A && ./$A.out
go.test/test/fixedbugs/bug345.go: unrecognized test line: // $G $D/$F.dir/io.go
&& errchk $G -e $D/$F.dir/main.go
go.test/test/fixedbugs/bug364.go: unrecognized test line: package main
go.test/test/interface/private.go: unrecognized test line: // $G $D/${F}1.go &&
errchk $G $D/$F.go
go.test/test/interface/private.go: unrecognized test line: // $G $D/${F}1.go &&
errchk $G $D/$F.go
Rainer
[Bug middle-end/50335] ICE in psct_dynamic_dim, at graphite-poly.h:659
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50335 --- Comment #2 from Gregory Maxwell 2011-10-07 14:52:37 UTC --- Still failing in r179659.
[Bug middle-end/50335] ICE in psct_dynamic_dim, at graphite-poly.h:659
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50335 --- Comment #3 from Paolo Carlini 2011-10-07 14:57:11 UTC --- No miracles, eh?
[Bug target/50655] Many of the new VIS2/VIS3 tests FAIL on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50655 --- Comment #1 from David S. Miller 2011-10-07 15:01:55 UTC --- Please try to figure out why the configure test is not detecting VIS3 instruction capabilities in your assembler. That's why the VIS3 tests are failing. The combined-1.c test is not a VIS3 test, and is failing because of a known register allocator issue that Eric has asked Vlad to look into.
[Bug target/50655] Many of the new VIS2/VIS3 tests FAIL on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50655
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-10-07 15:16:16 UTC ---
> --- Comment #1 from David S. Miller 2011-10-07
> 15:01:55 UTC ---
> Please try to figure out why the configure test is not detecting VIS3
> instruction capabilities in your assembler. That's why the VIS3 tests are
> failing.
On both Solaris 10 and 11, as complains:
configure:24069: /usr/ccs/bin/as -xarch=v9d -o conftest.o conftest.s >&5
/usr/ccs/bin/as: "conftest.s", line 4: error: detect global register use not
cov
ered .register pseudo-op
/usr/ccs/bin/as: "conftest.s", line 4: error: detect global register use not
cov
ered .register pseudo-op
configure:24072: $? = 1
Adding
.register %g2, #scratch
.register %g3, #scratch
to the testcase allows the test to be assembled without error.
The Solaris 8 and 9 as errors out with
as: error: unknown option 'xarch=v9d'
usage: as [-V] [-Q{y,n}] [-f[O][if]#] [-q] [-s]
[-S] [-K {pic,PIC}] [-o objfile] [-L] [-T]
[-P [[-Ipath] [-Dname] [-Dname=def] [-Uname]]...]
[-m [-Ym,path]] [-n] [-ul] [-xF] [-xarch=v7] [-xarch=v8] [-xarch=v8a]
[-xarch=v8plus] [-xarch=v8plusa] [-xarch=v8plusb] [-xarch=v9] [-xarch=v9a]
[-xarch=v9b] [-xcode={pic13,pic32}] file.s...
With gas 2.21.1, I get this failure instead:
configure:24069: /vol/gcc/bin/gas-2.21.1 -xarch=v9d -o conftest.o conftest.s
>
&5
Assembler messages:
Error: invalid architecture -xarch=v9d
Error: unrecognized option -\300v9d
configure:24072: $? = 1
Given that even the latest released gas doesn't support those insns, I
think the testsuite needs to accomodate the possibility that the
assembler used doesn't understand them.
> The combined-1.c test is not a VIS3 test, and is failing because of a known
> register allocator issue that Eric has asked Vlad to look into.
Ok, thanks.
Rainer
[Bug target/49868] Implement named address space to place/access data in flash memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49868 Georg-Johann Lay changed: What|Removed |Added Attachment #24916|0 |1 is obsolete|| --- Comment #2 from Georg-Johann Lay 2011-10-07 15:22:51 UTC --- Created attachment 25438 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25438 1/2: r175594: Ulrich Weigand's extension to some GCC hooks As posted by Ulrich in http://gcc.gnu.org/ml/gcc/2011-08/msg00131.html and updated to SVN 175594.
[Bug target/49868] Implement named address space to place/access data in flash memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49868 --- Comment #3 from Georg-Johann Lay 2011-10-07 15:24:32 UTC --- Created attachment 25439 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25439 2/2: r179594: AVR part of implementation
[Bug target/49868] Implement named address space to place/access data in flash memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49868 Georg-Johann Lay changed: What|Removed |Added Keywords||patch Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-07 Ever Confirmed|0 |1 --- Comment #4 from Georg-Johann Lay 2011-10-07 15:28:45 UTC --- See also discussion in gcc-patches@ http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00471.html
[Bug middle-end/50335] ICE in psct_dynamic_dim, at graphite-poly.h:659
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50335 --- Comment #4 from Gregory Maxwell 2011-10-07 15:29:42 UTC --- Ha, indeed. Well, I don't want it to be forgotten just because its become old and potentially inapplicable. I test GCC development periodically on all the software I work on— most of the time anything I find is fixed quickly, it's not something urgent for me. (I once reported a bug in a proprietary compiler: reporting bugs in GCC is my penance ;) )
[Bug other/49752] [4.7 Regression] Non-existing struct `tree_type' in fold_checksum_tree in fold-const.c, can't build with `--enable-checking=fold'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49752 --- Comment #2 from Richard Henderson 2011-10-07 15:35:56 UTC --- Author: rth Date: Fri Oct 7 15:35:49 2011 New Revision: 179663 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179663 Log: PR 49752 * fold-const.c (fold_checksum_tree): Remove out-of-date assert. Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c
[Bug other/49752] [4.7 Regression] Non-existing struct `tree_type' in fold_checksum_tree in fold-const.c, can't build with `--enable-checking=fold'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49752 Richard Henderson changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Richard Henderson 2011-10-07 15:36:32 UTC --- Fixed.
[Bug target/34888] Stack patterns for AVR not optimal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34888 Richard Henderson changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #7 from Richard Henderson 2011-10-07 15:37:40 UTC --- Re-open if you think there's still work to do.
[Bug tree-optimization/50644] ICE in set_is_used added today
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644 --- Comment #2 from Michael Matz 2011-10-07 15:45:44 UTC --- Try to find out what var is. The segfault should also happen with an unoptimized cc1 so that you can see the value of var.
[Bug middle-end/35860] [4.4/4.5/4.6/4.7 Regression] [avr] code bloat caused by -fsplit-wide-types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35860 Georg-Johann Lay changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #16 from Georg-Johann Lay 2011-10-07 15:50:10 UTC --- Closed this PR. If you are still uncomfortable with the code avr-gcc generates together with -fsplit-wide-types, please file a new bug report for the register allocator.
[Bug middle-end/50657] New: [4.7 Regression] FAIL: gfortran.dg/select_type_12.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50657 Bug #: 50657 Summary: [4.7 Regression] FAIL: gfortran.dg/select_type_12.f03 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86, revision 179620 gave FAIL: gfortran.dg/select_type_12.f03 -O (internal compiler error) FAIL: gfortran.dg/select_type_12.f03 -O (test for excess errors) Revision 179617 is OK.
[Bug middle-end/50640] [4.7 Regression] FAIL: gfortran.dg/select_type_12.f03 -O (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50640 Dominique d'Humieres changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #2 from Dominique d'Humieres 2011-10-07 16:15:28 UTC --- *** Bug 50657 has been marked as a duplicate of this bug. ***
[Bug middle-end/50657] [4.7 Regression] FAIL: gfortran.dg/select_type_12.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50657 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Dominique d'Humieres 2011-10-07 16:15:28 UTC --- Duplicate of pr50640. *** This bug has been marked as a duplicate of bug 50640 ***
[Bug middle-end/50633] [4.7 Regression] New test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50633 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #13 from H.J. Lu 2011-10-07 16:20:59 UTC --- Fixed as of revision 179662.
[Bug tree-optimization/50644] ICE in set_is_used added today
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek 2011-10-07 16:30:41 UTC --- +FAIL: gfortran.dg/select_type_12.f03 -O (internal compiler error) +FAIL: gfortran.dg/select_type_12.f03 -O (test for excess errors) is also ICE in set_is_used, both on x86_64-linux and i686-linux.
[Bug web/50642] onlinedocs formated text too small to read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50642 --- Comment #4 from Andreas Schwab 2011-10-07 16:33:46 UTC --- A @smallexample is supposed to be smaller than an @example.
[Bug tree-optimization/50644] ICE in set_is_used added today
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644 --- Comment #4 from Michael Matz 2011-10-07 16:34:49 UTC --- The fortran segfault is tracked as PR50640.
[Bug middle-end/50638] [4.7 Regression] emulated TLS fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50638 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #4 from Rainer Orth 2011-10-07 16:40:09 UTC --- The same issue breaks bootstrap on Solaris 8 and 9/x86 (so far, SPARC probably too) with Sun as in libgo: /vol/gcc/src/hg/trunk/local/libgo/runtime/go-defer.c: In function '__go_defer': /vol/gcc/src/hg/trunk/local/libgo/runtime/go-defer.c:16:1: internal compiler error: Segmentation Fault
[Bug tree-optimization/50658] New: [4.7 regression] SIGSEGV in tree-flow-inline.h:562
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50658 Bug #: 50658 Summary: [4.7 regression] SIGSEGV in tree-flow-inline.h:562 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: jojel...@gmail.com Host: i686-pc-cygwin Target: i686-pc-cygwin Build: i686-pc-cygwin Created attachment 25440 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25440 preprocessed source $ gdb --args /tmp/gcc/host-i686-pc-cygwin/gcc/cc1plus.exe -quiet -nostdinc++ -v -I /tmp/gcc/libstdc++-v3/../libgcc -I /tmp/gcc/i686-pc-cygwin/libstdc++-v3/include/i686-pc-cygwin -I /tmp/gcc/i686-pc-cygwin/libstdc++-v3/include -I /tmp/gcc/libstdc++-v3/libsupc++ -iprefix /tmp/gcc/host-i686-pc-cygwin/gcc/../lib/gcc/i686-pc-cygwin/4.7.0/ -isystem /tmp/gcc/host-i686-pc-cygwin/gcc/include -isystem /tmp/gcc/host-i686-pc-cygwin/gcc/include-fixed -D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter /usr/i686-pc-cygwin/bin/../include/w32api -idirafter /usr/i686-pc-cygwin/bin/../../include/w32api -isystem /usr/i686-pc-cygwin/include -isystem /usr/i686-pc-cygwin/sys-include ../../.././libstdc++-v3/libsupc++/eh_globals.cc -quiet -dumpbase eh_globals.cc -mtune=generic -march=pentiumpro -auxbase-strip eh_globals.o -O2 -Wall -Wextra -Wwrite-strings -Wcast-qual -version -fno-implicit-templates -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=eh_globals.lo -o /tmp/ccF1jDqY.s GNU gdb (GDB) 7.3.50.20110903-cvs Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-cygwin". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... warning: the current range check setting does not match the language. warning: the current type check setting does not match the language. Whether backtraces should continue past the entry point of a program is off. Reading symbols from /tmp/gcc/host-i686-pc-cygwin/gcc/cc1plus.exe...rdone. (gdb) r Starting program: /tmp/gcc/host-i686-pc-cygwin/gcc/cc1plus.exe -quiet -nostdinc++ -v -I /tmp/gcc/libstdc++-v3/../libgcc -I /tmp/gcc/i686-pc-cygwin/libstdc++-v3/include/i686-pc-cygwin -I /tmp/gcc/i686-pc-cygwin/libstdc++-v3/include -I /tmp/gcc/libstdc++-v3/libsupc++ -iprefix /tmp/gcc/host-i686-pc-cygwin/gcc/../lib/gcc/i686-pc-cygwin/4.7.0/ -isystem /tmp/gcc/host-i686-pc-cygwin/gcc/include -isystem /tmp/gcc/host-i686-pc-cygwin/gcc/include-fixed -D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter /usr/i686-pc-cygwin/bin/../include/w32api -idirafter /usr/i686-pc-cygwin/bin/../../include/w32api -isystem /usr/i686-pc-cygwin/include -isystem /usr/i686-pc-cygwin/sys-include ../../.././libstdc++-v3/libsupc++/eh_globals.cc -quiet -dumpbase eh_globals.cc -mtune=generic -march=pentiumpro -auxbase-strip eh_globals.o -O2 -Wall -Wextra -Wwrite-strings -Wcast-qual -version -fno-implicit-templates -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=eh_globals.lo -o /tmp/ccF1jDqY.s [New Thread 4884.0x2ac] warning: section .gnu_debuglink not found in /cygdrive/d/cygwin/bin/cygwin1.dbg [New Thread 4884.0x170c] GNU C++ (GCC) version 4.7.0 20111007 (experimental) (i686-pc-cygwin) compiled by GNU C version 4.7.0 20111006 (experimental), GMP version 5.0.0, MPFR version 3.0.1-p4, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory "/usr/i686-pc-cygwin/sys-include" ignoring nonexistent directory "/tmp/gcc/host-i686-pc-cygwin/gcc/../lib/gcc/i686-pc-cygwin/4.7.0/include" ignoring nonexistent directory "/tmp/gcc/host-i686-pc-cygwin/gcc/../lib/gcc/i686-pc-cygwin/4.7.0/include-fixed" ignoring nonexistent directory "/tmp/gcc/host-i686-pc-cygwin/gcc/../lib/gcc/i686-pc-cygwin/4.7.0/../../../../i686-pc-cygwin/include" ignoring duplicate directory "/usr/lib/gcc/i686-pc-cygwin/4.7.0/../../../../i686-pc-cygwin/include" ignoring duplicate directory "/usr/include" ignoring duplicate directory "/usr/i686-pc-cygwin/bin/../../include/w32api" #include "..." search starts here: #include <...> search starts here: /tmp/gcc/libstdc++-v3/../libgcc /tmp/gcc/i686-pc-cygwin/libstdc++-v3/include/i686-pc-cygwin /tmp/gcc/i686-pc-cygwin/libstdc++-v3/include /tmp/gcc/libstdc++-v3/libsupc++ /tmp/gcc/host-i686-pc-cygwin/gcc/include /tmp/gcc/host-i686-pc-cygwin/gcc/include-fixed /usr/i686-pc-cygwin/include /usr
[Bug middle-end/50640] [4.7 Regression] FAIL: gfortran.dg/select_type_12.f03 -O (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50640
--- Comment #3 from Michael Matz 2011-10-07 16:45:55
UTC ---
Hmm, this is not as trivial as PR50638. fortran frontend generates this
static variable local to MAIN:
static struct __vtype_MAIN___T1 __vtab_MAIN___T1 = {._hash=41707971, ._size=4,
._extends=0B, ._def_init=&__def_init_MAIN___T1, ._copy=__copy_MAIN___T1};
(the reference to &__def_init_MAIN___T1 will later cause the segfault).
__vtab_MAIN___T1 will be referenced from __vtab_MAIN___T2 (also static local
in MAIN). But __vtab_MAIN___T2 will _not_ be referenced from MAIN.
Instead references to __vtab_MAIN___T2 and __vtab_MAIN___T1 are emitted from
function 'fun'. So far so good. The problem lies in walking DECL_INITIAL
for these statics. add_referenced_var will only walk it if
DECL_CONTEXT==current_function_decl (sensible). Nobody calls
add_rerefenced_var(__vtab_MAIN___T1) for function MAIN (sensible, as there
are no references).
We will call add_rerefenced_var(__vtab_MAIN___T1) from function 'fun' (also
sane), which then won't walk DECL_INITIAL, i.e. nobody makes
__def_init_MAIN___T1 referenced.
The the code in tree-ssa-live comes and walks initializers of local variables
that are used. It does so for function MAIN and variable __vtab_MAIN___T
(which is in local_decls, just not in referenced_vars), because it is marked
used (it's a non-local decl, therefore var_ann is still active from the calls
from function 'fun'). That one then walks the initializer and now notices
that nothing in it is marked referenced.
The non-triviality here lies in deciding who's wrong: add_referenced_var
(i.e. should it always mark referenced all initializers, even though they
might come from other function contexts), the tree-ssa-live code (should
it perhaps not look into initializers or at least expect them not necessarily
marked), or in the fortran frontend (should it perhaps call add_referenced_var
also for the local static in MAIN).
[Bug target/50655] Many of the new VIS2/VIS3 tests FAIL on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50655 --- Comment #3 from David S. Miller 2011-10-07 16:45:52 UTC --- Thanks, I'll add the necessary register directives and work on making the testcases conditional on assembler support.
[Bug middle-end/50640] [4.7 Regression] FAIL: gfortran.dg/select_type_12.f03 -O (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50640 --- Comment #4 from Michael Matz 2011-10-07 16:50:10 UTC --- Or another solution: should the fortran frontend perhaps put all these variables not in MAINs scope (where they aren't referenced anyway), but rather into file scope? That last solution would probably be the sanest.
[Bug target/50655] Many of the new VIS2/VIS3 tests FAIL on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50655 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-10-07 16:51:36 UTC --- > --- Comment #3 from David S. Miller 2011-10-07 > 16:45:52 UTC --- > Thanks, I'll add the necessary register directives and work on making the > testcases conditional on assembler support. Great, thanks. Rainer
[Bug middle-end/50638] [4.7 Regression] emulated TLS fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50638 Michael Matz changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #5 from Michael Matz 2011-10-07 16:53:59 UTC --- Mine. See also http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00597.html . What's the variable that causes the segfault?
[Bug middle-end/50640] [4.7 Regression] FAIL: gfortran.dg/select_type_12.f03 -O (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50640 Tobias Burnus changed: What|Removed |Added CC||janus at gcc dot gnu.org, ||pault at gcc dot gnu.org --- Comment #5 from Tobias Burnus 2011-10-07 16:57:08 UTC --- (In reply to comment #4) > Or another solution: should the fortran frontend perhaps put all these > variables not in MAINs scope (where they aren't referenced anyway), but > rather into file scope? That last solution would probably be the sanest. Looks sensible. Janus & Paul, What do you think? (One can use "pushdecl_top_level (decl)" to push variable decls to file level.)
[Bug middle-end/50638] [4.7 Regression] emulated TLS fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50638 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-10-07 16:58:40 UTC --- > --- Comment #5 from Michael Matz 2011-10-07 > 16:53:59 UTC --- > Mine. See also http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00597.html . > What's the variable that causes the segfault? Program received signal SIGSEGV, Segmentation fault. set_is_used (tp=0xbf674be4, Parma_Polyhedra_Library14Grid_Generator11set_divisorERK10__gmp_exprIA1_12__mpz_structS3_E=0x80475fc, data=0x0) at /vol/gcc/src/hg/trunk/local/gcc/tree-flow-inline.h:562 562 ann->used = true; (gdb) where #0 set_is_used (tp=0xbf674be4, Parma_Polyhedra_Library14Grid_Generator11set_divisorERK10__gmp_exprIA1_12__mpz_structS3_E=0x80475fc, data=0x0) at /vol/gcc/src/hg/trunk/local/gcc/tree-flow-inline.h:562 #1 mark_all_vars_used_1 (tp=0xbf674be4, Parma_Polyhedra_Library14Grid_Generator11set_divisorERK10__gmp_exprIA1_12__mpz_structS3_E=0x80475fc, data=0x0) at /vol/gcc/src/hg/trunk/local/gcc/tree-ssa-live.c:379 #2 0x087b479a in walk_tree_1 (tp=0xbf674be4, func=0x868f570 , ZNK23Parma_Polyhedra_Library6Matrix8num_rowsEv=0x0, pset=0x0, lh=0) at /vol/gcc/src/hg/trunk/local/gcc/tree.c:10457 #3 0x08690152 in mark_all_vars_used () at /vol/gcc/src/hg/trunk/local/gcc/tree-ssa-live.c:595 #4 remove_unused_locals () at /vol/gcc/src/hg/trunk/local/gcc/tree-ssa-live.c:727 #5 0x084e8909 in execute_function_todo ( __gmp_exprIA1_12__mpq_structS3_EE6Status10ascii_loadERSi=0x826) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:1695 #6 0x084e8f44 in mp_exprIA1_12__mpq_structS1_E7set_strEPKci ( _RKNS_17Constraint_SystemEPj=0x84e87b4 , __gmp_exprIA1_12__mpq_structS3_EE6Status10ascii_loadERSi=0x826) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:1548 #7 0x084e943e in execute_todo (2__mpz_structS7_E=2086) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:1741 #8 0x084ec2da in execute_one_pass (essionENS_15Relation_SymbolES4_=0x923e6a0) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2087 #9 0x084ec601 in execute_pass_list (essionENS_15Relation_SymbolES4_=0x923e6a0) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2119 #10 0x084ec614 in execute_pass_list (essionENS_15Relation_SymbolES4_=0x8f6c420) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2120 #11 0x084ec614 in execute_pass_list (essionENS_15Relation_SymbolES4_=0x8f6bb20) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2120 #12 0x0860d603 in tree_rest_of_compilation ( 4NNC_PolyhedronEEESaIS3_EE6removeERKS3_=0xbf638f80) at /vol/gcc/src/hg/trunk/local/gcc/tree-optimize.c:420 #13 0x082927d3 in cgraph_expand_function ( ZN23Parma_Polyhedra_Library3BoxINS_8IntervalI10__gmp_exprIA1_12__mpq_structS4_ENS_25Interval_Restriction_NoneINS_20Interval_Info_BitsetIjNS_29Rational_Interval_Info_Policy24generalized_affine_imageENS_8VariableENS_15Relation_SymbolERKNS_17Linear_ExpressionERKS2_IA1_12__mpz_structSJ_E=0xbf5bf668) at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1805 #14 0x08294a15 in Status8test_allEj () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1864 #15 cgraph_optimize () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2141 #16 0x08294e7b in cgraph_finalize_compilation_unit () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1312 #17 0x08166724 in c_write_global_declarations () at /vol/gcc/src/hg/trunk/local/gcc/c-decl.c:9936 #18 0x0859e922 in compile_file (argc=11, argv=0x804794c) at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:581 #19 do_compile (argc=11, argv=0x804794c) at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:1925 #20 toplev_main (argc=11, argv=0x804794c) at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:2001 #21 0x08cacf9b in main (argc=11, argv=0x804794c) at /vol/gcc/src/hg/trunk/local/gcc/main.c:36 (gdb) up #1 mark_all_vars_used_1 (tp=0xbf674be4, Parma_Polyhedra_Library14Grid_Generator11set_divisorERK10__gmp_exprIA1_12__mpz_structS3_E=0x80475fc, data=0x0) at /vol/gcc/src/hg/trunk/local/gcc/tree-ssa-live.c:379 379 set_is_used (t); (gdb) p t $1 = (tree) 0xbf656e40 (gdb) pt unit size align 32 symtab 0 alias set -1 canonical type bf656de0 fields unsigned SI file Program received signal SIGSEGV, Segmentation fault. 0xbf6dd359 in strlen () from /usr/lib/libc.so.1 The program being debugged was signaled while in a function called from GDB. GDB remains in the frame where the signal was received. To change this behavior use "set unwindonsignal on". Evaluation of the expression containing the function (debug_tree(tree_node*)) will be abandoned. When the function is done executing, GDB will silently stop. Rainer
[Bug middle-end/50638] [4.7 Regression] emulated TLS fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50638 --- Comment #7 from Michael Matz 2011-10-07 17:00:59 UTC --- Hmm, I can't build go due to: ../../../gcc/libgo/runtime/sigqueue.goc:79:1: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2243 but that seems unrelated.
[Bug middle-end/50638] [4.7 Regression] emulated TLS fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50638 --- Comment #8 from Michael Matz 2011-10-07 17:02:00 UTC --- Okay, so it's really the emutlv_v variables. That should be fixed by the patch at gcc-patches.
[Bug middle-end/50638] [4.7 Regression] emulated TLS fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50638 --- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-10-07 17:03:31 UTC --- > --- Comment #7 from Michael Matz 2011-10-07 > 17:00:59 UTC --- > Hmm, I can't build go due to: > ../../../gcc/libgo/runtime/sigqueue.goc:79:1: internal compiler error: in > maybe_record_trace_start, at dwarf2cfi.c:2243 > > but that seems unrelated. Doesn't happen for me on i386-pc-solaris2.[89] as of r179656. Rainer
[Bug middle-end/50638] [4.7 Regression] emulated TLS fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50638 --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-10-07 17:05:11 UTC --- > --- Comment #8 from Michael Matz 2011-10-07 > 17:02:00 UTC --- > Okay, so it's really the emutlv_v variables. That should be fixed by the > patch at gcc-patches. I'll try a bootstrap on a different machine, but will only be able to report results on monday. Rainer
[Bug web/50642] onlinedocs formated text too small to read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50642 --- Comment #5 from Georg-Johann Lay 2011-10-07 17:17:30 UTC --- Legibility first. There is no need to be more catholic than the pope ;-)
[Bug fortran/50659] New: ICE on invalid with procedure interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50659 Bug #: 50659 Summary: ICE on invalid with procedure interface Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: aben...@caltech.edu :: arrSize end module Size_Mod module Test_Mod ! use Size_Mod !! Works if module used here. implicit none private public :: Init, Proc1 contains subroutine Init(Proc_Get) implicit none procedure(Proc1), pointer, intent(inout) :: Proc_Get return end subroutine Init function Proc1(arg1) result (res) use Size_Mod !! Fails if module used here. implicit none double precision, dimension(arrSize) :: res double precision, intent(in) :: arg1 return end function Proc1 end module Test_Mod $ gfortran -v Using built-in specs. COLLECT_GCC=/usr/local/gcc-4.7/bin/gfortran COLLECT_LTO_WRAPPER=/usr/local/gcc-4.7/libexec/gcc/i686-pc-linux- gnu/4.7.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../gcc-4.7/configure --prefix=/usr/local/gcc-4.7 --enable- languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 4.7.0 20111007 (experimental) (GCC) $ gfortran -c test.F90 -o test.o f951: internal compiler error: in replace_symbol, at fortran/expr.c:4155 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. The code is presumably invalid, because the "arrSize" variable (defined in Size_Mod) isn't in scope where Proc1 is used as a procedure interface - moving the "use Size_Mod" so that "arrSize" is in scope throughout the "Test_Mod" module makes the ICE go away. The ICE also seems to occur in 4.6.1. Interestingly, 4.4.5 compiles without complaint, unless I remove "Proc1" from the "public" statement in which case it instead complains "Error: Interface 'proc1' of procedure 'proc_get' at (1) must be explicit". My understanding is that Proc1 should have an explicit interface as it's in a module.
[Bug target/50655] Many of the new VIS2/VIS3 tests FAIL on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50655 --- Comment #5 from davem at gcc dot gnu.org 2011-10-07 17:23:53 UTC --- Author: davem Date: Fri Oct 7 17:23:47 2011 New Revision: 179667 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179667 Log: Fix VIS3 assembler check and conditionalize testsuite on VIS3 support. gcc/ PR 50655 * configure.ac: Add .register directives to VIS3 test. * configure: Regenerate. gcc/testsuite/ PR 50655 * gcc.target/sparc/sparc.exp: Add vis3 target test. * gcc.target/sparc/cmask.c: Use it. * gcc.target/sparc/fhalve.c: Likewise. * gcc.target/sparc/fnegop.c: Likewise. * gcc.target/sparc/fpadds.c: Likewise. * gcc.target/sparc/fshift.c: Likewise. * gcc.target/sparc/fucmp.c: Likewise. * gcc.target/sparc/lzd.c: Likewise. * gcc.target/sparc/vis3misc.c: Likewise. * gcc.target/sparc/xmul.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/configure trunk/gcc/configure.ac trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/sparc/cmask.c trunk/gcc/testsuite/gcc.target/sparc/fhalve.c trunk/gcc/testsuite/gcc.target/sparc/fnegop.c trunk/gcc/testsuite/gcc.target/sparc/fpadds.c trunk/gcc/testsuite/gcc.target/sparc/fshift.c trunk/gcc/testsuite/gcc.target/sparc/fucmp.c trunk/gcc/testsuite/gcc.target/sparc/lzd.c trunk/gcc/testsuite/gcc.target/sparc/sparc.exp trunk/gcc/testsuite/gcc.target/sparc/vis3misc.c trunk/gcc/testsuite/gcc.target/sparc/xmul.c
[Bug other/50660] New: gcc repeats warnings twice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50660 Bug #: 50660 Summary: gcc repeats warnings twice Classification: Unclassified Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: toralf.foers...@gmx.de Created attachment 25441 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25441 QA notice from gentoo As seen in the attached file from Gentoo's build system few dedicated compiler warnings are repeated .
[Bug other/50660] gcc repeats warnings twice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50660 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-10-07 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely 2011-10-07 18:17:04 UTC --- A testcase is missing, see http://gcc.gnu.org/bugs/
[Bug c++/50660] warning about pass NULL to non pointer argument happens twice for template function call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50660
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
Status|WAITING |NEW
Last reconfirmed|2011-10-07 00:00:00 |
Component|other |c++
Summary|gcc repeats warnings twice |warning about pass NULL to
||non pointer argument
||happens twice for template
||function call
Known to fail||4.5.0, 4.7.0
--- Comment #2 from Andrew Pinski 2011-10-07
18:20:51 UTC ---
Simplified testcase:
#include
template int f(T&);
int main(void)
{
return f(NULL);
}
--- CUT ---
t.cc: In function ‘int main()’:
t.cc:6:27: warning: passing NULL to non-pointer argument 1 of ‘int f(T&) [with
T = const int]’ [-Wconversion-null]
t.cc:6:27: warning: passing NULL to non-pointer argument 1 of ‘int f(T&) [with
T = const int]’ [-Wconversion-null]
It only happens with template functions too.
Confirmed.
[Bug tree-optimization/40210] gcc byte swap builtins inadequately optimized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40210 --- Comment #9 from Pawel Sikora 2011-10-07 18:22:25 UTC --- Created attachment 25442 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25442 testcase
[Bug fortran/50659] [F03] ICE on invalid with procedure interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50659 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Summary|ICE on invalid with |[F03] ICE on invalid with |procedure interface |procedure interface --- Comment #1 from janus at gcc dot gnu.org 2011-10-07 18:22:47 UTC --- (In reply to comment #0) > :: arrSize > end module Size_Mod Apparently the first line of the module is missing: module Size_Mod
[Bug tree-optimization/40210] gcc byte swap builtins inadequately optimized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40210 --- Comment #10 from Andrew Pinski 2011-10-07 18:29:07 UTC --- (In reply to comment #9) > Created attachment 25442 [details] > testcase I think those are hard to optimize really since those are inline-asm really. And the unsigned short one gets optimized correctly.
[Bug fortran/50659] [F03] ICE on invalid with procedure interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50659 --- Comment #2 from janus at gcc dot gnu.org 2011-10-07 18:45:43 UTC --- Slight reduction of the original test case: module m integer :: arrSize end module program p implicit none procedure(Proc) :: Proc_Get contains function Proc (arg) use m double precision, dimension(arrSize) :: proc double precision :: arg end function end Fails with 4.5, 4.6 and trunk.
[Bug tree-optimization/40210] gcc byte swap builtins inadequately optimized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40210 --- Comment #11 from Pawel Sikora 2011-10-07 18:45:57 UTC --- (In reply to comment #10) > (In reply to comment #9) > > Created attachment 25442 [details] > > testcase > > I think those are hard to optimize really since those are inline-asm really. > And the unsigned short one gets optimized correctly. ahhh, glibc uses a generic i386 implementation (ror+xchg) in while it has an optimized for i486+ :(
[Bug c++/50660] warning about pass NULL to non pointer argument happens twice for template function call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50660 Paolo Carlini changed: What|Removed |Added Severity|trivial |normal
