[Bug c++/42556] Unnecessary generation of a zero initializer for array with C++

--- Comment #2 from jiez at gcc dot gnu dot org 2010-03-15 05:34 --- I'm looking at this bug. -- jiez at gcc dot gnu dot org changed: What|Removed |Added Assigned

[Bug target/42040] [ia64] Inappropriate address spills

--- Comment #7 from wilson at gcc dot gnu dot org 2010-03-15 04:11 --- Created an attachment (id=20106) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20106&action=view) untested patch, imperfect solution -- wilson at gcc dot gnu dot org changed: What|Removed

[Bug target/42040] [ia64] Inappropriate address spills

--- Comment #6 from wilson at gcc dot gnu dot org 2010-03-15 04:08 --- I can reproduce the original problem with 28490 by changing the line in ia64_legitimate_constant_p from return (addend & 0x3fff) == 0; to return true; and compiling the testcase with -O. What ha

[Bug debug/43370] [4.4/4.5 Regression] ICE gen_type_die_with_usage, at dwarf2out.c:14745

--- Comment #4 from hjl dot tools at gmail dot com 2010-03-15 03:34 --- It is caused by revision 132681: http://gcc.gnu.org/ml/gcc-cvs/2008-02/msg00696.html -- hjl dot tools at gmail dot com changed: What|Removed |Added ---

[Bug c/43374] New: ICE with __builtin_isinf() and _Decimal argument

$ cat test.c int func(_Decimal32 v) { return __builtin_isinf(v); } $ gcc -c test.c test.c: In function 'func': test.c:2:25: internal compiler error: in prepare_float_lib_cmp, at optabs.c:4391 Please submit a full bug report, with preprocessed source if appropriate. See

[Bug lto/43373] New: whopr+linker plugin ICE compressed stream data error

cal --enable-languages=c,c++,objc,lto --enable-gold --enable-lto --prefix=/usr/local/gcc45 Thread model: posix gcc version 4.5.0 20100314 (experimental) (GCC) > ld --version GNU gold (GNU Binutils for Ubuntu 2.20) 1.9 Copyright 2008 Free Software Foundation, Inc. This program is free software; y

[Bug lto/43372] New: lto ICE in strip_extension with linker plugin

t;. (I added an extra line to print that, so the ICE line number is off by 1.) Using gcc 20100314 and gold from Ubuntu binutils-gold 2.20-0ubuntu2. -- Summary: lto ICE in strip_extension with linker plugin Product: gcc Version: 4.5.0 Status: UNC

[Bug debug/43370] [4.4/4.5 Regression] ICE gen_type_die_with_usage, at dwarf2out.c:14745

--- Comment #3 from falk at debian dot org 2010-03-14 23:35 --- Confirmed, here is a testcase: int fragile_block(void) { typedef __attribute__ ((aligned (16))) struct { int i; } XmmUint16; return 0; } -- falk at debian dot org changed: What|Removed

[Bug lto/43342] lto1: internal compiler error: failed to reclaim unneeded function

--- Comment #4 from astrange at ithinksw dot com 2010-03-14 23:33 --- This happens building ffmpeg --enable-shared with -fwhopr. I can make a testcase out of that if needed. -- astrange at ithinksw dot com changed: What|Removed |Added -

[Bug driver/43371] Add -fresolution to the list of switches that take arguments

--- Comment #1 from d dot g dot gorbachev at gmail dot com 2010-03-14 23:30 --- Created an attachment (id=20105) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20105&action=view) Patch to add "fresolution" to gcc.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43371

[Bug driver/43371] New: Add -fresolution to the list of switches that take arguments

As this option must have an argument, I think it should be mentioned in DEFAULT_WORD_SWITCH_TAKES_ARG. Why it works now, because the next argument after it is a temporary response file, 1st line of which is fresolution's argument. However, this looks ugly... -- Summary: Add -fresoluti

[Bug c++/43368] [4.3/4.4/4.5 Regression] different access to templated structure static field give different results

--- Comment #1 from hjl dot tools at gmail dot com 2010-03-14 23:27 --- It is caused by revision 131044: http://gcc.gnu.org/ml/gcc-cvs/2007-12/msg00495.html -- hjl dot tools at gmail dot com changed: What|Removed |Added ---

[Bug c++/43370] ICE gen_type_die_with_usage, at dwarf2out.c:14745

--- Comment #2 from greggyh at gmail dot com 2010-03-14 23:06 --- gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9) Target: x86_64-linux-gnu g++ -c -g -Wall -W -o NcBaseEncoderSse2.o -save-temps NcBaseEncoderSse2.ii ../../codecs/nc/sse2/NcBaseEncoderSse2.cpp: In member function ‘virtual unsign

[Bug c++/43370] ICE gen_type_die_with_usage, at dwarf2out.c:14745

--- Comment #1 from greggyh at gmail dot com 2010-03-14 23:04 --- Created an attachment (id=20104) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20104&action=view) Preprocessed source that demonstrates the compiler error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43370

[Bug c++/43370] New: ICE gen_type_die_with_usage, at dwarf2out.c:14745

Using gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9) Target: x86_64-linux-gnu g++ -c -g -Wall -W -o NcBaseEncoderSse2.o -save-temps NcBaseEncoderSse2.ii ../../codecs/nc/sse2/NcBaseEncoderSse2.cpp: In member function ‘virtual unsigned int NcBaseEncoderSse2::fragile_block(unsigned int, const int16*)’:

[Bug rtl-optimization/43360] [4.3/4.4/4.5 Regression] possible wrong code bug

--- Comment #8 from jakub at gcc dot gnu dot org 2010-03-14 22:17 --- Well, it is always executed, just [`g_3'] in REG_EQUAL is not invariant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43360

[Bug c/43367] [4.5 Regression] ice: in may_propagate_copy, at tree-ssa-copy.c:85

--- Comment #1 from hjl dot tools at gmail dot com 2010-03-14 21:46 --- It is caused by revision 156076: http://gcc.gnu.org/ml/gcc-cvs/2010-01/msg00543.html -- hjl dot tools at gmail dot com changed: What|Removed |Added ---

[Bug rtl-optimization/43360] [4.3/4.4/4.5 Regression] possible wrong code bug

--- Comment #7 from ebotcazou at gcc dot gnu dot org 2010-03-14 21:40 --- > So, the solution is to teach loop2_invariant to also look into REG_EQUAL notes > if the insn is _really_ invariant or eventually clear REG_EQUAL notes when > insn is moved out of the loop. Both should already h

[Bug rtl-optimization/43360] [4.3/4.4/4.5 Regression] possible wrong code bug

--- Comment #6 from ubizjak at gmail dot com 2010-03-14 20:59 --- The problem is actually in loop2_invariant rtl pass, and -O1/-O2 difference is in fact due to missing cprop pass in -O1 case. So, before _.162r.loop2_invariant, we have: 6 [`g_3']=0x1 7 r61:SI=[`l_5_5_2'] L13:

[Bug c/43367] [4.5 Regression] ice: in may_propagate_copy, at tree-ssa-copy.c:85

-- hjl dot tools at gmail dot com changed: What|Removed |Added Summary|ice: in may_propagate_copy, |[4.5 Regression] ice: in |at tree-ssa-copy.c:85

[Bug java/43369] New: gcjh's CNI text options don't work

All of gcjh's -add -append -friend and -prepend don't work. For example, for the following source file a.java: public class a { } Compiled like so: gcj -C a.java gcjh -friend ::java::lang::Number a.class Results in the following header: // DO NOT EDIT THIS FILE - it is machine generated -*- c++

[Bug c++/43368] New: different access to templated structure static field give different results

Tested with Debian testing 4.4.3-3 and 4.3.4-8. Compiling this code snippet: template struct Foo { static int bar () { return field; } }; template struct X { static int x; typedef Foo foo; }; // This makes first statement in main() compile, but not the second... template <>

[Bug c/43367] New: ice: in may_propagate_copy, at tree-ssa-copy.c:85

