[Bug fortran/37712] New: Parent component name getting confused with structure constructor

t%init (text) ! or... call base_init (base_t, text) this%value = value end subroutine end module [EMAIL PROTECTED]:/home/wws/fortran/oop> gfortran --version GNU Fortran (GCC) 4.4.0 20081001 (experimental) [trunk revision 140806] Copyright (C) 2008 Free Software Foundation, Inc. GN

[Bug tree-optimization/37690] typo in the example for -floop-strip-mine

--- Comment #2 from sebpop at gmail dot com 2008-10-02 06:18 --- Subject: Re: typo in the example for -floop-strip-mine The patch looks good. Please install. I also have installed a similar patch in htdocs/gcc-4.4/changes.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37690

Re: [Bug tree-optimization/37690] typo in the example for -floop-strip-mine

The patch looks good. Please install. I also have installed a similar patch in htdocs/gcc-4.4/changes.html

[Bug c/37711] Incorrect code generated for mips inline assembly

--- Comment #1 from andy-gcc at ultra-premium dot com 2008-10-02 04:37 --- Created an attachment (id=16449) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16449&action=view) Code for reproducing problem This is the example code from before and also a version of the function (GOOD_

[Bug c/37711] New: Incorrect code generated for mips inline assembly

I have some code which I believe is compiled incorrectly. It seems that the same register is being used for an input and an output, so the function returns incorrect results. The code can be compiled cleanly with a straight: "mipsel-linux-gcc filename.c" to reproduce the problem. If you look at t

[Bug libfortran/37707] Namelist read of array of derived type incorrect

--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-10-02 01:46 --- I am investigating. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added As

[Bug middle-end/37447] [4.4 Regression] test pr28982b.c fails execution on power4 or later with ira change

--- Comment #5 from luisgpm at linux dot vnet dot ibm dot com 2008-10-02 01:43 --- This problem also showed up as a CPU2000 regression in the Sixtrack benchmark for PPC64, causing problems in the ondering of ld/st instructions. A GCC patched with Richard's fix produced the right code a

[Bug target/33120] Large module object files when declare arrays on Mac OSX

--- Comment #2 from dave dot allured at noaa dot gov 2008-10-02 00:32 --- Confirmed this problem for gcc 4.3.1 on Mac OS 10.5.5. A workaround, and recommended best practice for new code, is to make arrays in modules allocatable, i.e. don't declare statically dimensioned large arrays.

[Bug middle-end/37710] New: When peeling an ordinary label off a case-table and making it a default label, strip from the end with identical labels.

See PR 35809, comment #3 : Looking at assembly-code for gcc.c-torture/execute/pr35800.c at r140821 reveals that the first case is still arbitrarily taken as the default, where the last one would have been better as it's repeated 32 times. So, w

[Bug middle-end/37447] [4.4 Regression] test pr28982b.c fails execution on power4 or later with ira change

--- Comment #4 from janis at gcc dot gnu dot org 2008-10-02 00:21 --- The test passes with a simple build of gcc with the patch from comment#3. I fired off a bootstrap and testsuite run. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37447

[Bug bootstrap/37702] Stage 2- C compiler cannot create executables-recent svn

--- Comment #6 from dannysmith at users dot sourceforge dot net 2008-10-02 00:20 --- In reply to comment #4) > xgcc: error trying to exec > '/cygdrive/c/jimdata/home/cvsroot/gcc-obj/./prev-gcc/cc1.exe': execv: > Permission denied > This may be related to: http://gcc.gnu.org/ml/gcc-bugs

[Bug middle-end/35809] default case label for casesi should be sliced off from last element

--- Comment #3 from hp at gcc dot gnu dot org 2008-10-02 00:14 --- Well, at least partially. The range is shifted and the number of values *is* now shrunk by one. Looking at assembly-code for gcc.c-torture/execute/pr35800.c at r140821 reveals that the first case is still arbitrarily ta

[Bug bootstrap/37702] Stage 2- C compiler cannot create executables-recent svn

