[Bug rtl-optimization/44013] [4.5 Regression] VTA produces wrong code

--- Comment #11 from jakub at gcc dot gnu dot org 2010-06-07 07:16 --- Fixed on the trunk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary

[Bug c/44438] New: ISO C99 6.7.4p3 not obeyed in C99 mode

Section 6.7.4 paragraph 3 of the ISO C99 standard states that: An inline definition of a function with external linkage ... shall not contain a reference to an identifier with internal linkage. GCC has code to check for this condition, but it does not work in C99 mode. Reproduce by:

[Bug fortran/43945] [OOP] Derived type with GENERIC: resolved to the wrong specific TBP

--- Comment #14 from sfilippone at uniroma2 dot it 2010-06-07 08:26 --- (In reply to comment #13) > The remaining issue (comment #4/#11/#12) is being tracked by PR 44434, so this > one can be closed. > The attached variation of generic_23 still does not work. [sfili...@donald bug15]$

[Bug fortran/43945] [OOP] Derived type with GENERIC: resolved to the wrong specific TBP

--- Comment #15 from sfilippone at uniroma2 dot it 2010-06-07 08:27 --- Created an attachment (id=20853) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20853&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43945

[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc > gcc-4.2.x

--- Comment #38 from rguenth at gcc dot gnu dot org 2010-06-07 08:39 --- *** Bug 44437 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added -

[Bug bootstrap/44437] 4.5 bootstrap failure on powerpc-linux

--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-07 08:39 --- Use STAGE1_CFLAGS="-O -g". *** This bug has been marked as a duplicate of 37739 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug bootstrap/44439] New: Configure states wrong required versions for GMP, MPFR, and MPC

In case of wrong prerequisite versions, configure says Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0+ but the prerequisites page says GNU Multiple Precision Library (GMP) version 4.3.2 (or later) MPFR Library version 2.4.2 (or later) MP

[Bug middle-end/44440] New: ira_initialization and buitins construction taking too much of startup time

Hi, oprofiling compilation of empty file I get: 4831959.8126 no-vmlinux /no-vmlinux 3057 3.7842 ld-2.11.1.so do_lookup_x 2935 3.6331 libc-2.11.1.so memset 2921 3.6158 ld-2.11.1.so _dl_relocate_object 1589 1.9670 as

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

--- Comment #11 from singler at kit dot edu 2010-06-07 09:35 --- Obviously, I'm not the only one having this problem, Jason has patched libstdc++-v3/testsuite/util/testsuite_abi.h in the meantime. r160313 | jason |

[Bug fortran/43945] [OOP] Derived type with GENERIC: resolved to the wrong specific TBP

--- Comment #16 from burnus at gcc dot gnu dot org 2010-06-07 09:41 --- (In reply to comment #14) > The attached variation of generic_23 still does not work. > > [sfili...@donald bug15]$ ./generic_23_1 > FOO%DOIT base version Aborted (core dumped) (In reply to comment #15) > Create

[Bug target/44364] Wrong code with e500 double floating point

--- Comment #25 from amodra at gmail dot com 2010-06-07 09:53 --- Yes it seems the patch is not sufficient on 4.4. On mainline the code looks good by inspection. (I don't have e500 hardware to run tests on.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364

[Bug c/44438] ISO C99 6.7.4p3 not obeyed in C99 mode

--- Comment #1 from jsm28 at gcc dot gnu dot org 2010-06-07 09:54 --- That's not an "inline definition", so that constraint does not apply. If all of the file scope declarations for a function in a translation unit include the inline function specifier without extern, then the

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

--- Comment #12 from paolo dot carlini at oracle dot com 2010-06-07 10:09 --- Yes, it's a glibc bug (I don't have available any machine using that old glibc), and if you look at the mailing list, I already commented that could be related to your issue. I think we should use the same wor

[Bug bootstrap/44439] Configure states wrong required versions for GMP, MPFR, and MPC