[reg...@gamow tmp282]$ current-gcc -O2 small.c small.c: In function 'int327': small.c:29:1: internal compiler error: in may_propagate_copy, at tree-ssa-copy.c:85 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. [reg...@g

[Bug target/43360] [4.3/4.4/4.5 Regression] possible wrong code bug

--- Comment #5 from hjl dot tools at gmail dot com 2010-03-14 18:31 --- The patch started at: http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01682.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43360

[Bug target/43360] [4.3/4.4/4.5 Regression] possible wrong code bug

--- Comment #4 from hjl dot tools at gmail dot com 2010-03-14 18:25 --- It is caused by revision 121227: http://gcc.gnu.org/ml/gcc-cvs/2007-01/msg00933.html -- hjl dot tools at gmail dot com changed: What|Removed |Added ---

[Bug c++/43365] [4.5 Regression] Destructor not called when returning in exception handler

--- Comment #2 from hjl dot tools at gmail dot com 2010-03-14 17:27 --- It is caused by revision 151696: http://gcc.gnu.org/ml/gcc-cvs/2009-09/msg00443.html -- hjl dot tools at gmail dot com changed: What|Removed |Added ---

[Bug middle-end/43359] gas_dyn benchmark 230% slower when compiled with -fgraphite-identity

--- Comment #3 from dominiq at lps dot ens dot fr 2010-03-14 16:22 --- > we have a fix in hand... I tried it, but it does not fix the vectorization!-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43359

[Bug middle-end/43359] gas_dyn benchmark 230% slower when compiled with -fgraphite-identity

--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-03-14 15:49 --- Since these vectorization omissions are a regression from gcc 4.4 and apparently we have a fix in hand... http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00533.html shouldn't these bugs be bumped to P1 to ma

[Bug c++/43361] missing uninitialzied warning without optimization (loop representation)

--- Comment #1 from manu at gcc dot gnu dot org 2010-03-14 15:45 --- In GCC 4.3.x you need optimization enabled for Wuninitialized. In GCC 4.4.1 and GCC 4.5 (trunk) I get warnings in line 6 with -O1 -O2 and -O3. We do not get a warning with -O0 because the default definition appears in

[Bug c/43360] possible wrong code bug

--- Comment #3 from hjl dot tools at gmail dot com 2010-03-14 15:32 --- Gcc 4.3 also failed. It also failed on Linux/x86-64. -- hjl dot tools at gmail dot com changed: What|Removed |Added

[Bug fortran/43366] [OOP][F2008] Intrinsic assign to polymorphic variable

--- Comment #1 from burnus at gcc dot gnu dot org 2010-03-14 14:01 --- See "Variable must not be polymorphic in assignment" in resolve.c and note that realloc on assignment must be supported to get this working properly (might already work for derived types). -- http://gcc.gnu.org/b

[Bug fortran/43366] New: [OOP][F2008] Intrinsic assign to polymorphic variable

Fortran 2003 has in Section 7.4.1.2: "In an intrinsic assignment statement, variable shall not be polymorphic, and [...]" Fortran 2008 has in Section 7.2.1.2 "If variable is a coindexed object, the variable * shall not be polymorphic, [...]" and the previous restriction has been removed. --

[Bug c++/43365] [4.5 Regression] Destructor not called when returning in exception handler

--- Comment #1 from erik at ejohansson dot se 2010-03-14 13:57 --- Created an attachment (id=20103) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20103&action=view) Sample code that triggers the error With gcc 4.4.3: /usr/bin/g++ -o exception exception.cc && ./exception; echo $? 0

[Bug c++/43365] New: [4.5 Regression] Destructor not called when returning in exception handler

When returning from a function in an exception handler, the destructor for objects local to the function is never called. The attached program returns 0 (as expected) when compiled with: gcc version 4.4.3 (Debian 4.4.3-3) The same program returns 1 when compiled with: gcc version 4.5.0 20100310 (

[Bug fortran/43362] ICE with structure constuctor with DT component

--- Comment #3 from burnus at gcc dot gnu dot org 2010-03-14 13:37 --- FIXED on the trunk (4.5). -- burnus at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/43362] ICE with structure constuctor with DT component

--- Comment #2 from burnus at gcc dot gnu dot org 2010-03-14 13:18 --- Subject: Bug 43362 Author: burnus Date: Sun Mar 14 13:18:28 2010 New Revision: 157447 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157447 Log: 2010-03-14 Tobias Burnus PR fortran/43362 *

[Bug c/43364] New: Suboptimal code for the use of ARM NEON intrinsic "vset_lane_f32"

/***/ #include void neon_add(float * __restrict out, float * __restrict a, float * __restrict b) { float32x2_t tmp1, tmp2; tmp1 = vset_lane_f32(*a, tmp1, 0); tmp2 = vset_lane_f32(*b, tmp2, 0); tmp1 = vadd_f32(tmp1, tmp2); *out = vget_lane_f32(tmp1, 0); } /***/ 000

[Bug target/43358] internal compiler error: in pool_free, at alloc-pool.c:335

--- Comment #2 from steven at gcc dot gnu dot org 2010-03-14 12:53 --- (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) Starting program: /home/stevenb/devel/build-mips/gcc/cc1 -quiet -O1 t.c Breakpoint 1, fancy_abort (file=0x4

[Bug testsuite/43363] New: [4.5 Regression] FAIL: g++.dg/ext/altivec-17.C

The test g++.dg/ext/altivec-17.C fails: FAIL: g++.dg/ext/altivec-17.C (test for errors, line 15) FAIL: g++.dg/ext/altivec-17.C (test for excess errors) (see for instance http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01113.html ). This is due to a recent change in the error message that has no

[Bug fortran/43362] ICE with structure constuctor with DT component

--- Comment #1 from burnus at gcc dot gnu dot org 2010-03-14 12:46 --- Accept. I have a patch: http://gcc.gnu.org/ml/fortran/2010-03/msg00084.html -- burnus at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug inline-asm/37188] Missing documentation about the use of ARM NEON quad registers in inline asm arguments

--- Comment #3 from siarhei dot siamashka at gmail dot com 2010-03-14 12:44 --- As of today, gcc seems to be clever enough to deduct whether to use single precision or double precision VFP register when given "w" constraint (so P modifier is not strictly needed). This behavior seems to

[Bug inline-asm/41538] Mixing ARM/NEON intrinsic variables and inline assembly

--- Comment #5 from siarhei dot siamashka at gmail dot com 2010-03-14 12:23 --- Do you want to force data into specific neon registers because of the restriction on the neon registers which can be used as scalar operand for multiplication? It works for me. /**/

[Bug target/43348] [4.4 regression] ICE in final_scan_insn, at final.c:2604

--- Comment #5 from mikpe at it dot uu dot se 2010-03-14 11:45 --- Disabling the "Do not inline regular functions into always-inline functions" part of r156601 prevents the ICE: --- gcc-4.4-20100209/gcc/ipa-inline.c.~1~ +++ gcc-4.4-20100209/gcc/ipa-inline.c @@ -1421,7 +1421,7 @@ cgraph_

[Bug middle-end/42181] [4.5 Regression][graphite] -fgraphite-identity miscompiles air.f90

--- Comment #24 from dominiq at lps dot ens dot fr 2010-03-14 11:40 --- > We are executing the range [scat_1+1, T_10-2] before executing the > range [0, scat_1-1]. This would be OK if fctr had been initialized with the right value. Failing to do so leads to an early NAN. -- http://

[Bug middle-end/43359] gas_dyn benchmark 230% slower when compiled with -fgraphite-identity

--- Comment #1 from dominiq at lps dot ens dot fr 2010-03-14 11:20 --- The subroutines EOS and CHOZDT are not vectorized with -fgraphite-identity. See http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00515.html and http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00524.html for a possible fi

[Bug fortran/43362] New: ICE with structure constuctor with DT component

The following program gives an ICE with gfortran 4.1, 4.2, 4.3, 4.4, and 4.5. The program is valid (except for the one marked line) and compiles with NAG f95, ifort, and g95. With the marked line, it is invalid which is not diagnosed but also gives an ICE. implicit none type t integer, pointer :

[Bug rtl-optimization/42216] [4.5 Regression] changes in scheduling regress 464.h264ref 20%

--- Comment #26 from dominiq at lps dot ens dot fr 2010-03-14 09:33 --- I have posted a full regression testing with the patch in comment #23 at http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01182.html The failures are the usual ones and pr42220 is still fixed. -- http://gcc.gn

[Bug c/43360] possible wrong code bug

--- Comment #2 from mikpe at it dot uu dot se 2010-03-14 09:08 --- Confirmed current 4.4 is affected too, -01 works -O2 fails. Reduced test case: int l_5_5_2 = 4; int g_3[1][1]; void func_1 (void) { for (g_3[0][0] = 1; g_3[0][0] < 8; g_3[0][0] += 7) { int *l_6 = &g_3[0][0]; *

[Bug regression/43356] Wrong code and misleading warning "statement with no effect"

--- Comment #3 from ktietz at gcc dot gnu dot org 2010-03-14 08:20 --- Correct, the fmod-family was marked as pure, which is obviously wrong. Thanks, Kai -- ktietz at gcc dot gnu dot org changed: What|Removed |Added ---