[Bug target/48454] gfortran.dg/char_result_13.f90 fails with -O3 -funroll-loops -mvectorize-with-neon-quad
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48454 --- Comment #2 from Ira Rosen irar at il dot ibm.com 2011-04-06 06:15:10 UTC --- Created attachment 23894 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23894 char_result_13.s
[Bug c++/48453] [C++0x] Invalid reference initialization via explicit conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48453 --- Comment #2 from Daniel Krügler daniel.kruegler at googlemail dot com 2011-04-06 06:34:20 UTC --- (In reply to comment #1) I agree, I just recognize that 13.3.1.6 [over.match.ref] p. 1 b. 1 is written to support this: The conversion functions of S and its base classes are considered, except that for copy-initialization, only the non-explicit conversion functions are considered. Those that are not hidden within S and yield type “lvalue reference to cv2 T2” (when 8.5.3 requires an lvalue result) or “cv2 T2” or “rvalue reference to cv2 T2” (when 8.5.3 requires an rvalue result), where “cv1 T” is reference-compatible (8.5.3) with “cv2 T2”, are candidate functions. IMO the core language should strike the reference to implicit conversions in 8.5.3.
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 Dongsheng Song dongsheng.song at gmail dot com changed: What|Removed |Added CC||dongsheng.song at gmail dot ||com --- Comment #55 from Dongsheng Song dongsheng.song at gmail dot com 2011-04-06 06:35:11 UTC --- (In reply to comment #54) (In reply to comment #53) If I don't use LTO Optimization, Vadim Zeitlin's patch works well. But if I use LTO Optimization, the compiling speed becomes vey slow, and the linker stage fails. I will get the information: lto1.exe: out of memory allocating 1900552 bytes lto-wrapper: g++ returned 1 exit status ld.exe: lto-wrapper failed collect2: ld returned 1 exit status mingw32-make: *** [wxmsw28u_gcc.dll] Error 1 BTW, I use gcc 4.6. me too. If I use 32bit compiler on windows/Linux, target 32bit windows, single huge monolithic library build with or without LTO will out of memory, multiple libraries build failed with LTO, OK for without LTO.
[Bug regression/48477] New: [4.7 Regression]: gfortran.dg/coarray_13.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48477 Summary: [4.7 Regression]: gfortran.dg/coarray_13.f90 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: h...@gcc.gnu.org CC: bur...@gcc.gnu.org Host: x86_64-unknown-linux-gnu Target: cris-axis-elf Created attachment 23895 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23895 Reduced gfortran.dg/coarray_13.f90 exposing the failure This test previously passed, now it fails. Revision r171949 caused this regression. Since then it fails as follows: Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gfortran.dg/dg.exp ... ... FAIL: gfortran.dg/coarray_13.f90 -O2 execution test FAIL: gfortran.dg/coarray_13.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/coarray_13.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/coarray_13.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/coarray_13.f90 -O3 -g execution test The messages in gfortran.log are similar: PASS: gfortran.dg/coarray_13.f90 -O2 (test for excess errors) core: 4 byte write to unmapped address 0x10190 at 0x146 program stopped with signal 11. Author/committer of suspect revision CC:ed. Looking into this, I see badness in the form of a modified test-case. Multiple tests for new (or greatly improved) functionality were apparently added to an existing test-case. While that worked for the tested platform, it didn't work for cris-elf and I'd guess also some other unfortunate platform. So, because an existing test was modified rather than new tests added, it comes out as a regression. That's why existing test-cases should never be upgraded like that; they should be fixed only if they were actually wrong or just enough to maintain the intention of the test when gcc gets too smart. I'm adding a reduced test-case which fails at r172016; all but a single test and call to abort. Hopefully this is enough to spark some ideas as to the cause. I can assist with some target-specific testing; execution tracing etc. but note that the general instructions for building and running on a simulator toolchain apply to cris-elf. (For the record, at revision r171949 the tree was in a flux, with 52 regressions in total for cris-elf, but that's been resolved to this single regression at r172016. I tested r171943 (last regression-free revision before r171949) patched with the single commit of r171949; that combination also fails.)
[Bug fortran/48404] SELECTED_REAL_KIND is returning KIND=16 when not available
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48404 --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2011-04-06 06:53:53 UTC --- (In reply to comment #8) My gcc4.5 and gcc4.4 apparently did not have libquadmath-support Yes, libquadmath is a new GCC 4.6 feature, cf. http://gcc.gnu.org/gcc-4.6/changes.html and http://gcc.gnu.org/onlinedocs/libquadmath/ -- While primarily added and used for gfortran, it also can be used with C/C++. On GLIBC systems, libquadmath has printf hooks, allowing one to use the __float128 directly in (s,sn,f,)printf. (On other systems, quadmath_snprintf has to be used.) Not much can be done if the packages get it wrong. Thanks for the help. I'll close the bug report. Thanks. (In terms of compatibility of older programs with newer libgfortans, it is unfortunate. However, as the capabilities of the compiler are checked during the compilation of the library, it is difficult to avoid. Fortunately, it only affects SELECTED_REAL_KIND where the arguments are not known at compile time. -- The Fortran 2008 workaround is to use ISO_Fortran_env's REAL_KINDS, which gfortran supports since GCC 4.6 - but F2008 only and GCC since 4.6 does not make it really portable.)
[Bug middle-end/48377] [4.6 regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-06 07:01:59 UTC --- Yeah, and with -O3 you are requesting vectorization. When that loop gets vectorized, gcc counts on that you don't lie about alignment. You should be using either typedef uint32_t unaligned_uint32 __attribute__((__aligned__ (1), __may_alias__))); and use that type for wordp, or just use may_alias attribute and first do a few byte cycles to align the pointer, then do the main cycle, then do any remaining bytes.
[Bug libstdc++/48476] [C++0x] conversion between std::tuple which have reference member is rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48476 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-04-06 07:38:39 UTC --- Hi. Not having looked into it in detail yet, your patch looks indeed reasonable. Do you have more testcases, for at lease some of the other issues you noticed? Indeed, I really meant to go again through std::tuple, I was nervous about some of those move and forward... Can you double check tuple_cat and tuple itself about that? I'm seeing some quite suspect moves, compared to the current draft. Thanks.
[Bug c/48199] unable to emulate 'TF'. Patch for mips64el r5900
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48199 Deny archicharmer at mail dot ru changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #2 from Deny archicharmer at mail dot ru 2011-04-06 07:43:17 UTC --- I knew that it is not gcc bug. And its confirmed. Need patch for glibc, not for gcc. http://www.kernel.org/pub/linux/devel/gcc/float128/libc-float128-14.patch and i successfully compiled glibc-2.12.1
[Bug other/48445] Release does not generate fixincludes directory needed by Makefile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48445 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-06 08:02:26 UTC --- invalid then N.B. if you copy the gmp/mpfr/mpc sources into the gcc source tree you don't need to build install them separately, and don't need to use LD_LIBRARY_PATH - it's much easier
[Bug libstdc++/48465] [4.6/4.7 Regression] undefined reference to std::basic_string::_S_compare(unsigned long, unsigned long)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48465 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org 2011-04-06 08:28:15 UTC --- --param=hot-bb-frequency-fraction=1 will effectively disable inlining within BBs that are not always executed when function is invoked. So the question is if the function in question is static within unit and should then be output as offline copy or there is just a bug in libstdc++ exported symbols.
[Bug libstdc++/48476] [C++0x] conversion between std::tuple which have reference member is rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48476 --- Comment #2 from Takaya Saito gintensubaru at gmail dot com 2011-04-06 08:32:09 UTC --- Created attachment 23896 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23896 simple test for operator=( Tuple )
[Bug libstdc++/48476] [C++0x] conversion between std::tuple which have reference member is rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48476 --- Comment #3 from Takaya Saito gintensubaru at gmail dot com 2011-04-06 08:32:57 UTC --- Created attachment 23897 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23897 simple test for std::tuple_cat
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #17 from Claudio Bantaloukas rockdreamer at gmail dot com 2011-04-06 08:35:27 UTC --- Comment on attachment 23120 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23120 Patch to simply not use bss section with .bs, but private-data-section instead Hi *, I've been bitten by this bug too. Patch 23120 resolves the C_SECT issue for me, however I get a new error when compiling a c++ file. ld: 0711-380 STABSTRING ERROR: Symbol table entry 1246, object file ../libpkg_mka.a[DB 2MkAQuery.cpp.o] Length of stabstring in .debug section is invalid. The stabstring is being deleted. ld: 0711-380 STABSTRING ERROR: Symbol table entry 1248, object file ../libpkg_mka.a[Or aMkAQuery.cpp.o] Length of stabstring in .debug section is invalid. The stabstring is being deleted. collect2: ld returned 12 exit status --- Any suggestions on how to add more details this are welcome!
[Bug middle-end/47663] Very simple wrapper not inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47663 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-06 08:51:27 UTC --- Author: rguenth Date: Wed Apr 6 08:51:23 2011 New Revision: 172023 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172023 Log: 2011-04-06 Richard Guenther rguent...@suse.de PR tree-optimization/47663 * cgraph.h (struct cgraph_edge): Add call_stmt_size and call_stmt_time fields. (cgraph_edge_inlinable_p): Declare. (cgraph_edge_recursive_p): New inline function. * cgraph.c (cgraph_create_edge_1): Initialize call_stmt_size. (cgraph_clone_edge): Copy it. * ipa-inline.c (cgraph_estimate_edge_time): New function. Account for call stmt time. (cgraph_estimate_time_after_inlining): Take edge argument. (cgraph_estimate_edge_growth): Account call stmt size. (cgraph_estimate_size_after_inlining): Take edge argument. (cgraph_mark_inline_edge): Adjust. (cgraph_check_inline_limits): Likewise. (cgraph_recursive_inlining_p): Remove. (cgraph_edge_badness): Use cgraph_edge_recursive_p. (cgraph_decide_recursive_inlining): Take edge argument and adjust. (cgraph_decide_inlining_of_small_functions): Do not avoid diags for recursive inlining here. (cgraph_flatten): Adjust. (cgraph_decide_inlining_incrementally): Likewise. (estimate_function_body_sizes): Remove call cost handling. (compute_inline_parameters): Initialize caller edge call costs. (cgraph_estimate_edge_growth): New function. (cgraph_estimate_growth): Use it. (cgraph_edge_badness): Likewise. (cgraph_check_inline_limits): Take an edge argument. (cgraph_decide_inlining_of_small_functions): Adjust. (cgraph_decide_inlining): Likewise. * tree-inline.c (estimate_num_insns): Only account for call return value if it is used. (expand_call_inline): Avoid diagnostics on recursive inline functions here. * lto-cgraph.c (lto_output_edge): Output edge call costs. (input_edge): Input edge call costs. * gcc.dg/tree-ssa/inline-8.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/inline-8.c Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.c trunk/gcc/cgraph.h trunk/gcc/ipa-inline.c trunk/gcc/lto-cgraph.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c
[Bug libstdc++/48340] Several wchar_t tests FAIL on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48340 --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-04-06 08:55:22 UTC --- --- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-03 17:58:14 UTC --- Created attachment 23858 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23858 handle ctype::mask values that don't fit in 16bits this should fix it, but changes the size of ctypewchar_t on Irix, which would break the ABI Unfortunately, it didn't work. At first, I applied the patch to my previous build tree and reran make and make check in libstdc++, but the failures persisted. To make sure there wasn't any missing dependency, I removed the libstdc++-v3 directory, reconfigure and rebuilt, but with the same results. I happened to build on Tru64 UNIX from the same sources, and see lots of wchar_t failures there, too. Rainer
[Bug libstdc++/48476] [C++0x] conversion between std::tuple which have reference member is rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48476 Takaya Saito gintensubaru at gmail dot com changed: What|Removed |Added Attachment #23896|application/octet-stream|text/plain mime type|| --- Comment #4 from Takaya Saito gintensubaru at gmail dot com 2011-04-06 09:05:19 UTC --- Comment on attachment 23896 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23896 simple test for operator=( Tuple ) in gcc-4.6.0, this code fails assertion 'q == p' and 'r == q', because references to p and q are not forwarded but moved ( see N3242 20.4.2.2 ).
[Bug libstdc++/48476] [C++0x] conversion between std::tuple which have reference member is rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48476 Takaya Saito gintensubaru at gmail dot com changed: What|Removed |Added Attachment #23897|application/octet-stream|text/plain mime type|| --- Comment #5 from Takaya Saito gintensubaru at gmail dot com 2011-04-06 09:07:03 UTC --- Comment on attachment 23897 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23897 simple test for std::tuple_cat gcc-4.6.0 rejects this code.
[Bug target/43920] Choosing conditional execution over conditional branches for code size in some cases.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43920 --- Comment #9 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-04-06 09:41:10 UTC --- Author: ramana Date: Wed Apr 6 09:41:07 2011 New Revision: 172031 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172031 Log: Fix commit for PR target/43920 Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/arm/pr43920-1.c
[Bug middle-end/48465] [4.6/4.7 Regression] undefined reference to std::basic_string::_S_compare(unsigned long, unsigned long)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48465 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Component|libstdc++ |middle-end --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-06 09:51:40 UTC --- The function is static and thus should be output as offline copy. This doesn't look like a libstdc++ bug.
[Bug lto/48467] [LTO/driver] Anomalous behavior of -save-temps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48467 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.04.06 10:01:51 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-06 10:01:51 UTC --- Confirmed. What we could do is try to arrange for the WPA lto1 stage to receive -o /dev/null, as it will not produce regular output. Or to simply avoid calling init_asm_output () for -fwpa. So, sth like Index: toplev.c === --- toplev.c(revision 172023) +++ toplev.c(working copy) @@ -1743,7 +1743,8 @@ lang_dependent_init (const char *name) return 0; input_location = save_loc; - init_asm_output (name); + if (!flag_wpa) +init_asm_output (name); /* If stack usage information is desired, open the output file. */ if (flag_stack_usage) @@ -1848,8 +1849,6 @@ finalize (bool no_backend) fatal_error (error writing to %s: %m, asm_file_name); if (fclose (asm_out_file) != 0) fatal_error (error closing %s: %m, asm_file_name); - if (flag_wpa) - unlink_if_ordinary (asm_file_name); } if (stack_usage_file) which likely needs fixups throughout the compiler in case of missing asm_out_file checks.
[Bug regression/48477] [4.7 Regression]: gfortran.dg/coarray_13.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48477 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug middle-end/47663] Very simple wrapper not inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47663 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-06 10:11:34 UTC --- Fixed.
[Bug middle-end/48465] [4.6/4.7 Regression] undefined reference to std::basic_string::_S_compare(unsigned long, unsigned long)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48465
--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-06
11:08:40 UTC ---
Adding these exports to libstdc++ does fix it though:
GLIBCXX_3.4.16 {
_ZNSs10_S_compareEmm;
_ZNSbIwSt11char_traitsIwESaIwEE10_S_compareEmm;
} GLIBCXX_3.4.15;
[Bug middle-end/48465] [4.6/4.7 Regression] undefined reference to std::basic_string::_S_compare(unsigned long, unsigned long)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48465
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-06
11:45:42 UTC ---
Note that for i686 it isn't *mm, but *jj, so I think you want to:
GLIBCXX_3.4.16 {
_ZNSs10_S_compareE[jmy][jmy];
_ZNSbIwSt11char_traitsIwESaIwEE10_S_compareE[jmy][jmy];
} GLIBCXX_3.4.15;
[Bug debug/48466] [4.4/4.5/4.6 Regression] Wrong variable locations at -O0 on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48466 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-06 11:50:03 UTC --- Author: jakub Date: Wed Apr 6 11:49:59 2011 New Revision: 172039 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172039 Log: PR debug/48466 * dwarf2out.c (based_loc_descr): If drap_reg is INVALID_REGNUM, use as base_reg whatever register reg has been eliminated to, instead of hardcoding STACK_POINTER_REGNUM. * gcc.dg/guality/pr36977.c: New test. * gcc.dg/guality/pr48466.c: New test. Added: trunk/gcc/testsuite/gcc.dg/guality/pr36977.c trunk/gcc/testsuite/gcc.dg/guality/pr48466.c Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/48478] New: Valid array-constructor syntax rejected/invalid accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48478 Summary: Valid array-constructor syntax rejected/invalid accepted Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ian_har...@bigpond.com Created attachment 23898 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23898 Demonstrates valid and invalid syntax gfortran 4.7 compiled from trunk revision 171951 rejects an array constructor with syntax: [ derived_type_name:: ... ] With -Wall --std=f2003 it accepts without complaint one of the form: [ TYPE(derived_type_name):: ... ] From F2008 draft: R468: array-constructor is (/ ac-spec /) or lbracket ac-spec rbracket R469: ac-specis type-spec :: or [type-spec ::] ac-value-list R402: type-spec is intrinsic-type-spec or derived-type-spec R453: derived-type-spec is type-name [(type-param-spec-list)] It looks like the compiler has confused a type-spec with a declaration-type-spec, (which does use the TYPE keyword).
Optimisation Problem
hello there... i am trying my hands on gcc optimisations options. i tried e.g. -finline-functions, -funroll-loops and the likes but none worked for me for ex. i tried -funroll-loops for code for (int i = 0; i 3; ++i) a[i] = i; which should unroll like a[0] = 0 a[1] = 1 a[2] = 2 but it didn't seem to happen. Is this a bug or something? please help me write good test case or suggest some. i am using gcc 4.1.2. tried 5.4.2 also on rhel5 Best Regards -- View this message in context: http://old.nabble.com/Optimisation-Problem-tp31332686p31332686.html Sent from the gcc - bugs mailing list archive at Nabble.com.
[Bug objc++/48479] New: [4.7 Regression] Many ICEs in the obj-c++.dg test suite on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48479 Summary: [4.7 Regression] Many ICEs in the obj-c++.dg test suite on *-apple-darwin* Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: nicola.p...@meta-innovation.com, ia...@gcc.gnu.org Host: *-apple-darwin* Target: *-apple-darwin* Build: *-apple-darwin* Between revisions 171800 and 171957 many failures appeared in the obj-c++.dg test suite on *-apple-darwin*(see http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg00442.html ): FAIL: obj-c++.dg/template-4.mm -fnext-runtime (internal compiler error) FAIL: obj-c++.dg/template-4.mm -fnext-runtime (test for excess errors) WARNING: obj-c++.dg/template-4.mm -fnext-runtime compilation failed to produce executable FAIL: obj-c++.dg/strings/const-str-12.mm -fnext-runtime (internal compiler error) FAIL: obj-c++.dg/strings/const-str-12.mm -fnext-runtime (test for excess errors) ... FAIL: obj-c++.dg/torture/strings/string1.mm -O2 -flto -fnext-runtime (internal compiler error) FAIL: obj-c++.dg/torture/strings/string1.mm -O2 -flto -fnext-runtime (test for excess errors) WARNING: obj-c++.dg/torture/strings/string1.mm -O2 -flto -fnext-runtime compilation failed to produce executable AFAICT they are all of the kind /opt/gcc/work/gcc/testsuite/obj-c++.dg/template-4.mm: In function 'int main()': /opt/gcc/work/gcc/testsuite/obj-c++.dg/template-4.mm:75:3: internal compiler error: tree check: expected tree that contains 'decl with RTL' structure, have 'const_decl' in cxx_mark_addressable, at cp/typeck.c:5378
[Bug testsuite/48480] New: FAIL: staticrootslib.lo -O2 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48480 Summary: FAIL: staticrootslib.lo -O2 (test for excess errors) Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: m...@gcc.gnu.org, r...@cebitec.uni-bielefeld.de, ia...@gcc.gnu.org Host: x86_64-apple-darwin10 Target: x86_64-apple-darwin10 Build: x86_64-apple-darwin10 On x86_64-apple-darwin10 the test staticrootslib.lo in the boehm-gc suite fails due to the following warnings Excess errors: /usr/bin/ranlib: file: .libs/libstaticrootslib.a(backgraph.o) has no symbols /usr/bin/ranlib: file: .libs/libstaticrootslib.a(checksums.o) has no symbols /usr/bin/ranlib: file: .libs/libstaticrootslib.a(gc_dlopen.o) has no symbols /usr/bin/ranlib: file: .libs/libstaticrootslib.a(pcr_interface.o) has no symbols /usr/bin/ranlib: file: .libs/libstaticrootslib.a(pthread_stop_world.o) has no symbols /usr/bin/ranlib: file: .libs/libstaticrootslib.a(real_malloc.o) has no symbols /usr/bin/ranlib: file: .libs/libstaticrootslib.a(specific.o) has no symbols /usr/bin/ranlib: file: .libs/libstaticrootslib.a(win32_threads.o) has no symbols AFAICT these warnings are rather usual (I see them with 'make install' for a lot of libraries) and they seem harmless.
[Bug libstdc++/48465] [4.6/4.7 Regression] undefined reference to std::basic_string::_S_compare(unsigned long, unsigned long)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48465 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Component|middle-end |libstdc++ --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-06 13:00:28 UTC --- If the class is explicitly instantiated we probably do not emit an out-of-line copy of the static (dependent) function. And I see extern template class basic_stringchar; in bits/basic_string.tcc, so it seems to be a library bug after all.
[Bug regression/48477] [4.7 Regression]: gfortran.dg/coarray_13.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48477 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.04.06 13:04:07 Ever Confirmed|0 |1 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-04-06 13:04:07 UTC --- Confirm on x86-64-Linux. In a way I am surprised that it does not crash there - but at least valgrind properly warns. The issue is: allocate(B(3)[-4:*]) call three_b(3,B) ... subroutine three_b(n,A) integer :: n integer :: A(-1:3,0:4,-2:5,-4:7)[n+2:n+5,n-1:*] ... A(1,1,1,1) = 42 Thus, one passes B which is a size 3 array as actual argument to a dummy array A which has the size 2400. (That's questionable usage, but still valid.) If one now accesses the element A(1,1,1,1) on effectively accesses array element B(144) which is not that healthy if B has only 3 elements.
[Bug testsuite/48480] FAIL: staticrootslib.lo -O2 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48480 --- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-04-06 13:20:24 UTC --- On x86_64-apple-darwin10 the test staticrootslib.lo in the boehm-gc suite fails due to the following warnings Excess errors: /usr/bin/ranlib: file: .libs/libstaticrootslib.a(backgraph.o) has no symbols [...] AFAICT these warnings are rather usual (I see them with 'make install' for a lot of libraries) and they seem harmless. Indeed, and they should be already pruned in boehm-gc/testsuite/lib/boehm-gc.exp (boehm-gc-dg-prune). That regexp doesn't account for a path to ranlib since that wasn't included in the message Iain Sandoe sent me when first testing my patch. Could you please try the following command instead? regsub -all (^|\n)(\[^\n\]*ranlib: file: \[^\n\]* has no symbols\n?)+ $text \\1 text It works with manual testing in tclsh. Thanks. Rainer
[Bug fortran/48478] Array-constructor with type-spec: reject valid/accept invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48478 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||accepts-invalid, ||rejects-valid Last reconfirmed||2011.04.06 13:20:35 CC||burnus at gcc dot gnu.org Ever Confirmed|0 |1 Summary|Valid array-constructor |Array-constructor with |syntax rejected/invalid |type-spec: reject |accepted|valid/accept invalid --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-04-06 13:20:35 UTC --- Confirmed. I first thought that it used to work properly (I cannot check at the moment), but I now think that I mixed it up with ALLOCATE ( type-spec :: ...) which has the the same syntax. Thus, the fix should be trivial: To use the same as for allocate. match.c's gfc_match_allocate has: m = match_type_spec (ts); While array.c's gfc_match_array_constructor uses: if (gfc_match_decl_type_spec (ts, 0) == MATCH_YES) (One should make sure that the array constructor also works in initialization expressions, it might use a different code path.)
[Bug c++/48468] [C++0x][SFINAE] noexcept operator does not handle function templates well
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48468 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.04.06 13:37:31 AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug objc++/48479] [4.7 Regression] Many ICEs in the obj-c++.dg test suite on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48479 Nathan Froyd froydnj at gcc dot gnu.org changed: What|Removed |Added CC||froydnj at gcc dot gnu.org --- Comment #1 from Nathan Froyd froydnj at gcc dot gnu.org 2011-04-06 13:39:29 UTC --- Bleh, that would be my change. I think what's required is making the CONST_DECL its own case there.
[Bug rtl-optimization/48442] ICE: in init_seqno, at sel-sched.c:6767 with -Os -fselective-scheduling2 --param max-sched-extend-regions-iters=100
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48442 --- Comment #1 from Alexander Monakov amonakov at gcc dot gnu.org 2011-04-06 13:39:44 UTC --- Created attachment 23899 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23899 proposed patch
[Bug objc++/48479] [4.7 Regression] Many ICEs in the obj-c++.dg test suite on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48479 --- Comment #2 from Nathan Froyd froydnj at gcc dot gnu.org 2011-04-06 13:41:01 UTC --- Created attachment 23900 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23900 untested patch
[Bug rtl-optimization/48442] ICE: in init_seqno, at sel-sched.c:6767 with -Os -fselective-scheduling2 --param max-sched-extend-regions-iters=100
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48442 --- Comment #2 from Alexander Monakov amonakov at gcc dot gnu.org 2011-04-06 13:41:33 UTC --- Confirmed. The 4.4/4.5 failure is most likely a dup of PR 46204. The 4.6/4.7 failure is due to selective scheduler removing a conditional jump during purge_empty_blocks in sel_sched_region_1 and then tripping on an incorrect assert in init_seqno (we probably never managed to remove jumps at that point prior to PR 46204 fix, but the nearby comment suggests we could and contradicts the assert). I'll test the attached patch that relaxes the assert and also drops number_of_insns argument to clean up a bit.
[Bug rtl-optimization/48442] ICE: in init_seqno, at sel-sched.c:6767 with -Os -fselective-scheduling2 --param max-sched-extend-regions-iters=100
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48442 Alexander Monakov amonakov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.04.06 13:41:57 CC||amonakov at gcc dot gnu.org AssignedTo|unassigned at gcc dot |amonakov at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug target/48227] rep ret generated for -march=core2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48227 --- Comment #3 from Zuxy zuxy.meng at gmail dot com 2011-04-06 13:42:21 UTC --- (In reply to comment #1) A good question is does it make a difference in actual performance numbers, it might still make a positive difference. Until someone tries it out and sees the difference in performance, I am going to say we should keep it. Actually GCC since 4.6 has stopped generating 'rep ret' for all Intel CPUs.
[Bug testsuite/48480] FAIL: staticrootslib.lo -O2 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48480 --- Comment #2 from Iain Sandoe iains at gcc dot gnu.org 2011-04-06 13:42:55 UTC --- (In reply to comment #1) On x86_64-apple-darwin10 the test staticrootslib.lo in the boehm-gc suite fails due to the following warnings Excess errors: /usr/bin/ranlib: file: .libs/libstaticrootslib.a(backgraph.o) has no symbols [...] AFAICT these warnings are rather usual (I see them with 'make install' for a lot of libraries) and they seem harmless. Indeed, and they should be already pruned in boehm-gc/testsuite/lib/boehm-gc.exp (boehm-gc-dg-prune). That regexp doesn't account for a path to ranlib since that wasn't included in the message Iain Sandoe sent me when first testing my patch. indeed, the path is not present for powerpc-darwin9 ;)
[Bug libstdc++/48476] [C++0x] conversion between std::tuple which have reference member is rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48476 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-04-06 14:07:19 UTC --- Ok, thanks. Still, I believe we have other std::move which should be turned into forward, in std::tuple. Those in std::tuple_cat itself also seem suspect, I see you are touching only the helper.
[Bug c++/6709] [DR743] decltype cannot be used with the :: operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6709
cheburnae osa252 at mail dot ru changed:
What|Removed |Added
CC||osa252 at mail dot ru
--- Comment #18 from cheburnae osa252 at mail dot ru 2011-04-06 14:23:53 UTC
---
A simple workaround:
template class T
struct TypeEcho {
typedef T R;
};
#define TYPE_OF(expr) TypeEchotypeof (*expr)::R
template class T
void foo() {
typename TYPE_OF(std::vectorT())::value_type();
}
void foo2() {
TYPE_OF(std::vectorint())::value_type();
fooint();
}
[Bug target/48273] [4.6/4.7 Regression] ICE: in create_copy_of_insn_rtx, at sel-sched-ir.c:5604 with -fsel-sched-pipelining -fselective-scheduling2 -march=core2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48273 --- Comment #5 from Alexander Monakov amonakov at gcc dot gnu.org 2011-04-06 14:40:28 UTC --- There's little value in allowing bookkeeping for calls, and the (untested yet) patch below forces calls to be unique. The test case also shows that our remove_insns_that_need_bookkeeping function works incorrectly for infinite loops (the single basic block dominates itself, and SPEC of the pipelined instruction is not increased because there's no conditional branch). It's possible to fix up that function by also looking at INSN_SCHED_TIMES, but the simpler way is to forbid pipelining for infinite loops. diff --git a/gcc/sel-sched-ir.c b/gcc/sel-sched-ir.c index 67484dd..95c1431 100644 --- a/gcc/sel-sched-ir.c +++ b/gcc/sel-sched-ir.c @@ -2905,6 +2905,7 @@ init_global_and_expr_for_insn (insn_t insn) if (CANT_MOVE (insn) || INSN_ASM_P (insn) || SCHED_GROUP_P (insn) + || CALL_P (insn) /* Exception handling insns are always unique. */ || (cfun-can_throw_non_call_exceptions can_throw_internal (insn)) /* TRAP_IF though have an INSN code is control_flow_insn_p (). */ diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c index 0e8173b..415eaa4 100644 --- a/gcc/sel-sched.c +++ b/gcc/sel-sched.c @@ -6781,7 +6781,9 @@ sel_setup_region_sched_flags (void) bookkeeping_p = 1; pipelining_p = (bookkeeping_p (flag_sel_sched_pipelining != 0) - current_loop_nest != NULL); + current_loop_nest != NULL + /* Check that there is at least one exit. */ + current_loop_nest-exits-next-e); max_insns_to_rename = PARAM_VALUE (PARAM_SELSCHED_INSNS_TO_RENAME); max_ws = MAX_WS; }
[Bug libstdc++/48465] [4.6/4.7 Regression] undefined reference to std::basic_string::_S_compare(unsigned long, unsigned long)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48465 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2011-04-06 14:45:36 UTC --- Jon, if you could run the patchlet (as tweaked by Jakub) through the testsuite, and apply it, it would be great. I'm still traveling and trying to find the time to work on the std::tuple issues over the next days.
[Bug objc++/48479] [4.7 Regression] Many ICEs in the obj-c++.dg test suite on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48479 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.06 14:58:01 Ever Confirmed|0 |1 --- Comment #3 from Iain Sandoe iains at gcc dot gnu.org 2011-04-06 14:58:01 UTC --- (In reply to comment #2) Created attachment 23900 [details] untested patch seems to do the trick on i686-darwin9 ... .. linux is still bootstrapping..
[Bug testsuite/48480] FAIL: staticrootslib.lo -O2 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48480
--- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-04-06
14:58:45 UTC ---
... Could you please try the following command instead? ...
This fixes the failure: i.e., running
make -k check RUNTESTFLAGS=--target_board=unix'{-m32,-m64}'
in x86_64-apple-darwin10.7.0/boehm-gc/testsuite, yields
=== boehm-gc Summary ===
# of expected passes24
# of unsupported tests2
Thanks.
[Bug libstdc++/48465] [4.6/4.7 Regression] undefined reference to std::basic_string::_S_compare(unsigned long, unsigned long)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48465 --- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-06 14:59:03 UTC --- ok, will do
[Bug testsuite/48480] FAIL: staticrootslib.lo -O2 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48480 --- Comment #4 from Rainer Orth ro at gcc dot gnu.org 2011-04-06 15:23:36 UTC --- Author: ro Date: Wed Apr 6 15:23:33 2011 New Revision: 172050 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172050 Log: PR testsuite/48480 * testsuite/lib/boehm-gc.exp (boehm-gc-dg-prune): Allow for path to ranlib. Modified: trunk/boehm-gc/ChangeLog trunk/boehm-gc/testsuite/lib/boehm-gc.exp
[Bug testsuite/48480] FAIL: staticrootslib.lo -O2 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48480 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-04/msg00478.htm ||l CC||ro at gcc dot gnu.org Resolution||FIXED AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 --- Comment #5 from Rainer Orth ro at gcc dot gnu.org 2011-04-06 15:31:40 UTC --- Fixed for 4.7.0, thanks for the report. Rainer
[Bug c++/48481] New: C++ overloading memory hog
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48481
Summary: C++ overloading memory hog
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: memory-hog
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: ja...@gcc.gnu.org
#define A(n) \
struct S##n { int i; }; \
S##n v##n;\
extern int foo (S##n, S##n);\
extern void bar (S##n);
#define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) A(n##5) A(n##6) A(n##7)
A(n##8) A(n##9)
#define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) B(n##5) B(n##6) B(n##7)
B(n##8) B(n##9)
#define D(n) C(n##0) C(n##1) C(n##2) C(n##3) C(n##4) C(n##5) C(n##6) C(n##7)
C(n##8) C(n##9)
#ifndef N
#define N 1
#endif
#if N == 1000
#define E(n) D(n##0)
#elif N == 2000
#define E(n) D(n##0) D(n##1)
#elif N == 3000
#define E(n) D(n##0) D(n##1) D(n##2)
#else
#define E(n) D(n##0) D(n##1) D(n##2) D(n##3) D(n##4) D(n##5) D(n##6) D(n##7)
D(n##8) D(n##9)
#endif
E(0)
void
foo ()
{
#undef A
#define A(n) if (foo (v##n, v##n)) bar (v##n);
E(0)
}
testcase eats huge amounts of memory. With -DN=1000 -O0 it compiles quickly,
using 432768 kB of memory (852MB in top), with -DN=2000 -O0 it already uses
1672544 kB (3.5GB in top). With -DN=3000 it took around 8GB in top.
In --enable-gather-detailed-mem-stats -fmem-report, for N=1000 I see:
cp/tree.c:1447 (ovl_cons) 64032000:15.1% 0:
0.0% 256032: 1.8% 0: 0.0%2009001
c-family/c-common.c:9556 (make_tree_vector) 159840120:37.8% 0:
0.0% 0: 0.0% 0: 0.0%3996003
cp/search.c:1135 (build_baselink) 191952000:45.4% 0:
0.0% 0: 0.0% 0: 0.0%3999000
Total 422660566 8986384
14294815 2724053 10281399
source location GarbageFreed
Leak OverheadTimes
and for N=2000:
cp/tree.c:1447 (ovl_cons) 256064000:15.3% 0:
0.0% 512032: 1.9% 0: 0.0%8018001
c-family/c-common.c:9556 (make_tree_vector) 639680120:38.1% 0:
0.0% 0: 0.0% 0: 0.0% 15992003
cp/search.c:1135 (build_baselink) 767904000:45.8% 0:
0.0% 0: 0.0% 0: 0.0% 15998000
Total1677099246 12464328
27061439 3876781 40545425
source location GarbageFreed
Leak OverheadTimes
[Bug libstdc++/48476] [C++0x] conversion between std::tuple which have reference member is rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48476 --- Comment #7 from Takaya Saito gintensubaru at gmail dot com 2011-04-06 15:32:00 UTC --- (In reply to comment #6) Ok, thanks. Still, I believe we have other std::move which should be turned into forward, in std::tuple. Those in std::tuple_cat itself also seem suspect, I see you are touching only the helper. Well, I think I had replaced all std::move that should be turned into forward ; remaining std::move are moving _Inherited ( _Tuple_impl_Idx + 1, _Tail... ), tupleElements... or rvalue reference to these classes, which are not lvalue reference type, so they are not to be replaced ( of course, it is not wrong to replace them with std::forward, since std::move(x) is equivalent to std::forwardT(x) if T is remove_referencedecltype((x))::type ).
[Bug c++/48481] C++ overloading memory hog
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48481 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-06 15:48:35 UTC --- During perform_overload_resolution add_candidates allocates lots of ggc memory which splice_viable immediately throws away and we don't ggc_collect during parsing.
[Bug objc++/48479] [4.7 Regression] Many ICEs in the obj-c++.dg test suite on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48479 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-04-06 15:58:42 UTC --- seems to do the trick on i686-darwin9 ... On x86_64-apple-darwin10 too (incremental update with the patch in comment #2 on top of r172043 and regtesting of g++ and obj-c++ with -m32 and -m64). Thanks for the quick fix.
[Bug rtl-optimization/48302] ICE: SIGSEGV in reposition_prologue_and_epilogue_notes (function.c:5662) with -fcrossjumping -fselective-scheduling2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48302
Alexander Monakov amonakov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2011.04.06 16:08:13
CC||amonakov at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |amonakov at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #1 from Alexander Monakov amonakov at gcc dot gnu.org 2011-04-06
16:08:13 UTC ---
Confirmed. We call sched_scan for preheader blocks from inner regions twice:
first during sel_add_loop_preheaders, and then during the subsequent call to
sel_init_bbs in setup_current_loop_nest. As a result, we also call
remove_notes for those blocks twice, and after the second call incorrectly
record that the block has no notes.
The solution is to call sel_add_loop_preheaders after sel_init_bbs. We need to
add new preheader blocks into bbs vector in setup_current_loop_nest, so we pass
the pointer to the vector to sel_add_loop_preheaders.
diff --git a/gcc/sel-sched-ir.c b/gcc/sel-sched-ir.c
index 95c1431..a6daa58 100644
--- a/gcc/sel-sched-ir.c
+++ b/gcc/sel-sched-ir.c
@@ -6094,11 +6094,11 @@ sel_find_rgns (void)
bbs_in_loop_rgns = NULL;
}
-/* Adds the preheader blocks from previous loop to current region taking
- it from LOOP_PREHEADER_BLOCKS (current_loop_nest).
+/* Add the preheader blocks from previous loop to current region taking
+ it from LOOP_PREHEADER_BLOCKS (current_loop_nest) and record them in *BBS.
This function is only used with -fsel-sched-pipelining-outer-loops. */
void
-sel_add_loop_preheaders (void)
+sel_add_loop_preheaders (bb_vec_t *bbs)
{
int i;
basic_block bb;
@@ -6109,6 +6109,7 @@ sel_add_loop_preheaders (void)
VEC_iterate (basic_block, preheader_blocks, i, bb);
i++)
{
+ VEC_safe_push (basic_block, heap, *bbs, bb);
VEC_safe_push (basic_block, heap, last_added_blocks, bb);
sel_add_bb (bb);
}
diff --git a/gcc/sel-sched-ir.h b/gcc/sel-sched-ir.h
index 5516da9..b0c52eb 100644
--- a/gcc/sel-sched-ir.h
+++ b/gcc/sel-sched-ir.h
@@ -1628,7 +1628,7 @@ extern void sel_sched_region (int);
extern loop_p get_loop_nest_for_rgn (unsigned int);
extern bool considered_for_pipelining_p (struct loop *);
extern void make_region_from_loop_preheader (VEC(basic_block, heap) **);
-extern void sel_add_loop_preheaders (void);
+extern void sel_add_loop_preheaders (bb_vec_t *);
extern bool sel_is_loop_preheader_p (basic_block);
extern void clear_outdated_rtx_info (basic_block);
extern void free_data_sets (basic_block);
diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c
index 415eaa4..42a2cde 100644
--- a/gcc/sel-sched.c
+++ b/gcc/sel-sched.c
@@ -6802,7 +6802,7 @@ current_region_empty_p (void)
/* Prepare and verify loop nest for pipelining. */
static void
-setup_current_loop_nest (int rgn)
+setup_current_loop_nest (int rgn, bb_vec_t *bbs)
{
current_loop_nest = get_loop_nest_for_rgn (rgn);
@@ -6811,7 +6811,7 @@ setup_current_loop_nest (int rgn)
/* If this loop has any saved loop preheaders from nested loops,
add these basic blocks to the current region. */
- sel_add_loop_preheaders ();
+ sel_add_loop_preheaders (bbs);
/* Check that we're starting with a valid information. */
gcc_assert (loop_latch_edge (current_loop_nest));
@@ -6850,9 +6850,6 @@ sel_region_init (int rgn)
if (current_region_empty_p ())
return true;
- if (flag_sel_sched_pipelining)
-setup_current_loop_nest (rgn);
-
sel_setup_region_sched_flags ();
bbs = VEC_alloc (basic_block, heap, current_nr_blocks);
@@ -6862,6 +6859,9 @@ sel_region_init (int rgn)
sel_init_bbs (bbs, NULL);
+ if (flag_sel_sched_pipelining)
+setup_current_loop_nest (rgn, bbs);
+
/* Initialize luids and dependence analysis which both sel-sched and haifa
need. */
sched_init_luids (bbs, NULL, NULL, NULL);
[Bug c++/45114] implement C++0x alias-declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45114 --- Comment #4 from Simon Hill yacwroy at gmail dot com 2011-04-06 16:17:35 UTC --- I was trying out this patch to see whether it might be usable to me, just as a preview. Firstly: Is this patch at a stage where it could be possible to complete a make/install, or am I jumping the gun? I don't want to update the patch (at least not without confirmation), but in case anyone else wants to try it as is, I believe that parser.c line 13496: if (at_class_scope () || template_parm_scope_p ()) should be changed to: if (at_class_scope_p () || template_parm_scope_p ()) (otherwise it doesn't compile). I got an ICE trying to make GCC on a SVN trunk checkout yesterday after (manually) patching with this (it only failed on building the libs). I can supply details if you want, but I guess this patch is outdated now?
[Bug target/48380] [gcc-4.7 regression] ICE in postreload.c while building trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48380 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution||FIXED --- Comment #6 from Jeffrey A. Law law at redhat dot com 2011-04-06 16:22:19 UTC --- Should be fixed by Vlad's patch.
[Bug libstdc++/48476] [C++0x] conversion between std::tuple which have reference member is rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48476 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.06 16:29:15 Ever Confirmed|0 |1 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2011-04-06 16:29:15 UTC --- Fair enough. I think the safe thing to do here is proceeding incrementally: today I will be testing your patch (+ testcases) and I think it's small enough to bd suited for 4_6-branch too. Then we can certainly imagine other improvements. If you notice something else which could be improved over the next weeks, please let us know, I mean to pay more attention to std::tuple than I used to lately, sadly.
[Bug rtl-optimization/48389] [4.5/4.6/4.7 Regression] ICE: in make_edges, at cfgbuild.c:319 with -mtune=pentiumpro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48389 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.06 16:53:11 CC||law at redhat dot com AssignedTo|unassigned at gcc dot |law at redhat dot com |gnu.org | Ever Confirmed|0 |1
[Bug rtl-optimization/48389] [4.5/4.6/4.7 Regression] ICE: in make_edges, at cfgbuild.c:319 with -mtune=pentiumpro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48389 --- Comment #1 from Jeffrey A. Law law at redhat dot com 2011-04-06 16:54:41 UTC --- Elimination of a PHI caused a loop to be inserted on an edge. The edge insertions were committed after calling rebuild_jump_labels resulting in a null JUMP_LABEL for the loop branch which later triggered the abort.
[Bug rtl-optimization/48455] [4.7 Regression] Huge code size regression for all ARM configurations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48455 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC||vmakarov at redhat dot com --- Comment #3 from Vladimir Makarov vmakarov at redhat dot com 2011-04-06 16:58:02 UTC --- That is a huge degradation. I am going to work on it. Could you provide me a small test? I can not even download CSiBE. Something wrong with their web-server.
[Bug libstdc++/48465] [4.6/4.7 Regression] undefined reference to std::basic_string::_S_compare(unsigned long, unsigned long)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48465 --- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com 2011-04-06 17:02:30 UTC --- Thanks!
[Bug rtl-optimization/47612] RTL crash when cc0 setter moved away from cc0 user
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612 --- Comment #8 from Vincent Riviere vincent.riviere at freesbee dot fr 2011-04-06 17:07:26 UTC --- Excellent! Your patch fixes both testcases here.
[Bug bootstrap/48158] [4.7 Regression] profiledbootstrap failure on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48158 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-06 17:22:39 UTC --- Ping, just hit this during Ada LTO bootstrap, so it isn't limited to Go...
[Bug rtl-optimization/47612] RTL crash when cc0 setter moved away from cc0 user
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612 --- Comment #9 from Bernd Schmidt bernds at gcc dot gnu.org 2011-04-06 17:28:43 UTC --- Any chance you can run the testsuite before/after the patch? m68k is problematic due to lack of a simulator.
[Bug tree-optimization/48482] New: ICE: in omega_alloc_problem, at omega.c:5498 with -fcheck-data-deps --param omega-max-vars=1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48482 Summary: ICE: in omega_alloc_problem, at omega.c:5498 with -fcheck-data-deps --param omega-max-vars=1 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 23901 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23901 reduced testcase (the same as gcc.dg/tree-ssa/pr42327.c) Maybe related to PR48393 and PR42327. Compiler output: $ gcc -O -fcheck-data-deps --param omega-max-vars=1 testcase.c testcase.c: In function 'foo': testcase.c:1: internal compiler error: in omega_alloc_problem, at omega.c:5498 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. (gdb) bt #0 fancy_abort (file=0x1349c28 /mnt/svn/gcc-trunk/gcc/omega.c, line=5473, function=0x134aae0 omega_alloc_problem) at /mnt/svn/gcc-trunk/gcc/diagnostic.c:892 #1 0x010338b1 in omega_alloc_problem (nvars=2, nprot=1) at /mnt/svn/gcc-trunk/gcc/omega.c:5473 #2 0x009004ba in init_omega_for_ddr (datarefs=Unhandled dwarf expression opcode 0xf3 ) at /mnt/svn/gcc-trunk/gcc/tree-data-ref.c:3907 #3 compute_affine_dependence (datarefs=Unhandled dwarf expression opcode 0xf3 ) at /mnt/svn/gcc-trunk/gcc/tree-data-ref.c:4078 #4 compute_all_dependences (datarefs=Unhandled dwarf expression opcode 0xf3 ) at /mnt/svn/gcc-trunk/gcc/tree-data-ref.c:4176 #5 0x00901a60 in compute_data_dependences_for_loop (loop=Unhandled dwarf expression opcode 0xf3 ) at /mnt/svn/gcc-trunk/gcc/tree-data-ref.c:4469 #6 0x00901dc6 in analyze_all_data_dependences () at /mnt/svn/gcc-trunk/gcc/tree-data-ref.c:4576 #7 tree_check_data_deps () at /mnt/svn/gcc-trunk/gcc/tree-data-ref.c:4625 #8 0x009b4087 in check_data_deps () at /mnt/svn/gcc-trunk/gcc/tree-ssa-loop.c:323 #9 0x007ee346 in execute_one_pass (pass=0x16447c0) at /mnt/svn/gcc-trunk/gcc/passes.c:1555 #10 0x007ee635 in execute_pass_list (pass=0x16447c0) at /mnt/svn/gcc-trunk/gcc/passes.c:1610 #11 0x007ee647 in execute_pass_list (pass=0x1644ac0) at /mnt/svn/gcc-trunk/gcc/passes.c:1611 #12 0x007ee647 in execute_pass_list (pass=0x1643d40) at /mnt/svn/gcc-trunk/gcc/passes.c:1611 #13 0x00932145 in tree_rest_of_compilation (fndecl=0x75977f00) at /mnt/svn/gcc-trunk/gcc/tree-optimize.c:422 #14 0x00afd5b7 in cgraph_expand_function (node=0x75994000) at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1580 #15 0x00affcfc in cgraph_expand_all_functions () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1639 #16 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1903 #17 0x00b0028a in cgraph_finalize_compilation_unit () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1100 #18 0x00508864 in c_write_global_declarations () at /mnt/svn/gcc-trunk/gcc/c-decl.c:9879 #19 0x008db16d in compile_file (argc=16, argv=0x7fffdc58) at /mnt/svn/gcc-trunk/gcc/toplev.c:591
[Bug c++/48483] New: Construct from yourself w/o warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48483
Summary: Construct from yourself w/o warning
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lis...@lisp2d.net
Simple slip in my program bring to waste the time.
Writing the constructor with arguments of new object bring to crash.
No warnings and deep stillness.
The example to crash:
#includeiostream
classB{
public:
intx;
};
classA{
public:
Bb;
A(Bx):b(x){}
};
intmain(void){
Aa(a.b);
std::cloga.b.x=a.b.xstd::endl;}
[Bug rtl-optimization/47612] RTL crash when cc0 setter moved away from cc0 user
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612 --- Comment #10 from Joel Sherrill joel at gcc dot gnu.org 2011-04-06 17:52:00 UTC --- (In reply to comment #9) Any chance you can run the testsuite before/after the patch? m68k is problematic due to lack of a simulator. I can test with RTEMS on Qemu targeting an mc5282 Coldfire. I just started a build and test sweep without the patch. Give me a bit to post test results without and with the patch. FWIW gcc 4.6.0 does fail with the test case and 5282 so this will be a good sweep. $ m68k-rtems4.11-gcc -O2 -mcpu=5282 -fwrapv -c j2.c j2.c: In function 'bug': j2.c:19:1: internal compiler error: in maybe_add_or_update_dep_1, at sched-deps.c:845 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650
--- Comment #29 from joe at mcknight dot de 2011-04-06 17:55:30 UTC ---
FWIW, I can reproduce this now on Solaris without any magic compiler switches:
The program is just this here:
---
void
foo(char *buf, int bufsz);
void
foo(char * const buf, const int bufsz)
{
}
---
Compiling with just
gcc -fplugin=/path/to/plugin/testplugin.so -c foo.c
(gcc 4.5.2 with your patch on sparc-sun-solaris2.10)
gives me:
static void foo (char * const, int, void, ...);
However it only shows up on Solaris, I tried it on a Linux installation I have
as well and I get the correct output there :-(
Note the differences between the declaration and the definition regarding
const. If I remove any const in the definition (for buf or bufsz) or add a
const to the declaration, the output will be correct.
[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18918 --- Comment #31 from Tobias Burnus burnus at gcc dot gnu.org 2011-04-06 18:29:58 UTC --- Author: burnus Date: Wed Apr 6 18:29:55 2011 New Revision: 172059 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172059 Log: 2011-04-06 Tobias Burnus bur...@net-b.de PR fortran/18918 * caf/mpi.c (_gfortran_caf_init, _gfortran_caf_finalize): Add global variable caf_mpi_initialized and use it for when finalizing. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/caf/mpi.c
[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18918 --- Comment #32 from Tobias Burnus burnus at gcc dot gnu.org 2011-04-06 18:31:03 UTC --- Author: burnus Date: Wed Apr 6 18:30:58 2011 New Revision: 172060 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172060 Log: 2011-04-06 Tobias Burnus bur...@net-b.de PR fortran/18918 * trans-intrinsic.c (gfc_conv_intrinsic_function): Fix call for this_image. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-intrinsic.c
[Bug regression/48477] [4.7 Regression]: gfortran.dg/coarray_13.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48477 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-04-06 18:32:31 UTC --- Author: burnus Date: Wed Apr 6 18:32:27 2011 New Revision: 172061 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172061 Log: 2011-04-06 Tobias Burnus bur...@net-b.de PR fortran/18918 PR fortran/48477 * gfortran.dg/coarray_13.f90: Avoid out-of-bounds access. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/coarray_13.f90
[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18918 --- Comment #33 from Tobias Burnus burnus at gcc dot gnu.org 2011-04-06 18:32:31 UTC --- Author: burnus Date: Wed Apr 6 18:32:27 2011 New Revision: 172061 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172061 Log: 2011-04-06 Tobias Burnus bur...@net-b.de PR fortran/18918 PR fortran/48477 * gfortran.dg/coarray_13.f90: Avoid out-of-bounds access. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/coarray_13.f90
[Bug c++/48483] Construct from yourself w/o warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48483 --- Comment #1 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2011-04-06 19:20:02 UTC --- No warnings and deep stillness. $ g++ -O -Wuninitialized pr48483.cc pr48483.cc: In function 'int main()': pr48483.cc:13:30: warning: 'a.A::b' is used uninitialized in this function From http://gcc.gnu.org/onlinedocs/gcc-4.5.2/gcc/Warning-Options.html#index-Wuninitialized-309: Because these warnings depend on optimization, the exact variables or elements for which there are warnings will depend on the precise optimization options and version of GCC used.
[Bug tree-optimization/48484] New: [4.7 Regression] ICE: vector VEC(use_pred_info_t,base) index domain error, in pred_chain_length_cmp at tree-ssa-uninit.c:1626 with -Wuninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48484 Summary: [4.7 Regression] ICE: vector VEC(use_pred_info_t,base) index domain error, in pred_chain_length_cmp at tree-ssa-uninit.c:1626 with -Wuninitialized Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 23902 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23902 auto-reduced testcase Compiler output: $ gcc -O -finline-functions -finline-small-functions -Wuninitialized testcase.C testcase.C: In member function 'bool SQVM::FOREACH_OP(SQObjectPtr, SQObjectPtr, SQObjectPtr, SQObjectPtr, long int, int, int)': testcase.C:53:19: warning: 'nrefidx' may be used uninitialized in this function [-Wuninitialized] testcase.C:60:10: warning: 'idx' may be used uninitialized in this function [-Wuninitialized] testcase.C: In member function 'bool SQVM::Execute(SQObjectPtr, long int, long int, long int, SQObjectPtr, unsigned int, int)': testcase.C:53:19: warning: 'nrefidx' may be used uninitialized in this function [-Wuninitialized] testcase.C:49:5: note: 'nrefidx' was declared here testcase.C:60:10: warning: 'idx' may be used uninitialized in this function [-Wuninitialized] testcase.C:59:4: note: 'idx' was declared here testcase.C:67:3: internal compiler error: vector VEC(use_pred_info_t,base) index domain error, in pred_chain_length_cmp at tree-ssa-uninit.c:1626 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. #4 0x00bdfa79 in vec_assert_fail (op=0x14b0858 index, struct_name=0x12fd7c7 VEC(use_pred_info_t,base), file=Unhandled dwarf expression opcode 0xf3) at /mnt/svn/gcc-trunk/gcc/vec.c:524 #5 0x004bae5c in VEC_use_pred_info_t_base_index (line_=Unhandled dwarf expression opcode 0xf3) at /mnt/svn/gcc-trunk/gcc/tree-ssa-uninit.c:326 #6 0x00b4044b in pred_chain_length_cmp (p1=Unhandled dwarf expression opcode 0xf3) at /mnt/svn/gcc-trunk/gcc/tree-ssa-uninit.c:1632 #7 0x7649f0bb in msort_with_tmp () from /lib/libc.so.6 #8 0x7649f510 in __GI_qsort_r.clone.0 () from /lib/libc.so.6 #9 0x00b42195 in normalize_preds (use_stmt=Unhandled dwarf expression opcode 0xf3) at /mnt/svn/gcc-trunk/gcc/tree-ssa-uninit.c:1655 #10 is_use_properly_guarded (use_stmt=Unhandled dwarf expression opcode 0xf3 ) at /mnt/svn/gcc-trunk/gcc/tree-ssa-uninit.c:1817 #11 0x00b438a9 in find_uninit_use () at /mnt/svn/gcc-trunk/gcc/tree-ssa-uninit.c:1878 #12 warn_uninitialized_phi () at /mnt/svn/gcc-trunk/gcc/tree-ssa-uninit.c:1950 #13 execute_late_warn_uninitialized () at /mnt/svn/gcc-trunk/gcc/tree-ssa-uninit.c:2022 #14 0x00934a26 in execute_one_pass (pass=0x17c60a0) at /mnt/svn/gcc-trunk/gcc/passes.c:1555 #15 0x00934d15 in execute_pass_list (pass=0x17c60a0) at /mnt/svn/gcc-trunk/gcc/passes.c:1610 #16 0x00934d27 in execute_pass_list (pass=0x17c4d20) at /mnt/svn/gcc-trunk/gcc/passes.c:1611 #17 0x00a78825 in tree_rest_of_compilation (fndecl=0x759d0900) at /mnt/svn/gcc-trunk/gcc/tree-optimize.c:422 #18 0x00c43c97 in cgraph_expand_function (node=0x759df2c0) at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1580 #19 0x00c463dc in cgraph_expand_all_functions () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1639 #20 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1903 #21 0x00c4696a in cgraph_finalize_compilation_unit () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1100 #22 0x005b6aa8 in cp_write_global_declarations () at /mnt/svn/gcc-trunk/gcc/cp/decl2.c:4000 #23 0x00a2184d in compile_file (argc=17, argv=0x7fffdc38) at /mnt/svn/gcc-trunk/gcc/toplev.c:591
[Bug tree-optimization/48484] [4.7 Regression] ICE: vector VEC(use_pred_info_t,base) index domain error, in pred_chain_length_cmp at tree-ssa-uninit.c:1626 with -Wuninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48484 Zdenek Sojka zsojka at seznam dot cz changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Zdenek Sojka zsojka at seznam dot cz 2011-04-06 19:26:42 UTC --- PR48158 ICEs with the same error message.
[Bug libmudflap/48485] New: mudflap don't discover mistake - negative one index on static array i.e. a[-1]=b;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48485 Summary: mudflap don't discover mistake - negative one index on static array i.e. a[-1]=b; Product: gcc Version: 4.5.4 Status: UNCONFIRMED Severity: major Priority: P3 Component: libmudflap AssignedTo: unassig...@gcc.gnu.org ReportedBy: krasu...@mail.ru mudflap don't discover mistake - negative one index on static array i.e. a[-1]=b;
Re: Optimisation Problem
hello there... i am trying my hands on gcc optimisations options. i tried e.g. -finline-functions, -funroll-loops and the likes but none worked for me for ex. i tried -funroll-loops for code for (int i = 0; i 3; ++i) a[i] = i; Try -O -funroll-loops. -- Eric Botcazou
[Bug inline-asm/48435] [4.7 Regression] Assertion failure during IRA (df_scan)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48435 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC||vmakarov at redhat dot com --- Comment #4 from Vladimir Makarov vmakarov at redhat dot com 2011-04-06 19:42:56 UTC --- All pseudos got 0 available hard regs and therefore spills. Something wrong with calculation of number of available hard regs for targets which can use reg pairs starting only on even/odd hard regs. The fix will need changes in very sensitive part of IRA code and need some time to write it, test, and benchmark it. I hope it will be done at the end of week. Sorry for the inconvenience.
[Bug middle-end/48470] ICE in expand_expr_addr_expr_1 at expr.c:6835
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48470
--- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2011-04-06
19:48:25 UTC ---
Created attachment 23903
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23903
reduced test case
The test case reduces to the following:
void __attribute__((naked)) f(void)
{
int x = 0;
g(x);
}
It ICEs 4.4.5, 4.5.2, and 4.6.0, but not 4.3.5, 4.2.4, or 4.1.2.
I suspect it isn't valid to make recursive calls or take the address of local
variables in naked functions.
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 Brooks Moses brooks at gcc dot gnu.org changed: What|Removed |Added CC||brooks at gcc dot gnu.org --- Comment #6 from Brooks Moses brooks at gcc dot gnu.org 2011-04-06 19:54:39 UTC --- It appears that this underlying issue will also affect C++0x support for thread-local storage, assuming that it also allows non-POD thread-local objects. (See links from http://gcc.gnu.org/projects/cxx0x.html.) This is also looking like it's going to be a significant problem for us in the near future in using OpenMP. Are there GLIBC and binutils issues filed for the necessary underlying functionality that Jakub mentions in comment 1? If so, what are they? If not, what additional information is needed to file a coherent and accurate feature request there?
[Bug middle-end/48335] [4.6/4.7 Regression] ICE in convert_move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48335 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-06 20:39:24 UTC --- Author: jakub Date: Wed Apr 6 20:39:20 2011 New Revision: 172063 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172063 Log: Backported from mainline 2011-04-01 Jakub Jelinek ja...@redhat.com PR middle-end/48335 * expr.c (expand_assignment): Handle all possibilities if TO_RTX is CONCAT. * expmed.c (store_bit_field_1): Avoid trying to create invalid SUBREGs. (store_split_bit_field): If SUBREG_REG (op0) or op0 itself has smaller mode than word, return it for offset 0 and const0_rtx for out-of-bounds stores. If word is const0_rtx, skip it. * gcc.c-torture/compile/pr48335-1.c: New test. * gcc.dg/pr48335-1.c: New test. * gcc.dg/pr48335-2.c: New test. * gcc.dg/pr48335-3.c: New test. * gcc.dg/pr48335-4.c: New test. * gcc.dg/pr48335-5.c: New test. * gcc.dg/pr48335-6.c: New test. * gcc.dg/pr48335-7.c: New test. * gcc.dg/pr48335-8.c: New test. * gcc.target/i386/pr48335-1.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/compile/pr48335-1.c branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr48335-1.c branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr48335-2.c branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr48335-3.c branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr48335-4.c branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr48335-5.c branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr48335-6.c branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr48335-7.c branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr48335-8.c branches/gcc-4_6-branch/gcc/testsuite/gcc.target/i386/pr48335-1.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/expmed.c branches/gcc-4_6-branch/gcc/expr.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug debug/48466] [4.4/4.5/4.6 Regression] Wrong variable locations at -O0 on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48466 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-06 20:40:28 UTC --- Author: jakub Date: Wed Apr 6 20:40:24 2011 New Revision: 172064 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172064 Log: PR debug/48466 * dwarf2out.c (based_loc_descr): If drap_reg is INVALID_REGNUM, use as base_reg whatever register reg has been eliminated to, instead of hardcoding STACK_POINTER_REGNUM. * gcc.dg/guality/pr36977.c: New test. * gcc.dg/guality/pr48466.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/guality/pr36977.c branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/guality/pr48466.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/dwarf2out.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug middle-end/48335] [4.6/4.7 Regression] ICE in convert_move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48335 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-06 20:40:52 UTC --- Fixed.
[Bug rtl-optimization/48389] [4.5/4.6/4.7 Regression] ICE: in make_edges, at cfgbuild.c:319 with -mtune=pentiumpro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48389
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
--- Comment #2 from Steven Bosscher steven at gcc dot gnu.org 2011-04-06
20:41:40 UTC ---
I think this should fix the problem:
Index: cfgexpand.c
===
--- cfgexpand.c (revision 172003)
+++ cfgexpand.c (working copy)
@@ -4143,8 +4143,6 @@ gimple_expand_cfg (void)
/* Zap the tree EH table. */
set_eh_throw_stmt_table (cfun, NULL);
- rebuild_jump_labels (get_insns ());
-
FOR_BB_BETWEEN (bb, ENTRY_BLOCK_PTR, EXIT_BLOCK_PTR, next_bb)
{
edge e;
@@ -4170,6 +4168,8 @@ gimple_expand_cfg (void)
}
}
+ rebuild_jump_labels (get_insns ());
+
/* We're done expanding trees to RTL. */
currently_expanding_to_rtl = 0;
[Bug debug/48466] [4.4/4.5 Regression] Wrong variable locations at -O0 on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48466 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.04.06 20:41:29 Summary|[4.4/4.5/4.6 Regression]|[4.4/4.5 Regression] Wrong |Wrong variable locations at |variable locations at -O0 |-O0 on i686 |on i686 Ever Confirmed|0 |1 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-06 20:41:29 UTC --- Fixed for 4.6+ for now.
[Bug rtl-optimization/48455] [4.7 Regression] Huge code size regression for all ARM configurations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48455 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.06 20:46:33 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1
[Bug c++/48483] Construct from yourself w/o warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48483
--- Comment #2 from Lisp2D lisp2d at lisp2d dot net 2011-04-06 21:15:42 UTC
---
Try the next example, more close to my code:
#includeiostream
classA{
public:
inta;
A(intx):a(x){}
intTheInt(){returna;}
};
voidFunc(Aa){
std::cloga.a=a.astd::endl;}
intmain(void){
Aa(a.TheInt());
Func(a);}
g++ -O -Winit-self -obug -Wall -Wextra bug.cpp
no warning
[Bug tree-optimization/32691] fold *(float*)(complex_float_var) into REALPART_EXPRcomplex_float_var in when cfv is in a different statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32691 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2011-04-06 21:24:51 UTC --- This was fixed by commit at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26134#c9 .
[Bug tree-optimization/32691] fold *(float*)(complex_float_var) into REALPART_EXPRcomplex_float_var in when cfv is in a different statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32691 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug rtl-optimization/48389] [4.5/4.6/4.7 Regression] ICE: in make_edges, at cfgbuild.c:319 with -mtune=pentiumpro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48389 --- Comment #3 from Steven Bosscher steven at gcc dot gnu.org 2011-04-06 21:52:54 UTC --- OK, not quite. We somehow have a barrier _inside_ a basic block, and that's somehow a problem after the patch but not before?!
[Bug c++/48453] [C++0x] Invalid reference initialization via explicit conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48453 Jens Maurer jens.maurer at gmx dot net changed: What|Removed |Added CC||jens.maurer at gmx dot net --- Comment #3 from Jens Maurer jens.maurer at gmx dot net 2011-04-06 21:56:51 UTC --- Agreed. The wording in the standard should be fixed.
[Bug middle-end/48486] New: cfgexpand leaves BARRIERs at the end of basic blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48486 Summary: cfgexpand leaves BARRIERs at the end of basic blocks Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: ste...@gcc.gnu.org Consider this code, following the expansion of a gimple switch statement: (gdb) call debug_rtx_list(last, -7) (insn 594 593 595 (set (reg/f:DI 809) (label_ref:DI 598)) ../../../../trunk/libgcc/../gcc/config/soft-fp/divtf3.c:44 -1 (nil)) (insn 595 594 596 (set (reg:DI 810) (mem/u/c:DI (plus:DI (mult:DI (reg:DI 808) (const_int 8 [0x8])) (reg/f:DI 809)) [0 S8 A8])) ../../../../trunk/libgcc/../gcc/config/soft-fp/divtf3.c:44 -1 (nil)) (jump_insn 596 595 597 (parallel [ (set (pc) (reg:DI 810)) (use (label_ref 598)) ]) ../../../../trunk/libgcc/../gcc/config/soft-fp/divtf3.c:44 -1 (nil)) (barrier 597 596 598) (code_label 598 597 599 46 [0 uses]) (jump_insn 599 598 600 (addr_vec:DI [ (label_ref:DI 0) (label_ref:DI 0) (label_ref:DI 0) (label_ref:DI 0) (label_ref:DI 0) (label_ref:DI 0) (label_ref:DI 0) (label_ref:DI 0) (label_ref:DI 0) (label_ref:DI 0) (label_ref:DI 0) (label_ref:DI 0) (label_ref:DI 0) (label_ref:DI 0) (label_ref:DI 0) (label_ref:DI 0) ]) ../../../../trunk/libgcc/../gcc/config/soft-fp/divtf3.c:44 -1 (nil)) (barrier 600 599 0) At this point: (gbd) p debug_rtx (get_last_insn()) (barrier 600 599 0) $24 = void Now cfgexpand tries to avoid having BARRIERs at the end of a basic block because that is, well, wrong to have. So: /* Find the block tail. The last insn in the block is the insn before a barrier and/or table jump insn. */ last = get_last_insn (); if (BARRIER_P (last)) last = PREV_INSN (last); if (JUMP_TABLE_DATA_P (last)) last = PREV_INSN (PREV_INSN (last)); BB_END (bb) = last; (gdb) p debug_rtx(last) (barrier 597 596 598) $25 = void (gdb)
[Bug middle-end/48486] cfgexpand leaves BARRIERs at the end of basic blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48486 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.04.06 22:09:35 Blocks||48389 AssignedTo|unassigned at gcc dot |steven at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Steven Bosscher steven at gcc dot gnu.org 2011-04-06 22:09:35 UTC --- Found while looking into a way to fix bug 48389 without having two calls of rebuild_jump_labels(). Mine.
[Bug middle-end/48377] [4.6 regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #10 from Matt Hargett matt at use dot net 2011-04-06 22:22:41 UTC
---
I do see the alignment problem you point out (though I'm disappointed that
neither PC-Lint nor GCC's warnings alerted me). I made the changes you
proposed, but still get the same crash:
typedef uint32_t unaligned_uint32_t __attribute__((__aligned__
(1),__may_alias__));
// ...
static inline uint32_t
Hashcode( const char* s, uint32_t len, bool case_insensitive)
{
const unaligned_uint32_t* wordp = (const unaligned_uint32_t*)s;
// ...
}
==30742== Process terminating with default action of signal 11 (SIGSEGV)
==30742== General Protection Fault
==30742==at 0x400F38: TE_Field_id::Initialize_token_maps()
(hashmap.hpp:672)
==30742==by 0x4017A8: main (te_main.cpp:5)
It crashes on the same line (with or without valgrind):
hash += *wordp++ 0xdfdfdfdf;
For grins, I initialized the hash variable and cast the 0xdfdfdfdf constant to
unaligned_uint32_t as well, but the problem persists. I did verify that
removing -ftree-vectorize alone does fix the eliminate the crash;
-O2 -finline-functions -funswitch-loops -fpredictive-commoning
-fgcse-after-reload -fipa-cp-clone -ftree-loop-distribute-patterns
-ftree-slp-vectorize does not crash.
So, is there a bug in the annotations you suggested? Is there any other easy
workaround besides disabling the optimization on this function?
Very sincerely, thanks for working with me on this issue! :)
[Bug libstdc++/38875] parallel fill and copy in the parallel version of libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875 --- Comment #16 from Paolo Carlini paolo.carlini at oracle dot com 2011-04-06 22:25:44 UTC --- Johannes, I lost a bit track of this enhancement PR: what do you think, now that we are again in Stage 1 in mainline, are there chances we can resolve it somehow? Is there something I can do to help?
[Bug c++/48483] Construct from yourself w/o warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48483
Dmitry Gorbachev d.g.gorbachev at gmail dot com changed:
What|Removed |Added
CC||d.g.gorbachev at gmail dot
||com
--- Comment #3 from Dmitry Gorbachev d.g.gorbachev at gmail dot com
2011-04-06 22:38:20 UTC ---
Simpler testcase:
int main(void)
{
struct S { int a; } s;
return s.a;
}
It's a regression (latest working version is 4.4). I think there is a duplicate
PR somewhere.
[Bug middle-end/48486] cfgexpand leaves BARRIERs at the end of basic blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48486
--- Comment #2 from Steven Bosscher steven at gcc dot gnu.org 2011-04-06
22:38:51 UTC ---
find_many_sub_basic_blocks breaks its own STATE:
Breakpoint 6, find_many_sub_basic_blocks (blocks=0x19b6ea0) at
../../trunk/gcc/cfgbuild.c:577
577 SET_STATE (bb,
(gdb) p bb
$24 = (basic_block) 0x770d1f08
(gdb) watch ((basic_block) 0x770d1f08)-aux
Hardware watchpoint 9: ((struct basic_block_def *) 140737338220296)-aux
(gdb) cont
Continuing.
Hardware watchpoint 9: ((struct basic_block_def *) 140737338220296)-aux
Old value = (void *) 0x0
New value = (void *) 0x2
find_many_sub_basic_blocks (blocks=0x19b6ea0) at ../../trunk/gcc/cfgbuild.c:576
576 FOR_EACH_BB (bb)
(gdb) cont
Continuing.
Hardware watchpoint 9: ((struct basic_block_def *) 140737338220296)-aux
Old value = (void *) 0x2
New value = (void *) 0x22
mark_tablejump_edge (label=0x76fdb000) at ../../trunk/gcc/cfgbuild.c:391
391 }
(gdb) l cfgbuild.c:577
572 find_many_sub_basic_blocks (sbitmap blocks)
573 {
574 basic_block bb, min, max;
575
576 FOR_EACH_BB (bb)
577 SET_STATE (bb,
578TEST_BIT (blocks, bb-index) ? BLOCK_TO_SPLIT :
BLOCK_ORIGINAL);
579
580 FOR_EACH_BB (bb)
581 if (STATE (bb) == BLOCK_TO_SPLIT)
(gdb) l cfgbuild.c:391
386 /* See comment in make_label_edge. */
387 if (INSN_UID (label) == 0)
388 return;
389 bb = BLOCK_FOR_INSN (label);
390 SET_STATE (bb, FULL_STATE (bb) | BLOCK_USED_BY_TABLEJUMP);
391 }
392
393 static void
394 purge_dead_tablejump_edges (basic_block bb, rtx table)
395 {
(gdb)
(gdb) cont
Continuing.
Breakpoint 7, find_many_sub_basic_blocks (blocks=0x19b6ea0) at
../../trunk/gcc/cfgbuild.c:581
581 if (STATE (bb) == BLOCK_TO_SPLIT)
(gdb) p STATE(bb)
$25 = 34
(gdb)
[Bug lto/48447] LTO link fails to link libgcc correctly when -nostdlib option is specified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48447 --- Comment #4 from Patrick Oppenlander patrick at motec dot com.au 2011-04-06 22:47:12 UTC --- (In reply to comment #3) For now, option -Wl,-plugin-opt=-pass-through=$(LIBGCC) can be manually added to the command line (as discussed in PR42690). That does seem to work for now. Does that mean this is a duplicate?
[Bug rtl-optimization/48389] [4.5/4.6/4.7 Regression] ICE: in make_edges, at cfgbuild.c:319 with -mtune=pentiumpro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48389 --- Comment #4 from Jeffrey A. Law law at redhat dot com 2011-04-06 22:51:26 UTC --- -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/06/11 15:52, steven at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48389 --- Comment #3 from Steven Bosscher steven at gcc dot gnu.org 2011-04-06 21:52:54 UTC --- OK, not quite. We somehow have a barrier _inside_ a basic block, and that's somehow a problem after the patch but not before?! I tried to warn you that it wasn't as easy as just moving hte call to rebuild_jump_labels :-) jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNnO5iAAoJEBRtltQi2kC7y1kH/R+nRv2iL79CgbPFxWYBTX44 6Fb7f72e6VdymlXu3xOSvkQ3em+4AdWzjay9o5UWRIQSFUuFgS41Yc9z/UR0uqQd OVwdX56kDFJaDfCX0XLjtddjiMN2js2jxiiXlGr1nq2sprWGFEabRxSmU6KqhN+Z hdrXH18h2nOe9KjVfshZrUgM80UxhykorjuWo7d+TBwARU21C051OSRwvAYr7I3o anYEBBzAvw2RzRyyUOVzVi24ErTyY+ZIn2wXJp9mIJmHKsdZMZCzYz4RGLysmnw5 gyzR6NsOU6st0K4SsLSqMWBIBddP5QI5Z+wEMiYUiu7Qto8lC3uE8xE3Edf7ja8= =2qbJ -END PGP SIGNATURE-