--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-07 10:13 --- Prerequesites states the recommended versions, configure only tests the minimal required versions. The inconsistency is "ok". -- rguenth at gcc dot gnu dot org changed: What|Removed

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

--- Comment #13 from paolo dot carlini at oracle dot com 2010-06-07 10:18 --- As a matter of fact, in testsuite_allocator.h the problem can be solved much more cleanly by simply qualifying with std:: the size_t and ptrdiff_t in tge second half of the file, I can do that later today.

[Bug target/44364] Wrong code with e500 double floating point

--- Comment #26 from amodra at gmail dot com 2010-06-07 10:29 --- Doh! No, it's still broken on mainline too. I wasn't testing what I thought I was... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364

[Bug objc++/23716] obj-c++.dg/comp-types-10.mm ICE with the GNU runtime

--- Comment #14 from iains at gcc dot gnu dot org 2010-06-07 10:45 --- closing after back-porting to 4.5; if anyone feels passionately about a merge to 4.4 ... they can re-open. -- iains at gcc dot gnu dot org changed: What|Removed |Added

[Bug testsuite/44159] CPU options cause testsuite failures

--- Comment #2 from ktietz at gcc dot gnu dot org 2010-06-07 10:57 --- Subject: Bug 44159 Author: ktietz Date: Mon Jun 7 10:56:44 2010 New Revision: 160363 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160363 Log: 2010-06-07 Kai Tietz PR target/44159 * gcc.

[Bug libstdc++/44441] New: std::getline set failbit in situation when shouldn't

In this code s failbit is set if last line in s is empty (stream ends with \n\n): std::istream s; //s is some kind of input stream like std::istringstream s("\n\n"); while (s.good()) { std::string line; std::getline(s, line); } -- Summary: std::getline set failbit in situation when

[Bug testsuite/44159] CPU options cause testsuite failures

--- Comment #3 from ktietz at gcc dot gnu dot org 2010-06-07 11:09 --- Subject: Bug 44159 Author: ktietz Date: Mon Jun 7 11:08:46 2010 New Revision: 160365 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160365 Log: 2010-06-07 Kai Tietz Backport from mainline:

[Bug testsuite/44159] CPU options cause testsuite failures

--- Comment #4 from ktietz at gcc dot gnu dot org 2010-06-07 11:09 --- Fixed an 4.5 branch and on mainline. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added

[Bug libstdc++/44441] std::getline set failbit in situation when shouldn't

--- Comment #1 from schwab at linux-m68k dot org 2010-06-07 11:19 --- You are getting eof. -- schwab at linux-m68k dot org changed: What|Removed |Added Status

[Bug rtl-optimization/44404] auto-inc-dec generates an invalid assembly instruction

--- Comment #4 from kazu at gcc dot gnu dot org 2010-06-07 11:35 --- Posted a patch. -- kazu at gcc dot gnu dot org changed: What|Removed |Added URL|

[Bug libstdc++/44441] std::getline set failbit in situation when shouldn't

--- Comment #2 from qwak82 at gmail dot com 2010-06-07 11:36 --- But also fail bit, this program prints: line: a //this is OK, first line line://this is also OK, second (empty) line fail bit //eof is set - OK; but fail bit should be set here? #include #incl

[Bug fortran/44442] New: Useless temporary with RESHAPE

While playing with -Warray-temporaries, I noticed that the warning is emitted twice for RESHAPE as illustrated by the following example: [macbook] f90/bug% cat pr36928_red.f90 ! { dg-do compile } ! { dg-options "-Warray-temporaries" } ! PR 36928 - optimize array interleaving array temporaries prog

[Bug libstdc++/44441] std::getline set failbit in situation when shouldn't

--- Comment #3 from redi at gcc dot gnu dot org 2010-06-07 11:56 --- [lib.string.io] paragraph 8 If the function extracts no characters, it calls is.setstate(ios_base::failbit) which may throw ios_base::failure (27.4.4.3). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1