--- Comment #5 from brian at dessent dot net 2008-10-02 00:10 --- Subject: Re: Stage 2- C compiler cannot create executables-recent svn What does "stat /cygdrive/c/jimdata/home/cvsroot/gcc-obj/./prev-gcc/cc1.exe" report? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37702

[Bug tree-optimization/37709] [4.4 Regression] inliner gone crazy

--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-01 23:48 --- The inlininer is going crazy some how. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --

[Bug c/37709] cc1: out of memory

--- Comment #1 from regehr at cs dot utah dot edu 2008-10-01 23:42 --- Created an attachment (id=16448) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16448&action=view) failure-inducing input -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37709

[Bug c/37709] New: cc1: out of memory

I don't know how much memory gcc is "supposed" to use but this seems disproportionate. Seen on r140777 on Ubuntu Hardy. Obviously the testcase itself is meaningless, but it is supposed to be free of undefined behavior. Before CPP it was about 37 kB. [EMAIL PROTECTED]:~/volatile/tmp43$ current-

[Bug bootstrap/37702] Stage 2- C compiler cannot create executables-recent svn

--- Comment #4 from pinskia at gcc dot gnu dot org 2008-10-01 23:40 --- xgcc: error trying to exec '/cygdrive/c/jimdata/home/cvsroot/gcc-obj/./prev-gcc/cc1.exe': execv: Permission denied -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37702

[Bug bootstrap/37702] Stage 2- C compiler cannot create executables-recent svn

--- Comment #3 from James dot W dot Mckelvey at jpl dot nasa dot gov 2008-10-01 23:36 --- Created an attachment (id=16447) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16447&action=view) Proper config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37702

[Bug middle-end/37447] [4.4 Regression] test pr28982b.c fails execution on power4 or later with ira change

--- Comment #3 from rth at gcc dot gnu dot org 2008-10-01 23:19 --- Created an attachment (id=16446) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16446&action=view) proposed patch Please try this and see if it works. I believe it does, since I see - stw 21,16(9) - a

[Bug middle-end/37447] [4.4 Regression] test pr28982b.c fails execution on power4 or later with ira change

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

[Bug middle-end/37689] [4.4 Regression] ICE compiling newlib

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot |

[Bug tree-optimization/37686] [4.4 Regression] Building of CPU2000's bzip2 with peak flags with -mcpu=power4 fails with an ICE.

--- Comment #13 from jakub at gcc dot gnu dot org 2008-10-01 22:20 --- Thanks, finally #c12 is something I can reproduce in native stage1. Will investigate this morning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37686

[Bug bootstrap/37702] Stage 2- C compiler cannot create executables-recent svn

--- Comment #2 from brian at dessent dot net 2008-10-01 22:11 --- Subject: Re: Stage 2- C compiler cannot create executables-recent svn That looks like the config.log from the top level, which is not the relevant file. The error happens in the stage2 intl/ directory, and there shoul

[Bug tree-optimization/37708] ICE: vector VEC(name_tree,base) index domain error, in loop_iv_stack_get_iv at graphite.c:123

--- Comment #2 from rguenth at gcc dot gnu dot org 2008-10-01 22:01 --- Probably a dup of PR37485. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug tree-optimization/37686] [4.4 Regression] Building of CPU2000's bzip2 with peak flags with -mcpu=power4 fails with an ICE.

--- Comment #12 from pinskia at gcc dot gnu dot org 2008-10-01 21:55 --- This is far as reduced testcase I could get, if I remove anything that is unrelated the ICE goes away: unsigned char inUse[256]; unsigned char len[6][258]; int code[6][258]; unsigned int crc32Table[256] = { }; un

[Bug c/37708] ICE: vector VEC(name_tree,base) index domain error, in loop_iv_stack_get_iv at graphite.c:123

--- Comment #1 from hbent at cs dot oberlin dot edu 2008-10-01 21:47 --- Created an attachment (id=16445) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16445&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37708

