[Bug other/53316] Change -O1 to be easily debugged and on by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53316 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-05-11 06:07:42 UTC --- As it stands, does anyone even use -O1? It seems like it would be a major improvement to make it useful. Of course people do use -O1 and making such an incompatible change to it is out of question I think. That's largely orthogonal to introducing -Odebug (and making it the default) in my opinion.
[Bug other/53319] exact subtract of two decimal floating-point values raises FE_INEXACT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53319 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c |other --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-05-11 06:27:06 UTC --- This seems like a bug in the library.
[Bug fortran/53310] [4.5/4.6/4.7/4.8 Regression] EOSHIFT leaks memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53310 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-05-11 08:15:05 UTC --- Author: burnus Date: Fri May 11 08:14:56 2012 New Revision: 187395 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187395 Log: 2012-05-11 Tobias Burnus bur...@net-b.de PR fortran/53310 * intrinsics/eoshift2.c (eoshift2): Do not leak memory by allocating it in the loop. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/eoshift2.c
[Bug c++/53305] internal crash with variadic templates and decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53305 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-05-11 08:22:39 UTC --- Author: paolo Date: Fri May 11 08:22:16 2012 New Revision: 187396 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187396 Log: /cp 2012-05-11 Paolo Carlini paolo.carl...@oracle.com PR c++/53305 * pt.c (tsubst_copy: case PARM_DECL): Return error_mark_node if tsubst_decl returns NULL_TREE. * cxx-pretty-print.c (pp_cxx_simple_type_specifier): Handle BOUND_TEMPLATE_TEMPLATE_PARM. /testsuite 2012-05-11 Paolo Carlini paolo.carl...@oracle.com PR c++/53305 * g++.dg/cpp0x/variadic132.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic132.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cxx-pretty-print.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/53305] internal crash with variadic templates and decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53305 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-05-11 08:25:02 UTC --- Fixed for 4.8.0.
[Bug other/53319] exact subtract of two decimal floating-point values raises FE_INEXACT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53319 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* CC||bje at gcc dot gnu.org --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-11 08:29:17 UTC --- Ben?
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #68 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-11 08:31:57 UTC --- *** Bug 53318 has been marked as a duplicate of this bug. ***
[Bug lto/53318] ICE in verify_gimple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53318 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-11 08:31:57 UTC --- dup *** This bug has been marked as a duplicate of bug 45586 ***
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #124 from Jan Hubicka hubicka at ucw dot cz 2012-05-11 08:34:17 UTC --- Just for comparison, clang with -O4 runs only single threaded and does everything in memory (no streaming out). It uses 3.5GB of memory (peak) and takes 19 minutes to finish... Interesting. Micsofot's compiler is also barely in 4GB space, right? Is it with debug info? I will try non-WHOPR build to see how bad we are. The actual IL is about 1.5GB of the footprint (measuing GGC memory). I think good part of the rest comes to mmap address space (the object files are rather large). Honza
[Bug other/53317] Conversion from __int128 to __float128
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53317 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-05-11 Component|c |other Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-11 08:35:15 UTC --- Please provide a testcase.
[Bug other/53316] Introduce -Odebug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53316 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-05-11 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Summary|Change -O1 to be easily |Introduce -Odebug |debugged and on by default | Ever Confirmed|0 |1 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-11 08:38:41 UTC --- (In reply to comment #4) As it stands, does anyone even use -O1? It seems like it would be a major improvement to make it useful. Of course people do use -O1 and making such an incompatible change to it is out of question I think. That's largely orthogonal to introducing -Odebug (and making it the default) in my opinion. Of course people should realize that -O1 is by no means maintained as in tuned in any way to do something reasonable. At the moment it wastes much time for no good reason, just selectively turning off some optimizations. Re-tuning -O1 definitely makes sense - maybe not to the point we'd want to go with -Odebug. I'm taking this bug as a request to add -Odebug, something I was working on, so - mine.
[Bug bootstrap/53300] [4.8 Regression] AIX bootstrap related to varpool patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53300 --- Comment #11 from Jan Hubicka hubicka at gcc dot gnu.org 2012-05-11 08:40:25 UTC --- Author: hubicka Date: Fri May 11 08:40:15 2012 New Revision: 187397 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187397 Log: PR bootstrap/53300 * varpool.c (varpool_assemble_decl): Also output constat pool entries that output_constant_pool missed. Modified: trunk/gcc/ChangeLog trunk/gcc/varpool.c
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #125 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-11 08:44:51 UTC --- (In reply to comment #122) oprofile shows: 139188 15.6963 lto1 lto1 uniquify_nodes 66390 7.4868 lto1 lto1 estimate_edge_growth 52815 5.9560 lto1 lto1 VEC_edge_growth_cache_entry_base_length 47137 5.3157 lto1 lto1 iterative_hash_hashval_t 34037 3.8384 lto1 lto1 htab_find_slot_with_hash 33604 3.7895 lto1 lto1 bp_unpack_value 26584 2.9979 lto1 lto1 do_estimate_growth_1 21410 2.4144 lto1 lto1 ggc_set_mark 17124 1.9311 lto1 lto1 inflate_fast 14464 1.6311 lto1 lto1 streamer_read_uhwi 14204 1.6018 lto1 lto1 lookup_page_table_entry 11430 1.2890 libc-2.11.1.so libc-2.11.1.so memset 11405 1.2861 lto1 lto1 streamer_read_hwi_in_range 11286 1.2727 lto1 lto1 gt_ggc_mx_lang_tree_node 11017 1.2424 lto1 lto1 iterative_hash_gimple_type 10851 1.2237 lto1 lto1 pointer_map_insert 10674 1.2037 lto1 lto1 lto_input_tree 10536 1.1881 lto1 lto1 ht_lookup_with_hash 10269 1.1580 lto1 lto1 streamer_read_uchar 9972 1.1245 lto1 lto1 streamer_read_uchar 9089 1.0250 libc-2.11.1.so libc-2.11.1.so _int_malloc 9086 1.0246 lto1 lto1 alloc_page 6603 0.7446 lto1 lto1 VEC_edge_growth_cache_entry_base_index looks like uniquify_nodes got out of control? Well - the obvious possibly slow part of uniquify nodes is that it walks all fields of record/union types. So - do you have a more detailed profile of uniquify_nodes?
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #126 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-05-11 08:46:39 UTC --- (In reply to comment #124) Just for comparison, clang with -O4 runs only single threaded and does everything in memory (no streaming out). It uses 3.5GB of memory (peak) and takes 19 minutes to finish... Interesting. Micsofot's compiler is also barely in 4GB space, right? IIRC Mozilla recently switched to a 64-bit toolchain on windows, because the 32-bit linker ran out of memory. So they are above 4GB already. Is it with debug info? No.
[Bug lto/53312] crash in materialize_cgraph (invalid free)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53312 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-05-11 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-11 08:46:37 UTC --- This looks like PR53214 - unable to verify without a testcase though. Thus, please try a recent GCC 4.7 snapshot instead. You can also simply grep for optimization attribute usage in your sources.
[Bug other/53316] Introduce -Odebug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53316 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-05-11 08:52:51 UTC --- A big question for -Odebug is e.g. if we should enable var-tracking for it or not. While it is time consuming, it should improve the debug experience, there are various cases where -O -g is actually better debuggable than -O0 -g which doesn't do var-tracking, e.g. with register vars, or VLAs, or during prologues/epilogues.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #127 from Mike Hommey mh+gcc at glandium dot org 2012-05-11 08:52:24 UTC --- (In reply to comment #126) (In reply to comment #124) Just for comparison, clang with -O4 runs only single threaded and does everything in memory (no streaming out). It uses 3.5GB of memory (peak) and takes 19 minutes to finish... Interesting. Micsofot's compiler is also barely in 4GB space, right? IIRC Mozilla recently switched to a 64-bit toolchain on windows, because the 32-bit linker ran out of memory. So they are above 4GB already. There is unfortunately no cross-linker in MSVC, so you can't link 32-bit binaries with a 64-bit toolchain. We're in the process of switching to 64-bits OS with a 32-its toolchain, which will allow an extra gigabyte of address-space. We've gone past the current 3GB limit a couple times now, at which point, we moved some stuff out of libxul. Before that, we hit the 2GB limit, at which point we used the /3GB option that allows for the extra GB.
[Bug other/53316] Introduce -Odebug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53316 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-11 08:56:41 UTC --- (In reply to comment #6) A big question for -Odebug is e.g. if we should enable var-tracking for it or not. While it is time consuming, it should improve the debug experience, there are various cases where -O -g is actually better debuggable than -O0 -g which doesn't do var-tracking, e.g. with register vars, or VLAs, or during prologues/epilogues. Well, -Odebug should aid debugging, so yes, we should enable var-tracking for it (we can throttle the limiting --params more if compile-time is going to be an issue). Of course we should evaluate the actual benefit of var-tracking for -Odebug when it materializes.
[Bug other/53316] Introduce -Odebug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53316 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-11 08:58:23 UTC --- (In reply to comment #7) (In reply to comment #6) A big question for -Odebug is e.g. if we should enable var-tracking for it or not. While it is time consuming, it should improve the debug experience, there are various cases where -O -g is actually better debuggable than -O0 -g which doesn't do var-tracking, e.g. with register vars, or VLAs, or during prologues/epilogues. Well, -Odebug should aid debugging, so yes, we should enable var-tracking for it (we can throttle the limiting --params more if compile-time is going to be an issue). Of course we should evaluate the actual benefit of var-tracking for -Odebug when it materializes. Btw, my personal goal is to make -Odebug a good default for my GCC development tree (which currently sits at -O0 -g) - I suppose for that particular case var-tracking isn't that important, but I will definitely notice if there is a difference ;)
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #128 from Jan Hubicka hubicka at ucw dot cz 2012-05-11 08:52:50 UTC --- Well - the obvious possibly slow part of uniquify nodes is that it walks all fields of record/union types. So - do you have a more detailed profile of uniquify_nodes? No, I will try to generate annotated sources then. I am bit puzzled by this - looking at the stuff there seems nothing inherently expensive in it. Honza
[Bug rtl-optimization/53125] Very slow compilation on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53125 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Keywords||alias Summary|Very slow register |Very slow compilation on |allocation on SPARC |SPARC --- Comment #7 from Steven Bosscher steven at gcc dot gnu.org 2012-05-11 09:17:44 UTC --- At -O1, with Vlad's patch and mine applied, compile time is ~230s. The forward prop pass takes 18% of that time, and alias stmt walking takes 67%. This is with a cross from x86_64-linux-gnu to sparc-sun-solaris2.11, trunk r187371, checking enabled.
[Bug fortran/53320] New: -fcheck=pointer should diagnose pointer-assignment of a noncontiguous tgt to a CONTIGUOUS ptr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53320 Bug #: 53320 Summary: -fcheck=pointer should diagnose pointer-assignment of a noncontiguous tgt to a CONTIGUOUS ptr Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Depends on: 45424 Related to PR 49232 (compile-time check) and PR 45424 (is_contiguous intrinsic, of interest is the trans-intrinsic.c part). For: integer, pointer, CONTIGUOUS :: ptr ptr = target -fcheck=pointer should check whether the RHS is contiguous. The standard demands: If the pointer object has the CONTIGUOUS attribute, the pointer target shall be contiguous. (Cf. 7.2.2.3 Data pointer assignment in the Fortran 2008 standard.) But that's not a constraint and thus needs to be checked at run time.
[Bug rtl-optimization/53125] Very slow compilation on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53125 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-11 09:33:19 UTC --- The alias stmt walking time is because of the redundant store removal code and because of PR52054 it has to re-do the walks (there are 7200 stores in the function).
[Bug tree-optimization/52054] Value-numbering does not enter translated expressions into the hash table
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52054 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-11 09:34:40 UTC --- PR53125 has a testcase where we spend time in redundant store removal in eliminate() which does vn_reference_lookup with VN_WALK (which it should not need).
[Bug target/53315] simple xtest program generates ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315 --- Comment #6 from Uros Bizjak ubizjak at gmail dot com 2012-05-11 09:41:15 UTC --- (In reply to comment #5) Created attachment 27370 [details] A patch Patch looks OK to me, but please let Andi play with this a bit, so we are sure we won't hit some other reload limitation with this pattern.
[Bug target/53291] Code generated for xtest is wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53291 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-05/msg00769.htm ||l Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #10 from Uros Bizjak ubizjak at gmail dot com 2012-05-11 09:49:12 UTC --- (In reply to comment #9) The example in PR53315 is a runtime test case, except: - it needs cpuid checks to be part of the test suite - the printfs need to be replaced with asserts - it needs to stop iceing first So, let's close this PR as FIXED.
[Bug target/53315] simple xtest program generates ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Keywords||patch Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-11 Version|unknown |4.8.0 Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #7 from Uros Bizjak ubizjak at gmail dot com 2012-05-11 09:51:46 UTC --- As discussed in PR 53291, please also add a runtime testcase that will cover PR 53291 as well as this PR.
[Bug middle-end/53161] [4.8 Regression] ICE with weakref function and a function which takes vector types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53161 Igor Zamyatin izamyatin at gmail dot com changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #6 from Igor Zamyatin izamyatin at gmail dot com 2012-05-11 10:00:51 UTC --- I also see that LTO bootstrap fails with following message ../../src-trunk/gcc/gcov.c:2348:1: internal compiler error: vector VEC(inline_edge_summary_t,base) index domain error, in inline_edge_summary at ipa-inline.h:200 } ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[6]: *** [gcov.o] Error 1 make[6]: *** Waiting for unfinished jobs rm gcj-dbtool.pod jcf-dump.pod jv-convert.pod grmic.pod gcj.pod gc-analyze.pod gcov.pod gfdl.pod cpp.pod gij.pod gfortran.pod gcc.pod fsf-funding.pod make[6]: Leaving directory `/export/gnu/import/git/gcc-test-profile/bld/gcc' make[5]: *** [all-stageprofile-gcc] Error 2 make[5]: Leaving directory `/export/gnu/import/git/gcc-test-profile/bld' make[4]: *** [stageprofile-bubble] Error 2 make[4]: Leaving directory `/export/gnu/import/git/gcc-test-profile/bld' make[3]: *** [profiledbootstrap] Error 2 make[3]: Leaving directory `/export/gnu/import/git/gcc-test-profile/bld' 6968.90user 244.95system 24:30.58elapsed 490%CPU (0avgtext+0avgdata 567304maxresident)k 16256inputs+8351248outputs (112major+65804975minor)pagefaults 0swaps make[2]: *** [profiledbootstrap] Error 2 make[2]: Leaving directory `/export/gnu/import/git/gcc-test-profile'
[Bug middle-end/53161] [4.8 Regression] ICE with weakref function and a function which takes vector types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53161 --- Comment #7 from Igor Zamyatin izamyatin at gmail dot com 2012-05-11 10:07:07 UTC --- Error message for x86 compilation
[Bug bootstrap/53300] [4.8 Regression] AIX bootstrap related to varpool patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53300 --- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-05-11 10:08:11 UTC --- --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org 2012-05-10 17:59:46 UTC --- [...] Does the following hack avoid the problem? Perhaps during the years when varpool was outputting constant pool vars something broke in the code tracking when the var is needed. It does on i386-pc-solaris2.10. Ada bootstrap completed with it. Thanks. Rainer
[Bug libstdc++/53297] Linker error on solaris 10 using gcc-4.4.4 64bit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53297 birender.singh at hotmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | --- Comment #4 from birender.singh at hotmail dot com 2012-05-11 10:49:36 UTC --- Below error is not resolved, kindly provide the solution for the below error message, Do i need to build gcc-4.4.4 64 bit once again, --with-gnu-as and --without-gnu-ld while configure. . . ../prodStartLicTest/prodStartLicTest.h: In member function 'void prodStartLicTest::prodStartEnumTest(char*, const char*, int, SLIC_STATUS, int, int)': ../prodStartLicTest/prodStartLicTest.h:1692: warning: deprecated conversion from string constant to 'char*' ../../../nobuilds/bin/fipsld -m64 -o sparc_SunOS_64/release/SuiteMain sparc_SunOS_64/release/SuiteMain.o -L/els/install/staf64/lib -lSTAF ../../../nobuilds/key/sparc_SunOS_64/release/slic_devkey.o -L../../../nobuilds/lib/sparc_SunOS_64/release -lslic -lPoco -lopenssl -lm -lstdc++ ../SlicTestLib/sparc_SunOS_64/release/libSlicTest.a -lresolv -lrt -lc -ldl -lsocket -lnsl Undefined first referenced symbol in file std::basic_streambufchar, std::char_traitschar ::seekoff(long long, std::_Ios_Seekdir, std::_Ios_Openmode) ../../../nobuilds/lib/sparc_SunOS_64/release/libPoco.a(Base64Decoder.o) ld: fatal: Symbol referencing errors. No output written to sparc_SunOS_64/release/SuiteMain collect2: ld returned 1 exit status make[3]: *** [sparc_SunOS_64/release/SuiteMain] Error 1 make[3]: Leaving directory `/els/licensing/licensing_sdk/trunk/qa/SuiteMain' make[2]: *** [all] Error 2 make[2]: Leaving directory `/els/licensing/licensing_sdk/trunk/qa/SuiteMain' make[1]: *** [all_subdirs] Error 1 make[1]: Leaving directory `/els/licensing/licensing_sdk/trunk/qa' make: *** [all] Error 2 Is this error is due to -lstdc++ library. I have provided this in the command but still same error message received all the time. or this might be a bugg in lstdc++ for Undefined first referenced symbol in file std::basic_streambufchar, std::char_traitschar ::seekoff(long long, std::_Ios_Seekdir, std::_Ios_Openmode) ../../../nobuilds/lib/sparc_SunOS_64/release/libPoco.a(Base64Decoder.o)
[Bug c/53275] GCC-4.4.4 gives error: ld: fatal: Symbol referencing errors. No output written to sparc_SunOS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53275 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2012-05-11 11:05:51 UTC --- *** Bug 53297 has been marked as a duplicate of this bug. ***
[Bug libstdc++/53297] Linker error on solaris 10 using gcc-4.4.4 64bit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53297 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-05-11 11:05:51 UTC --- This is a duplicate, again is the linker, not the compiler to fail. *** This bug has been marked as a duplicate of bug 53275 ***
[Bug libstdc++/53297] Linker error on solaris 10 using gcc-4.4.4 64bit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53297 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2012-05-11 11:14:25 UTC --- Incidentally, also note that the 4.4.x series is not maintained anymore, thus it doesn't make much sense to file reports against it and older release series. But this is just a digression.
[Bug bootstrap/53321] New: [4.8 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53321 Bug #: 53321 Summary: [4.8 Regression] LTO bootstrap failed with bootstrap-profiled Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86-64, revision 187375 failed to profiledbootstrap: ../../src-trunk/gcc/gcov.c:2348:1: internal compiler error: vector VEC(inline_edge_summary_t,base) index domain error, in inline_edge_summary at ipa-inline.h:200 } ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[6]: *** [gcov.o] Error 1 when configured with --prefix=/usr/local --enable-clocale=gnu --with-system-zlib --enable-sh ared --with-demangler-in-ld --with-build-config=bootstrap-lto --with-fpmath=sse --enable-languages=c,c++,fortran,java,lto,objc Revision 187371 is OK.
[Bug bootstrap/53321] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53321 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Target Milestone|--- |4.8.0 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-05-11 11:20:37 UTC --- It may be caused by revision 187375: http://gcc.gnu.org/ml/gcc-cvs/2012-05/msg00371.html
[Bug tree-optimization/53295] Vectorizer support for non-constant strided loads depends on gather support overwriting the data-ref with bogus data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53295 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-11 12:03:19 UTC --- Author: rguenth Date: Fri May 11 12:03:10 2012 New Revision: 187402 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187402 Log: 2012-05-11 Richard Guenther rguent...@suse.de PR tree-optimization/53295 * tree-data-ref.h (stride_of_unit_type_p): Handle non-constant strides. * tree-data-ref.c (dr_analyze_innermost): Allow non-constant strides when analyzing data-references in a loop context. * tree-vect-data-refs.c (vect_mark_for_runtime_alias_test): Reject non-constant strides for now. (vect_enhance_data_refs_alignment): Ignore data references that are strided loads. (vect_analyze_data_ref_access): Handle non-constant strides. (vect_check_strided_load): Verify the data-reference is a load. (vect_analyze_data_refs): Restructure to make strided load support not dependent on gather support. * tree-vect-stmts.c (vectorizable_load): Avoid useless work when doing strided or gather loads. * tree-vect-loop-manip.c (vect_vfa_segment_size): Use integer_zerop to compare stride with zero. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-data-ref.c trunk/gcc/tree-data-ref.h trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-loop-manip.c trunk/gcc/tree-vect-stmts.c
[Bug tree-optimization/53295] Vectorizer support for non-constant strided loads depends on gather support overwriting the data-ref with bogus data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53295 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-11 12:03:35 UTC --- Fixed.
[Bug c/53063] encode group options in the .opt files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53063 --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-05-11 12:24:00 UTC --- Author: manu Date: Fri May 11 12:23:50 2012 New Revision: 187403 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187403 Log: 2012-05-11 Manuel López-Ibáñez m...@gcc.gnu.org PR 53063 gcc/ * doc/options.texi (EnabledBy): Document * opts.c: Include opts.h and options.h before tm.h. (finish_options): Do not handle some sub-options here... (common_handle_option): ... instead call common_handle_option_auto here. * optc-gen.awk: Handle EnabledBy. * opth-gen.awk: Declare common_handle_option_auto. * common.opt (Wuninitialized): Use EnabledBy. Delete Init. (Wmaybe-uninitialized): Likewise. (Wunused-but-set-variable): Likewise. (Wunused-function): Likewise. (Wunused-label): Likewise. (Wunused-value): Likewise. (Wunused-variable): Likewise. * opt-read.awk: Create opt_numbers array. ada/ * gcc-interface/misc.c (gnat_parse_file): Move before ... (gnat_handle_option): ... this. Use handle_generated_option. c-family/ * c-opts.c (c_common_handle_option): Use handle_generated_option to enable sub-options. fortran/ * options.c: Include diagnostics.h instead of diagnostics-core.h. (set_Wall): Do not see warn_unused here. (gfc_handle_option): Set it here using handle_generated_option. Modified: trunk/gcc/ChangeLog trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/misc.c trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-opts.c trunk/gcc/common.opt trunk/gcc/doc/options.texi trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/options.c trunk/gcc/opt-read.awk trunk/gcc/optc-gen.awk trunk/gcc/opth-gen.awk trunk/gcc/opts.c
[Bug c++/53322] New: Wunused-local-typedefs is not enabled by Wall or Wunused
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53322 Bug #: 53322 Summary: Wunused-local-typedefs is not enabled by Wall or Wunused Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@gcc.gnu.org Since warn_unused_local_typedefs is never -1, then it is never enabled by Wunused. The fix is: Index: gcc/c-family/c.opt === --- gcc/c-family/c.opt (revision 187385) +++ gcc/c-family/c.opt (working copy) @@ -672,11 +672,11 @@ Warn about unrecognized pragmas Wunsuffixed-float-constants C ObjC Var(warn_unsuffixed_float_constants) Warning Warn about unsuffixed float constants Wunused-local-typedefs -C ObjC C++ ObjC++ Var(warn_unused_local_typedefs) Warning +C ObjC C++ ObjC++ Var(warn_unused_local_typedefs) Warning EnabledBy(Wunused) Warn when typedefs locally defined in a function are not used Wunused-macros C ObjC C++ ObjC++ Warning Warn about macros defined in the main file that are not used But I am sure this will trigger some warnings.
[Bug c++/53322] Wunused-local-typedefs is not enabled by Wall or Wunused
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53322 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||dodji at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-05-11 12:31:11 UTC --- CCing Dodji.
[Bug c++/53311] [C++0x] argument packs are not handled correctly in decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53311 chesstr at hotmail dot com changed: What|Removed |Added Attachment #27368|0 |1 is obsolete|| --- Comment #1 from chesstr at hotmail dot com 2012-05-11 12:36:12 UTC --- Created attachment 27371 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27371 simpler test case Tested and simplified.Uncomment the problematic lines to see the bugs.
[Bug ada/53323] New: Compiler bomb with indefinite array of controlled objects and storage pools
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53323 Bug #: 53323 Summary: Compiler bomb with indefinite array of controlled objects and storage pools Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: si...@pushface.org Created attachment 27372 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27372 Zipped reproducer source files This is a 4.7.0 regression (compiles OK with 4.6.0). With the attached code, $ gcc -c dynamic_bug.ads +===GNAT BUG DETECTED==+ | 4.7.0 (x86_64-apple-darwin11) Assert_Failure sinfo.adb:762 | | Error detected at dynamic_bug.ads:12:4 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). dynamic_bug.ads indefinite_dynamic.ads indefinite_reference.ads compilation abandoned I’ve tried removing various features of the code, I _think_ this is the minimum set to reproduce.
[Bug c++/53209] [4.7/4.8 Regression] tree check ICE: expected tree_vec, have error_mark in comp_template_args_with_info, at cp/pt.c:7038
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53209 --- Comment #11 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-05-11 13:27:15 UTC --- Author: aoliva Date: Fri May 11 13:27:03 2012 New Revision: 187404 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187404 Log: PR c++/53209 * pt.c (tsubst_decl): Bail out if argvec is error_mark_node. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/53209] [4.7/4.8 Regression] tree check ICE: expected tree_vec, have error_mark in comp_template_args_with_info, at cp/pt.c:7038
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53209 Alexandre Oliva aoliva at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||aoliva at gcc dot gnu.org AssignedTo|unassigned at gcc dot |aoliva at gcc dot gnu.org |gnu.org | --- Comment #10 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-05-11 13:25:38 UTC --- Mine
[Bug libstdc++/53297] Linker error on solaris 10 using gcc-4.4.4 64bit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53297 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2012-05-11 13:32:52 UTC --- You haven't even provided the command that produces the error. Noone can suggest a solution if you don't properly describe the problem. Other people use GCC on Solaris without problems, so it's probably user error.
[Bug c++/53209] [4.7/4.8 Regression] tree check ICE: expected tree_vec, have error_mark in comp_template_args_with_info, at cp/pt.c:7038
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53209 --- Comment #12 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-05-11 13:52:00 UTC --- Fixed
[Bug c++/53209] [4.7/4.8 Regression] tree check ICE: expected tree_vec, have error_mark in comp_template_args_with_info, at cp/pt.c:7038
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53209 Alexandre Oliva aoliva at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #13 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-05-11 13:52:58 UTC --- Fixed, really!
[Bug libfortran/52537] slow trim function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52537 --- Comment #5 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-05-11 13:56:16 UTC --- Author: tkoenig Date: Fri May 11 13:56:06 2012 New Revision: 187406 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187406 Log: 2012-05-11 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/52537 * frontend-passes.c (optimize_op): Change old-style comparison operators to new-style, simplify switch as a result. (empty_string): New function. (get_len_trim_call): New function. (optimize_comparison): If comparing to an empty string, use comparison of len_trim to zero. Use new-style comparison operators only. (optimize_trim): Use get_len_trim_call. 2012-05-11 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/52537 * gfortran.dg/string_compare_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/string_compare_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/frontend-passes.c trunk/gcc/testsuite/ChangeLog
[Bug c++/53209] [4.7/4.8 Regression] tree check ICE: expected tree_vec, have error_mark in comp_template_args_with_info, at cp/pt.c:7038
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53209 --- Comment #14 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-11 14:16:00 UTC --- What about the branch?
[Bug fortran/51055] deferred length character allocation: allocate(character(len=i)::s) rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51055 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-05-11 14:31:26 UTC --- See http://gcc.gnu.org/ml/fortran/2012-05/msg00054.html The problem is that the character length is used for reallocation before it is set. The following should work. The only question is whether it causes problems by enabling not only REPEAT but all other functions. Well, seemingly also other functions are affected. The following code has the same problem. The bug is also mentioned in: PR 49110 PR 45170 comment 14 (mentioned there and in some other comments, but not the bug)
[Bug libstdc++/53324] New: Crash when mixing _GLIBCXX_DEBUG and non-_GLIBCXX_DEBUG std::deque
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53324 Bug #: 53324 Summary: Crash when mixing _GLIBCXX_DEBUG and non-_GLIBCXX_DEBUG std::deque Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dominik.stras...@onespin-solutions.com Created attachment 27373 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27373 Example to illustrate the problem The attached example mixes std::deque compiled without _GLIBCXX_DEBUG. The non-_GLIBCXX_DEBUG comes in the original from a binary supplied lib. IMHO the mixture should either work or disallowed by making std::deque not assignable to a std::__debug::deque.
[Bug target/53325] New: arm-rtems switch default target to EABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53325 Bug #: 53325 Summary: arm-rtems switch default target to EABI Classification: Unclassified Product: gcc Version: 4.6.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@gcc.gnu.org I have to start by saying the RTEMS Project didn't manage the transition from ARM ELF to ARM EABI as well as we have managed similar changes in the past. The crux of the issue is that the preferred RTEMS tool target is ALWAYS CPU-rtemsversion. We have transitioned from a.out - coff - elf in the past and always followed the same target renaming pattern. 1) provide alternative for old target CPU-rtemsOLD where OLD is aout, coff, elf, etc. - CPU-rtems stays tied to old 2) provide new target at CPU-rtemsNEW where new is aout, coff, elf, eabi, etc 3) verify RTEMS builds and no obvious issues with NEW. test what can be tested internally. 4) limited (1-2 week) open period for feedback and outside testing 5) if no feedback/bugs, switch CPU-rtems to CPU-rtemsNEW leaving CPU-rtemsOLD around as a backup Using CPU-rtems* makes our build instructions and use very consistent across the 15 or so architectures, RTEMS runs on. This time, we missed something somewhere along the way and arm-rtems* got on the obsolete list and arm-rtemseabi* became the preferred target name. That breaks a very long standing and well documented pattern. Myself and Sebastian Huber wrote and he tested these patches. From http://www.rtems.org/pipermail/rtems-devel/2012-May/001001.html o the target arm-rtemseabi4.11 should be renamed to arm-rtems4.11 providing the up to date ARM EABI version 5 tool chain, o the target arm-rtemself4.11 provides the obsolete GNU EABI (also known as ARM ELF) variant. The patches for 4.6, 4.7, and the head are attached. We didn't remove the ARM ELF rtems target at this point. That is left for removal when general gcc clean up catches it. GCC test suite results for arm-rtems4.11: http://gcc.gnu.org/ml/gcc-testresults/2012-05/msg00322.html http://gcc.gnu.org/ml/gcc-testresults/2012-05/msg00323.html http://gcc.gnu.org/ml/gcc-testresults/2012-05/msg00324.html
[Bug target/53325] arm-rtems switch default target to EABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53325 --- Comment #1 from Joel Sherrill joel at gcc dot gnu.org 2012-05-11 14:54:08 UTC --- Created attachment 27374 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27374 GCC Patch for 4.6
[Bug target/53325] arm-rtems switch default target to EABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53325 --- Comment #2 from Joel Sherrill joel at gcc dot gnu.org 2012-05-11 14:54:35 UTC --- Created attachment 27375 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27375 GCC Patch for 4.7
[Bug target/53325] arm-rtems switch default target to EABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53325 --- Comment #3 from Joel Sherrill joel at gcc dot gnu.org 2012-05-11 14:55:02 UTC --- Created attachment 27376 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27376 GCC Patch for 4.8
[Bug bootstrap/53300] [4.8 Regression] AIX bootstrap related to varpool patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53300 --- Comment #13 from David Edelsohn dje at gcc dot gnu.org 2012-05-11 15:07:46 UTC --- Created attachment 27377 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27377 Pre-processed source for libcpp/line-map.c
[Bug bootstrap/53300] [4.8 Regression] AIX bootstrap related to varpool patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53300 --- Comment #15 from David Edelsohn dje at gcc dot gnu.org 2012-05-11 15:09:09 UTC --- Created attachment 27379 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27379 Wrong assembly output for line-map.c
[Bug bootstrap/53300] [4.8 Regression] AIX bootstrap related to varpool patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53300 --- Comment #14 from David Edelsohn dje at gcc dot gnu.org 2012-05-11 15:08:29 UTC --- Created attachment 27378 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27378 Correct assembly output for line-map.c
[Bug bootstrap/53300] [4.8 Regression] AIX bootstrap related to varpool patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53300
--- Comment #16 from David Edelsohn dje at gcc dot gnu.org 2012-05-11
15:11:59 UTC ---
The mis-compiled file is libcpp/line-map.c. I have attached the pre-processed
output for line-map.c on AIX. I also have attached assembly files showing the
correct and incorrect output. The difference is:
--- line-map.s.good 2012-05-11 11:01:33.0 -0400
+++ line-map.s.bad 2012-05-11 11:00:43.0 -0400
@@ -4536,26 +4536,6 @@
.byte 10
.byte Macro line maps
.byte 10, 0
- .space 2
-LC..0:
- .byte LC_ENTER
- .byte 0
- .space 3
-LC..1:
- .byte LC_LEAVE
- .byte 0
- .space 3
-LC..2:
- .byte LC_RENAME
- .byte 0
- .space 2
-LC..3:
- .byte LC_RENAME_VERBATIM
- .byte 0
- .space 1
-LC..4:
- .byte LC_ENTER_MACRO
- .byte 0
.csect _linemap.rw_[RW],4
.align 2
.set LANCHOR..1,$ + 0
which corresponds to
enum lc_reason
{
LC_ENTER = 0,
LC_LEAVE,
LC_RENAME,
LC_RENAME_VERBATIM,
LC_ENTER_MACRO
};
[Bug bootstrap/53300] [4.8 Regression] AIX bootstrap related to varpool patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53300
--- Comment #17 from David Edelsohn dje at gcc dot gnu.org 2012-05-11
15:44:44 UTC ---
A minimal testcase:
enum lc_reason
{
LC_ENTER = 0,
LC_LEAVE,
LC_RENAME,
LC_RENAME_VERBATIM,
LC_ENTER_MACRO
};
const char *
foo (enum lc_reason reason)
{
const char *lc_reasons_v[LC_ENTER_MACRO + 1]
= { LC_ENTER, LC_LEAVE, LC_RENAME, LC_RENAME_VERBATIM,
LC_ENTER_MACRO };
return lc_reasons_v[reason];
}
Without your TREE_ASM_WRITTEN kludge, the string values of the array are not
emitted in the assembly. The array referencing the strings is emitted, but the
values themselves are not.
[Bug bootstrap/53321] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53321 --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org 2012-05-11 15:48:32 UTC --- I fixed identically looking ICE seen on Mozilla build yesterday. Hopefully the boostrap is fixed now, too. Honza
[Bug other/53316] Introduce -Odebug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53316 --- Comment #9 from David Stone david at doublewise dot net 2012-05-11 15:48:53 UTC --- I suppose this is a much better way to phrase the suggestion as a starting point. First get -Odebug and then see where we go from there.
[Bug bootstrap/53321] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53321 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-05-11 15:52:38 UTC --- (In reply to comment #2) I fixed identically looking ICE seen on Mozilla build yesterday. Hopefully the boostrap is fixed now, too. It still fails with the same error as of revision 187408. Does revision 187408 have your fix for Mozilla?
[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::functionvoid (std::__regex::_PatternCursor const, std::__regex::_Results)::function(std::functionvoid (std::__regex::_Patte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887 --- Comment #6 from Daniel Richard G. skunk at iskunk dot org 2012-05-11 17:05:57 UTC --- With the new build, I now see one missing symbol instead of two. (Not sure why the earlier hacked build went through): gmake[3]: Entering directory `/tmp/gcc-4.7.0/_build/gcc' /tmp/gcc-4.7.0/_build/./prev-gcc/g++ -B/tmp/gcc-4.7.0/_build/./prev-gcc/ -B/opt/tg/powerpc-ibm-aix5.3.0.0/bin/ -nostdinc++ -B/tmp/gcc-4.7.0/_build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs -B/tmp/gcc-4.7.0/_build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/libsupc++/.libs -I/tmp/gcc-4.7.0/_build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/include/powerpc-ibm-aix5.3.0.0 -I/tmp/gcc-4.7.0/_build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/include -I/tmp/gcc-4.7.0/libstdc++-v3/libsupc++ -L/tmp/gcc-4.7.0/_build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs -L/tmp/gcc-4.7.0/_build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/libsupc++/.libs -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -Wl,-bbigtoc -Wl,-bmaxdata:0x4000 -o cc1 c-lang.o c-family/stub-objc.o attribs.o c-errors.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-objc-common.o c-parser.o tree-mudflap.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o default-c.o rs6000-c.o \ cc1-checksum.o main.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/tg/freeport/arch/aix64/lib -L/tg/freeport/arch/aix64/lib -L/tg/freeport/arch/aix64/lib -lmpc -lmpfr -lgmp -L../zlib -lz ld: 0711-317 ERROR: Undefined symbol: .std::functionbool (std::__regex::_PatternCursor const)::function(std::functionbool (std::__regex::_PatternCursor const) const) ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: error: ld returned 8 exit status gmake[3]: *** [cc1] Error 1 gmake[3]: Leaving directory `/tmp/gcc-4.7.0/_build/gcc' gmake[2]: *** [all-stage2-gcc] Error 2 gmake[2]: Leaving directory `/tmp/gcc-4.7.0/_build' gmake[1]: *** [stage2-bubble] Error 2 gmake[1]: Leaving directory `/tmp/gcc-4.7.0/_build' gmake: *** [bootstrap] Error 2 Perhaps one more instantiation is needed?
[Bug libstdc++/53324] Crash when mixing _GLIBCXX_DEBUG and non-_GLIBCXX_DEBUG std::deque
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53324 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-05-11 17:09:26 UTC --- Even if it wasn't assignable your program would crash, C++ name mangling doesn't include the return type so the symbol _ZN2XX5getmeEv defined in x.o reolves the undefined reference in y.o even though they disagree on the return type. I don't think it's possible to fix that, you just have to follow the documentation and ensure you recompile all necessary code with -D_GLIBCXX_DEBUG
[Bug fortran/53326] New: -finit-integer, -finit-real and INTENT(OUT)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53326 Bug #: 53326 Summary: -finit-integer, -finit-real and INTENT(OUT) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: arnau...@users.sourceforge.net
[Bug libstdc++/53324] Crash when mixing _GLIBCXX_DEBUG and non-_GLIBCXX_DEBUG std::deque
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53324 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-05-11 17:20:13 UTC --- N.B. this is basically the same scenario as if you compiled x.C, then changed XX::getme to return a std::list instead of std::deque, then compiled y.C -- it would link, but crash at runtime. This is a general feature of C++ name-mangling and separrate compilation, not specific to our debug mode. If you create a file called deque in the same directory containing: #include list #define deque list then change the makefile to build y.o with this rule, not using debug mode: y.o: y.C g++ -c -I. y.C then it will link (even though you can't assign std::list to std::deque, i.e. your suggestion won't help) but it will segfault when run.
[Bug fortran/53326] -finit-integer, -finit-real and INTENT(OUT)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53326 --- Comment #1 from Arnaud Desitter arnaud02 at users dot sourceforge.net 2012-05-11 17:31:12 UTC --- Consider: cat UIN15-int.f !! check whether uninitialised variables are detected !! for INTENT(OUT) arrays program uin integer x(10) x = 2 call sub2(x,size(x)) ! x undefined on return write(*,*) x(1) end subroutine sub2(x,n) integer, intent(in) :: n integer, intent(out) :: x(n) end gfortran470 -finit-integer=10 UIN15-int.f abg-ecldev01:/tmp/arnaud./a.out 2 cat UIN15-double.f !! check whether uninitialised variables are detected !! for INTENT(OUT) arrays program uin double precision x(10) x = 2 call sub2(x,size(x)) ! x undefined on return write(*,*) x(1) end subroutine sub2(x,n) integer, intent(in) :: n double precision, intent(out) :: x(n) end gfortran470 -finit-real=snan UIN15-double.f ./a.out 2. As seen above, -finit-real and -finit-integer have no effect on INTENT(OUT) variables. This would be a nice and useful improvement. Note that the NAG compiler (-nan) and the Sun compiler (-xcheck=init_local -stackvar) implement this feature. (tests UNI15 of http://ftp.aset.psu.edu/pub/ger/fortran/test/results.txt are related)
[Bug bootstrap/49797] CLooG use of LANGUAGE_C conflicts with MIPS compilers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49797 --- Comment #5 from Matt Hargett matt at use dot net 2012-05-11 17:58:27 UTC --- It's not an IRIX-specific thing AFAICS, but rather that newer versions of cloog/ppl renamed the macro to avoid conflicts on IRIX. 4.6 still checks for the old macro name, which is no longer set. I have applied the patch locally to work around the issue and can verify it solved the problem for me. Let me know if there's anything else you'd like me to test/validate to get it back ported.
[Bug target/53315] simple xtest program generates ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315 --- Comment #8 from Andi Kleen andi-gcc at firstfloor dot org 2012-05-11 18:02:43 UTC --- I tested HJs fix on the test case and also on a more complex program and it all works as expected. Please commit.
[Bug bootstrap/53321] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53321 --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org 2012-05-11 18:25:06 UTC --- was comitted as revision 187382. I am trying profiledbootstrap now. Honza
[Bug c/53327] New: Invalid ASM being generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53327 Bug #: 53327 Summary: Invalid ASM being generated Classification: Unclassified Product: gcc Version: 4.4.6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: bugzilla-...@thewrittenword.com Created attachment 27380 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27380 Problematic C source file We have a 64-bit build of GCC 4.4.6 on hppa64-hp-hpux11.31 that, when compiling a particular .c file, is returning an Invalid operands error: % /opt/TWWfsw/gcc64-44/bin/gcc -v Reading specs from /opt/TWWfsw/gcc64-44/lib/gcc/hppa64-hp-hpux11.31/4.4/specs Target: hppa64-hp-hpux11.31 Configured with: /opt/build/gcc-4.4.6/configure --with-included-gettext --enable-shared --with-gnu-as --with-as=/opt/TWWfsw/gcc64-44/hppa64-hp-hpux11.31/bin/as --with-gmp-include=/opt/TWWfsw/libgmp43/include --with-gmp-lib=/opt/TWWfsw/libgmp43/lib/pa20_64 --with-mpfr-include=/opt/TWWfsw/libmpfr30/include --with-mpfr-lib=/opt/TWWfsw/libmpfr30/lib/pa20_64 --with-gmp-ldflags=-Wl,+s,+b,/opt/TWWfsw/libgmp43/lib/pa20_64 --with-mpfr-ldflags=-Wl,+s,+b,/opt/TWWfsw/libmpfr30/lib/pa20_64 --datadir=/opt/TWWfsw/gcc64-44/share --with-x --enable-java-awt=xlib --build=hppa64-hp-hpux11.31 --host=hppa64-hp-hpux11.31 --with-local-prefix=/opt/TWWfsw/gcc64-44 --with-gxx-include-dir=/opt/TWWfsw/gcc64-44/include/c++ --prefix=/opt/TWWfsw/gcc64-44 Thread model: posix % /opt/TWWfsw/gcc64-44/bin/gcc -O2 -c a.c /var/tmp//cc8ArhN4.s: Assembler messages: /var/tmp//cc8ArhN4.s:30: Error: Invalid operands
[Bug c/53327] Invalid ASM being generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53327 --- Comment #1 from The Written Word bugzilla-gcc at thewrittenword dot com 2012-05-11 18:30:02 UTC --- Created attachment 27381 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27381 a.c from -save-temps
[Bug c/53327] Invalid ASM being generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53327 --- Comment #2 from The Written Word bugzilla-gcc at thewrittenword dot com 2012-05-11 18:31:55 UTC --- Created attachment 27382 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27382 Assembler file from -save-temps
[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::functionvoid (std::__regex::_PatternCursor const, std::__regex::_Results)::function(std::functionvoid (std::__regex::_Patte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2012-05-11 18:34:59 UTC --- Looks as though it also needs template class functionbool (__regex::_PatternCursor const);
[Bug c++/8564] [3.2 regression] ICE in find_function_data, at function.c:329
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8564 michael777 bestvideos2011 at live dot co.uk changed: What|Removed |Added CC||bestvideos2011 at live dot ||co.uk --- Comment #12 from michael777 bestvideos2011 at live dot co.uk 2012-05-11 18:38:28 UTC --- hi, good work at fixing all these bugs, The bug can be demonstrated with the following code snippet: good coding with what you do here. this is a good blog if you want to audition for the x factor http://x-factor-2013.blogspot.co.uk
[Bug rtl-optimization/11198] [3.3 regression] -O2 -frename-registers generates wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11198 michael777 bestvideos2011 at live dot co.uk changed: What|Removed |Added CC||bestvideos2011 at live dot ||co.uk --- Comment #22 from michael777 bestvideos2011 at live dot co.uk 2012-05-11 18:41:50 UTC --- see http://x-factor-2013.blogspot.co.uk/2012/04/son-i-am-disappoint-is-x-factors-simon.html
[Bug libfortran/52537] slow trim function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52537 --- Comment #6 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-05-11 18:50:27 UTC --- Author: tkoenig Date: Fri May 11 18:50:14 2012 New Revision: 187413 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187413 Log: 2012-05-11 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/52537 * gfortran.dg/string_compare_4.f90: Change option to -fdump-tree-original. Add test case for kind=4. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/string_compare_4.f90
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #129 from Jan Hubicka hubicka at gcc dot gnu.org 2012-05-11
19:05:19 UTC ---
OK, the slow part of uniuqify_nodes is:
/* Remove us from our main variant list if we are not the
variant leader. */
if (TYPE_MAIN_VARIANT (t) != t)
{
tem = TYPE_MAIN_VARIANT (t);
while (tem TYPE_NEXT_VARIANT (tem) != t)
tem = TYPE_NEXT_VARIANT (tem);
if (tem)
TYPE_NEXT_VARIANT (tem) = TYPE_NEXT_VARIANT (t);
TYPE_NEXT_VARIANT (t) = NULL_TREE;
}
[Bug libfortran/52537] slow trim function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52537 --- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-05-11 19:16:08 UTC --- Does this fix the problem?
[Bug bootstrap/37122] fixed-value.c and tree-ssa-loop-ivopts.c won't compile with Sun Studio 11 on Solaris 9 due to incompatible operand types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37122
--- Comment #6 from Daniel Richard G. skunk at iskunk dot org 2012-05-11
19:16:50 UTC ---
Created attachment 27383
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27383
updated patch for 4.7.0
I got bitten by this recently. Bootstrapping GCC 4.7.0 on Solaris 8:
[...]
cc -xarch=v9 -xildoff -c -g -DIN_GCC-DHAVE_CONFIG_H -I. -I.
-I/home/src/gcc-4.7.0/gcc -I/home/src/gcc-4.7.0/gcc/.
-I/home/src/gcc-4.7.0/gcc/../include
-I/home/src/gcc-4.7.0/gcc/../libcpp/include -I/tg/freeport/arch/sunos64/include
-I/tg/freeport/arch/sunos64/include -I/tg/freeport/arch/sunos64/include
-I/home/src/gcc-4.7.0/gcc/../libdecnumber
-I/home/src/gcc-4.7.0/gcc/../libdecnumber/dpd -I../libdecnumber
/home/src/gcc-4.7.0/gcc/tree-ssa-loop-ivopts.c -o tree-ssa-loop-ivopts.o
/home/src/gcc-4.7.0/gcc/tree-ssa-loop-ivopts.c, line 6047: operands have
incompatible types:
struct {int cost, unsigned int complexity} : const struct {int cost,
unsigned int complexity}
/home/src/gcc-4.7.0/gcc/tree-ssa-loop-ivopts.c, line 6048: operands have
incompatible types:
struct {int cost, unsigned int complexity} : const struct {int cost,
unsigned int complexity}
cc: acomp failed for /home/src/gcc-4.7.0/gcc/tree-ssa-loop-ivopts.c
gmake[3]: *** [tree-ssa-loop-ivopts.o] Error 2
gmake[3]: Leaving directory `/tmp/gcc-build/gcc'
gmake[2]: *** [all-stage1-gcc] Error 2
gmake[2]: Leaving directory `/tmp/gcc-build'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/tmp/gcc-build'
gmake: *** [bootstrap-lean] Error 2
I'd love to patch the compiler, but Oracle won't let me do that unless I give
them a fat wad of money. David's patch to the source is no longer applicable to
4.7.0, so I'm attaching an update.
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 --- Comment #11 from François Dumont fdumont at gcc dot gnu.org 2012-05-11 19:21:38 UTC --- Author: fdumont Date: Fri May 11 19:21:31 2012 New Revision: 187414 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187414 Log: 2012-05-11 François Dumont fdum...@gcc.gnu.org PR libstdc++/53263 * include/debug/safe_iterator.h (__gnu_debug::__base): Move... * include/debug/functions.h: ... Here. Add debug function overloads to perform checks on normal iterators when possible. * include/debug/macros.h (__glibcxx_check_heap) (__glibcxx_check_heap_pred): Use __gnu_debug::__base on iterator range. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/debug/functions.h trunk/libstdc++-v3/include/debug/macros.h trunk/libstdc++-v3/include/debug/safe_iterator.h
[Bug debug/51564] [4.7 Regression] ICE in force_type_die, at dwarf2out.c:19288
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51564 --- Comment #7 from Matt Hargett matt at use dot net 2012-05-11 20:19:01 UTC --- Applying the patch does allow DWARF serialization to get further, but now it dies here: internal compiler error: in add_AT_specification, at dwarf2out.c:7536 It looks like this problem (hiding beneath the original) is related to PR47839, whose fix was fortran front-end specific. Should I just file a new bug and reference these other bugs?
[Bug fortran/53029] missed optimization in internal read (without implied-do-loop)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53029 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution||FIXED --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-05-11 20:38:53 UTC --- Fixed together with PR 50673. Closing.
[Bug fortran/53029] missed optimization in internal read (without implied-do-loop)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53029 Manfred Schwarb manfred99 at gmx dot ch changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | --- Comment #2 from Manfred Schwarb manfred99 at gmx dot ch 2012-05-11 21:25:14 UTC --- Is not. Please see the opening date of this bug compared to BUG 50673. It _is_ actually a reaction on seeing that BUG 50673 has not fixed this particular issue ... I just verified it again with # gfc-test -v Using built-in specs. COLLECT_GCC=/usr/local/gfortran-test/bin/gfortran COLLECT_LTO_WRAPPER=/usr/local/gfortran-test/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gfortran-source/gcc-4.8-20120506/configure --enable-languages=c,c++,fortran --disable-libmudflap --enable-libgomp --disable-nls --enable-checking=release --disable-bootstrap --prefix=/usr/local/gfortran-test --enable-lto --enable-gold --with-plugin-ld=/usr/bin/gold Thread model: posix gcc version 4.8.0 20120506 (experimental) (GCC)
[Bug fortran/53328] New: [OOP] Ambiguous check for type-bound GENERIC shall ignore PASSed arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53328 Bug #: 53328 Summary: [OOP] Ambiguous check for type-bound GENERIC shall ignore PASSed arguments Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: accepts-invalid, diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: ja...@gcc.gnu.org Based on a report by Rafik Zurob. Compile the following module - and then the following: use m type(t) :: x call x%gen(5) end Does the call invoke sub1 or sub2? Obviously, gfortran should ignore the PASSed argument for the generic resolution of type-bound procedures, when checking for ambiguity. The following code is invalid but accepted: module m type t contains procedure, pass(this) :: sub1 procedure, pass(this) :: sub2 generic :: gen = sub1, sub2 end type t contains subroutine sub1(x, this) integer :: i class(t) :: this end subroutine sub1 subroutine sub2 (this, y) integer :: i class(t) :: this end subroutine sub2 end module m
[Bug target/53315] simple xtest program generates ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315
--- Comment #9 from Andi Kleen andi-gcc at firstfloor dot org 2012-05-11
21:35:47 UTC ---
Sorry I was wrong earlier. Retested now fully with a full test case and HJs
patch and i always get aborts
The xbegin gets miscompiled now, the in transaction branch disappears.
400460: 48 83 ec 08 sub$0x8,%rsp
400464: b8 ff ff ff ff mov$0x,%eax
400469: c7 f8 00 00 00 00 xbeginq 40046f main+0xf
40046f: bf d8 06 40 00 mov$0x4006d8,%edi
400474: 31 f6 xor%esi,%esi
400476: 31 c0 xor%eax,%eax
400478: e8 b3 ff ff ff callq 400430 printf@plt
40047d: 31 ff xor%edi,%edi
40047f: e8 bc ff ff ff callq 400440 exit@plt
/* PR53315 and PR53291 */
/* { dg-do run } */
/* { dg-options -O2 -mrtm } */
#include immintrin.h
#include cpuid.h
#include stdlib.h
#include stdio.h
static int cpu_has_rtm(void)
{
if (__get_cpuid_max(0, NULL) = 7) {
unsigned a, b, c, d;
__cpuid_count(7, 0, a, b, c, d);
return !!(b bit_RTM);
}
return 0;
}
int main(void)
{
int flag = -1;
unsigned status;
if (!cpu_has_rtm) {
printf(no tsx support. untested\n);
exit(0);
}
if ((status = _xbegin()) == _XBEGIN_STARTED) {
flag = _xtest();
_xend();
} else {
/* Note this is legal according to the TSX spec */
printf(unexpected abort %x. untested\n, status);
exit(0);
}
if (flag != 1)
abort();
if (_xtest() != 0)
abort();
return 0;
}
[Bug fortran/53328] [OOP] Ambiguous check for type-bound GENERIC shall ignore PASSed arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53328 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-05-11 21:42:00 UTC --- See Fortran 2003, 16.2.3 for details. (For type-bound operators, the PASS argument itself also plays a role in distinguishing the calls - thus, it cannot completely be ignored. For type-bound generic names, I think the PASS argument should be always be indistinguishable.)
[Bug lto/53312] crash in materialize_cgraph (invalid free)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53312 --- Comment #2 from philippe.waroquiers at skynet dot be 2012-05-11 22:16:25 UTC --- (In reply to comment #1) This looks like PR53214 - unable to verify without a testcase though. Thus, please try a recent GCC 4.7 snapshot instead. You can also simply grep for optimization attribute usage in your sources. It looks effectively the same (or least similar). In my case, the offending line was: # pragma GCC optimize(-fomit-frame-pointer) When removing this line, the crash disappeared. I suppose this is the same bug as PR53214 (even if this bug was with attribute rather than pragma). Thanks for the help
[Bug fortran/53310] [4.5/4.6/4.7/4.8 Regression] EOSHIFT leaks memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53310 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-05-11 22:32:36 UTC --- Author: burnus Date: Fri May 11 22:32:27 2012 New Revision: 187417 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187417 Log: 2012-05-12 Tobias Burnus bur...@net-b.de PR fortran/53310 * intrinsics/eoshift2.c (eoshift2): Do not leak memory by allocating it in the loop. Modified: branches/gcc-4_7-branch/libgfortran/ChangeLog branches/gcc-4_7-branch/libgfortran/intrinsics/eoshift2.c
[Bug lto/46820] toplevel ASM statements should be allowed to reffer local symbols in LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46820 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Summary|Undefined reference errors |toplevel ASM statements |with LTO|should be allowed to reffer ||local symbols in LTO Severity|normal |enhancement
[Bug fortran/53310] [4.5/4.6/4.7/4.8 Regression] EOSHIFT leaks memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53310 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2012-05-11 22:33:30 UTC --- Author: burnus Date: Fri May 11 22:33:21 2012 New Revision: 187418 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187418 Log: 2012-05-12 Tobias Burnus bur...@net-b.de PR fortran/53310 * intrinsics/eoshift2.c (eoshift2): Do not leak memory by allocating it in the loop. Modified: branches/gcc-4_6-branch/libgfortran/ChangeLog branches/gcc-4_6-branch/libgfortran/intrinsics/eoshift2.c
[Bug lto/46820] toplevel ASM statements should be allowed to reffer local symbols in LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46820
--- Comment #13 from Jan Hubicka hubicka at gcc dot gnu.org 2012-05-11
22:38:23 UTC ---
Updated description to match reality. Here it should really be user defined
alias with weak visibility.
void __f () { /* Do something. */; }
void f () __attribute__ ((weak, alias (__f)))
works as expected.
But still toplevel asm statements should be allowed to have list of used and
defined symbols. I think there was patch circulating for this. But this is an
enhancement request. The asm statement as written has no chance to work unless
GCC gets into busyness of parsing assembly.
Honza
[Bug target/53315] simple xtest program generates ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315
--- Comment #10 from phpbbaid at gmail dot com 2012-05-11 23:02:22 UTC ---
please unsubscribe
-Original Message-
From: andi-gcc at firstfloor dot org
Sent: Friday, May 11, 2012 11:35 PM
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/53315] simple xtest program generates ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315
--- Comment #9 from Andi Kleen andi-gcc at firstfloor dot org 2012-05-11
21:35:47 UTC ---
Sorry I was wrong earlier. Retested now fully with a full test case and HJs
patch and i always get aborts
The xbegin gets miscompiled now, the in transaction branch disappears.
400460: 48 83 ec 08 sub$0x8,%rsp
400464: b8 ff ff ff ff mov$0x,%eax
400469: c7 f8 00 00 00 00 xbeginq 40046f main+0xf
40046f: bf d8 06 40 00 mov$0x4006d8,%edi
400474: 31 f6 xor%esi,%esi
400476: 31 c0 xor%eax,%eax
400478: e8 b3 ff ff ff callq 400430 printf@plt
40047d: 31 ff xor%edi,%edi
40047f: e8 bc ff ff ff callq 400440 exit@plt
/* PR53315 and PR53291 */
/* { dg-do run } */
/* { dg-options -O2 -mrtm } */
#include immintrin.h
#include cpuid.h
#include stdlib.h
#include stdio.h
static int cpu_has_rtm(void)
{
if (__get_cpuid_max(0, NULL) = 7) {
unsigned a, b, c, d;
__cpuid_count(7, 0, a, b, c, d);
return !!(b bit_RTM);
}
return 0;
}
int main(void)
{
int flag = -1;
unsigned status;
if (!cpu_has_rtm) {
printf(no tsx support. untested\n);
exit(0);
}
if ((status = _xbegin()) == _XBEGIN_STARTED) {
flag = _xtest();
_xend();
} else {
/* Note this is legal according to the TSX spec */
printf(unexpected abort %x. untested\n, status);
exit(0);
}
if (flag != 1)
abort();
if (_xtest() != 0)
abort();
return 0;
}
[Bug tree-optimization/52054] Value-numbering does not enter translated expressions into the hash table
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52054 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #4 from Steven Bosscher steven at gcc dot gnu.org 2012-05-11 23:08:15 UTC --- (In reply to comment #3) PR53125 has a testcase where we spend time in redundant store removal in eliminate() which does vn_reference_lookup with VN_WALK (which it should not need). The patch of comment #2 has no influence on the compile time for bug 53125. Is that expected?
[Bug fortran/53310] [4.5/4.6/4.7/4.8 Regression] EOSHIFT leaks memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53310 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2012-05-11 23:09:35 UTC --- Author: burnus Date: Fri May 11 23:09:30 2012 New Revision: 187419 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187419 Log: 2012-05-12 Tobias Burnus bur...@net-b.de PR fortran/53310 * intrinsics/eoshift2.c (eoshift2): Do not leak memory by allocating it in the loop. Modified: branches/gcc-4_5-branch/libgfortran/ChangeLog branches/gcc-4_5-branch/libgfortran/intrinsics/eoshift2.c
[Bug fortran/53310] [4.5/4.6/4.7/4.8 Regression] EOSHIFT leaks memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53310 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.6.4 |4.5.4 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2012-05-11 23:11:16 UTC --- FIXED on the 4.8 trunk and backported to 4.5-4.7.
[Bug c++/53289] unnecessary repetition of caret diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53289 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-05-12 00:14:41 UTC --- Thus, this fixed, right?
[Bug target/48009] Bootstrap failure: c++locale.cc: invalid conversion from 'const char*' to 'char*'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48009 Daniel Richard G. skunk at iskunk dot org changed: What|Removed |Added Version|4.5.2 |4.7.0 --- Comment #2 from Daniel Richard G. skunk at iskunk dot org 2012-05-12 04:30:17 UTC --- Still an issue in 4.7.0. user@host:/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/c++98 gmake libc++98convenience.la /opt/freeware/bin/bash ../../libtool --tag CXX --tag disable-shared --mode=compile /tmp/gcc-build/./gcc/xgcc -shared-libgcc -B/tmp/gcc-build/./gcc -nostdinc++ -L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src -L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs -B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/ -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/sys-include -I/home/src/gcc-4.7.0/libstdc++-v3/../libgcc -I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0 -I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include -I/home/src/gcc-4.7.0/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=c++locale.lo -g -c -o c++locale.lo c++locale.cc libtool: compile: /tmp/gcc-build/./gcc/xgcc -shared-libgcc -B/tmp/gcc-build/./gcc -nostdinc++ -L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src -L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs -B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/ -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/sys-include -I/home/src/gcc-4.7.0/libstdc++-v3/../libgcc -I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0 -I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include -I/home/src/gcc-4.7.0/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=c++locale.lo -g -c c++locale.cc -DPIC -o c++locale.o c++locale.cc: In function 'void std::__convert_to_v(const char*, _Tp, std::ios_base::iostate, int* const) [with _Tp = float; std::ios_base::iostate = std::_Ios_Iostate; std::__c_locale = int*]': c++locale.cc:67:34: error: invalid conversion from 'const char*' to 'char*' [-fpermissive] In file included from /tmp/gcc-build/./gcc/include-fixed/math.h:388:0, from /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cmath:46, from c++locale.cc:33: /tmp/gcc-build/./gcc/include-fixed/stdlib.h:479:18: error: initializing argument 1 of 'float strtof(char*, char**)' [-fpermissive] gmake: *** [c++locale.lo] Error 1