[Bug c/43893] Error: Invalid controlling predicate with -fopenmp

--- Comment #9 from gccbug at oxyware dot com 2010-06-07 12:12 --- The patch doesn't seem to handle != as a terminating condition: #pragma omp parallel for for (int i = 0; i != 1000; i++) {} doesn't compile on 4.4.1, whereas i<1000 does. -- http://gcc.gnu.org/bugzilla/show_bug.cgi

[Bug c/43893] Error: Invalid controlling predicate with -fopenmp

--- Comment #10 from jakub at gcc dot gnu dot org 2010-06-07 12:17 --- That's correct, it shouldn't compile. The OpenMP standard doesn't allow != comparisons in omp for condition, only <, <=, >, >=. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43893

[Bug c++/14258] typename in a using declaration not supported

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

[Bug c++/44443] New: [4.6 Regression] -Wunused-but-set-variable problem with unused attribute on type

int i; void f1 () { const int * __attribute__((unused)) a = &i; const int *b __attribute__((unused)) = &i; } warns for a (incorrectly) and not for b in C++, in C it correctly doesn't warn at all. -- Summary: [4.6 Regression] -Wunused-but-set-variable problem with

[Bug c++/44444] New: [4.6 Regression] -Wunused-but-set-variable problem with field references

struct S { const int &u; const int &v; S (const int &a, const int &b) : u(a), v(b) { } }; bool f1 () { bool t = false; S z = S (1, 2); t |= z.u == 1; t |= z.v == 2; return t; } void f2 () { S z = S (1, 2); z.u; } int i; void f3 () { S z = S (1, 2); i++, z.u; } warns wit

[Bug target/44364] Wrong code with e500 double floating point

--- Comment #27 from Kyle dot D dot Moffett at boeing dot com 2010-06-07 12:49 --- (In reply to comment #25) > Yes it seems the patch is not sufficient on 4.4. On mainline the code looks > good by inspection. (I don't have e500 hardware to run tests on.) If you'd like login access to

[Bug rtl-optimization/44404] auto-inc-dec generates an invalid assembly instruction

--- Comment #5 from kazu at gcc dot gnu dot org 2010-06-07 13:12 --- Subject: Bug 44404 Author: kazu Date: Mon Jun 7 13:12:42 2010 New Revision: 160372 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160372 Log: gcc/ PR rtl-optimization/44404 * auto-inc-dec.c (fi

[Bug rtl-optimization/44404] auto-inc-dec generates an invalid assembly instruction

--- Comment #6 from kazu at gcc dot gnu dot org 2010-06-07 13:15 --- Fixed. -- kazu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED

[Bug c++/30195] Using declaration doesn't work in template.

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

[Bug rtl-optimization/44404] auto-inc-dec generates an invalid assembly instruction

--- Comment #7 from kazu at gcc dot gnu dot org 2010-06-07 13:17 --- Subject: Bug 44404 Author: kazu Date: Mon Jun 7 13:17:32 2010 New Revision: 160374 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160374 Log: gcc/ PR rtl-optimization/44404 * auto-inc-dec.c (fi

[Bug middle-end/44440] ira_initialization and buitins construction taking too much of startup time

--- Comment #1 from jakub at gcc dot gnu dot org 2010-06-07 13:36 --- Created an attachment (id=20854) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20854&action=view) callgrind.startup.bz2 Callgrind dump for --enable-checking=release trunk cc1 from today on an empty file. --

[Bug c/44445] New: gcc-4.5.0 cannot find gmp-5.0.1

I'm trying to build a gcc cross-compiler. The configure script was passed the following arguments: --prefix=${tools}/usr --build=${host} --host=${host} --target=${target} --with-sysroot=${sysroot} --with-newlib --enable-languages=c --with-gmp=${tools}/usr --with-mpfr=${tools}/usr --disable-decimal

[Bug fortran/44442] Useless temporary with RESHAPE

--- Comment #1 from dominiq at lps dot ens dot fr 2010-06-07 13:49 --- Useless temporaries are also emitted for PAD and ORDER optional arguments: program main integer :: i, k, l, m, n real :: e1, e2 real, dimension(4,5) :: b real, dimension(5,4) :: c b = reshape([(i, i=1,20)],

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

-- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org

[Bug libstdc++/44436] Associative containers lack emplace() and emplace_hint() methods.

--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-07 14:03 --- Yes, we lack *tons* of other C++0x things. -- paolo dot carlini at oracle dot com changed: What|Removed |Added ---

[Bug libgcj/44415] [4.6 regression] gmp multilib support broke bootstrap with static libgmp

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-07 14:03 --- Subject: Re: [4.6 regression] gmp multilib support broke bootstrap with static libgmp > --- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-04 17:48 > --- > First off this is not a regress

[Bug c/44445] gcc-4.5.0 cannot find gmp-5.0.1

--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-07 14:24 --- You need to adjust LD_LIBRARY_PATH. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug bootstrap/43073] libiberty fails to build when using gcc-core

--- Comment #5 from zero at boolean-domain dot net 2010-06-07 14:35 --- I obtain a similar error message when building a gcc-4.5.0 cross compiler: /media/data/linux/sources/gcc-4.4.4-build/./gcc/xgcc -B/media/data/linux/sources/gcc-4.4.4-build/./gcc/ -B/media/data/linux/tools/usr/x86_64

[Bug libstdc++/44413] inefficient code for std::string::compare on x86-64

--- Comment #2 from paolo dot carlini at oracle dot com 2010-06-07 14:52 --- I think Jon is right on both accounts: the request is reasonable, but, even before that last changes, thus since the very beginning of v3: if (!__r) __r = __size - __osize; thus, I think we

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

--- Comment #14 from paolo dot carlini at oracle dot com 2010-06-07 15:17 --- Created an attachment (id=20855) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20855&action=view) Tentative patch (only sanity checked on a system not affected by the glibc issue) -- http://gcc.gnu.

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

--- Comment #15 from paolo dot carlini at oracle dot com 2010-06-07 15:23 --- Johannes, can you try the patch and in case, give me some details about the remaining issues? The idea is simply that if a glibc header has been included by before , then __GLIBC__ is defined and __GLIBC_MINO

[Bug middle-end/44386] builtin_object_size_ assumes a flexible array for a long array in a structure of known length

--- Comment #4 from meklund at cisco dot com 2010-06-07 15:26 --- I see your point that some legacy code might use a larger size as a flexible array. What is you opinion on the possibility of adding a bit-flag to __builtin_object_size() (like 0x04) that tightens the allowed flexible arr

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

--- Comment #16 from paolo dot carlini at oracle dot com 2010-06-07 15:27 --- Errata: "... by before ..." should read "... before wants to include ..." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44417

[Bug fortran/44446] New: Error with protected pocedure pointer

When compiling the attached code with gfortran I get: procedure(i_f), pointer, protected :: p_f => null() 1 Error: PROTECTED attribute conflicts with EXTERNAL attribute at (1) I think that the code is legal, according to the standard C535 (R501) The P

[Bug c++/39055] [4.3/4.4/4.5/4.6 regression] ICE with questionable default parameter of a member function

--- Comment #12 from jason at gcc dot gnu dot org 2010-06-07 15:51 --- Suspending. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|NEW

[Bug fortran/44446] Error with protected pocedure pointer

--- Comment #1 from burnus at gcc dot gnu dot org 2010-06-07 15:58 --- Untested: --- a/gcc/fortran/symbol.c +++ b/gcc/fortran/symbol.c @@ -567,8 +567,9 @@ check_conflict (symbol_attribute *attr, const char *name, locus *where) } conf (is_protected, intrinsic) - conf (is_protec

[Bug fortran/44442] Useless temporary with RESHAPE

