[Bug middle-end/42130] [graphite-branch] dealII fails

--- Comment #7 from spop at gcc dot gnu dot org 2009-12-15 08:21 --- I will add -fgraphite-identity to the testcase as otherwise we're not going to test graphite on trunk... diff --git a/gcc/testsuite/g++.dg/graphite/pr42130.C b/gcc/testsuite/g++.dg/graphite/pr42130.C index ca00227..565

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

--- Comment #7 from irar at il dot ibm dot com 2009-12-15 08:25 --- I can't reproduce it with current mainline on powerpc64-suse-linux. Could you please attach vectorizer dump? Does the good old version gets vectorized? If so, could you please attach it as well? Thanks, Ira -- http

[Bug middle-end/42130] [graphite-branch] dealII fails

--- Comment #8 from spop at gcc dot gnu dot org 2009-12-15 08:27 --- Also, I don't know why the test fails at runtime like this: FAIL: g++.dg/graphite/pr42130.C execution test -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42130

[Bug fortran/41235] Missing explicit interface for variable-length character functions

--- Comment #2 from burnus at gcc dot gnu dot org 2009-12-15 08:37 --- Subject: Bug 41235 Author: burnus Date: Tue Dec 15 08:37:41 2009 New Revision: 155247 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155247 Log: 2009-12-15 Tobias Burnus Daniel Franke

[Bug tree-optimization/42334] segfault in graphite-poly.h for 200.sixtrack

--- Comment #2 from spop at gcc dot gnu dot org 2009-12-15 08:39 --- Subject: Bug 42334 Author: spop Date: Tue Dec 15 08:39:25 2009 New Revision: 155248 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155248 Log: Fix PR42334: correct the update of the LST on loop interchange and

[Bug middle-end/42178] [4.5 Regression] gcc.dg/graphite/interchange-8.c causes ICE

--- Comment #3 from spop at gcc dot gnu dot org 2009-12-15 08:39 --- Subject: Bug 42178 Author: spop Date: Tue Dec 15 08:39:25 2009 New Revision: 155248 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155248 Log: Fix PR42334: correct the update of the LST on loop interchange and

[Bug tree-optimization/42376] New: [4.5] Performance regression of generated code

I have noticed a big performance decrease in one of my numerical codes when switching from gcc 4.4 to gcc 4.5. A small test case is attached. When compiling this test case with "gcc -O3 perf.c -lm -std=c99" and executing the resulting binary, the CPU time with the head of the 4.4 branch is about 1.

[Bug tree-optimization/42334] segfault in graphite-poly.h for 200.sixtrack

--- Comment #3 from spop at gcc dot gnu dot org 2009-12-15 08:41 --- Fixed in the graphite branch. I will commit this to trunk after further test. -- spop at gcc dot gnu dot org changed: What|Removed |Added

[Bug middle-end/42178] [4.5 Regression] gcc.dg/graphite/interchange-8.c causes ICE

--- Comment #4 from spop at gcc dot gnu dot org 2009-12-15 08:41 --- Fixed in the graphite branch. I will commit this to trunk after further test. -- spop at gcc dot gnu dot org changed: What|Removed |Added

[Bug tree-optimization/42376] [4.5] Performance regression of generated code

--- Comment #1 from martin at mpa-garching dot mpg dot de 2009-12-15 08:41 --- Created an attachment (id=19305) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19305&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42376

[Bug tree-optimization/42376] [4.5] Performance regression of generated code

--- Comment #2 from martin at mpa-garching dot mpg dot de 2009-12-15 08:42 --- Created an attachment (id=19306) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19306&action=view) assembler generated by gcc 4.5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42376

[Bug tree-optimization/42376] [4.5] Performance regression of generated code

--- Comment #3 from martin at mpa-garching dot mpg dot de 2009-12-15 08:43 --- Created an attachment (id=19307) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19307&action=view) assembler generated by gcc 4.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42376

[Bug fortran/30668] -fwhole-file should catch function of wrong type

--- Comment #4 from burnus at gcc dot gnu dot org 2009-12-15 08:44 --- It also should check (kind/length) type-parameters, cf. http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/d710371aed91e75f This is kind of a follow up to PR 41235; cf. also PR 41603. -- http:/

[Bug fortran/41235] Missing explicit interface for variable-length character functions

