[Bug target/39291] _Unwind_Backtrace fails.

--- Comment #3 from pluto at agmk dot net 2009-02-25 08:24 --- (In reply to comment #2) > I get this with your testcase on mingw32, DW@ build: > GNU C (GCC) version 4.4.0 20090221 (experimental) (mingw32) i have a gcc/dw2 configured with: Using built-in specs. Target: i486-pc-mingw32 C

[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c

--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-25 08:52 --- Sooo - what is the content of the .optimized dump? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39297

[Bug target/37520] [4.4 Regression] junk `(,%eax,4)' after expression / suffix or operands invalid for `lea' for libstdc++ deque/init-list.cc

--- Comment #11 from rguenth at gcc dot gnu dot org 2009-02-25 08:57 --- Let's make this P1 until we are sure it is not an ABI problem. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug middle-end/39298] New: Optimize away only set but not used variable

In the following Fortran program, the variable "foo" is never used, it is only set. Result: Using "gfortran -O3", "foo" is not optimized away. Expected: "foo" is optimized away as it happens with "ifort -O2". program a implicit none integer*8 it,two parameter(it=1073741824

[Bug middle-end/39298] Optimize away only set but not used variable

--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-25 09:43 --- Is there a reason the Fortran frontend gives function local variables static storage duration? a () { struct __st_parameter_dt dt_parm.1; static integer(kind=4) options.0[8] = {68, 255, 0, 0, 0, 1, 0, 1}; stat

[Bug middle-end/39298] Optimize away only set but not used variable

--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-25 09:51 --- It works with it == 1024 in which case foo is not static. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39298

[Bug c++/28274] [4.2/4.3/4.4 Regression] Redeclaration with extra default argument doesn't work

--- Comment #11 from andreasmeier80 at gmx dot de 2009-02-25 10:33 --- The target milestone 4.0.4 is wrong -- andreasmeier80 at gmx dot de changed: What|Removed |Added

[Bug middle-end/39298] Optimize away only set but not used variable

--- Comment #4 from burnus at gcc dot gnu dot org 2009-02-25 10:35 --- I did some testing with sunf95, icc and ifort. sunf95 also puts the variable in .bss as gfortran does, while ifort puts it on the stack (unless explicitly declared as static ["SAVE"]). If the variable is static, neit

[Bug middle-end/39298] Optimize away only set but not used variable

--- Comment #3 from burnus at gcc dot gnu dot org 2009-02-25 10:21 --- > Is there a reason the Fortran frontend gives function local variables static > storage duration? For huge arrays, there is a problem if the memory is allocated on the stack, as one quickly hits stack-size limits. T

[Bug tree-optimization/39299] New: wrong PTA for structure copies

At -O2 -fno-tree-sra we compute y.p as pointing to nothing. Which causes the abort to trigger on alias-improvements branch. struct X { long l1; struct Y { long l2; int *p; } y; }; int i; int foo (struct X *x) { struct Y y = x->y; *y.p = 0; i = 1; return *y.p; } extern void

[Bug middle-end/39298] Optimize away only set but not used variable

--- Comment #5 from rguenth at gcc dot gnu dot org 2009-02-25 11:21 --- Optimizing dead local static variables requires special handling which probably is not thought to be worth the trouble. If the variable is unused the programmer can as well remove it. -- http://gcc.gnu.org/bugz

[Bug tree-optimization/39300] New: vectorizer confused by predictive commoning

The loop in this test is not vectorized if either PRE or predictive commoning is active: % cat vecttest2.f subroutine Bench_StaggeredLeapfrog2( cctk_dim,XADM_curv_stag0, &ADM_kzz_stag,lgxx,nx) implicit none INTEGER cctk_dim INTEGER XADM_curv_stag0 REAL*8 ADM_kzz_s

[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp

--- Comment #16 from bonzini at gnu dot org 2009-02-25 12:18 --- The upcoming C++0x memory model forbids this; see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2338.html (Concurrency memory model compiler consequences). But it says that this is acceptable instead: tmp = v

[Bug fortran/39292] [4.3/4.4 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:3884

--- Comment #5 from pault at gcc dot gnu dot org 2009-02-25 13:05 --- Steve, > > At this stage in the 4.4 release process, I think my patch is too risky. > I've only done some limited testing. This should probably be considered > a 4.5 patch. > Should I apply mine, with a check that

[Bug tree-optimization/39299] wrong PTA for structure copies

--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-25 13:08 --- I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|

[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp

--- Comment #17 from rguenth at gcc dot gnu dot org 2009-02-25 13:25 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNC

Re: [Bug middle-end/39298] Optimize away only set but not used variable

Sent from my iPhone On Feb 25, 2009, at 1:43 AM, "rguenth at gcc dot gnu dot org" > wrote: --- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-25 09:43 --- Is there a reason the Fortran frontend gives function local variables static storage duration? Yes, it is larg

[Bug middle-end/39298] Optimize away only set but not used variable

--- Comment #6 from pinskia at gmail dot com 2009-02-25 13:37 --- Subject: Re: Optimize away only set but not used variable Sent from my iPhone On Feb 25, 2009, at 1:43 AM, "rguenth at gcc dot gnu dot org" wrote: > > > --- Comment #1 from rguenth at gcc dot gnu dot org 2009-0

[Bug tree-optimization/39300] vectorizer confused by predictive commoning

--- Comment #1 from matz at gcc dot gnu dot org 2009-02-25 13:53 --- For reference intel fortran (11.0) produces three loops, one where it uses predictive commoning (that is used when there are only few iterations): ..B1.7: # Preds ..B1.6 movsd 8(%r8)

[Bug tree-optimization/39300] vectorizer confused by predictive commoning

--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-25 13:56 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC|

[Bug c/39301] New: ICE in register_overhead, at bitmap.c:115

With this compiler: [luc...@descartes gambc-v4_4_1-devel]$ /pkgs/gcc-mainline/bin/gcc -v Using built-in specs. Target: powerpc64-unknown-linux-gnu Configured with: ../../mainline/configure --prefix=/pkgs/gcc-mainline --enable-languages=c --enable-gather-detailed-mem-stats --with-cpu=default64 Thre

[Bug other/39302] New: [meta-bug] bugs waiting for Copyright Assignment acknowledgemt for ARC International (UK) Ltd

Before patches from ARC International (UK) Ltd can be reviewed, it must be verified that a valid copyright assignment is on file at the FSF. This blocks a number of bugs where patches are available, but cannot be reviewed. -- Summary: [meta-bug] bugs waiting for Copyright Assignment

[Bug tree-optimization/39300] vectorizer confused by predictive commoning and PRE

--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-25 14:07 --- Simpler C testcase: float res[1024], data[1024]; void foo(void) { int i; float tmp = data[0]; for (i = 1; i < 1024; ++i) { float tmp2 = data[i]; res[i] = tmp + tmp2; tmp = tmp2; } }

[Bug tree-optimization/39300] vectorizer confused by predictive commoning and PRE

--- Comment #4 from irar at il dot ibm dot com 2009-02-25 14:08 --- Looks similar to PR 35229. We get here: # pre.1 = PHI .. load D.2 D.3 = D.2 + pre.1 + ... store D.3 -- irar at il dot ibm dot com changed: What|Removed |Added --

[Bug c/39301] ICE in register_overhead, at bitmap.c:115

--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-25 14:10 --- /* Store information about each particular bitmap. */ struct bitmap_descriptor { const char *function; const char *file; int line; int allocated; int created; int peak; int current; int nsearches; };

[Bug tree-optimization/35229] Vectorizer doesn't support dependence created by predictive commoning

--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-25 14:12 --- Indeed. Proper testcase: float res[1024], data[1024]; void foo(void) { int i; float tmp = data[0]; for (i = 1; i < 1024; ++i) { float tmp2 = data[i]; res[i] = tmp + tmp2; tmp = tmp2;

[Bug tree-optimization/35229] Vectorizer doesn't support dependence created by predictive commoning

--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-25 14:33 --- Or like the following, which is just a bunch of reductions of two elements float data[1024]; void foo(void) { int i; for (i = 1; i < 1024; ++i) data[i] = data[i] + data[i-1]; } -- http://gcc.gnu.org/bu

[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c

--- Comment #2 from hjl dot tools at gmail dot com 2009-02-25 14:37 --- (In reply to comment #1) > Sooo - what is the content of the .optimized dump? > ;; Function foo (foo) Analyzing Edge Insertions. foo (int len, int v) { long unsigned int D.1255; long unsigned int ivtmp.14; :

[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c

--- Comment #3 from pinskia at gcc dot gnu dot org 2009-02-25 14:41 --- Note index: again, bo. I thought I got rid of all those. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39297

[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c

--- Comment #4 from rguenther at suse dot de 2009-02-25 14:48 --- Subject: Re: [4.4 Regression] gcc.dg/tree-ssa/loop-31.c On Wed, 25 Feb 2009, hjl dot tools at gmail dot com wrote: > --- Comment #2 from hjl dot tools at gmail dot com 2009-02-25 14:37 > --- > (In reply to co

[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c

--- Comment #5 from hjl dot tools at gmail dot com 2009-02-25 14:53 --- Revision 144404 gave: ;; Function foo (foo) Analyzing Edge Insertions. foo (int len, int v) { short int * D.1254; short int * ivtmp.14; : if (len > 0) goto ; else goto ; : D.1254 = &a[0] + ((lon

[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c

--- Comment #6 from rguenther at suse dot de 2009-02-25 15:01 --- Subject: Re: [4.4 Regression] gcc.dg/tree-ssa/loop-31.c On Wed, 25 Feb 2009, hjl dot tools at gmail dot com wrote: > --- Comment #5 from hjl dot tools at gmail dot com 2009-02-25 14:53 > --- > Revision 144404

[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c

--- Comment #7 from hjl dot tools at gmail dot com 2009-02-25 15:09 --- Revision 144405 gave: .text .align 16 .global foo# .type foo#, @function .proc foo# foo: .prologue .body cmp4.ge p6, p7 = 0, r32 (p6) br.cond

[Bug rtl-optimization/39241] [4.4 Regression] ICE in subreg_get_info, at rtlanal.c:3104

--- Comment #6 from hjl dot tools at gmail dot com 2009-02-25 15:52 --- An updated patch is at http://gcc.gnu.org/ml/gcc-patches/2009-02/msg01171.html -- hjl dot tools at gmail dot com changed: What|Removed |Added -

[Bug target/39303] New: ARC port does not support ARCompact architecture

The ARC port that is currently in the FSF GCC does not support the ARCompact architecture, which is used by the current and ARC chips ARC600 and ARC700, and by the already superceded ARCtangent-A5. -- Summary: ARC port does not support ARCompact architecture Product: gcc

[Bug fortran/39304] New: ICE on module compilation

I am trying to compile a module for automatic differentiation. The file is called auto_deriv.f90 and is distributed by the journal Computer Physics Communications at http://www.cpc.cs.qub.ac.uk/summaries/ADLS_v1_0.html . However, when trying to compile this with gfortran -c auto_deriv.f90 I get:

[Bug fortran/39304] ICE on module compilation

--- Comment #1 from Huub dot van-Dam at stfc dot ac dot uk 2009-02-25 16:02 --- Created an attachment (id=17358) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17358&action=view) The file that fails to compile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39304

[Bug fortran/39304] ICE on module compilation

--- Comment #2 from Huub dot van-Dam at stfc dot ac dot uk 2009-02-25 16:03 --- Created an attachment (id=17359) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17359&action=view) A tiny sample program that uses auto_deriv.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3930

[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp

--- Comment #18 from davids at webmaster dot com 2009-02-25 16:06 --- This is a real bug. There is simply no way to write correct threaded code if the compiler is free to read a variable and write it back when the code didn't specifically tell it to. Optimizations on threaded code canno

[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp

--- Comment #19 from dnovillo at google dot com 2009-02-25 16:12 --- Subject: Re: Loop IM and other optimizations harmful for -fopenmp On Wed, Feb 25, 2009 at 11:06, davids at webmaster dot com wrote: > > > --- Comment #18 from davids at webmaster dot com  2009-02-25 16:

[Bug fortran/39304] ICE on module compilation

--- Comment #3 from dominiq at lps dot ens dot fr 2009-02-25 16:23 --- Confirmed on powerpc-apple-darwin9 (trunk rev. 144372, 4.2.3 and 4.3.3). g95 gives the following warning (lines 477, 488, 499, 510, 521, 532, and 543) Warning (158): INTENT(OUT) variable 'res' at (1) is never set

[Bug ada/39172] libada parsing of multilib options

--- Comment #2 from schwab at suse dot de 2009-02-25 16:43 --- The problem seems to be that the AWK makefile variable is not properly passed down to submakes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39172

[Bug tree-optimization/39305] New: tree-ssa-loop-ch.c:copy_loop_headers performs loop unrolling

For some simple loops with early exits, like libgcc2.c:__gcc_bcmp, copy_loop_headers copies not only the header, but also the loop body, and thus disables doloop optimizations. -- Summary: tree-ssa-loop-ch.c:copy_loop_headers performs loop unrolling Prod

[Bug ada/39172] libada parsing of multilib options

--- Comment #3 from schwab at suse dot de 2009-02-25 16:57 --- Created an attachment (id=17360) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17360&action=view) Candidate patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39172

[Bug ada/39172] libada parsing of multilib options

--- Comment #4 from schwab at suse dot de 2009-02-25 16:58 --- Can you please try out the attached patch? -- schwab at suse dot de changed: What|Removed |Added

[Bug middle-end/39274] internal compiler error: in check_cfg, at haifa-sched.c, var-tracking

--- Comment #2 from sergei_lus at yahoo dot com 2009-02-25 17:00 --- Thank you for the suggestion, but... I use schedule_ebbs in machine dependent reorg, and I do call compute_bb_for_insn before it. CFG is messed up before I get there... -- http://gcc.gnu.org/bugzilla/show_bug.c

[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c

--- Comment #8 from hjl dot tools at gmail dot com 2009-02-25 17:00 --- gcc.dg/tree-ssa/loop-31.c comes from PR 32283. This testcase only runs on arms and ia64. -- hjl dot tools at gmail dot com changed: What|Removed |Added

[Bug ada/39172] libada parsing of multilib options

--- Comment #5 from bonzini at gnu dot org 2009-02-25 17:03 --- Subject: Re: libada parsing of multilib options schwab at suse dot de wrote: > --- Comment #3 from schwab at suse dot de 2009-02-25 16:57 --- > Created an attachment (id=17360) --> (http://gcc.gnu.org/bugzilla/at

[Bug ada/39172] libada parsing of multilib options

--- Comment #6 from joel at gcc dot gnu dot org 2009-02-25 17:04 --- Can you include the generated files please? I do not have autoconf 2.59 installed. I can test the Ada build quickly though. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39172

[Bug c/39306] New: -fstack-check + large frame == SIGSEGV

Discovered as a failure of GDB test: FAIL: gdb.base/stack-checking.exp: continue to breakpoint: breakpoint for big frame With current SVN head @144426: /* t.c */ void foo() { char buf[524188]; } int main() { foo(); return 0; } i686-unknown-linux-gnu-gcc t.c -fstack-check && ./a.out Segmentation

[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp

--- Comment #20 from davids at webmaster dot com 2009-02-25 17:53 --- I don't like this either: tmp = var; modified = false; for (i = 0; i < 100; i++) { if (i > x) tmp = i, modified = true; } if (modified) var = tmp; This can be a pessimization as well

[Bug middle-end/39306] -fstack-check + large frame == SIGSEGV

--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-25 17:56 --- fstack-check is known to be broken on x86 GNU/Linux, see PR 13757. So I don't think this is a regression even. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39306

[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp

--- Comment #21 from matz at gcc dot gnu dot org 2009-02-25 18:04 --- The question if such transformation is or isn't worthwhile is independent from the issue at hand (which is about the validity in the light of the new memory model). If you find a clearly pessimizing but valid transfor

[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp

--- Comment #22 from pinskia at gcc dot gnu dot org 2009-02-25 18:07 --- Really to me this is still a valid transformation even in the inside threads. If you want to be able to access via different threads, use locks, heavy or light weight ones. -- http://gcc.gnu.org/bugzilla/show

[Bug fortran/39304] ICE on module compilation

--- Comment #4 from kargl at gcc dot gnu dot org 2009-02-25 18:08 --- Created an attachment (id=17361) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17361&action=view) Reduced testcase -- kargl at gcc dot gnu dot org changed: What|Removed |Ad

[Bug fortran/39304] ICE on module compilation

-- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fa

[Bug tree-optimization/39259] [4.4 Regression] internal compiler error: in initialize_cfun, at tree-inline.c:1749

--- Comment #8 from jamborm at gcc dot gnu dot org 2009-02-25 18:19 --- Fixed with: Author: jamborm Date: Wed Feb 25 17:34:40 2009 New Revision: 144428 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144428 Log: 2009-02-25 Martin Jambor * tree-inline.c (initialize_cfu

[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c

--- Comment #9 from hjl dot tools at gmail dot com 2009-02-25 18:24 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-02/msg01185.html -- hjl dot tools at gmail dot com changed: What|Removed |Added ---

[Bug fortran/39304] ICE with MATMUL, specific/generic functions and rank checking

--- Comment #5 from burnus at gcc dot gnu dot org 2009-02-25 18:30 --- Confirm. Also works with NAG f95. It fails with 4.1 to 4.4 and thus it does not seem to be a regression. It fails in spec_dimen_size for "dimen=1, as->rank=1". Some more debugging information from gfc_array_dimen_siz

[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c

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

[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp

--- Comment #23 from davids at webmaster dot com 2009-02-25 18:35 --- "Really to me this is still a valid transformation even in the inside threads. If you want to be able to access via different threads, use locks, heavy or light weight ones." Absolutely, you do use locks everywhere y

[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp

--- Comment #24 from bonzini at gnu dot org 2009-02-25 18:43 --- Andrew, your comments #6 #8 #9 clearly show that you haven't understood the issue and are just talking past others. The other hand the transformation has been shown to be an optimization on single-thread cases; if it is ba

[Bug c/39307] New: avr-gcc ICE in start_function, at c-decl.c:6248

Seen in avr-gcc 4.3.3 built using the script that comes with FemtoOS 0.88. [reg...@babel tmp40]$ avr-gcc -mmcu=atmega128 small.c small.c:3: internal compiler error: in start_function, at c-decl.c:6248 Please submit a full bug report, with preprocessed source if appropriate. See

[Bug rtl-optimization/39241] [4.4 Regression] ICE in subreg_get_info, at rtlanal.c:3104

--- Comment #7 from hjl at gcc dot gnu dot org 2009-02-25 18:49 --- Subject: Bug 39241 Author: hjl Date: Wed Feb 25 18:49:28 2009 New Revision: 144430 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144430 Log: gcc/ 2008-02-25 H.J. Lu PR rtl-optimization/39241

[Bug c/39307] avr-gcc ICE in start_function, at c-decl.c:6248

--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-25 18:50 --- *** This bug has been marked as a duplicate of 34299 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --

[Bug target/34299] [avr] ICE on function attribute syntax for main()

--- Comment #7 from pinskia at gcc dot gnu dot org 2009-02-25 18:50 --- *** Bug 39307 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug rtl-optimization/39241] [4.4 Regression] ICE in subreg_get_info, at rtlanal.c:3104

--- Comment #8 from hjl at gcc dot gnu dot org 2009-02-25 18:55 --- Subject: Bug 39241 Author: hjl Date: Wed Feb 25 18:55:14 2009 New Revision: 144431 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144431 Log: 2009-02-25 H.J. Lu Backport from mainline: 2008-0

[Bug rtl-optimization/39241] [4.4 Regression] ICE in subreg_get_info, at rtlanal.c:3104

--- Comment #9 from hjl dot tools at gmail dot com 2009-02-25 18:55 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW

[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c

--- Comment #10 from rakdver at gcc dot gnu dot org 2009-02-25 19:09 --- The difference between > D.1254 = &a[0] + ((long unsigned int) ((unsigned int) len + 4294967295) + 1) > * 2; (original) and > D.1255 = ((long unsigned int) &a + 2) + (long unsigned int) ((unsigned int) >

[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c

--- Comment #11 from hjl dot tools at gmail dot com 2009-02-25 19:18 --- (In reply to comment #10) > The difference between > > > D.1254 = &a[0] + ((long unsigned int) ((unsigned int) len + 4294967295) + > > 1) > > * 2; > > (original) and > > > D.1255 = ((long unsigned int) &a +

[Bug target/34299] [avr] ICE on function attribute syntax for main()

--- Comment #8 from regehr at cs dot utah dot edu 2009-02-25 20:01 --- Sorry for the dup. This bug prevents compilation of almost all TinyOS apps using 4.3.3! Is there a workaround? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34299

[Bug c++/28274] [4.2/4.3/4.4 Regression] Redeclaration with extra default argument doesn't work

--- Comment #12 from reichelt at gcc dot gnu dot org 2009-02-25 21:00 --- The culprit is in the function pushdecl_maybe_friend: Functions declared extern "C" bypass the usual mechanism, because duplicate_decls isn't called for them (see lines 727ff): else if ((DECL_EXTERN_C_F

[Bug c/39308] New: ICE when compiling with -O[s123] -floop-interchange

In almost any nontrivial C project, using GCC 4.4 SVN (rev 144432) results in an ICE when building with any nonzero value of -O and -floop-interchange. -- Summary: ICE when compiling with -O[s123] -floop-interchange Product: gcc Version: 4.4.0 Status:

[Bug c/39308] ICE when compiling with -O[s123] -floop-interchange

--- Comment #1 from il dot basso dot buffo at gmail dot com 2009-02-25 21:49 --- Created an attachment (id=17362) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17362&action=view) Preprocessed C source (from bzip2 sources) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39308

[Bug middle-end/36578] cast to long double not taken into account when result stored to a double

--- Comment #6 from janis at gcc dot gnu dot org 2009-02-25 22:09 --- Subject: Bug 36578 Author: janis Date: Wed Feb 25 22:08:55 2009 New Revision: 144436 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144436 Log: 2009-02-25 Janis Johnson gcc/ Backport from mainline:

[Bug tree-optimization/39248] FAIL: gcc.dg/vect/vect-complex-1.c

--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2009-02-25 22:35 --- Subject: Re: FAIL: gcc.dg/vect/vect-complex-1.c On Wed, 25 Feb 2009, irar at il dot ibm dot com wrote: > Does adding attribute aligned, as below, help? Yes, it fixes the failure. > Could you ple

[Bug target/39296] ICE in cselib_hash_rtx with -O -fPIC -mcmodel=large

--- Comment #2 from sgk at troutmask dot apl dot washington dot edu 2009-02-25 22:38 --- Subject: Re: ICE in cselib_hash_rtx with -O -fPIC -mcmodel=large On Wed, Feb 25, 2009 at 01:47:45AM -, hjl dot tools at gmail dot com wrote: > > --- Comment #1 from hjl dot tools at gmail

[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c

--- Comment #12 from rakdver at kam dot mff dot cuni dot cz 2009-02-25 22:41 --- Subject: Re: [4.4 Regression] gcc.dg/tree-ssa/loop-31.c > --- Comment #11 from hjl dot tools at gmail dot com 2009-02-25 19:18 > --- > (In reply to comment #10) > > The difference between > > >

[Bug c/39044] -Wformat warns on printf() with stringpointer as sole argument

--- Comment #3 from vapier at gentoo dot org 2009-02-25 23:58 --- i'd reconstruct this report as gcc not properly handling constant strings with printf() when the string is readily available to it and clearly does not change as for the kernel and this warning flag, that's a different is

[Bug target/34299] [avr] ICE on function attribute syntax for main()

--- Comment #9 from eric dot weddington at atmel dot com 2009-02-26 01:00 --- (In reply to comment #8) > Sorry for the dup. > > This bug prevents compilation of almost all TinyOS apps using 4.3.3! Is there > a workaround? > See comment #4 of this bug. -- http://gcc.gnu.org/bugz

[Bug c++/29027] template conversion specialization found by using declaration

--- Comment #2 from janis at gcc dot gnu dot org 2009-02-26 01:02 --- Subject: Bug 29027 Author: janis Date: Thu Feb 26 01:02:22 2009 New Revision: 13 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=13 Log: libcpp/ PR c/29027 * include/cpplib.h (CPP_N_DEFA

[Bug libobjc/27466] RFE: Support for libobjc equivalent of std::set_unexpected

--- Comment #6 from ayers at fsfe dot org 2009-02-26 05:16 --- Created an attachment (id=17364) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17364&action=view) Updated patch (using and accessor function) inlcuding a test case For the record: This is an update of the existing pat

[Bug libobjc/27466] RFE: Support for libobjc equivalent of std::set_unexpected

--- Comment #7 from ayers at fsfe dot org 2009-02-26 05:24 --- Created an attachment (id=17365) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17365&action=view) Alternative patch using a callback hook This patch was posted as an RFA: http://gcc.gnu.org/ml/gcc-patches/2009-02/msg01

[Bug fortran/39292] [4.3/4.4 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:3884

--- Comment #6 from pault at gcc dot gnu dot org 2009-02-26 06:24 --- Subject: Bug 39292 Author: pault Date: Thu Feb 26 06:23:42 2009 New Revision: 14 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=14 Log: 2009-02-26 Paul Thomas PR fortran/39292 * tra

[Bug inline-asm/39058] [4.3 regression] ICE with double in inline-asm

--- Comment #6 from uros at gcc dot gnu dot org 2009-02-26 07:07 --- Subject: Bug 39058 Author: uros Date: Thu Feb 26 07:06:48 2009 New Revision: 15 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=15 Log: Backport from mainline: 2009-02-02 Jakub Jelinek

[Bug inline-asm/39058] [4.3 regression] ICE with double in inline-asm

--- Comment #7 from ubizjak at gmail dot com 2009-02-26 07:23 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED