[Bug c++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314 Richard Guenther changed: What|Removed |Added CC|rguenther at suse dot de| Component|regression |c++ Target Milestone|--- |4.8.0 Summary|undefined references to |[4.8 Regression] undefined |'construction vtable for|references to 'construction |std::ostream-in-std::basic_ |vtable for |ostringstream, |ostringstream >' |std::char_traits, ||std::allocator >' --- Comment #2 from Richard Guenther 2012-08-20 07:00:27 UTC --- Can you identify the commit that caused this?
[Bug middle-end/54327] [4.8 Regression] Segmentation fault in init_ggc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54327 Richard Guenther changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #4 from Richard Guenther 2012-08-20 07:17:02 UTC --- Mine.
[Bug other/54324] [4.8 Regression] GCC install document does not list minimum required g++ version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54324 Richard Guenther changed: What|Removed |Added Keywords||documentation Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-20 Target Milestone|--- |4.8.0 Summary|GCC install document does |[4.8 Regression] GCC |not list minimum required |install document does not |g++ version |list minimum required g++ ||version Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-08-20 07:18:51 UTC --- Confirmed. Marked as regression to be on the radar.
[Bug target/54246] Bytemark FOURIER 54% slower with glibc 2.16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54246 Richard Guenther changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #3 from Richard Guenther 2012-08-20 07:20:31 UTC --- Thus, invalid here.
[Bug tree-optimization/54317] [4.8 Regression] FAIL: c45532m c45532n c45532o c45532p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54317 Richard Guenther changed: What|Removed |Added CC||glisse at gcc dot gnu.org Target Milestone|--- |4.8.0
[Bug c++/54328] capture pointer by value is not correct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54328 --- Comment #1 from Jonathan Wakely 2012-08-20 07:24:38 UTC --- 'a' isn't a pointer, it's an array, so the closure has a copy of the array and a[0] = 2 doesn't alter the closure's copy.
[Bug lto/54312] uniquify_nodes takes 12% of Mozilla LTO build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54312 --- Comment #1 from Richard Guenther 2012-08-20 07:29:00 UTC --- I don't see how we can do better. Or well, we can put in an assert instead (we stream TYPE_NEXT_VARIANT as NULL). #ifdef ENABLE_CHECKING if (TYPE_MAIN_VARIANT (t) != t) { tem = TYPE_MAIN_VARIANT (t); while (tem && TYPE_NEXT_VARIANT (tem) != t) tem = TYPE_NEXT_VARIANT (tem); gcc_assert (!tem && !TYPE_NEXT_VARIANT (t)); } #endif
[Bug c++/54328] capture pointer by value is not correct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54328 --- Comment #2 from yaoyuan1216 at gmail dot com 2012-08-20 07:38:18 UTC --- (In reply to comment #1) > 'a' isn't a pointer, it's an array, so the closure has a copy of the array and > a[0] = 2 doesn't alter the closure's copy. Thanks for your reply. You are absolutely right and I'm glad that it is my mistake instead of gcc.
[Bug c++/54328] capture pointer by value is not correct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54328 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #3 from Jakub Jelinek 2012-08-20 07:45:21 UTC --- Invalid then.
[Bug other/54326] GCC does not build with G++ version 3.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54326 --- Comment #2 from Richard Guenther 2012-08-20 07:49:47 UTC --- Author: rguenth Date: Mon Aug 20 07:49:41 2012 New Revision: 190524 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190524 Log: 2012-08-20 Richard Guenther PR bootstrap/54326 * genoutput.c (note_constraint): Properly use CONST_CAST. Modified: trunk/gcc/ChangeLog trunk/gcc/genoutput.c
[Bug bootstrap/54326] GCC does not build with G++ version 3.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54326 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|other |bootstrap Resolution||FIXED --- Comment #3 from Richard Guenther 2012-08-20 07:59:30 UTC --- Fixed(?).
[Bug bootstrap/54326] GCC does not build with G++ version 3.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54326 --- Comment #4 from Paul H. Hargrove 2012-08-20 08:22:18 UTC --- (In reply to comment #3) > Fixed(?). YES. I was the one to originally observe the failure. Just svn-uped to revision 190524 and was able to build stage1 with g++-3.4.0.
[Bug middle-end/54327] [4.8 Regression] Segmentation fault in init_ggc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54327 --- Comment #5 from Richard Guenther 2012-08-20 08:53:13 UTC --- The issue is that we now merge two blocks we didn't merge before which introduces SSA names into a STMT that are marked for update (thus, in old_ssa_names): : # a_12 = PHI <0B(3)> _13 = *a_1; _14 = (int) _4; _15 = _4 == 0; _16 = (int) _6; goto ; : # a_11 = PHI _9 = strlen (a_11); if (_9 <= 1) goto ; else goto ; a_1 is marked to be replaced by a_12, block merging from CFG cleanup (called via TODO, which calls CFG cleanup before updating SSA form ...) now replaces a_11 with a_1 in _9 = strlen (a_11) via replace_uses_by which ends up folding the stmt (but a_1 has a dead DEF stmt). update_ssa only needs unreachable blocks removed to make DOM info computable. So this might be solved by re-ordering cfgcleanup/SSA update in the TODO. OTOH passes registering things for manual SSA update should eventually call update_ssa themselves, not relying on TODO (in this case it is jump threading from DOM). OTOH calling into SSA def stmt walking folders from this situation is bad, the folding in question is gimple_fold_builtin calling get_maxval_strlen (which may even result in wrong-code with a non-up-to-date SSA form). So the bug IMHO is fold_stmt walking SSA def stmts.
[Bug target/54308] [4.8 regression] build regression in 190498 on ppc64/linux: legitimate_indirect_address_p undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54308 --- Comment #8 from Paul H. Hargrove 2012-08-20 08:57:29 UTC --- (In reply to comment #7) [...] > Ok, but see comment 4; try just removing the "inline" there. If necessary, > the > inline can be wrapped in some #ifdef construct. It depends on the maintainer > to deem it acceptable of course. I tried removing the "inline" keyword as suggested, from revision 190524 if it matters. I then attempted to build stage1 using gcc-4.1.2, just as I had originally. I was able to build stage w/o any problems with just that 1-word change.
[Bug c++/52026] [c++0x] g++: Constexpr Variable Appears Uninitialized in Lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52026 --- Comment #9 from Paolo Carlini 2012-08-20 09:07:26 UTC --- That's a big problem if you are serious about contributing to gcc. See: http://gcc.gnu.org/contribute.html In short, if you don't want to waste time, make sure to obtain, fill and return the forms before sending patches.
[Bug middle-end/54321] [4.8 Regression] ice in tree_low_cst at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54321 --- Comment #4 from Jakub Jelinek 2012-08-20 09:12:11 UTC --- Author: jakub Date: Mon Aug 20 09:12:05 2012 New Revision: 190526 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190526 Log: PR tree-optimization/54321 * tree-ssa-forwprop.c (simplify_builtin_call): Pass 0 instead of 1 as second argument to tree_low_cst call on val2. * gcc.c-torture/compile/pr54321.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr54321.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-forwprop.c
[Bug middle-end/54321] [4.8 Regression] ice in tree_low_cst at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54321 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Jakub Jelinek 2012-08-20 09:14:54 UTC --- Fixed.
[Bug fortran/54195] [4.8 Regression][OOP] IMPORT fails with GENERIC TBP: "is already present in the interface"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54195 --- Comment #8 from janus at gcc dot gnu.org 2012-08-20 09:45:15 UTC --- A similar test case (also a regression) was reported by Andrew Benson at http://gcc.gnu.org/ml/fortran/2012-08/msg00101.html: module gn implicit none type :: nc contains procedure :: assign => nca generic :: assignment(=) => assign end type type, extends(nc) :: ncb contains procedure , nopass :: tis => bf end type contains subroutine nca(to,from) class(nc), intent(out) :: to type(nc), intent(in) :: from end subroutine logical function bf() bf=.false. end function end module This fails with: generic :: assignment(=) => assign 1 Error: Entity 'nca' at (1) is already present in the interface
[Bug target/54212] ARM: invalid instruction (vdupeq.32) generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54212 --- Comment #4 from Ramana Radhakrishnan 2012-08-20 10:18:41 UTC --- Author: ramana Date: Mon Aug 20 10:18:36 2012 New Revision: 190527 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190527 Log: Fix PR target/54212 2012-08-20 Ramana Radhakrishnan Backport from mainline. 2012-08-15 Ramana Radhakrishnan PR target/54212 * config/arm/neon.md (vec_set_internal VD,VQ): Do not mark as predicable. Adjust asm template. (vec_setv2di_internal): Likewise. (vec_extract VD, VQ): Likewise. (vec_extractv2di): Likewise. (neon_vget_lane_sext_internal VD, VQ): Likewise. (neon_vset_lane_sext_internal VD, VQ): Likewise. (neon_vdup_n VX, V32): Likewise. (neon_vdup_nv2di): Likewise. Modified: branches/gcc-4_7-branch/ (props changed) branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/arm/neon.md Propchange: branches/gcc-4_7-branch/ ('svn:mergeinfo' modified)
[Bug middle-end/54327] [4.8 Regression] Segmentation fault in init_ggc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54327 --- Comment #6 from Richard Guenther 2012-08-20 10:26:52 UTC --- Author: rguenth Date: Mon Aug 20 10:26:45 2012 New Revision: 190528 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190528 Log: 2012-08-20 Richard Guenther PR tree-optimization/54327 * gimple-fold.c (get_maxval_strlen): Do not walk use-def chains if the use is registered for SSA update. * gcc.dg/torture/pr54327.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr54327.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog
[Bug c++/31952] parameters may be redeclared in a function try-block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31952 Paolo Carlini changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org |janis at gcc dot gnu.org --- Comment #6 from Paolo Carlini 2012-08-20 10:29:11 UTC --- Comment #2 is PR5605. Comparing to Janis' fix for PR2288 (http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00838.html) looks like the pushdecl_maybe_friend_1 checks must be beefed up, maybe we need an additional sk_* for Comment #2. Seems doable. Adding Janis in CC in case she wants to beat me (or somebody else) on this.
[Bug c++/5605] name of caught object redeclared (c.f. 3.3.2/3)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5605 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED CC||paolo.carlini at oracle dot ||com Resolution||DUPLICATE --- Comment #7 from Paolo Carlini 2012-08-20 10:40:59 UTC --- Per Comment #5 this is identical to Comment #2 of PR31952. *** This bug has been marked as a duplicate of bug 31952 ***
[Bug c++/31952] parameters may be redeclared in a function try-block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31952 Paolo Carlini changed: What|Removed |Added CC||cs at plesk dot com --- Comment #7 from Paolo Carlini 2012-08-20 10:40:59 UTC --- *** Bug 5605 has been marked as a duplicate of this bug. ***
[Bug c++/6273] [DR 502] Dependency of nested enumerations and enumerators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6273 Paolo Carlini changed: What|Removed |Added Status|SUSPENDED |NEW CC|gcc-bugs at gcc dot gnu.org | --- Comment #15 from Paolo Carlini 2012-08-20 10:51:47 UTC --- Unsuspended.
[Bug c++/8966] [Alpha OSF5.1] Lost exceptions across library boundaries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8966 Paolo Carlini changed: What|Removed |Added Status|SUSPENDED |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Known to work||4.5.0 Resolution||FIXED --- Comment #11 from Paolo Carlini 2012-08-20 11:01:31 UTC --- At this point, I think we can safely close this as fixed in 4.5.
[Bug c++/9666] Argument used as expression in a new-declarator does not get implicitly converted to integral type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9666 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.6.2, 4.7.1, 4.8.0 Resolution||FIXED --- Comment #4 from Paolo Carlini 2012-08-20 11:10:26 UTC --- Fixed long time ago, apparently.
[Bug middle-end/54327] [4.8 Regression] Segmentation fault in init_ggc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54327 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Richard Guenther 2012-08-20 11:10:57 UTC --- Fixed.
[Bug c++/10112] static data member is not correctly initialised
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10112 Paolo Carlini changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org | --- Comment #18 from Paolo Carlini 2012-08-20 11:14:20 UTC --- Jason, should this really be in status, or something else?
[Bug bootstrap/54329] New: gcc/reginfo.o differs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54329 Bug #: 54329 Summary: gcc/reginfo.o differs Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com gcc 4.8 0adffe7816495b961a1bab85eaaf7bcea85ed2a8 gcc/reginfo.o differs gcc/ira.o differs make[2]: *** [compare] Error 1
[Bug bootstrap/54329] gcc/reginfo.o differs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54329 --- Comment #1 from wbrana 2012-08-20 11:20:33 UTC --- Created attachment 28055 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28055 build log
[Bug bootstrap/54329] gcc/reginfo.o differs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54329 Richard Guenther changed: What|Removed |Added Target||x86_64-*-* --- Comment #2 from Richard Guenther 2012-08-20 11:42:24 UTC --- Please always fill in the target field and in the initial description provide the full configure command you use.
[Bug c++/10416] 'unused variable' warning ignores ctor/dtor side-effects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10416 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED CC|gcc-bugs at gcc dot gnu.org | AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.8.0 --- Comment #11 from Paolo Carlini 2012-08-20 11:50:38 UTC --- For the new Wunused_but_set_variable warning, handled nearby, we actually check: && (!CLASS_TYPE_P (TREE_TYPE (decl)) || !TYPE_HAS_NONTRIVIAL_DESTRUCTOR (TREE_TYPE (decl Doing the same for Wunused_variable too looks like progress to me.
[Bug bootstrap/54329] gcc/reginfo.o differs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54329 --- Comment #3 from wbrana 2012-08-20 12:04:05 UTC --- configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-pre --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-pre/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-pre/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-lto --disable-nls --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --enable-multilib --with-multilib-list=m32,m64 --with-arch=core2 --with-tune=core2 --disable-plugin --disable-libmudflap --disable-libssp --disable-libgomp --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre999 9/python --enable-checking=release --disable-libgcj --disable-build-with-cxx --disable-build-poststage1-with-cxx --disable-libquadmath --enable-languages=c --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion=Gentoo 4.8.0_pre CFLAGS="-O2 -O3 -pipe -march=core2 -mtune=core2 -fomit-frame-pointer -funroll-loops --param max-unrolled-insns=64" CXXFLAGS="-O2 -O3 -pipe -march=core2 -mtune=core2 -fomit-frame-pointer -funroll-loops --param max-unrolled-insns=64"
[Bug c++/54309] [C++11] type alias accessing class template typename
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54309 --- Comment #4 from dodji at seketeli dot org 2012-08-20 12:10:27 UTC --- I think this is the same problem as PR c++/53540 for which a candidate patch was sent to the gcc-patches mailing list [1]. So unless I am mistaken, I am marking this bug as a duplicate of the former. [1]: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg0.html
[Bug c++/54309] [C++11] type alias accessing class template typename
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54309 --- Comment #5 from Paolo Carlini 2012-08-20 12:12:44 UTC --- Ah great, I suspected that.
[Bug target/54257] gcc.target/i386/pr53249.c failure at -m64 on x86_64-apple-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54257 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-20 Ever Confirmed|0 |1 --- Comment #2 from Dominique d'Humieres 2012-08-20 12:13:35 UTC --- I got rid of the error with the following patch --- /opt/gcc/_clean/gcc/testsuite/gcc.target/i386/pr53249.c2012-05-09 15:56:54.0 +0200 +++ /opt/gcc/work/gcc/testsuite/gcc.target/i386/pr53249.c2012-06-23 14:30:38.0 +0200 @@ -1,4 +1,4 @@ -/* { dg-do compile { target { ! { ia32 } } } } */ +/* { dg-do compile { target { { ! { ia32 } } && { ! *-*-darwin* } } } } */ /* { dg-options "-O2 -mx32 -ftls-model=initial-exec -maddress-mode=short" } */ struct gomp_task AFAICT -mx32 is not supported on darwin.
[Bug target/54255] FAIL: gcc.target/i386/asm-dialect-1.c (test for excess errors) fails on x86_64/i686 darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54255 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-20 Ever Confirmed|0 |1 --- Comment #2 from Dominique d'Humieres 2012-08-20 12:18:19 UTC --- Confirmed. The test should be skipped on darwin.
[Bug debug/54251] FAIL: g++.dg/debug/dwarf2/nested-4.C -std=gnu++[98,11] scan-assembler-times debug_types 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54251 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-20 Ever Confirmed|0 |1 --- Comment #2 from Dominique d'Humieres 2012-08-20 12:22:13 UTC --- Confirmed.
[Bug debug/54230] g++.dg/debug/dwarf2/pubnames-2.C failures on darwin12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54230 Dominique d'Humieres changed: What|Removed |Added Target|x86_64-apple-darwin12 |x86_64-apple-darwin* Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-20 Host|x86_64-apple-darwin12 |x86_64-apple-darwin* Ever Confirmed|0 |1 Build|x86_64-apple-darwin12 |x86_64-apple-darwin* --- Comment #1 from Dominique d'Humieres 2012-08-20 12:36:58 UTC --- Confirmrd, see http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00386.html
[Bug tree-optimization/54295] [4.7/4.8 regression] Widening multiply-accumulate operation uses wrong value extension
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54295 --- Comment #3 from Richard Earnshaw 2012-08-20 12:49:55 UTC --- Author: rearnsha Date: Mon Aug 20 12:49:47 2012 New Revision: 190533 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190533 Log: PR tree-ssa/54295 * tree-ssa-math-opts.c (widening_mult_conversion_strippable_p): New function. (is_widening_mult_rhs_p): Use it. * gcc.c-torture/execute/20120817-1.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20120817-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-math-opts.c
[Bug bootstrap/54209] [4.8 Regression] Failed to build gcc for Android/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54209 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #6 from H.J. Lu 2012-08-20 14:02:52 UTC --- link.h has been added to AOSP.
[Bug debug/53135] [4.7/4.8 Regression] internal compiler error: in value_format, at dwarf2out.c:8010
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53135 --- Comment #9 from Jakub Jelinek 2012-08-20 14:03:39 UTC --- Alex, the patch is ok for trunk and 4.7 branch. That said, with similar code just appearing not in call site parameter, but in a .debug_loc section we'd ICE anyway, as .debug_loc has a hard limit of 64K, and furthermore we should do a better job on this testcase, instead of creating such a huge expression which keeps recomputing the same values again and again introduce some kind of temporaries in the expression, if some expression occurs more than a few times, compute it into a temporary first (on the DWARF stack) and then just pick it when needed, drop at the end.
[Bug other/54330] New: Wrong optimization for code from fixed-bit.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54330 Bug #: 54330 Summary: Wrong optimization for code from fixed-bit.c Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org Host: i686-pc-linux-gnu Target: avr Build: i686-pc-linux-gnu Created attachment 28056 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28056 fixed-bit-bug.c: preprocessed bit for fixed.bit.c::__satfractudadq This is a wrong code bug seen while implementing the ISO/IED TR18037 fixed-point support for AVR. == compile == $ avr-gcc fixed-bit-bug.c -mmcu=atmega128 -Os -S -fdump-rtl-expand-details == configure == $ ../../gcc.gnu.org/trunk/configure --target=avr --prefix=/local/gnu/install/gcc-4.8 --disable-nls --with-dwarf2 --enable-target-optspace=yes --enable-languages=c,c++ == Bug == The .expand dump contains a wrong insn, a GTU branch instead of a LEU branch: The code tests if the high bit of a shift result is set by comparing > 0x7fff. If the value is less-or-equal, the saturation against 0 must be skipped (goto #76), but the GTU leads to a reversal of the condition. The block that saturates is BB6: (insn 104 103 105 5 (parallel [ (set (cc0) (compare (reg:DI 18 r18) (const_double -1 [0x] 2147483647 [0x7fff] 0 [0] 0 [0] 0 [0] 0 [0]))) (clobber (scratch:QI)) ]) fixed-bit-bug.c:56 -1 (nil)) (jump_insn 105 104 132 5 (set (pc) (if_then_else (gtu (cc0) (const_int 0 [0])) (label_ref 76) (pc))) fixed-bit-bug.c:56 -1 (expr_list:REG_BR_PROB (const_int 6100 [0x17d4]) (nil)) -> 76) (note 132 105 29 6 [bb 6] NOTE_INSN_BASIC_BLOCK) (insn 29 132 21 6 (clobber (reg/v:DI 42 [ low ])) fixed-bit-bug.c:56 -1 (nil)) (insn 21 29 22 6 (set (subreg:QI (reg/v:DI 42 [ low ]) 0) (const_int 0 [0])) fixed-bit-bug.c:56 -1 (nil)) All of the following changes lead to correct code, u.e. LEU instead of GTU: * -O1 instead of -O0 * -fno-builtin-memcpy * Using DI mode instead of DQ resp. DA mode, see the respective #define in the attaches test case. Correct code will look like that: (jump_insn 91 90 132 4 (set (pc) (if_then_else (leu (cc0) (const_int 0 [0])) (label_ref:HI 102) (pc))) 444 {difficult_branch} (expr_list:REG_BR_PROB (const_int 5000 [0x1388]) (nil)) -> 102) (note 132 91 100 5 [bb 5] NOTE_INSN_BASIC_BLOCK) (insn 100 132 92 5 (clobber (reg/v:DI 42 [ low ])) -1 (nil)) (insn 92 100 93 5 (set (subreg:QI (reg/v:DI 42 [ low ]) 0) (const_int -1 [0x])) -1 (nil))
[Bug other/54330] Wrong optimization for code from fixed-bit.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54330 --- Comment #1 from Georg-Johann Lay 2012-08-20 14:11:30 UTC --- Created attachment 28057 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28057 fixed-bit-bug.c.150r.expand: Correct code if DI used instead of DQ/DA
[Bug tree-optimization/54295] [4.7/4.8 regression] Widening multiply-accumulate operation uses wrong value extension
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54295 --- Comment #4 from Richard Earnshaw 2012-08-20 14:13:40 UTC --- Author: rearnsha Date: Mon Aug 20 14:13:16 2012 New Revision: 190534 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190534 Log: PR tree-ssa/54295 * tree-ssa-math-opts.c (is_widening_mult_rhs_p): Delete rhs_code declaration and setter. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-math-opts.c
[Bug other/54330] Wrong optimization for code from fixed-bit.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54330 --- Comment #2 from Georg-Johann Lay 2012-08-20 14:15:51 UTC --- Created attachment 28058 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28058 fixed-bit-bug.c.150r.expand: Wrong code
[Bug other/54330] Wrong optimization for code from fixed-bit.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54330 --- Comment #3 from Georg-Johann Lay 2012-08-20 14:22:46 UTC --- FYI, there is the fixed-point configuration output from ... -E -dM | egrep '(DQ)|(DA)|([^L]LACC)|(LLFRA)' | sort DImode (long long) is 64 bits #define __DA_FBIT__ 32 #define __DA_IBIT__ 31 #define __DQ_FBIT__ 63 #define __DQ_IBIT__ 0 #define __LACCUM_EPSILON__ 0x1P-32LK #define __LACCUM_FBIT__ 32 #define __LACCUM_IBIT__ 31 #define __LACCUM_MAX__ 0X7FFFP-32LK #define __LACCUM_MIN__ (-0X1P30LK-0X1P30LK) #define __LLFRACT_EPSILON__ 0x1P-63LLR #define __LLFRACT_FBIT__ 63 #define __LLFRACT_IBIT__ 0 #define __LLFRACT_MAX__ 0X7FFFP-63LLR #define __LLFRACT_MIN__ (-0.5LLR-0.5LLR) #define __UDA_FBIT__ 32 #define __UDA_IBIT__ 32 #define __UDQ_FBIT__ 64 #define __UDQ_IBIT__ 0 #define __ULACCUM_EPSILON__ 0x1P-32ULK #define __ULACCUM_FBIT__ 32 #define __ULACCUM_IBIT__ 32 #define __ULACCUM_MAX__ 0XP-32ULK #define __ULACCUM_MIN__ 0.0ULK #define __ULLFRACT_EPSILON__ 0x1P-64ULLR #define __ULLFRACT_FBIT__ 64 #define __ULLFRACT_IBIT__ 0 #define __ULLFRACT_MAX__ 0XP-64ULLR #define __ULLFRACT_MIN__ 0.0ULLR
[Bug c/54162] Please accept static global anonymous unions or structs as an extension
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54162 Josh Triplett changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | Summary|Does not accept static |Please accept static global |global anonymous unions or |anonymous unions or structs |structs |as an extension --- Comment #3 from Josh Triplett 2012-08-20 14:50:35 UTC --- How odd. Quite a number of sources seem to suggest that C11 allows this. But in any case, several other compilers *do* allow this syntax; thus, reopening this and turning it into a request for an extension.
[Bug c/54331] New: configure: error: C++ compiler missing or inoperational
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54331 Bug #: 54331 Summary: configure: error: C++ compiler missing or inoperational Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: michael.a.richm...@nasa.gov Host: i686-pc-linux-gnu Target: i686-pc-linux-gnu Build: i686-pc-linux-gnu When I attempt to compile the snapshot of 08/19/2012 on openSuSE Linux 12.1 I get the following error message: configure: error: C++ compiler missing or inoperational The error does not occur in the snapshot of 08/12/2012
[Bug target/54212] ARM: invalid instruction (vdupeq.32) generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54212 Ramana Radhakrishnan changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Ramana Radhakrishnan 2012-08-20 14:58:13 UTC --- Now fixed.
[Bug c/54331] configure: error: C++ compiler missing or inoperational
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54331 --- Comment #1 from Jonathan Wakely 2012-08-20 15:00:39 UTC --- GCC now requires a C++ compiler to build.
[Bug c++/54213] please help to determine whether it is an PostgreSQL error or GCC error (combobox and SQL data sorting)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54213 --- Comment #7 from Denis Kolesnik 2012-08-20 15:12:04 UTC --- (In reply to comment #4) > Have you tried to reduce the problem to a simple source file where you only > call the PostgreSQL functions? Try that and see what happens. Right now your > source is huge and dependent on files most people here don't have access to. I did try to make my program to look more compact, but anyway I find my code beautiful.
[Bug c++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314 --- Comment #3 from gee 2012-08-20 15:21:53 UTC --- --export-all-symbols didn't work at all. pick-reverting just one commit failed with conflict. [966](sec 86)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x Contents of section .rdata$_ZNSt14numeric_limitsIdE14min_exponent10E: cdfe following is one of the symbol that linker failed to include in shared library. __ZNSt14numeric_limitsIdE14min_exponent10E .globl__ZNSt14numeric_limitsIdE14min_exponent10E .section.rdata$_ZNSt14numeric_limitsIdE14min_exponent10E,"dr" .align 4 __ZNSt14numeric_limitsIdE14min_exponent10E: .long-307
[Bug c/54331] configure: error: C++ compiler missing or inoperational
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54331 Michael Richmond changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Michael Richmond 2012-08-20 15:44:03 UTC --- I installed the C++ compiler and the problem is fixed
[Bug tree-optimization/54317] [4.8 Regression] FAIL: c45532m c45532n c45532o c45532p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54317 --- Comment #1 from Marc Glisse 2012-08-20 15:46:58 UTC --- Wow, I didn't expect that patch to break a multiplication test... It sounds like you have before and after compilers. Do you have tree-vrp dumps from both? (I would ask if a stage1 compiler fails too, to rule out miscompilation of the compiler, but I have no idea how ada works...) Is hwint 32 bits on this platform? I am looking for acats testresults from other such platforms in gcc-testresults but can't find them...
[Bug target/54300] [4.7/4.8 Regression] Erroneous optimization causes wrong Neon data management
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54300 --- Comment #2 from Eric Batut 2012-08-20 16:11:35 UTC --- (In reply to comment #1) Hi Richard Using "-O2 -fno-strict-aliasing" generates the exact same (incorrect) code. > Your testcase is quite convoluted but it looks you may be violating C > type-based aliasing rules. Thus, try -fno-strict-aliasing.
[Bug c++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314 --- Comment #4 from gee 2012-08-20 16:15:41 UTC --- (In reply to comment #3) > --export-all-symbols didn't work at all. > pick-reverting just one commit failed with conflict. > > > [966](sec 86)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x > Contents of section .rdata$_ZNSt14numeric_limitsIdE14min_exponent10E: > cdfe > > following is one of the symbol that linker failed to include in shared > library. > > __ZNSt14numeric_limitsIdE14min_exponent10E > .globl__ZNSt14numeric_limitsIdE14min_exponent10E > .section.rdata$_ZNSt14numeric_limitsIdE14min_exponent10E,"dr" > .align 4 > __ZNSt14numeric_limitsIdE14min_exponent10E: > .long-307 objdump -p src/.libs/cygstdc++-6.dll |grep "_ZNSt14numeric_limitsIdE14min_exponent10E" [1747] _ZNSt14numeric_limitsIdE14min_exponent10E 85 .rdata$_ZNSt14numeric_limitsIdE14min_exponent10E 0004 4644 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA above symbol was defined in dll, sorry for the noise. $ objdump -p src/.libs/cygstdc++-6.dll |grep "_ZTCSt13basic_fstreamIwSt11char_traitsIwEE0_St14basic_iostreamIwS1_E" 209 .rdata$_ZTCSt13basic_fstreamIwSt11char_traitsIwEE0_St14basic_iostreamIwS1_E 0040 bd14 2**5 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA, LINK_ONCE_SAME_SIZE (COMDAT __ZTCSt13basic_fstreamIwSt11char_traitsIwEE0_St14basic_iostreamIwS1_E 966) .globl __ZTCSt13basic_fstreamIwSt11char_traitsIwEE0_St14basic_iostreamIwS1_E .section .rdata$_ZTCSt13basic_fstreamIwSt11char_traitsIwEE0_St14basic_iostreamIwS1_E,"dr" .linkonce same_size .align 32 __ZTCSt13basic_fstreamIwSt11char_traitsIwEE0_St14basic_iostreamIwS1_E: .long136 only difference for both section is RELOC, LINK_ONCE_SAME_SIZE. and some symbol in section with reloc failed to export symbols within.
[Bug middle-end/53992] Combining -fopenmp and -fgnu-tm results in segfault or misbehaving binaries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53992 --- Comment #1 from pmarlier at gcc dot gnu.org 2012-08-20 16:22:26 UTC --- Author: pmarlier Date: Mon Aug 20 16:22:17 2012 New Revision: 190536 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190536 Log: gcc/ 2012-08-20 Patrick Marlier PR middle-end/53992 * omp-low.c (lower_omp_1): Handle GIMPLE_TRANSACTION. testsuite/ 2012-08-20 Patrick Marlier PR middle-end/53992 * gcc.dg/gomp/pr53992.c: New test. Added: trunk/gcc/testsuite/gcc.dg/gomp/pr53992.c Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/54317] [4.8 Regression] FAIL: c45532m c45532n c45532o c45532p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54317 --- Comment #2 from dave.anglin at bell dot net 2012-08-20 16:23:57 UTC --- On 8/20/2012 11:46 AM, glisse at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54317 > > --- Comment #1 from Marc Glisse 2012-08-20 > 15:46:58 UTC --- > Wow, I didn't expect that patch to break a multiplication test... > It sounds like you have before and after compilers. Do you have tree-vrp dumps > from both? (I would ask if a stage1 compiler fails too, to rule out > miscompilation of the compiler, but I have no idea how ada works...) At the moment, I have no idea as to which module is broken but I believe the problem is in the Ada runtime library. I compared the .o files for the first test of the four failing tests using before and after compilers and they were identical. The ada tests are not compiled with debugging enabled, so they are a bit difficult to debug. The tests invoke a lot of arithmetic operations... > Is hwint 32 bits on this platform? I am looking for acats testresults from > other such platforms in gcc-testresults but can't find them... > Yes, hwint is 32 bits. I just fixed a couple of issues with expand_mult (PR middle-end/53823). The synth_mult code can't handle multiplication by negative coefficients when the mode is larger than a hwint. One possibility might be that this code is being invoked by another path.
[Bug target/54257] gcc.target/i386/pr53249.c failure at -m64 on x86_64-apple-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54257 --- Comment #3 from Mike Stump 2012-08-20 16:24:49 UTC --- Looks good to me... HJ?
[Bug middle-end/53992] Combining -fopenmp and -fgnu-tm results in segfault or misbehaving binaries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53992 --- Comment #2 from pmarlier at gcc dot gnu.org 2012-08-20 16:25:34 UTC --- Author: pmarlier Date: Mon Aug 20 16:25:21 2012 New Revision: 190537 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190537 Log: gcc/ 2012-08-20 Patrick Marlier Backported from trunk 2012-08-20 Patrick Marlier PR middle-end/53992 * omp-low.c (lower_omp_1): Handle GIMPLE_TRANSACTION. testsuite/ 2012-08-20 Patrick Marlier Backported from trunk 2012-08-20 Patrick Marlier PR middle-end/53992 * gcc.dg/gomp/pr53992.c: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/gomp/pr53992.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/omp-low.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug target/54257] gcc.target/i386/pr53249.c failure at -m64 on x86_64-apple-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54257 --- Comment #4 from H.J. Lu 2012-08-20 16:27:26 UTC --- (In reply to comment #3) > Looks good to me... HJ? Looks good to me too.
[Bug c++/10416] 'unused variable' warning ignores ctor/dtor side-effects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10416 --- Comment #12 from paolo at gcc dot gnu.org 2012-08-20 17:39:00 UTC --- Author: paolo Date: Mon Aug 20 17:38:53 2012 New Revision: 190538 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190538 Log: /cp 2012-08-20 Paolo Carlini PR c++/10416 * decl.c (poplevel): Check TYPE_HAS_NONTRIVIAL_DESTRUCTOR for Wunused_variable too. /testsuite 2012-08-20 Paolo Carlini PR c++/10416 * g++.dg/warn/Wunused-var-17.C: New. Added: trunk/gcc/testsuite/g++.dg/warn/Wunused-var-17.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug c++/10416] 'unused variable' warning ignores ctor/dtor side-effects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10416 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #13 from Paolo Carlini 2012-08-20 17:40:25 UTC --- Fixed for 4.8.0.
[Bug fortran/54332] New: [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 Bug #: 54332 Summary: [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86-64, revision 190521 takes > 10 GB memory to compile 481.wrf in SPEC CPU 2006: gfortran -c -o module_domain.fppized.o -I. -I./netcdf/include -O3 -funroll-loops -ffast-math -frecord-marker=4 module_domain.fppized.f90
[Bug c++/54293] When a reference is bound to subobject of a temporary, lifetime of the temporary is not extended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54293 crowl at gcc dot gnu.org changed: What|Removed |Added CC||crowl at gcc dot gnu.org --- Comment #5 from crowl at gcc dot gnu.org 2012-08-20 18:14:32 UTC --- I think there is a compiler bug. The ruling text seems to be the first bullet of 8.5.3/5 and its first sub-bullet: - If the reference is an lvalue reference and the initializer expression - is an lvalue (but is not a bit-field), and "cv1 T1" is reference-compatible with "cv2 T2," or which matches the expression in the test case: const int& ref_int = ValueHolder().v; The lifetime is extended by 12.2/5 where none of the exceptions apply.
[Bug rtl-optimization/54294] [4.8 Regression]: [alpha] Bootstrap comparison failure due to fwprop handling of debug insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54294 --- Comment #9 from Jakub Jelinek 2012-08-20 18:56:58 UTC --- Author: jakub Date: Mon Aug 20 18:56:49 2012 New Revision: 190541 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190541 Log: PR rtl-optimization/54294 * fwprop.c (all_uses_available_at): Ignore debug insns in between def_insn and target_insn when checking whether the shortcut is possible. Modified: trunk/gcc/ChangeLog trunk/gcc/fwprop.c
[Bug rtl-optimization/54294] [4.8 Regression]: [alpha] Bootstrap comparison failure due to fwprop handling of debug insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54294 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Jakub Jelinek 2012-08-20 18:58:24 UTC --- Fixed.
[Bug middle-end/54146] Very slow compile with attribute((flatten))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 Steven Bosscher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #55 from Steven Bosscher 2012-08-20 19:30:34 UTC --- The remaining problem areas are all liveness calculation routines that are essentially inherent quadratic problems: DF liveness, IRA liveness, and out-of-SSA liveness. I think it would be good to deprecate the flatten attribute...
[Bug c/54303] -fdata-sections -ffunction-sections and -fmerge-constants do not work well together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 Mike Frysinger changed: What|Removed |Added CC||toolchain at gentoo dot org --- Comment #1 from Mike Frysinger 2012-08-20 19:31:54 UTC --- should update the Target field to reflect that this is for ARM
[Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54301 --- Comment #8 from Tobias Burnus 2012-08-20 19:49:53 UTC --- Author: burnus Date: Mon Aug 20 19:49:46 2012 New Revision: 190542 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190542 Log: 2012-08-20 Tobias Burnus PR fortran/54301 * expr.c (gfc_check_pointer_assign): Warn when a pointer, which is a function result, might outlive its target. 2012-08-20 Tobias Burnus PR fortran/54301 * gfortran.dg/warn_target_lifetime_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/warn_target_lifetime_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/53850] [4.8 Regression] ICE: in expand_call_tm, at trans-mem.c:2289 with -fgnu-tm -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53850 Patrick Marlier changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||patrick.marlier at gmail ||dot com --- Comment #1 from Patrick Marlier 2012-08-20 20:27:18 UTC --- expand_call_tm fails because the memset builtin has no node associated to the decl. The problem here is that between tmipa and tmmark passes, some stores are replaced by a memset. However tmipa is supposed to transform the memset builtin to TM-aware memset (_ITM_memsetW). The solution I see is to postpone transformation of these builtins in tmmark pass.
[Bug c++/54333] New: sprinf and fprintf work not always equal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54333 Bug #: 54333 Summary: sprinf and fprintf work not always equal Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: lirex.softw...@gmail.com Created attachment 28059 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28059 the c++ source file in the following part of the code: profit_tax_stream = fopen ("test_write.txt","w"); profit_tax_stream2 = fopen ("test2.txt","r"); //fputc(c, profit_tax_stream[0]); fprintf(profit_tax_stream, "testtest\" test 123"); strcpy(chBuffer,"\0"); //strcat(chBuffer," adsadasda"); fscanf(profit_tax_stream2,"%s", chBuffer); fprintf(profit_tax_stream,"%s", chBuffer); //fscanf(profit_tax_stream2, chBuffer); //fprintf(profit_tax_stream, chBuffer); //fprintf(profit_tax_stream[0], ""); fclose(profit_tax_stream); fclose(profit_tax_stream2); fscanf reads a portion of data delimited by space, but only when I use fscanf(profit_tax_stream2,"%s", chBuffer); but it reads nothing at all(I see nothing added to the file opened for write and also I tried to output the content of chBuffer via Messagebox) when I use fscanf(profit_tax_stream2, chBuffer); line of code instead. The problem is, that the "opposite" function fprintf works in both cases. My operation system is Windows XP HOME Edition OEM Service Pack 3 My compile line: c++ -I"D:\Program Files\PostgreSQL\9.1\include" -L"D:\Program Files\PostgreSQL\9.1\lib" -lpq -o %application_file% %application_file%.cpp -Wl,--subsystem,windows -lgdi32 -lcomctl32 -D_WIN32_IE=0x0300 -save-temps
[Bug bootstrap/54334] New: Unable to bootstrap using gcc 4.1.0 after cxx-conversion merge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54334 Bug #: 54334 Summary: Unable to bootstrap using gcc 4.1.0 after cxx-conversion merge Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: rmansfi...@qnx.com Host: i686-unknown-linux-gnu Target: i686-unknown-linux-gnu Build: i686-unknown-linux-gnu Created attachment 28060 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28060 configure and build log I've read on the ML that others have had issues and that fixes went in, and it was working. But I'm still not able to bootstrap with rev 190543. g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc -I../../gcc/build -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber \ -o build/genflags.o ../../gcc/genflags.c cc1: warning: command line option "-fno-rtti" is valid for C++/ObjC++ but not for C In file included from ../../gcc/rtl.h:29, from ../../gcc/genflags.c:28: ../../gcc/vec.h:167: error: expected '=', ',', ';', 'asm' or '__attribute__' before '<' token ../../gcc/vec.h:176: error: expected '=', ',', ';', 'asm' or '__attribute__' before '<' token ../../gcc/vec.h:188: error: expected '=', ',', ';', 'asm' or '__attribute__' before '<' token ../../gcc/vec.h:197: error: expected '=', ',', ';', 'asm' or '__attribute__' before '<' token ../../gcc/vec.h:205: error: expected '=', ',', ';', 'asm' or '__attribute__' before '<' token ../../gcc/vec.h:274: error: expected '=', ',', ';', 'asm' or '__attribute__' before '<' token ../../gcc/vec.h:277: error: expected '=', ',', ';', 'asm' or '__attribute__' before '<' token ../../gcc/vec.h:301: error: expected '=', ',', ';', 'asm' or '__attribute__' before '<' token ../../gcc/vec.h:316: error: expected '=', ',', ';', 'asm' or '__attribute__' before '<' token ../../gcc/vec.h:332: error: expected '=', ',', ';', 'asm' or '__attribute__' before '<' token ../../gcc/vec.h:349: error: expected '=', ',', ';', 'asm' or '__attribute__' before '<' token ../../gcc/vec.h:367: error: expected '=', ',', ';', 'asm' or '__attribute__' before '<' token ../../gcc/vec.h:375: error: expected '=', ',', ';', 'asm' or '__attribute__' before '<' token ../../gcc/vec.h:398: error: expected '=', ',', ';', 'asm' or '__attribute__' before '<' token ../../gcc/vec.h:414: error: expected '=', ',', ';', 'asm' or '__attribute__' before '<' token ../../gcc/vec.h:458: error: expected '=', ',', ';', 'asm' or '__attribute__' before '<' token ../../gcc/vec.h:467: error: expected '=', ',', ';', 'asm' or '__attribute__' before '<' token ../../gcc/vec.h:502: error: expected '=', ',', ';', 'asm' or '__attribute__' before '<' token ../../gcc/vec.h:509: error: expected '=', ',', ';', 'asm' or '__attribute__' before '<' token ...
[Bug c++/54333] sprinf and fprintf work not always equal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54333 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski 2012-08-20 20:48:48 UTC --- sprinf and fprintf functions are not controlled by the compiler but rather the System libc. Report this bug to who you got the libc which GCC uses.
[Bug target/51244] SH Target: Inefficient conditional branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #48 from Oleg Endo 2012-08-20 20:51:12 UTC --- Author: olegendo Date: Mon Aug 20 20:51:06 2012 New Revision: 190544 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190544 Log: PR target/51244 * config/sh/sh.md (*cset_zero): New insns. PR target/51244 * gcc.target/sh/pr51244-11.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/pr51244-11.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.md trunk/gcc/testsuite/ChangeLog
[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 H.J. Lu changed: What|Removed |Added CC||areg.melikadamyan at gmail ||dot com, dnovillo at google ||dot com --- Comment #1 from H.J. Lu 2012-08-20 20:53:14 UTC --- It is caused by revision 190402: http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00379.html
[Bug rtl-optimization/50489] [UPC/IA64] mis-schedule of MEM ref with -ftree-vectorize and -fschedule-insns2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50489 --- Comment #8 from Oleg Endo 2012-08-20 20:54:25 UTC --- Author: olegendo Date: Mon Aug 20 20:54:20 2012 New Revision: 190545 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190545 Log: PR target/50489 * config/sh/sh.md (rotcr, *rotcr, shar, shlr): New insns and splits. (ashrdi3_k, lshrdi3_k): Rewrite as insn_and_split. * config/sh/sh.c (sh_lshrsi_clobbers_t_reg_p): New function. * config/sh/sh-protos.h (sh_lshrsi_clobbers_t_reg_p): Declare it. PR target/50489 * gcc.target/sh/pr54089-1.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/pr54089-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh-protos.h trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.md trunk/gcc/testsuite/ChangeLog
[Bug c++/54333] sprinf and fprintf work not always equal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54333 --- Comment #2 from Denis Kolesnik 2012-08-20 21:01:54 UTC --- thanks for the quick answer!
[Bug bootstrap/54334] Unable to bootstrap using gcc 4.1.0 after cxx-conversion merge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54334 Ryan Mansfield changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Ryan Mansfield 2012-08-20 21:06:07 UTC --- Sorry for the noise, somehow the g++ drivers on the box I was using were calling cc1 instead of cc1plus.
[Bug c++/19351] [DR 624] operator new[] can return heap blocks which are too small
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351 --- Comment #27 from Florian Weimer 2012-08-20 21:13:29 UTC --- Author: fw Date: Mon Aug 20 21:13:23 2012 New Revision: 190546 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190546 Log: Fix PR C++/19351: integer overflow in operator new[] 2012-08-20 Florian Weimer PR c++/19351 * call.c (build_operator_new_call): Add size_check argument and evaluate it. * cp-tree.h (build_operator_new_call): Adjust declaration. * init.c (build_new_1): Compute array size check and apply it. 2012-08-10 Florian Weimer PR c++/19351 * g++.dg/init/new38.C: New test. * g++.dg/init/new39.C: New test. Added: trunk/gcc/testsuite/g++.dg/init/new38.C trunk/gcc/testsuite/g++.dg/init/new39.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 --- Comment #2 from H.J. Lu 2012-08-20 21:18:00 UTC --- Revision 190401 takes 512MB virtual memory to compile module_domain.fppized.f90 while revision 190402 takes 10GB. This is a 20x increase.
[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 Steven Bosscher changed: What|Removed |Added Keywords||memory-hog Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-20 CC||steven at gcc dot gnu.org Ever Confirmed|0 |1
[Bug c++/19351] [DR 624] operator new[] can return heap blocks which are too small
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351 Florian Weimer changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |fweimer at redhat dot com |gnu.org | Target Milestone|--- |4.8.0 --- Comment #28 from Florian Weimer 2012-08-20 21:23:09 UTC --- This is the best we can do without an ABI change. (Expanding inline the code to throw std::bad_array_new_length, as required by C++11, is a bit too messy.)
[Bug target/54089] [SH] Refactor shift patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #14 from Oleg Endo 2012-08-20 21:29:26 UTC --- For the record, I've committed the following under the wrong PR number by accident. Author: olegendo Date: Mon Aug 20 20:54:20 2012 New Revision: 190545 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190545 Log: PR target/50489 * config/sh/sh.md (rotcr, *rotcr, shar, shlr): New insns and splits. (ashrdi3_k, lshrdi3_k): Rewrite as insn_and_split. * config/sh/sh.c (sh_lshrsi_clobbers_t_reg_p): New function. * config/sh/sh-protos.h (sh_lshrsi_clobbers_t_reg_p): Declare it. PR target/50489 * gcc.target/sh/pr54089-1.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/pr54089-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh-protos.h trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.md trunk/gcc/testsuite/ChangeLog
[Bug driver/54335] New: -dm doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54335 Bug #: 54335 Summary: -dm doesn't work Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com invoke.texi has @item -dm @opindex dm Print statistics on memory usage, at the end of the run, to But I got [hjl@gnu-ivb-1 tmp]$ gcc -dm -S x.c cc1: warning: unrecognized gcc debugging option: m [enabled by default] [hjl@gnu-ivb-1 tmp]$
[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 H.J. Lu changed: What|Removed |Added Status|NEW |UNCONFIRMED Ever Confirmed|1 |0 --- Comment #3 from H.J. Lu 2012-08-20 21:41:46 UTC --- Revision 190402 memory stat: Memory consumption before IPA Number of expanded macros: 0 Line Table allocations during the compilation process Number of ordinary maps used:3 Ordinary map used size:120 Number of ordinary maps allocated: 409 Ordinary maps allocated size: 15k Number of macro maps used: 0 Macro maps used size:0 Macro maps locations size: 0 Macro maps size: 0 Duplicated maps locations size: 0 Total allocated maps size: 15k Total used maps size: 120 Memory still allocated at the end of the compilation process Size AllocatedUsedOverhead 8 36k 11k 1080 1696k 82k 2112 32 132k 62k 2376 64 1460k 1338k 22k 256 440k432k 6160 512 81923584 112 1024 16k 11k224 2048 12k 8192 168 4096 84k 84k 1176 8192 32k 32k224 16384 48k 48k168 65536 64k 64k 56 131072128k128k 56 262144512k512k112 2468k 32k 1224 40 3740k 1482k 58k 48 2108k876k 32k 56 1396k913k 21k 7228k 2232 392 80 104k101k 1456 8816k 2200 224 96 4252k 4140k 58k 112 16k 12k224 120 81925160 112 184 72k 67k 1008 128 36k 14k504 152 4324k 4168k 59k 168 788k362k 10k 160 504k487k 7056 104 2836k 2770k 38k 312 212k208k 2968 136 40962448 56 Total 23M 18M331k String pool entries10710 identifiers7074 (66.05%) slots16384 deleted3636 bytes86k (17592186044415M overhead) table size128k coll/search0.6146 ins/search0.2503 avg. entry8.25 bytes (+/- 8.27) longest entry46 (No per-node statistics) Type hash: size 2039, 996 elements, 1.024948 collisions DECL_DEBUG_EXPR hash: size 1021, 294 elements, 0.128814 collisions DECL_VALUE_EXPR hash: size 1021, 0 elements, 0.00 collisions No gimple statistics No RTX statistics Alias oracle query stats: refs_may_alias_p: 0 disambiguations, 0 queries ref_maybe_used_by_call_p: 0 disambiguations, 0 queries call_may_clobber_ref_p: 0 disambiguations, 0 queries PTA query stats: pt_solution_includes: 0 disambiguations, 0 queries pt_solutions_intersect: 0 disambiguations, 0 queries Memory consumption after IPA Number of expanded macros: 0 Line Table allocations during the compilation process Number of ordinary maps used:3 Ordinary map used size:120 Number of ordinary maps allocated: 409 Ordinary maps allocated size: 15k Number of macro maps used: 0 Macro maps used size:0 Macro maps locations size: 0 Macro maps size: 0 Duplicated maps locations size: 0 Total allocated maps size: 15k Total used maps size: 120 Memory still allocated at the end of the compilation process Size AllocatedUsedOverhead 8 36k 11k 1080 1696k 82k 2112 32 132k 70k 2376 64 1460k 1160k 22k 256 1724k 1722k 23k 512 81925120 112 1024 28k 27k392 2048 12k 8192 168 4096 116k116k 1624 8192 32k 32k224 16384 4544k 4544k 15k 65536 64k 64k 56 131072128k128k 56 262144512k512k112 524288512k512k 56 24 200k 74k 3600 40 3740k 1280k 58k 48 2108k425k 32k 56 1396k910k 21k 7228k 2232 392 80 4824k 2840k 65k 8816k 2024 224
[Bug c++/54293] When a reference is bound to subobject of a temporary, lifetime of the temporary is not extended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54293 --- Comment #6 from Jiří Paleček 2012-08-20 21:56:39 UTC --- (In reply to comment #5) > I think there is a compiler bug. The ruling text seems to be the > first bullet of 8.5.3/5 and its first sub-bullet: > > - If the reference is an lvalue reference and the initializer > expression > >- is an lvalue (but is not a bit-field), and "cv1 T1" is > reference-compatible with "cv2 T2," or > > which matches the expression in the test case: > >const int& ref_int = ValueHolder().v; The initializer is NOT an lvalue. ValueHolder() is a class (p)rvalue, and rvalue.something is still an rvalue, cf. 5.2.5/4, the second bullet applies: — If E2 is a non-static data member and the type of E1 is “cq1 vq1 X”, and the type of E2 is “cq2 vq2 T”, the expression designates the named member of the object designated by the first expression. If E1 is an lvalue, then E1.E2 is an lvalue; if E1 is an xvalue, then E1.E2 is an xvalue; otherwise, it is a prvalue. [ IMHO it misses the case when T is a reference type, but that doesn't apply here ] Therefore, I think the binding should proceed by the last case (because the initializer expression is not a *class* (don't ask me why, but it is in the standard text) prvalue, the first sub-bullet of the second bullet doesn't apply either; only the second sub-bullet is left). In that case, you don't bind to the ValueHolder temporary at all, so you don't extend its lifetime. BTW you never extend the lifetime of anything when you bind according to the first bullet of 8.5.3/5, because lvalues either don't trace to their object, even if they were obtained from a temporary, so it would be impossible to do; or they are named variables whose lifetime is simply not extended.
[Bug c++/54293] When a reference is bound to subobject of a temporary, lifetime of the temporary is not extended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54293 --- Comment #7 from Daniel Krügler 2012-08-20 22:17:45 UTC --- (In reply to comment #6) > — If E2 is a non-static data member and the type of E1 is “cq1 vq1 X”, and the > type of E2 is “cq2 vq2 > T”, the expression designates the named member of the object designated by the > first expression. If > E1 is an lvalue, then E1.E2 is an lvalue; if E1 is an xvalue, then E1.E2 is an > xvalue; otherwise, it is a > prvalue. [ IMHO it misses the case when T is a reference type, but that > doesn't > apply here ] Did you mean E2 instead of T here? In this case this is described in the beginning of 5.2.5 p4: "If E2 is declared to have type “reference to T,” then E1.E2 is an lvalue; the type of E1.E2 is T." I agree with your analysis, but would like to point out that there is change planned to essentially this part of the wording due to http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#616 Assuming it becomes accepted E1.E2 will become an xvalue in this case (SE bullet 2 of the P/R)
[Bug c++/54336] New: [c++0x] diagnostics for functions with arg-dependent return types have bad signatures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54336 Bug #: 54336 Summary: [c++0x] diagnostics for functions with arg-dependent return types have bad signatures Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: l...@mit.edu This code: template auto func(T x) -> decltype(x.method()) { static_assert(false, "test"); } fails to compile with: decltype_return.cc: In function 'decltype (x.method()) func(T)': decltype_return.cc:3:3: error: static assertion failed: test static_assert(false, "test"); ^ What's 'decltype (x.method()) func(T)'? x isn't defined. 'auto func(T x) -> decltype(x.method())' or even 'decltype (x.method()) func (T x)' would be better.
[Bug c++/54336] [c++0x] diagnostics for functions with arg-dependent return types have bad signatures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54336 --- Comment #1 from Andrew Pinski 2012-08-20 22:39:47 UTC --- The issue is we decided that static_asserts which are dependent should be resolved at definition time rather than instantiation time.
[Bug c++/12076] gcov misreports coverage of return statement [NRV]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12076 Paolo Carlini changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #19 from Paolo Carlini 2012-08-20 22:49:26 UTC --- I understand this is still an issue. Let's add Jason in CC, IIRC he contributed the NRV optimization on trees.
[Bug c++/54293] When a reference is bound to subobject of a temporary, lifetime of the temporary is not extended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54293 --- Comment #8 from Jiří Paleček 2012-08-20 22:52:31 UTC --- (In reply to comment #7) > (In reply to comment #6) > > — If E2 is a non-static data member and the type of E1 is “cq1 vq1 X”, and > > the > > type of E2 is “cq2 vq2 > > T”, the expression designates the named member of the object designated by > > the > > first expression. If > > E1 is an lvalue, then E1.E2 is an lvalue; if E1 is an xvalue, then E1.E2 is > > an > > xvalue; otherwise, it is a > > prvalue. [ IMHO it misses the case when T is a reference type, but that > > doesn't > > apply here ] > > Did you mean E2 instead of T here? In this case this is described in the > beginning of 5.2.5 p4: > > "If E2 is declared to have type “reference to T,” then E1.E2 is an lvalue; the > type of E1.E2 is T." You're right, my bad. I thought it MUST be there but missed that - anyway, it is not relevant here. > I agree with your analysis, but would like to point out that there is change > planned to essentially this part of the wording due to > > http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#616 > > Assuming it becomes accepted E1.E2 will become an xvalue in this case (SE > bullet 2 of the P/R) Thanks for the info, it is interesting (although I can't see the relevance of this particular change to the issues it should solve, which are basically about using uninitialized objects).
[Bug other/54337] New: Dramatic Compilation slow-down on higher Optimizaitons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54337 Bug #: 54337 Summary: Dramatic Compilation slow-down on higher Optimizaitons Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: nbharg...@google.com Created attachment 28061 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28061 Test Case The attached file contains a few function definitions followed by a main method with a single line of code duplicated 2500 times. At optimization levels O0, the code compiles relatively quickly (~8s). However, at optimization levels O2 and O3, the compilation time jumps to over 30s to compile -- almost a 4x difference. Interesting things about what speeds up the optimized compilation: Having an if-statement with an empty body cuts down compilation times on all optimization levels to under 3s. This could be related to http://llvm.org/bugs/show_bug.cgi?id=13651, as the problem was discovered in a file that repeats a macro heavily, as these examples do.
[Bug middle-end/54337] Dramatic Compilation slow-down on higher Optimizaitons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54337 --- Comment #1 from Andrew Pinski 2012-08-20 23:07:54 UTC --- For me it does not even compile: t1.cc:44:36: error: ‘numeric_limits’ is not a member of ‘std’ expected_ss << std::setprecision(std::numeric_limits::digits10);
[Bug c++/54336] [c++0x] diagnostics for functions with arg-dependent return types have bad signatures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54336 --- Comment #2 from Andy Lutomirski 2012-08-20 23:21:32 UTC --- Fair enough. Here's a better example: struct A { int method(); }; template auto func(T x) -> decltype(x.method()) { bogus(x); } int main() { func(A()); } The error is: decltype_return.cc: In instantiation of 'decltype (x.method()) func(T) [with T = A; decltype (x.method()) = int]': decltype_return.cc:8:22: required from here decltype_return.cc:5:3: error: 'bogus' was not declared in this scope bogus(x); ^ 'decltype (x.method())' is still meaningless in that context. Even just 'auto func(T) [with ...; auto = int]' might be less puzzling. (This is a very minor issue -- I just found it puzzling when I hit it earlier today in an STL error message.)
[Bug middle-end/54337] Dramatic Compilation slow-down on higher Optimizaitons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54337 --- Comment #2 from nbhargava at google dot com 2012-08-20 23:21:43 UTC --- Created attachment 28062 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28062 Linux-compatible test case The original test case was timed and compiled on a Mac. This one shows a much less extreme version of the problem (only goes from 2.5 seconds to 5 seconds). The original problem was found as part of the gtest framework and was slow on all architectures. I will try to manufacture a version that better showcases the original problem in the meanwhile.
[Bug rtl-optimization/53533] [4.7/4.8 regression] vectorization causes loop unrolling test slowdown as measured by Adobe's C++Benchmark
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533 --- Comment #20 from Matt Hargett 2012-08-20 23:52:31 UTC --- Some additional information: Compared to LLVM 3.1 with -O3, GCC 4.7 is twice as slow on these benchmarks. LLVM even outperforms GCC 4.1, which previously had the best result. We are very eager to hear about any resolution for this major regression in 4.7 so we can deploy it. Even a return to GCC 4.1 performance levels would be fine. Thanks!
[Bug middle-end/54337] Dramatic Compilation slow-down on higher Optimizaitons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54337 nbhargava at google dot com changed: What|Removed |Added Attachment #28062|0 |1 is obsolete|| --- Comment #3 from nbhargava at google dot com 2012-08-21 00:04:10 UTC --- Created attachment 28063 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28063 Linux-compatible test case $ time g++ -O3 -c t2.cc real0m22.806s user0m22.390s sys0m0.330s $ time g++ -O0 -c t2.cc real0m2.357s user0m2.260s sys0m0.050s On both Linux and Mac, this type of discrepancy exists.
[Bug c/54303] -fdata-sections -ffunction-sections and -fmerge-constants do not work well together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 Marek Vasut changed: What|Removed |Added CC||marek.vasut at gmail dot ||com --- Comment #2 from Marek Vasut 2012-08-21 00:35:12 UTC --- Confirmed on Debian: gcc version 4.7.1 (Debian 4.7.1-3)