[Bug c/37708] New: ICE: vector VEC(name_tree,base) index domain error, in loop_iv_stack_get_iv at graphite.c:123

model: posix gcc version 4.4.0 20081001 (experimental) (GCC) aelfric% /usr/gcc/bin/gcc -O1 -w -fstrict-overflow -floop-block -o heapsort-acovea.c heapsort-acovea.c: In function 'HSORT': heapsort-acovea.c:180: internal compiler error: vector VEC(name_tree,base) index domain

[Bug libfortran/37707] Namelist read of array of derived type incorrect

--- Comment #1 from burnus at gcc dot gnu dot org 2008-10-01 21:42 --- Jerry, that sounds like something for you. I think Toon is right and ifort 10.1 prints (using a file as internal I/O does not work): 87 88 89 97 98 99 &NAMLIS

[Bug fortran/37706] [4.3, 4.4 Regression] ICE with use only and equivalent

--- Comment #4 from burnus at gcc dot gnu dot org 2008-10-01 21:34 --- Valgrind shows: ==5704==at 0x49B7AD: calculate_offset (trans-common.c:744) ==5704==by 0x49BAB9: add_equivalences (trans-common.c:859) ==5704==by 0x49DA01: gfc_trans_common (trans-common.c:1170) ==5704==

[Bug tree-optimization/37658] [4.3 Regression] long compile times in PRE on source with lots of labels/gotos

--- Comment #4 from rguenth at gcc dot gnu dot org 2008-10-01 21:32 --- Confirmed. SCC consists of: MPT.765_6816(ab) ...[5000 others snipped]... code_6815 MPT.765_6793 Danny has some speedup ideas, apart from that you can tune --parm sccvn-max-scc-size. A value of 5000 shrinks compile

[Bug fortran/37706] ICE with use only and equivalent

--- Comment #3 from dominiq at lps dot ens dot fr 2008-10-01 21:24 --- The ICE also disappears if 'l' is replaced by say 'l1' in the module data_C. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37706

[Bug libfortran/37707] New: Namelist read of array of derived type incorrect

The following program: type s integer m integer n end type s type(s) :: a(3) character*80 :: l = ' &namlis a%m=1,2, a%n=5,6, /' namelist /namlis/ a a%m=[87,88,89] a%n=[97,98,99] print*,a%m print*,a%n read(l,namlis) write(*,namlis) end prints: 87 88 89

[Bug fortran/37706] ICE with use only and equivalent

--- Comment #2 from dominiq at lps dot ens dot fr 2008-10-01 20:26 --- Confirmed, reduced code: module data_C integer, dimension(200) :: l integer :: l0 integer :: l24, l27, l28, l29 equivalence ( l(1), l0 ) end module data_C subroutine nuda

[Bug middle-end/22207] Spurious 'might be used uninitialized' warnings in STL headers with -O2

--- Comment #9 from brian at dessent dot net 2008-10-01 20:25 --- Subject: Re: Spurious 'might be used uninitialized' warnings in STL headers with -O2 You are confusing the state of the Cygwin port of gcc with gcc in general. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22207

[Bug regression/37686] [4.4 Regression] Building of CPU2000's bzip2 with peak flags with -mcpu=power4 fails with an ICE.

--- Comment #11 from pinskia at gcc dot gnu dot org 2008-10-01 20:23 --- If I change the GC Parameters, I get a different backtrace: #0 0x105c9abc in gsi_stmt (i=Cannot access memory at address 0x4 ) at /home/apinski/src/other/gcc/gcc/gimple.h:4392 #1 0x105dd4fc in verify_stmts () at

[Bug regression/37686] [4.4 Regression] Building of CPU2000's bzip2 with peak flags with -mcpu=power4 fails with an ICE.

--- Comment #10 from pinskia at gcc dot gnu dot org 2008-10-01 20:14 --- This was with: GNU C (GCC) version 4.4.0 20080929 (experimental) [trunk revision 140763] (powerpc64-unknown-linux-gnu) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37686