--- Comment #3 from burnus at gcc dot gnu dot org 2009-12-15 08:45 --- FIXED -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW

[Bug libstdc++/42374] 23_containers/map/operators/1_neg.cc fails test for errors on darwin10

--- Comment #1 from chris at bubblescope dot net 2009-12-15 08:54 --- I see you are building with fink. Looking on the fink website, they do not seem to have a gcc45 package. Where did you get it from? Or has it just not made it to the website yet? -- chris at bubblescope dot net cha

[Bug target/42374] 23_containers/map/operators/1_neg.cc fails test for errors on darwin10

--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-15 09:12 --- And these can only be either target or, maybe, c++ front-end, certainly not libstdc++ proper -- paolo dot carlini at oracle dot com changed: What|Removed |Added -

[Bug c++/42336] [c++0x] ICE with pointer-to-member-function decltype argument in template function

--- Comment #4 from paolo dot carlini at oracle dot com 2009-12-15 09:22 --- Ok, thanks, I'll track that one instead... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42336

[Bug c++/42364] C++ testsuite fails with -g

--- Comment #4 from jakub at gcc dot gnu dot org 2009-12-15 09:35 --- make -j4 -k check-g++ RUNTESTFLAGS=--target_board=unix/-g -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42364

[Bug middle-end/42372] Error: undefined symbol `.LPIC7' in operation

--- Comment #3 from ramana at gcc dot gnu dot org 2009-12-15 09:50 --- Created an attachment (id=19308) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19308&action=view) Reduced testcase. Reduced testcase attached - Compiling with -c -Os -frename-registers exposes the problem. --

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

--- Comment #8 from dominiq at lps dot ens dot fr 2009-12-15 09:58 --- > I can't reproduce it with current mainline on powerpc64-suse-linux. I know;) > Does the good old version gets vectorized? I don't have any working 4.5 version, but 4.4.2 is working. The differences are (4.4.2)

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

--- Comment #9 from dominiq at lps dot ens dot fr 2009-12-15 09:59 --- Created an attachment (id=19309) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19309&action=view) dump file for gfortran 4.4.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

--- Comment #10 from dominiq at lps dot ens dot fr 2009-12-15 10:00 --- Created an attachment (id=19310) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19310&action=view) dump file for gfortran 4.5.0 revision 155196 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

--- Comment #99 from dominiq at lps dot ens dot fr 2009-12-15 10:14 --- > i686-apple-darwin9 bootstraps without dsymutil fails at 155225, thanks Jakub. powerpc-apple-darwin9 too at 155239. For x86_64-apple-darwin10, I think the problem is fixed too, but between revisions 154996 and 1550

[Bug c++/41183] [4.4 Regression] ICE compiling chromium

-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

--- Comment #11 from irar at il dot ibm dot com 2009-12-15 10:59 --- Looks that it has to be my patch that enables vectorization of conditions: r149806 | irar | 2009-07-20 14:59:10 +0300 (Mon, 20 Jul 2009) | 19 lines * tree-vectorizer.h (vectorizable_condition): Add parameters

[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression

--- Comment #37 from rguenth at gcc dot gnu dot org 2009-12-15 11:08 --- No, there isn't. I'd simply allow TREE_THIS_NOTRAP on all expression codes that in principle could. Now of course the middle-end would still need to make use of this (like transition it to a stmt flag on a tuple)

[Bug libstdc++/42377] New: libstdc++.dll.a misses a definition of std::string::reserve

Even though libstdc++-6.dll has: 6fc94700 T std::string::reserve(unsigned long long), libstdc++.dll.a misses a definition of std::string::reserve! Which makes it impossible to build libgmpxx against a shared version of libstdc++-6, see: /bin/sh ./libtool --mode=link g++ -O2 -pedantic -m6

[Bug c++/42336] [c++0x] ICE with pointer-to-member-function decltype argument in template function

--- Comment #5 from paolo dot carlini at oracle dot com 2009-12-15 11:29 --- FYI, I have checked, however, that the last posted patch for 42225 http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00755.html doesn't fix this one at once. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4

[Bug c++/42336] [c++0x] ICE with pointer-to-member-function decltype argument in template function

--- Comment #6 from dodji at seketeli dot org 2009-12-15 11:48 --- Subject: Re: [c++0x] ICE with pointer-to-member-function decltype argument in template function > FYI, I have checked, however, that the last posted patch for 42225 > doesn't fix this one at once. To be honest, I am n

[Bug target/42377] libstdc++.dll.a misses a definition of std::string::reserve

--- Comment #1 from davek at gcc dot gnu dot org 2009-12-15 11:49 --- Hi Rainer, it'll take a little time but I'll set myself up a build environment and see if I can reproduce this. The libtool dependency libs stuff is a known problem in libtool IIRC. Details to follow. -- http:/

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

--- Comment #12 from dominiq at lps dot ens dot fr 2009-12-15 13:05 --- > Looks that it has to be my patch that enables vectorization of conditions: I am doing a clean bootstrap of C and FORTRAN of revision 149805 to see if the test works for it (allow for ~6h on my poor G5). Then I'll

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

--- Comment #13 from irar at il dot ibm dot com 2009-12-15 13:07 --- (In reply to comment #12) > > Looks that it has to be my patch that enables vectorization of conditions: > I am doing a clean bootstrap of C and FORTRAN of revision 149805 to see if the > test works for it (allow for ~6

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

--- Comment #14 from irar at il dot ibm dot com 2009-12-15 13:08 --- Created an attachment (id=19311) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19311&action=view) powerpc64-suse-linux vect dump -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug tree-optimization/42376] [4.5 Regression] Performance regression of generated code

--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-15 13:15 --- This is because (quoting http://gcc.gnu.org/gcc-4.5/changes.html): "GCC now supports handling floating-point excess precision arising from use of the x87 floating-point unit in a way that conforms to ISO C99. This i

[Bug libffi/42378] New: cls_*double_va.c failures on powerpc-apple-darwin9

I have started to see the following failures between revisions 148215 and 148502 (likely 148285, which means that these tests never passed on powerpc-apple-darwin9): Running target unix FAIL: libffi.call/cls_double_va.c -O0 -W -Wall output pattern test, is -0.0 FAIL: libffi.call/cls_longdouble_va.

[Bug libffi/42243] [4.5 Regression] powerpc-apple-darwin9 libffi failures

--- Comment #26 from dominiq at lps dot ens dot fr 2009-12-15 13:21 --- I have open pr42378 for the remaining failures in comment #21 (I did not include libffi.call/nested_struct5.c that is pr34311). Closing this PR as fixed, please reopen if you disagree. -- dominiq at lps dot ens

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

--- Comment #15 from dominiq at lps dot ens dot fr 2009-12-15 13:29 --- > and the second one has this bb: > > : > dt_parm.33.common.filename = &"where_2.f90"[1]{lb: 1 sz: 1}; > ... > _gfortran_st_write_done (&dt_parm.33); This is probably due to a print I put in the code to look at

[Bug middle-end/42372] Error: undefined symbol `.LPIC7' in operation