--- Comment #2 from mikael at gcc dot gnu dot org 2010-06-07 15:59 --- (In reply to comment #1) > Useless temporaries are also emitted for PAD and ORDER optional arguments: > This is a known limitation of array constructors handling by gfortran. For passing to the library function, a t

[Bug rtl-optimization/44447] New: [MinGW GCC]: Faulty code optimization when -masm=intel added

Occurred on Windows Vista, with GCC 4.5.0 and 4.4.0 and -masm=intel and -Ox x>0, the code generation produces a faulty output with -O1 and a faulty control frow leading to SIGSEGV when -O2 or -O3. When -masm=intel or -Ox deleted, no SIGSEGV occurs and output is right. This phenomena doesn't occur

[Bug rtl-optimization/44447] [MinGW GCC]: Faulty code optimization when -masm=intel added

--- Comment #1 from dg dot recrutement31 at gmail dot com 2010-06-07 16:20 --- Created an attachment (id=20856) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20856&action=view) source file in which a faulty control flow occurs. Compiled with gcc 4.5 with the following potions: -a

[Bug c/43893] Error: Invalid controlling predicate with -fopenmp

--- Comment #11 from manu at gcc dot gnu dot org 2010-06-07 16:21 --- (In reply to comment #10) > That's correct, it shouldn't compile. > The OpenMP standard doesn't allow != comparisons in omp for condition, only <, > <=, >, >=. Is it so difficult to write that in the error message? Wo

[Bug rtl-optimization/44447] [MinGW GCC]: Faulty code optimization when -masm=intel added

--- Comment #2 from dg dot recrutement31 at gmail dot com 2010-06-07 16:24 --- (From update of attachment 20856) The program in which this bug occurs have been tested with valgrind that does not reveal memory leak and other bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-07 16:32 --- Subject: Re: [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously I've now analysed this further: the test only fails at -O3. The failure is an abort in l

[Bug fortran/44448] New: 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0