[Bug regression/37686] [4.4 Regression] Building of CPU2000's bzip2 with peak flags with -mcpu=power4 fails with an ICE.

--- Comment #9 from pinskia at gcc dot gnu dot org 2008-10-01 20:13 --- #0 0x10195c2c in single_exit (loop=0xf7b31930) at /home/apinski/src/other/gcc/gcc/cfgloop.c:1618 #1 0x106a1208 in number_of_latch_executions (loop=0xf7b31930) at /home/apinski/src/other/gcc/gcc/tree-scalar-evolutio

[Bug regression/37686] [4.4 Regression] Building of CPU2000's bzip2 with peak flags with -mcpu=power4 fails with an ICE.

--- Comment #8 from pinskia at gcc dot gnu dot org 2008-10-01 20:13 --- I can reproduce this even with a stage1 compiler. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug fortran/37706] ICE with use only and equivalent

--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-01 20:10 --- Reduced testcase: module data_C integer, dimension(200) :: l integer ::v equivalence ( l(1), l0 ) end module data_C subroutine nudata(a, l) USE data_C, only: v

[Bug fortran/37706] New: ICE: Segmentation fault

When the deck below is compiled with gfortran, an ICE occurs. Gfortran version: Using built-in specs. Target: i586-pc-linux-gnu Configured with: /home/fx/gfortran_nightbuild/trunk/configure --prefix=/home/fx/gfortran_nightbuild/irun-20080925 --enable-languages=c,fortran --build=i586-pc-linux-gnu -

[Bug middle-end/22207] Spurious 'might be used uninitialized' warnings in STL headers with -O2

--- Comment #8 from pdemarco at ppg dot com 2008-10-01 18:19 --- (In reply to comment #7) > (In reply to comment #6) > > okay, but I wish that you wouldn't freeze 3.x when 4.x is still in Alpha. > Alpha?!? What do you mean, exactly? Certainly we have a very stable 4.3.x > release series,

[Bug middle-end/22207] Spurious 'might be used uninitialized' warnings in STL headers with -O2

--- Comment #7 from paolo dot carlini at oracle dot com 2008-10-01 18:17 --- (In reply to comment #6) > okay, but I wish that you wouldn't freeze 3.x when 4.x is still in Alpha. Alpha?!? What do you mean, exactly? Certainly we have a very stable 4.3.x release series, and previously we

[Bug debug/37410] DW_TAG_imported_module is not in its DW_TAG_lexical_block

--- Comment #6 from jason at redhat dot com 2008-10-01 18:01 --- Subject: Re: DW_TAG_imported_module is not in its DW_TAG_lexical_block Please send patches to gcc-patches for review (and CC me) rather than attaching them to the PR. (It would be nice if a bot would notice relevant su

[Bug middle-end/35809] default case label for casesi should be sliced off from last element

--- Comment #2 from rguenth at gcc dot gnu dot org 2008-10-01 18:05 --- This is maybe fixed with the patch for PR37285? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added -

[Bug middle-end/22207] Spurious 'might be used uninitialized' warnings in STL headers with -O2

--- Comment #6 from pdemarco at ppg dot com 2008-10-01 18:04 --- (In reply to comment #5) > Sorry mate, all 3.x compilers are way past end-of-life now; there will never > be > another release. okay, but I wish that you wouldn't freeze 3.x when 4.x is still in Alpha. If I could upgrade

[Bug regression/37686] [4.4 Regression] Building of CPU2000's bzip2 with peak flags with -mcpu=power4 fails with an ICE.

--- Comment #7 from luisgpm at linux dot vnet dot ibm dot com 2008-10-01 17:44 --- I still can ICE it with the same flags in a native system. Any other info you'd like to have available? I have a more reduced source, will post it soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?i

[Bug c/37303] const compound initializers in structs are written to .data instead of .rodata

--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-01 17:25 --- >From C99 6.5.2.5/8: "String literals, and compound literals with const-qualified types, need not designate distinct objects" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37303

[Bug ada/37681] [4.4 regression] Building 64-bit libada fails on Solaris/x86: alignment error

--- Comment #9 from ro at techfak dot uni-bielefeld dot de 2008-10-01 17:17 --- Subject: Re: [4.4 regression] Building 64-bit libada fails on Solaris/x86: alignment error bonzini at gnu dot org writes: > No, there is not yet an extra configure switch for that, but I'll add it. You >

[Bug tree-optimization/37705] [graphite] Fix problems with SCoPs, that contain more than one loop

-- grosser at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Prio

[Bug tree-optimization/37705] New: [graphite] Fix problems with SCoPs, that contain more than one loop

Graphite calls limit_scops() to ensure, that every SCoP contains a single surrounding loop, as graphite - at the moment - is not able to handle SCoPs with two outermost loops or a bb not contained in any loop. In theory that is possible without problems, only some little bugs are in the way. So f

[Bug bootstrap/37704] New: RFE: Need specific version of --disable-multilib

As seen in PR ada/37681, lack of multilib support in a specific target library can break bootstrap. To avoid this without having to disable multilib support completely, it would be useful to have either a --disable-libada-multilib or (better yet) a generic --disable-multilib[=,]. --

[Bug middle-end/37154] static inline function problem

--- Comment #12 from pinskia at gcc dot gnu dot org 2008-10-01 17:11 --- GCC is doing the correct thing. Glibc is broken so closing as invalid as glibc has already been fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug middle-end/37154] static inline function problem

--- Comment #11 from sparky at pld-linux dot org 2008-10-01 16:47 --- Note: glibc problem have been detected and fixed already: - bug: https://bugzilla.redhat.com/show_bug.cgi?id=450790 - fix: http://www.sourceware.org/ml/libc-hacker/2008-06/msg1.html -- http://gcc.gnu.org/bugzi

[Bug tree-optimization/37617] [4.4 Regression] ICE on valid code

--- Comment #7 from edwintorok at gmail dot com 2008-10-01 16:43 --- Thanks, gcc4.4 doesn't crash anymore now. -- edwintorok at gmail dot com changed: What|Removed |Added

[Bug c++/37697] dynamic_cast to void cv* wrongly allowed with -fno-rtti

--- Comment #2 from algrant at acm dot org 2008-10-01 16:40 --- Bug report in error. -- algrant at acm dot org changed: What|Removed |Added Status|UNCONFIRMED

[Bug testsuite/37703] New: Ada testsuites lack multilib support

As I found while testing a patch for PR ada/37681, all parts of the Ada testsuite lack proper multilib support: * ada/acats isn't multilib-aware at all (i.e. runs only for the default multilib), and * gnat.dg at least runs the tests for all multilibs, but fails to pass the proper --RTS switc

[Bug ada/37309] Ada tasking is not implemented on NetBSD

--- Comment #3 from aran at 100acres dot us 2008-10-01 16:30 --- Created an attachment (id=16444) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16444&action=view) patch for svn trunk -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37309

[Bug tree-optimization/37617] [4.4 Regression] ICE on valid code

--- Comment #6 from rguenth at gcc dot gnu dot org 2008-10-01 16:24 --- Subject: Bug 37617 Author: rguenth Date: Wed Oct 1 16:23:23 2008 New Revision: 140816 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140816 Log: 2008-10-01 Richard Guenther <[EMAIL PROTECTED]> PR

[Bug tree-optimization/37617] [4.4 Regression] ICE on valid code

--- Comment #5 from rguenth at gcc dot gnu dot org 2008-10-01 16:24 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug bootstrap/37702] Stage 2- C compiler cannot create executables-recent svn

--- Comment #1 from James dot W dot Mckelvey at jpl dot nasa dot gov 2008-10-01 16:14 --- Created an attachment (id=16443) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16443&action=view) config.log from bootstrap -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37702

[Bug bootstrap/37702] New: Stage 2- C compiler cannot create executables-recent svn

Configuring stage 2 in ./intl configure: creating cache ./config.cache checking whether make sets $(MAKE)... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether NLS is requested... no checking for msgfmt... /usr/bin/msgfmt checking for gmsgfmt... /usr/bin/msgfmt checki

[Bug c++/37701] dynamic_cast to void cv* wrongly allowed with -fno-rtti

--- Comment #1 from algrant at acm dot org 2008-10-01 15:35 --- *** This bug has been marked as a duplicate of 37697 *** -- algrant at acm dot org changed: What|Removed |Added --

[Bug c++/37697] dynamic_cast to void cv* wrongly allowed with -fno-rtti

--- Comment #1 from algrant at acm dot org 2008-10-01 15:35 --- *** Bug 37701 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37697

[Bug c++/37701] New: dynamic_cast to void cv* wrongly allowed with -fno-rtti

Compiled -fno-rtti, g2 and g3 are faulted but g1 is not. Code for g1 (on ARM target) shows use of RTTI which we have asserted is absent. struct B1 { virtual int f(); }; struct B2 { virtual int g(); }; struct D: B1, B2 { }; /* These should be allowed even with -fno-rtti */ B1 *f2(B1 *p) { return

[Bug tree-optimization/37700] [alias-improvements-branch] redundant load doesn't get eliminated

--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-01 15:33 --- Smaller testcase, FRE should remove the redundancy but doesn't. unsigned int out[16]; unsigned int in[16]; unsigned int ia[16]; int foo (void) { unsigned int i; for (i = 0; i < 16; ++i) { out[i] = in

[Bug middle-end/37154] static inline function problem

--- Comment #10 from sparky at pld-linux dot org 2008-10-01 15:29 --- In that case the bug report is incorrect. The problem lays in glibc, in function lroundl which does not save cr3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37154

[Bug middle-end/37285] [4.4 Regression] ICE while building binutils on ppc

--- Comment #7 from rguenth at gcc dot gnu dot org 2008-10-01 15:11 --- Subject: Bug 37285 Author: rguenth Date: Wed Oct 1 15:09:26 2008 New Revision: 140814 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140814 Log: 2008-10-01 Richard Guenther <[EMAIL PROTECTED]> PR

[Bug middle-end/37285] [4.4 Regression] ICE while building binutils on ppc

--- Comment #6 from rguenth at gcc dot gnu dot org 2008-10-01 15:09 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug middle-end/14187] [tree-ssa] C restricted pointers are not properly implemented

--- Comment #15 from rguenth at gcc dot gnu dot org 2008-10-01 15:01 --- This is not solely a tree issue. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug middle-end/37696] [meta-bug] PRs blocking adoption of the alias-improvements branch

--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-01 14:54 --- Proper restrict implementation is required. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added -

[Bug tree-optimization/35737] [4.2/4.3/4.4 regression] ICE with __builtin_setjmp and complex variable

--- Comment #6 from rth at gcc dot gnu dot org 2008-10-01 14:42 --- Fixed. -- rth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug tree-optimization/33705] restrict doesn't improve char * aliasing

--- Comment #5 from rguenth at gcc dot gnu dot org 2008-10-01 14:40 --- This is because restrict is implemented as regular alias-sets. *** This bug has been marked as a duplicate of 14187 *** -- rguenth at gcc dot gnu dot org changed: What|Removed

[Bug tree-optimization/14187] [tree-ssa] restricted pointers should not alias on the tree level

--- Comment #14 from rguenth at gcc dot gnu dot org 2008-10-01 14:40 --- *** Bug 33705 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added -

[Bug target/15623] nop insertion does not look see restrict pointers

--- Comment #3 from rguenth at gcc dot gnu dot org 2008-10-01 14:31 --- Depends on proper restrict implementation. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --

[Bug tree-optimization/14187] [tree-ssa] restricted pointers should not alias on the tree level

--- Comment #13 from rguenth at gcc dot gnu dot org 2008-10-01 14:38 --- *** Bug 33272 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added -

[Bug middle-end/33272] Compiler does not take advantage of restrict

--- Comment #5 from rguenth at gcc dot gnu dot org 2008-10-01 14:38 --- The implementation detail of restrict makes the alias-oracle not work properly. Dup of PR14187 - restrict should be a PTA thing. *** This bug has been marked as a duplicate of 14187 *** -- rguenth at gcc dot gnu

[Bug tree-optimization/14187] [tree-ssa] restricted pointers should not alias on the tree level

--- Comment #7 from rguenth at gcc dot gnu dot org 2008-10-01 14:30 --- Note that C restrict semantics make it necessary to properly track what pointer is based on what other pointer. For this we miss both annotations and a (simple) propagator that propagates this information, maybe as

[Bug tree-optimization/14187] [tree-ssa] restricted pointers should not alias on the tree level

--- Comment #12 from rguenth at gcc dot gnu dot org 2008-10-01 14:35 --- *** Bug 32273 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added -

[Bug tree-optimization/32273] 'restrict' is forgotten after loop unrolling

--- Comment #6 from rguenth at gcc dot gnu dot org 2008-10-01 14:35 --- PR14187 again. *** This bug has been marked as a duplicate of 14187 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug tree-optimization/14187] [tree-ssa] restricted pointers should not alias on the tree level

--- Comment #11 from rguenth at gcc dot gnu dot org 2008-10-01 14:35 --- *** Bug 29239 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added -

[Bug middle-end/29239] -fno-strict-aliasing disables restrict

--- Comment #8 from rguenth at gcc dot gnu dot org 2008-10-01 14:35 --- This boils down to restrict being implemented as a different alias-set instead of as points-to information. Dup of PR14187. *** This bug has been marked as a duplicate of 14187 *** -- rguenth at gcc dot gnu dot

[Bug tree-optimization/37700] New: [alias-improvements-branch] redundant load doesn't get eliminated

This happens in testcase gcc.dg/vect/slp-19.c: The problem is with the loop at line 17: with trunk we detect that one of the elements of array 'in' is read twice, so we generate overall 8 loads (reusing one of them). On the alias branch we do not eliminate the extra load. All the reads and write a

[Bug tree-optimization/28030] missed optimization with load in a loop (restrict gets lost)

--- Comment #4 from rguenth at gcc dot gnu dot org 2008-10-01 14:34 --- *** This bug has been marked as a duplicate of 14187 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --

[Bug tree-optimization/14187] [tree-ssa] restricted pointers should not alias on the tree level

--- Comment #10 from rguenth at gcc dot gnu dot org 2008-10-01 14:34 --- *** Bug 28030 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added -

[Bug tree-optimization/14187] [tree-ssa] restricted pointers should not alias on the tree level

--- Comment #9 from rguenth at gcc dot gnu dot org 2008-10-01 14:33 --- *** Bug 16913 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug tree-optimization/16913] [4.2/4.3/4.4 Regression] restrict does not make a difference

--- Comment #13 from rguenth at gcc dot gnu dot org 2008-10-01 14:33 --- This is a dup of PR14187 - we simply fail to implement restrict properly. *** This bug has been marked as a duplicate of 14187 *** -- rguenth at gcc dot gnu dot org changed: What|Removed

[Bug tree-optimization/16306] [4.2/4.3/4.4 Regression] restrict and copying pointers problem

--- Comment #9 from rguenth at gcc dot gnu dot org 2008-10-01 14:32 --- This is effectively a dup of PR14187. We fail to track what pointers are based on a restrict pointer. *** This bug has been marked as a duplicate of 14187 *** -- rguenth at gcc dot gnu dot org changed:

[Bug tree-optimization/14187] [tree-ssa] restricted pointers should not alias on the tree level

--- Comment #8 from rguenth at gcc dot gnu dot org 2008-10-01 14:32 --- *** Bug 16306 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14187

[Bug tree-optimization/37699] New: [alias-improvements-branch] can't alias ptr and local array

This happens in gcc.dg/vect/vect-96.c and gcc.dg/vect/no-vfa-vect-43.c. In the first, we can't distinguish between a write through a (local) pointer to a global array (which is a field in a struct), and a read from a local array. s a result we vectorize the loop using loop-versioning controled by

[Bug tree-optimization/35737] [4.2/4.3/4.4 regression] ICE with __builtin_setjmp and complex variable

--- Comment #5 from rth at gcc dot gnu dot org 2008-10-01 14:32 --- Subject: Bug 35737 Author: rth Date: Wed Oct 1 14:30:37 2008 New Revision: 140813 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140813 Log: PR tree-opt/35737 * tree-complex.c (set_component_ssa

[Bug tree-optimization/35737] [4.2/4.3/4.4 regression] ICE with __builtin_setjmp and complex variable

--- Comment #4 from rth at gcc dot gnu dot org 2008-10-01 14:29 --- Subject: Bug 35737 Author: rth Date: Wed Oct 1 14:28:04 2008 New Revision: 140812 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140812 Log: PR tree-opt/35737 * tree-complex.c (set_component_ssa

[Bug tree-optimization/14187] [tree-ssa] restricted pointers should not alias on the tree level

--- Comment #6 from rguenth at gcc dot gnu dot org 2008-10-01 14:28 --- *** Bug 14192 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug middle-end/14192] Restrict pointers don't help

--- Comment #11 from rguenth at gcc dot gnu dot org 2008-10-01 14:28 --- Only two_restrict_pointers is valid. This is a dup of PR14187. *** This bug has been marked as a duplicate of 14187 *** -- rguenth at gcc dot gnu dot org changed: What|Removed

[Bug tree-optimization/37698] New: [alias-improvements-branch] pre makes latech-block non-empty

This happens in testcase gcc.dg/vect/vect-62.c: looks like on the alias branch pre is more powerful, as it moves the load into the latch block; as a result the latch block is not empty, and we fail to vectorize (with -fno-tree-pre vectorization succeeds). Related non-empty-latch PRs that prevernt

[Bug tree-optimization/37694] [alias-improvements-branch] can't alias (restrict) function-pointer (read) and local array (write)

--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-01 14:24 --- restricted pointers are still not properly handled by the middle-end, neither are they dealt with by the alias-oracle. -- rguenth at gcc dot gnu dot org changed: What|Removed |

[Bug c++/37697] New: dynamic_cast to void cv* wrongly allowed with -fno-rtti

Compiled -fno-rtti, g2 and g3 are faulted but g1 is not. Code for g1 (on ARM target) shows use of RTTI which we have asserted is absent. struct B1 { virtual int f(); }; struct B2 { virtual int g(); }; struct D: B1, B2 { }; /* These should be allowed even with -fno-rtti */ B1 *f2(B1 *p) { return

[Bug middle-end/37696] New: [meta-bug] PRs blocking adoption of the alias-improvements branch

Add PRs in the Depends on field. All dependent bugs are latent on the trunk in case partitioning would chose a pessimizing partitioning. -- Summary: [meta-bug] PRs blocking adoption of the alias- improvements branch Product: gcc Version: 4.4.

[Bug tree-optimization/37695] New: [alias-improvements-branch] can't alias a restrict pointer write and a local array read

This happens in gcc.dg/vect/vect-42.c: On the alias branch we can't tell that a write through a restrict pointer (which is a function argument) does not overlap with reads from local arrays. As a result we vectorize using loop-versioning controled by a run-time aliasing test. This in turn forces u

[Bug middle-end/22207] Spurious 'might be used uninitialized' warnings in STL headers with -O2

--- Comment #5 from dave dot korn at artimi dot com 2008-10-01 14:19 --- Sorry mate, all 3.x compilers are way past end-of-life now; there will never be another release. Your best bet is to hand-edit the header files in your local install. I don't remember the exact recipe, but of the

[Bug tree-optimization/37692] [alias-improvements-branch] can't alias fortran function arguments

--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-01 14:17 --- Mine. The alias-oracle doesn't use PTA information yet. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

  1   2   >