--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-15 13:33 --- Is this a regression? If so please mark it so. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added -

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

--- Comment #16 from irar at il dot ibm dot com 2009-12-15 13:35 --- But in comment #5 you wrote that it passes with the print, right? So, this dump contains correct or incorrect code? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug tree-optimization/42375] trunk hangs during diffutils configure

--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-15 13:35 --- This is a bug in the test. Early inter-procedural SRA avoids passing array by reference in the recurse() function and instead passes the first element which is the only one read. Thus the function is optimized to a

[Bug middle-end/42371] dead code not eliminated during folding with whole-program

--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-15 13:38 --- This is because we never re-compute the address-taken flag of functions. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug tree-optimization/42326] segfault in tree-data-ref.c with Graphite building 200.sixtrack

--- Comment #5 from rguenth at gcc dot gnu dot org 2009-12-15 13:50 --- I can reproduce it with the testcase in comment #1 on i?86-linux: $ ./f951 -quiet t.f -O2 -floop-strip-mine -fprefetch-loop-arrays -msse2 t.f: In function 'blts': t.f:1:0: internal compiler error: Segmentation faul

[Bug tree-optimization/42326] [4.5 Regression] segfault in tree-data-ref.c with Graphite building 200.sixtrack

--- Comment #6 from rguenth at gcc dot gnu dot org 2009-12-15 13:51 --- Works for me with 4.4.2 on i?86-linux. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --

[Bug target/42374] 23_containers/map/operators/1_neg.cc fails test for errors on darwin10

--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-12-15 13:53 --- I am building with custom fink packaging for the gcc45 pre-releases. All the important build information should be in the specs output of the compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42

[Bug tree-optimization/42185] [4.5 Regression] [graphite] expected gimple_assign(error_mark), have gimple_call() in gimple_assign_rhs_code, at gimple.h:1820

--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-15 13:54 --- Still fails the same way for me. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

--- Comment #17 from dominiq at lps dot ens dot fr 2009-12-15 14:15 --- > But in comment #5 you wrote that it passes with the print, right? So, this > dump > contains correct or incorrect code? The dump for 4.5 is from the incorrect code. The behavior of this bug has change over time,

[Bug target/42377] libstdc++.dll.a misses a definition of std::string::reserve

--- Comment #2 from rainer at emrich-ebersheim dot de 2009-12-15 14:25 --- (In reply to comment #1) > Hi Rainer, it'll take a little time but I'll set myself up a build > environment > and see if I can reproduce this. > > The libtool dependency libs stuff is a known problem in libtoo

[Bug c++/41183] [4.4 Regression] ICE compiling chromium

--- Comment #8 from jakub at gcc dot gnu dot org 2009-12-15 15:13 --- Subject: Bug 41183 Author: jakub Date: Tue Dec 15 15:13:08 2009 New Revision: 155254 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155254 Log: PR c++/41183 * cp-tree.h (current_class_ptr): Giv

[Bug c++/42379] New: [4.5 Regression] Revision 155245 failed 1_neg.cc

Revision 155245: http://gcc.gnu.org/ml/gcc-cvs/2009-12/msg00389.html caused: FAIL: 23_containers/map/operators/1_neg.cc (test for errors, line 212) FAIL: 23_containers/map/operators/1_neg.cc (test for errors, line 216) FAIL: 23_containers/map/operators/1_neg.cc (test for excess errors) FAIL: 2

[Bug c++/41183] [4.4 Regression] ICE compiling chromium

--- Comment #9 from jakub at gcc dot gnu dot org 2009-12-15 15:15 --- Subject: Bug 41183 Author: jakub Date: Tue Dec 15 15:14:59 2009 New Revision: 155255 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155255 Log: PR c++/41183 * cp-tree.h (current_class_ptr): Giv

[Bug target/42374] 23_containers/map/operators/1_neg.cc fails test for errors on darwin10

--- Comment #4 from dominiq at lps dot ens dot fr 2009-12-15 15:16 --- See also http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg01308.html for i686-pc-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42374

[Bug tree-optimization/42185] [4.5 Regression] [graphite] expected gimple_assign(error_mark), have gimple_call() in gimple_assign_rhs_code, at gimple.h:1820

--- Comment #4 from aldyh at gcc dot gnu dot org 2009-12-15 15:18 --- Subject: Bug 42185 Author: aldyh Date: Tue Dec 15 15:17:46 2009 New Revision: 155256 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155256 Log: PR graphite/42185 * graphite-sese-to-poly.c (is_re

[Bug tree-optimization/42185] [4.5 Regression] [graphite] expected gimple_assign(error_mark), have gimple_call() in gimple_assign_rhs_code, at gimple.h:1820

--- Comment #5 from aldyh at gcc dot gnu dot org 2009-12-15 15:18 --- That's because I hadn't committed. Tests pass. Committing and closing. -- aldyh at gcc dot gnu dot org changed: What|Removed |Added

[Bug testsuite/41146] FAIL: gcc.target/powerpc/asm-es-2.c scan-assembler *

--- Comment #2 from dominiq at lps dot ens dot fr 2009-12-15 15:37 --- A patch has been posted to http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00772.html . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41146

[Bug c++/42379] [4.5 Regression] Revision 155245 failed 1_neg.cc

--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-15 15:42 --- *** Bug 42374 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug target/42374] 23_containers/map/operators/1_neg.cc fails test for errors on darwin10

--- Comment #5 from rguenth at gcc dot gnu dot org 2009-12-15 15:42 --- *** This bug has been marked as a duplicate of 42379 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --

[Bug c++/42379] [4.5 Regression] Revision 155245 failed 1_neg.cc

-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.5 Regression] Revision |[4.5 Regression] Revision |155245 failed 1_neg.cc

[Bug c++/42379] [4.5 Regression] Revision 155245 failed 1_neg.cc

--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-15 15:59 --- It's trivial, just one more "candidates are" which must be adjusted to "candidate is" in the dg-error strings. -- paolo dot carlini at oracle dot com changed: What|Removed

[Bug c++/42379] [4.5 Regression] Revision 155245 failed 1_neg.cc

--- Comment #3 from paolo at gcc dot gnu dot org 2009-12-15 16:11 --- Subject: Bug 42379 Author: paolo Date: Tue Dec 15 16:11:32 2009 New Revision: 155258 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155258 Log: 2009-12-15 Paolo Carlini PR c++/42379 * tests

[Bug c++/42379] [4.5 Regression] Revision 155245 failed 1_neg.cc

--- Comment #4 from paolo dot carlini at oracle dot com 2009-12-15 16:12 --- Done. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status

[Bug c++/27425] [4.3/4.4/4.5 regression] ICE with invalid template-template-parameter

-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.5.0 |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27425

[Bug c++/34274] [4.3/4.4/4.5 regression] Broken diagnostic: 'template_template_parm' not supported by dump_decl

-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.5.0 |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34274

[Bug c++/33492] [4.3 regression] Broken diagnostic: 'must_not_throw_expr' not supported by dump_expr

-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.4.0 Summary|[4.2/4.3 regression] Broken |[4.3 regression

[Bug debug/39412] [4.3 Regression] ICE in gen_tagged_type_instantiation_die

-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2/4.3 Regression] ICE in |[4.3 Regression] ICE in |gen_tagged_type_instantiat

[Bug middle-end/40106] [4.4/4.5 Regression] Time increase for the Polyhedron test air.f90 due to bad optimization

--- Comment #34 from rguenth at gcc dot gnu dot org 2009-12-15 16:40 --- 4.4 is also slow, we know what causes it so this can't be P1. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added -

[Bug debug/42380] New: CFI statements vs. -pg

See . To sum up: the question is whether the CFA needs to be adjusted after push {lr}, and before calling __gnu_mcount_nc. Currently it is not valid until __gnu_mcount_nc returns. -- Summary: CFI statements vs. -pg Product:

[Bug debug/42380] CFI statements vs. -pg

--- Comment #1 from tschwinge at gcc dot gnu dot org 2009-12-15 16:57 --- Richard Earnshaw wrote: > I'm not sure what other architectures do in this case. Do they also put > out adjustments to the cfi? I had a look at x86 and x86_64 -- they still need a frame pointer together with -pg

[Bug libstdc++/24803] [c++0x] reference_wrapper and pointers to member functions

--- Comment #17 from paolo dot carlini at oracle dot com 2009-12-15 17:00 --- At the moment, not actively working on this... -- paolo dot carlini at oracle dot com changed: What|Removed |Added --

[Bug libstdc++/35942] Self Reference In Dynamic Linked Library builds for building Cross-Compiler

--- Comment #14 from paolo dot carlini at oracle dot com 2009-12-15 17:02 --- Is this still an issue? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35942

[Bug libstdc++/38923] symbol versioning disabled due to non-portable sed script

--- Comment #18 from paolo dot carlini at oracle dot com 2009-12-15 17:04 --- I'm closing this as fixed for 4.5.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added

[Bug libstdc++/34419] Weirdness with numeric_limits in special functions

--- Comment #6 from paolo dot carlini at oracle dot com 2009-12-15 17:17 --- Ok, let's close this as invalid. -- paolo dot carlini at oracle dot com changed: What|Removed |Added -

[Bug libstdc++/35968] nth_element fails to meet its complexity requirements

--- Comment #8 from paolo dot carlini at oracle dot com 2009-12-15 17:19 --- Roger, are you still actively working on this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35968

[Bug libstdc++/42381] New: deque shouldn't reserve that much memory

In bits/stl_deque.h, line 80ff the minimal allocated size is set fixed to 512. This should be configurable, at least via a macro. In case of small memory systems (embedded devices) resveration of this amount of memory is much too high. -- Summary: deque shouldn't reserve that much mem

[Bug debug/42288] please emit empty .debug_aranges section