The last remaining gfortran testsuite failure on Solaris 10/11 x86 is FAIL: gfortran.dg/atan2_1.f90 -O0 execution test (only for 32-bit). The test aborts at l.12: do i = 1, 10 if(atan(1.0, i/10.0) -atan2(1.0, i/10.)/= 0.0) call abort() if(atan(1.0d0,i/10.0d0)-atan2(1.0d0,i/10.0d0

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

--- Comment #18 from ro at gcc dot gnu dot org 2010-06-07 16:48 --- Created an attachment (id=20857) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20857&action=view) assembler output at -O0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

--- Comment #19 from ro at gcc dot gnu dot org 2010-06-07 16:49 --- Created an attachment (id=20858) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20858&action=view) assembler output at -O3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946

[Bug tree-optimization/44406] wrong code generation with -ftree-sra

--- Comment #4 from jamborm at gcc dot gnu dot org 2010-06-07 16:51 --- Moreover, I cannot reproduce this bug on the 4.5 branch since: r159866 | rguenth | 2010-05-26 13:46:01 +0200 (Wed, 26 May 2010) | 12 lines 2010-05-26 Richard Guenther PR rtl-optimization/44164 *

[Bug rtl-optimization/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

--- Comment #26 from jamborm at gcc dot gnu dot org 2010-06-07 16:51 --- *** Bug 44406 has been marked as a duplicate of this bug. *** -- jamborm at gcc dot gnu dot org changed: What|Removed |Added -

[Bug c++/44449] New: incorrectly allows assignment to arrays from braced-init-list (c++0x)

I am able to compile this using -std=c++0x (not even -std=gnu++0x): #include int main() { int test[] = {1,2,3}; std::cout << test[0] << test[1] << test[2]; test = {4,5,6}; std::cout << test[0] << test[1] << test[2] << std::endl; } it compiles without warnings (-Wa

[Bug tree-optimization/44258] [4.5/4.6 Regression] possible SRA wrong-code generation.

--- Comment #8 from jamborm at gcc dot gnu dot org 2010-06-07 16:56 --- (In reply to comment #5) > > have a look at PR44406... i believe its the same thing. > I think it probably is because the patch of mine would lead to code very similar to what exposed PR 44406. However, PR 44406

[Bug middle-end/44450] New: gcc.dg/lto/20090210 fails with emutls

I've recently compared testsuite results on Solaris 11/x86 with --enable-tls (the default) and --disable-tls before going on to investigate TLS problems on Solaris 8 and 9, especially given that emutls has been broken on mainline (and the 4.5 branch) for quite some time. In doing so, I noticed an

[Bug c++/44449] incorrectly allows assignment to arrays from braced-init-list (c++0x)

--- Comment #1 from redi at gcc dot gnu dot org 2010-06-07 17:03 --- I think this is Bug 44045 and was fixed for 4.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9

[Bug middle-end/44451] New: libgomp.c/pr33880.c and libgomp.fortran/omp_parse1.f90 fail with emultls

During my investigtion of testsuite differences with and without --enable-tls (cf. PR middle-end/44450), I noticed another bunch of failures that only happen with emutls, but only for 32-bit: +FAIL: libgomp.c/pr33880.c execution test +FAIL: libgomp.fortran/omp_parse1.f90 -O0 execution test +FAIL

[Bug target/44364] Wrong code with e500 double floating point

--- Comment #28 from amodra at gmail dot com 2010-06-07 17:05 --- Please bootstrap and test this addition to e500.h /* When setting up caller-save slots (MODE == VOIDmode) ensure we allocate space for DFmode. Save gprs in the correct mode too. */ #define HARD_REGNO_CALLER_SAVE_MODE

[Bug c++/44449] incorrectly allows assignment to arrays from braced-init-list (c++0x)

--- Comment #2 from redi at gcc dot gnu dot org 2010-06-07 17:10 --- pr.cc: In function 'int main()': pr.cc:6:22: error: assigning to an array from an initializer list -- redi at gcc dot gnu dot org changed: What|Removed |Added

[Bug target/44452] New: gcc.target/i386/abi-2.c and gcc.target/i386/pr22076.c fail on 32-bit Solaris 10+/x86

Investigating the few remaining testsuite failures on Solaris 11/x86, I came across FAIL: gcc.target/i386/abi-2.c scan-assembler-times ymm0 1 In the assembler output, ymm0 appears twice: vmovdqa .LC0, %ymm0 vmovdqa %ymm0, (%eax) FAIL: gcc.target/i386/pr22076.c scan-assembler-times

[Bug target/44067] internal compiler error: in rs6000_split_multireg_move, at config/rs6000/rs6000.c:16713

--- Comment #5 from amodra at gmail dot com 2010-06-07 17:25 --- Created an attachment (id=20859) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20859&action=view) fix pr42427 fallout Would someone with e500 hardware please bootstrap and regression test this patch? I'm running pow

[Bug tree-optimization/44393] [4.5/4.6 Regression] ICE: verify_ssa failed: no immediate_use list with -Os -ftree-loop-distribution

--- Comment #2 from pinskia at gcc dot gnu dot org 2010-06-07 17:29 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords|

[Bug c/44420] [feature request] Warn for certain integer overflows

--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-07 17:34 --- > foo = bar << 20; Yes this can overflow but so can "bar * 2" and "bar + 1". Maybe I am missing something here because we don't warn for those cases. Do you want a warning where the assignment happens to be a wid

[Bug c/44420] [feature request] Warn for certain integer overflows

--- Comment #2 from pinskia at gcc dot gnu dot org 2010-06-07 17:36 --- (In reply to comment #1) > uint64_t = uint32_t OP uint32_t; With an implicit casting to uint64_t? If that is the case this is a dup of bug 42935. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44420

[Bug c++/44443] [4.6 Regression] -Wunused-but-set-variable problem with unused attribute on type

--- Comment #1 from jakub at gcc dot gnu dot org 2010-06-07 17:49 --- Subject: Bug 3 Author: jakub Date: Mon Jun 7 17:49:06 2010 New Revision: 160387 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160387 Log: PR c++/3 * decl.c (initialize_local_var): If

[Bug c++/44444] [4.6 Regression] -Wunused-but-set-variable problem with field references

--- Comment #1 from jakub at gcc dot gnu dot org 2010-06-07 17:50 --- Subject: Bug 4 Author: jakub Date: Mon Jun 7 17:50:10 2010 New Revision: 160388 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160388 Log: PR c++/4 * expr.c (mark_exp_read): Handle IND

[Bug c++/44401] [4.5/4.6 regression] Doesn't correctly hide injected class name

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

[Bug c/42935] warn if a binary operation is performed on a type but the result is then casted to a larger type

--- Comment #4 from manu at gcc dot gnu dot org 2010-06-07 17:52 --- uint32_t bar; uint64_t foo; ... foo = bar << 20; Is another testcase from PR 44420. -- manu at gcc dot gnu dot org changed: What|Removed |Added --

[Bug c/44420] [feature request] Warn for certain integer overflows

--- Comment #3 from manu at gcc dot gnu dot org 2010-06-07 17:53 --- I think it is a duplicate. *** This bug has been marked as a duplicate of 42935 *** -- manu at gcc dot gnu dot org changed: What|Removed |Added --

[Bug c/42935] warn if a binary operation is performed on a type but the result is then casted to a larger type

--- Comment #5 from manu at gcc dot gnu dot org 2010-06-07 17:53 --- *** Bug 44420 has been marked as a duplicate of this bug. *** -- manu at gcc dot gnu dot org changed: What|Removed |Added -

[Bug rtl-optimization/42461] Missed optimisation for pure functions with __builtin_unreachable

--- Comment #5 from ebotcazou at gcc dot gnu dot org 2010-06-07 17:53 --- Investigating. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Assigne

[Bug c/42935] warn if a binary operation is performed on a type but the result is then casted to a larger type

--- Comment #6 from manu at gcc dot gnu dot org 2010-06-07 18:04 --- I think the condition of this warning should be: warn if a binary operation is performed on a type but the result is then implicitly converted to a larger type. The workaround for a valid case should be casting to t

[Bug c++/44443] [4.6 Regression] -Wunused-but-set-variable problem with unused attribute on type

--- Comment #2 from jakub at gcc dot gnu dot org 2010-06-07 18:05 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED

[Bug c++/44444] [4.6 Regression] -Wunused-but-set-variable problem with field references

--- Comment #2 from jakub at gcc dot gnu dot org 2010-06-07 18:05 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED

[Bug fortran/44354] implied do loop with its own variable name as upper bound

--- Comment #22 from tkoenig at gcc dot gnu dot org 2010-06-07 18:11 --- Adjusting subject, setting severity to "enhancement" and adding "diagnostic" keyword.(In reply to comment #21) > (In reply to comment #18) > > Expected: > > a) Allow it as extension (-std=gnu or -std=legacy; especi

[Bug other/44435] gengtype: don't test undefined value after vasprintf failure

--- Comment #3 from dj at redhat dot com 2010-06-07 18:14 --- Subject: Re: gengtype: don't test undefined value after vasprintf failure > If the libiberty maintainers won't review the xvasprintf patch, I did: http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00589.html -- http://gcc.

[Bug other/44435] gengtype: don't test undefined value after vasprintf failure

--- Comment #4 from jim at meyering dot net 2010-06-07 18:24 --- Good! I see that there's already a patch to deal with all of the unchecked asprintf calls, too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44435

[Bug middle-end/44297] Big spec cpu2006 prefetch regressions on gcc 4.6 on x86

--- Comment #14 from changpeng dot fang at amd dot com 2010-06-07 18:27 --- Here is the current status of my investigation: (1) 465.tonto regression (~9%): The regressions mainly comes from loops which have array references with both constant (prefetch_mod = 8) and non-constant (prefet

[Bug target/44364] Wrong code with e500 double floating point

--- Comment #29 from Kyle dot D dot Moffett at boeing dot com 2010-06-07 18:28 --- Awesome!!! Both of our testcases that were failing pass with this patch applied! I'm not going to call it a 100% victory yet, I want to rebuild our native compilers and build-and-run the PostgreSQL, GMP

[Bug middle-end/44297] Big spec cpu2006 prefetch regressions on gcc 4.6 on x86

--- Comment #15 from changpeng dot fang at amd dot com 2010-06-07 18:30 --- Created an attachment (id=20860) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20860&action=view) Don't consider effect of unrolling in the computation of insn-to-prefetch ratio -- http://gcc.gnu.org/

[Bug middle-end/44297] Big spec cpu2006 prefetch regressions on gcc 4.6 on x86

--- Comment #16 from changpeng dot fang at amd dot com 2010-06-07 18:32 --- Created an attachment (id=20861) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20861&action=view) Limit non-constant step prefetching only to the innermost loops -- http://gcc.gnu.org/bugzilla/show_bu

[Bug middle-end/44297] Big spec cpu2006 prefetch regressions on gcc 4.6 on x86

--- Comment #17 from changpeng dot fang at amd dot com 2010-06-07 18:37 --- (In reply to comment #15) > Created an attachment (id=20860) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20860&action=view) [edit] > Don't consider effect of unrolling in the computation of insn-to-prefe

[Bug target/40483] gcc 4.x needs to utilize better COMDAT mechanism under Solaris

--- Comment #3 from ro at gcc dot gnu dot org 2010-06-07 18:50 --- Revised patch available. -- ro at gcc dot gnu dot org changed: What|Removed |Added URL|h

[Bug target/44364] Wrong code with e500 double floating point

--- Comment #30 from Kyle dot D dot Moffett at boeing dot com 2010-06-07 18:56 --- Ok, the cross-compiler built with this patch fails to build a native GCC for the target with the following ICE: ../../../src/libgcc/../libdecnumber/decLibrary.c: In function 'isinfd128': ../../../src/lib

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

--- Comment #4 from matt at use dot net 2010-06-07 19:46 --- Let me know when this is implemented on trunk (preferrably by marking this report as resolved) and I'll test my proprietary test cases here. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42371

[Bug debug/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

--- Comment #23 from jan dot kratochvil at redhat dot com 2010-06-07 20:03 --- (In reply to comment #9) > In debug info we could use DW_OP_call{2,4} to refer to those > DIEs' DW_AT_location, but AFAIK gdb doesn't handle those 2 yet. FYI FSF GDB HEAD supports them now: http://sourceware

[Bug other/32499] libstdc++ testsuite fails on platforms without ranlib

--- Comment #16 from ro at gcc dot gnu dot org 2010-06-07 20:11 --- Subject: Bug 32499 Author: ro Date: Mon Jun 7 20:10:41 2010 New Revision: 160395 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160395 Log: toplevel: Backport from mainline: 2010-03-01

[Bug other/44435] gengtype: don't test undefined value after vasprintf failure

--- Comment #5 from joseph at codesourcery dot com 2010-06-07 20:17 --- Subject: Re: gengtype: don't test undefined value after vasprintf failure On Mon, 7 Jun 2010, dj at redhat dot com wrote: > > If the libiberty maintainers won't review the xvasprintf patch, > > I did: http://gcc

[Bug middle-end/44297] Big spec cpu2006 prefetch regressions on gcc 4.6 on x86

--- Comment #18 from rakdver at kam dot mff dot cuni dot cz 2010-06-07 20:24 --- Subject: Re: Big spec cpu2006 prefetch regressions on gcc 4.6 on x86 > --- Comment #14 from changpeng dot fang at amd dot com 2010-06-07 18:27 > --- > Here is the current status of my in

  1   2   >