--- Comment #6 from rth at gcc dot gnu dot org 2009-12-15 17:36 --- rth: sorry... yeah, I tested the aranges patch and it worked for me. but it isn't clear we will need it now, we're discussing some form of caching w/ gdb rather than using the index sections ok. i'll leave the patch

[Bug libstdc++/42381] deque shouldn't reserve that much memory

--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-15 17:38 --- Changing the value, via macro or whatever is trivial, and I can tell you for sure from some experiment I did, that a *larger* value is much better, when memory is available, for operations like copies. Changing

[Bug libstdc++/42381] deque shouldn't reserve that much memory

-- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42381

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

--- Comment #18 from dominiq at lps dot ens dot fr 2009-12-15 17:47 --- The tests (with/without print) pass at revision 149806 (a clean bootstrap of 149805, followed by an update to 149806). I am currently bootstrapping 149852. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug libstdc++/42381] deque shouldn't reserve that much memory

--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-15 17:57 --- Let's add a macro (with a *big* warning), will be also useful for experimenting when I will add (soon) the segmented iterator optimization for copies. -- paolo dot carlini at oracle dot com changed:

[Bug tree-optimization/42205] [4.5 Regression] [graphite] internal compiler error: verify_ssa failed with -ffast-math -floop-interchange

--- Comment #5 from zsojka at seznam dot cz 2009-12-15 18:41 --- (In reply to comment #4) > Created an attachment (id=19250) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19250&action=view) [edit] > different testcase, this one is using doubles > > tested r155020, crashes with: >

[Bug c++/42373] g++.dg/cpp0x/lambda/lambda-mangle.C scan-assembler weak[ \t]*_?_ZN1RIiE1xMUlvE_clEv fails on x86_64-apple-darwin

--- Comment #3 from jason at gcc dot gnu dot org 2009-12-15 18:57 --- Subject: Bug 42373 Author: jason Date: Tue Dec 15 18:57:30 2009 New Revision: 155266 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155266 Log: PR c++/42373 * g++.dg/cpp0x/lambda/lambda-mangle.

[Bug c++/42358] [4.5 Regression][C++0x] Assembler failure on libstdc++-v3/testsuite/23_containers/multimap/init-list.cc with -O0

--- Comment #5 from jason at gcc dot gnu dot org 2009-12-15 18:57 --- Subject: Bug 42358 Author: jason Date: Tue Dec 15 18:57:39 2009 New Revision: 155267 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155267 Log: PR c++/42358 * pt.c (iterative_hash_template_arg)

[Bug c++/42373] g++.dg/cpp0x/lambda/lambda-mangle.C scan-assembler weak[ \t]*_?_ZN1RIiE1xMUlvE_clEv fails on x86_64-apple-darwin

--- Comment #4 from jason at gcc dot gnu dot org 2009-12-15 18:58 --- fixed, I think. Needs confirmation. -- jason at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/42358] [4.5 Regression][C++0x] Assembler failure on libstdc++-v3/testsuite/23_containers/multimap/init-list.cc with -O0

--- Comment #6 from jason at gcc dot gnu dot org 2009-12-15 18:58 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug c/42382] New: _Bool foo &= bar; vs _Bool foo = foo && bar; vs _Bool foo = foo & bar; emitted code different

gcc 4.4.1 produces different code for these equivalent inputs. optimization levels -Os -O2 -O3 It'd be good if the produced code were identical. #include #include #include int main(int argc, char** argv) { _Bool foo; _Bool bar; foo = !!rand(); bar = !!rand(); foo &= bar; printf

[Bug c++/42336] [c++0x] ICE with pointer-to-member-function decltype argument in template function

--- Comment #7 from jason at gcc dot gnu dot org 2009-12-15 20:04 --- You're right, they probably aren't; this doesn't involve typedefs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42336

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

--- Comment #13 from armand dot potter at free dot fr 2009-12-15 20:48 --- I'm using about the same configuration (cross-LFS build but with gcc 4.4.2) and got the same error. I did some investigations and the problem is that fenv.h file from build tree is first included (and defines _GL

[Bug libstdc++/42381] deque shouldn't reserve that much memory

--- Comment #3 from paolo at gcc dot gnu dot org 2009-12-15 20:58 --- Subject: Bug 42381 Author: paolo Date: Tue Dec 15 20:58:29 2009 New Revision: 155271 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155271 Log: 2009-12-15 Paolo Carlini PR libsdtc++/42381 *

[Bug c++/42355] Segmentation fault

--- Comment #6 from peter_foelsche at agilent dot com 2009-12-15 20:58 --- Created an attachment (id=19313) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19313&action=view) tmp.cpp g++ -c tmp.cpp -I ~/boost_1_40_0 -g -g is important -- http://gcc.gnu.org/bugzilla/show_bug.c

[Bug libstdc++/42381] deque shouldn't reserve that much memory

--- Comment #4 from paolo dot carlini at oracle dot com 2009-12-15 21:01 --- Done. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status

[Bug middle-end/42178] [4.5 Regression] gcc.dg/graphite/interchange-8.c causes ICE

--- Comment #5 from spop at gcc dot gnu dot org 2009-12-15 21:12 --- Subject: Bug 42178 Author: spop Date: Tue Dec 15 21:11:48 2009 New Revision: 155273 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155273 Log: Fix fall outs from Fix-PR42334. 2009-12-15 Sebastian Pop

[Bug tree-optimization/42334] segfault in graphite-poly.h for 200.sixtrack

--- Comment #4 from spop at gcc dot gnu dot org 2009-12-15 21:12 --- Subject: Bug 42334 Author: spop Date: Tue Dec 15 21:11:48 2009 New Revision: 155273 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155273 Log: Fix fall outs from Fix-PR42334. 2009-12-15 Sebastian Pop

[Bug c/42384] New: attribute((warning(""))) should warn on function addresses

Right now, use of attribute((warning)) only triggers a warning when encountering a direct call of a labeled function (line 13 in the example below) or simple indirection that can trivially be reduced to a direct call (line 17). But there is a hole: any time the address of a function is not immedia

[Bug tree-optimization/42221] [4.5 Regression] ICE from '-Os -fgraphite-identity'

--- Comment #2 from spop at gcc dot gnu dot org 2009-12-15 21:28 --- Mine. -- spop at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gc

[Bug tree-optimization/42221] [4.5 Regression] ICE from '-Os -fgraphite-identity'

--- Comment #3 from spop at gcc dot gnu dot org 2009-12-15 21:41 --- Reduced testcase as follows: static void b2w(unsigned int *out, const unsigned char *in, unsigned int len) { const unsigned char *bpend = in + len; for (; in != bpend; in += 4, ++out) { *out = (unsigned int)

[Bug libstdc++/42273] atomic_2.h:111: = instead of == in if

--- Comment #9 from bkoz at gcc dot gnu dot org 2009-12-15 21:46 --- Fixed. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug c++/42336] [c++0x] ICE with pointer-to-member-function decltype argument in template function

--- Comment #8 from jason at gcc dot gnu dot org 2009-12-15 21:54 --- The problem here is that after we're done parsing the translation unit, we do IPA optimizations, and IPA decides to change the type of X::func from a METHOD_TYPE to a FUNCTION_TYPE. Then later we're emitting debug inf

[Bug libstdc++/41865] map as class static member variable causing crash on process exit

--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-15 21:55 --- Feedback not forthcoming, closing. If you mean to provide a reproducer, please re-open, thanks. -- paolo dot carlini at oracle dot com changed: What|Removed |Added --

[Bug target/39640] MIPS : buggy va_list with float, long long and long double arguments

--- Comment #2 from xavier dot guerin at imag dot fr 2009-12-15 22:13 --- Hello list, Just checking if anyone had time to dig into this issue. If necessary, I can provide more material. Regards, Xavier -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39640

[Bug c++/42336] ICE with pointer-to-member-function argument in template function

--- Comment #9 from jason at gcc dot gnu dot org 2009-12-15 22:24 --- It does seem kind of dodgy that IPA is modifying the types of functions directly, though... Here's a non-C++0x testcase: struct X { void func() {} }; template void b(T) {} int main() { b(X()); /* line 9 */ X(

[Bug target/39640] MIPS : buggy va_list with float, long long and long double arguments

--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-15 22:26 --- If you are willing to help more I think you can do two things: 1- Double check if the problem still exists in the current, that is 4.4, release branch and in mainline; 2- Actually provide "less" material, that

  1   2   >