[Bug target/42894] [4.5 Regression] Invalid rtl sharing in Thumb1.

[abel at gcc dot gnu dot org]

--- Comment #6 from abel at gcc dot gnu dot org  2010-02-12 10:25 ---
I could take a look at this, but I cannot reproduce the ICE no matter how I
try, both with the full and reduced testcases, both with current trunk and the
one of Jan 29 (host x86-64, target
arm-oe-linux-uclibceabi/arm-unknown-linux-gnueabi).  Can someone tell exactly
how the compiler should be configured?


-- 

abel at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||abel at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42894

[Bug libstdc++/9679] Strange behaviour of valarray::apply method

[paolo dot carlini at oracle dot com]

--- Comment #12 from paolo dot carlini at oracle dot com  2010-02-12 10:43 
---
Ok, so this is resolved as WONTFIX. Anyway, the PR remains in the database, of
course, and if somebody has ideas, partial solutions, whatever, those are of
course welcome, but let's not keep the PR in this limbo state further, without
progress for years, it doesn't make any sense.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution||WONTFIX


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9679

[Bug libstdc++/9679] Strange behaviour of valarray::apply method

[gdr at integrable-solutions dot net]

--- Comment #13 from gdr at integrable-solutions dot net  2010-02-12 11:06 
---
Subject: Re:  Strange behaviour of valarray::apply method

On Thu, Feb 11, 2010 at 6:22 PM, paolo dot carlini at oracle dot com
 wrote:
> --- Comment #11 from paolo dot carlini at oracle dot com  2010-02-12 
> 00:22 ---
> Thanks. Thus, would you support closing this as WONTFIX?

if that is agreable to you, that is fine by me.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9679

[Bug fortran/43040] [lto] gfortran.dg/gamma_5.f90: Wrong code for call to gamma w/ -flto

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-02-12 11:07 ---
This is because the Fortran frontend has different DECL_FUNCTION_CODE for the
same builtins as the middle-end, so they get mixed up (in this case LGAMMA
and GAMMA).

This needs to be fixed.

I also see

  /* We define these separately as the fortran versions have different
 semantics (they return an integer type) */
  gfc_define_builtin ("__builtin_roundl", mfunc_longdouble[0],
  BUILT_IN_ROUNDL, "roundl", true);
...

ugh.  You can't overload existing builtin names with different semantics.
The middle-end expects that of gcc/builtins.def.  For the above case
there exists BUILT_IN_LROUNDL.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|middle-end  |fortran
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-02-12 11:07:37
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43040

[Bug fortran/43050] New: -fopenmp causes segementation fault with large arrays

[rknochenmuss at gmx dot net]

gfortran / gcc version 4.5.0 20100107 on OSX 10.6.2

This works if -fopenmp is _not_ used:
  INTEGER*4 LISTEL(6,6,2000,200) ! 5760 bytes
  COMMON/LKCELL/ LISTEL

It gives a runtime segmentation fault if -fopenmp is selected, even when there
are _no_ OMP directives in the code. 

It works if the array is smaller, for example:
INTEGER*4 LISTEL(6,6,2000,20) 

Does the -fopenmp gfortran option induce erroneous addressing of large common
arrays?


-- 
   Summary: -fopenmp causes segementation fault with large arrays
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rknochenmuss at gmx dot net
 GCC build triplet: x86_64-apple-darwin10
  GCC host triplet: x86_64-apple-darwin10
GCC target triplet: x86_64-apple-darwin10


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43050

[Bug fortran/43050] -fopenmp causes segementation fault with large arrays

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2010-02-12 12:40 ---
I cannot reproduce the problem with the array you have, but I can imagine one
problem with the real program.

By default, local variables of subroutines/functions are put into STATIC
memory; this no longer works if the function is called by different OpenMP
threads simultaneously - or if the procedure is called recursively. Thus all
local variables need to be put on the stack.

The stack is used for variables in a RECURSIVE routine or when the -frecursive
option (implied by -frecursive) is used. I would suggest to read the manual
(man page) under the keyword '-frecursive" (including cross references).

I do not know OSX well, but the following should work

  ulimit -s unlimited(Bash, SH)
  limit stacksize unlimited  (TCSH, CSH)

If you leave out the "unlimited", the current value will be shown. Note: The
maximally allowed value can be lower due to system-wide setting ("hard limit").


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43050

[Bug fortran/43050] -fopenmp causes segementation fault with large arrays

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2010-02-12 12:53 ---
As far as I know the "unlimited" stack size on Darwin cannot be larger than
64Mbytes. If you need/want more you need some special incantations:
-Wl,-stack_size,...
 (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42135 ). Note that I have
found that -stack_addr,...
must be added on 32 bit mode. 

Disclaimer: I have a very limited understanding of this feature and recommend
to look at the Apple's doc for any serious use of it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43050

[Bug debug/43051] New: [4.5 Regression] VTA causes a stack living parameter unavailable in most of the function

[jakub at gcc dot gnu dot org]

static void __attribute__((noinline))
foo (const char *x, long long y, int z)
{
  asm volatile ("" : : "r" (x), "r" ((int) y), "r" (z) : "memory");
}

typedef struct S
{
  struct S *n;
  int v;
} *P;

P
bar (P c, int v, P e)
{
  register int si asm ("esi"), di asm ("edi"), bx asm ("ebx");
  asm volatile ("" : "=r" (si), "=r" (di), "=r" (bx));
  while (c < e)
{
  foo ("c", (unsigned int) c, 0);
  foo ("v", v, 0);
  foo ("e", (unsigned int) e, 0);
  if (c->v == v) return c;
  foo ("c", (unsigned int) c, 0);
  foo ("v", v, 0);
  foo ("e", (unsigned int) e, 0);
  c++;
}
  asm volatile ("" : : "r" (si), "r" (di), "r" (bx));
  return 0;
}

at -g -O2 -m32 makes c unavailable in most of the function, while the c var is
for the whole time living in the parameter stack slot.  GCC 4.4.x and earlier
emit correct location info in this case.


-- 
   Summary: [4.5 Regression] VTA causes a stack living parameter
unavailable in most of the function
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: wrong-debug
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: i686-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43051

[Bug debug/43051] [4.5 Regression] VTA causes a stack living parameter unavailable in most of the function

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43051

[Bug debug/43051] [4.5 Regression] VTA causes a stack living parameter unavailable in most of the function

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43051

[Bug fortran/40850] double free in nested types with allocatable components

[domob at gcc dot gnu dot org]

--- Comment #8 from domob at gcc dot gnu dot org  2010-02-12 13:51 ---
I hit this bug, too, it seems.  My reduced test-case:

PROGRAM analysis
  IMPLICIT NONE

  TYPE numlist
REAL, ALLOCATABLE :: nums(:)
  END TYPE numlist

  TYPE(numlist) :: lines
  ALLOCATE (lines%nums(1))

  CALL test ((/ lines /))

CONTAINS

  SUBROUTINE test (vec)
TYPE(numlist), INTENT(IN) :: vec(:)
  END SUbROUTINE test

END PROGRAM analysis

This produces 126 lines of -fdump-tree-original, so I hope it may help here as
being "simpler" than the one posted by Janus (it seems).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40850

[Bug fortran/43040] Wrong decl for mathbuiltins -> wrong code with LTO

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2010-02-12 13:54 ---
(In reply to comment #2)
>   /* We define these separately as the fortran versions have different
>  semantics (they return an integer type) */
>   gfc_define_builtin ("__builtin_roundl", mfunc_longdouble[0],
> 
> ugh.  You can't overload existing builtin names with different semantics.
> The middle-end expects that of gcc/builtins.def.  For the above case
> there exists BUILT_IN_LROUNDL.

My impression is that the comment is old and does not apply to "roundl" as the
trans-intrinsics.c uses both BUILT_IN_ROUND* and BUILT_IN_LROUND - and given
that the "round*" were added much later than the comment according to svn
blame.

Having said that, I think one should check the other intrinsics in that file
(f95-lang.c) and remove then the bogus comment.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43040

[Bug debug/43051] [4.5 Regression] VTA causes a stack living parameter unavailable in most of the function

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-02-12 14:05 ---
Slightly smaller testcase:
static void __attribute__((noinline))
foo (const char *x, long long y)
{
  asm volatile ("" : : "r" (x), "r" ((int) y), "r" (0) : "memory");
}

typedef struct S
{
  struct S *n;
  int v;
} *P;

P
bar (P c, int v, P e)
{
  register int si asm ("esi"), di asm ("edi"), bx asm ("ebx");
  asm volatile ("" : "=r" (si), "=r" (di), "=r" (bx));
  while (c < e)
{
  foo ("c", (unsigned int) c);
  foo ("v", v);
  c++;
}
  asm volatile ("" : : "r" (si), "r" (di), "r" (bx));
  return 0;
}
again -g -O2 -m32.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43051

[Bug c++/43036] c++ compilation hang

[Roger dot Jeurninck at home dot nl]

--- Comment #7 from Roger dot Jeurninck at home dot nl  2010-02-12 14:14 
---
Created an attachment (id=19850)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19850&action=view)
test file


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43036

[Bug c++/43036] c++ compilation hang

[Roger dot Jeurninck at home dot nl]

--- Comment #8 from Roger dot Jeurninck at home dot nl  2010-02-12 14:15 
---
I have attached a file on which I could reproduce the hang on:
- sparc-sun-solaris2.8 / GCC 4.4.2
- sparc-sun-solaris2.10 / GCC 4.4.2
- sparc-sun-solaris2.10 / GCC 4.4.3
- i486-linux-gnu / GCC 4.4.2

I hope you can help me with the analysis of this issue.
thanks,

Roger


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43036

[Bug java/41802] When attempting to compile pdftk-1.41 my machine comes to a grind

[howarth at nitro dot med dot uc dot edu]

--- Comment #10 from howarth at nitro dot med dot uc dot edu  2010-02-12 
14:40 ---
Does slackware provide packaging files to show how they build their gcc?
Normally all you need to do is download
ftp://sourceware.org/pub/java/ecj-latest.jar and place it as ecj.jar in the top
of the gcc source tree for the build to properly utilize it. Does your stock
gcj compile simple java code like...

public class testme { 
  public static void main(String args[]){ 
System.out.println("Hello"); 
  } 
} 

with just 'gcj --main=testme -O testme.java'? You shouldn't need to pass more
than that for gcj to work if it is using ecj.jar.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41802

[Bug c/43052] New: Inline memcmp is *much* slower than glibc's

[bjorn at haxx dot se]

memcmp-intensive code becomes up to 6 times slower if compiled with the -O3
option than with the -g or -O0 option. The reason for this is that the inline
memcmp function is *much* slower than the glibc memcmp.

Here's a simple test case:

#include 
#include 
#include 
#include 

void* list[1024 * 1024];

int main(void)
{
int count = sizeof(list) / sizeof(char*);
int i;
for (i=0; i < count; i++)
list[i] = calloc(1024, 1);

int dupes = 0;
int start = times(NULL);
for (i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052

[Bug tree-optimization/43012] [4.5 Regression][graphite] wrong code for -floop-strip-mine in 453.povray

[spop at gcc dot gnu dot org]

--- Comment #11 from spop at gcc dot gnu dot org  2010-02-12 14:54 ---
You need to upgrade your CLooG-PPL to 0.15.8 for this testcase to not fail. 
I've put a comment in the testcase itself for this.

ftp://gcc.gnu.org/pub/gcc/infrastructure/cloog-ppl-0.15.8.tar.gz

Sebastian


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43012

[Bug debug/43053] New: DWARF info adds bogus const to 'this' argument

[drow at gcc dot gnu dot org]

Compile this code (from the GDB testsuite) with G++ (tested 4.4.3, trunk):

class foo {
public:
  int overload1arg (char);
};


int main ()
{
foo foo_instance1;
return 0;
}

int foo::overload1arg (char arg){ arg = 0; return 2;}

Here's the relevant bit of debug info:

 <2><2d>: Abbrev Number: 3 (DW_TAG_subprogram)
<2e>   DW_AT_external: 1
<2f>   DW_AT_name: (indirect string, offset: 0x59): overload1arg
<33>   DW_AT_decl_file   : 1
<34>   DW_AT_decl_line   : 3
<35>   DW_AT_MIPS_linkage_name: (indirect string, offset: 0x0):
_ZN3foo12overload1argEc
<39>   DW_AT_type: <0x4b>
<3d>   DW_AT_declaration : 1
 <3><3e>: Abbrev Number: 4 (DW_TAG_formal_parameter)
<3f>   DW_AT_type: <0x52>
<43>   DW_AT_artificial  : 1
 <3><44>: Abbrev Number: 5 (DW_TAG_formal_parameter)
<45>   DW_AT_type: <0x58>

 <1><94>: Abbrev Number: 12 (DW_TAG_subprogram)
<95>   DW_AT_specification: <0x2d>
<99>   DW_AT_decl_line   : 13
<9a>   DW_AT_low_pc  : 0xe
<9e>   DW_AT_high_pc : 0x25
   DW_AT_frame_base  : 0x38 (location list)
   DW_AT_sibling : <0xc6>
 <2>: Abbrev Number: 13 (DW_TAG_formal_parameter)
   DW_AT_name: (indirect string, offset: 0x66): this
   DW_AT_type: <0xc6>
   DW_AT_artificial  : 1
   DW_AT_location: 2 byte block: 91 0   (DW_OP_fbreg: 0)
 <2>: Abbrev Number: 14 (DW_TAG_formal_parameter)
   DW_AT_name: arg
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 13
   DW_AT_type: <0x58>
   DW_AT_location: 2 byte block: 91 64  (DW_OP_fbreg: -28)
 <1>: Abbrev Number: 15 (DW_TAG_const_type)
   DW_AT_type: <0x52>

The in-class declaration of foo::overload1arg function has two arguments, of
types <0x52> and <0x58>.  The out of line version references that with
DW_AT_specification, but has argument types <0xc6> and <0x58>.  The
specification has a foo * argument, the implementation has a foo * const
argument.

'this' can not be modified, so arguably the const is right.  But it should be
consistent between the two DIEs.


-- 
   Summary: DWARF info adds bogus const to 'this' argument
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: wrong-debug
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43053

[Bug c/43052] Inline memcmp is *much* slower than glibc's

[amonakov at gcc dot gnu dot org]

--- Comment #1 from amonakov at gcc dot gnu dot org  2010-02-12 15:45 
---
Confirmed. GCC simply emits repz cmpsb.  There was even an e-mail with
benchmark results and a patch (never applied):

http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02129.html


-- 

amonakov at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-02-12 15:45:19
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052

[Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location

[dodji at gcc dot gnu dot org]

--- Comment #1 from dodji at gcc dot gnu dot org  2010-02-12 15:48 ---
There are actually up to three destructors:

- an in-charge one (or complete-object one)
- a not-in-charge one
- a deleting in-charge one

The three of them are useful in different ways and in different circumstances. 

The destructor being represented in the DWARF output right now is the
"abstract" one, i.e. the one that got cloned (at most) 3 times into the 3
different types of destructors. It doesn't have any DW_AT_vtable_elem_location
precisely because that abstract version of destructor is not present in the
vtable. The destructors present in vtable are the clones. We do not output
those in the debug info today.

Daniel, why would you prefer having the DW_AT_vtable_elem_location only for the
in-charge one?

We could chose to have all three of them being represented in the DWARF output
but then there should be a way to say that they are different concrete
instances of the abstract ~A destructor. Maybe by using the extension
DW_AT_MIPS_clone_origin to make it point to the abstract constructor/destructor
instance which a particular constructor/destructor clone implements?


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dodji at gcc dot gnu dot org
 AssignedTo|dodji at gcc dot gnu dot org|unassigned at gcc dot gnu
   ||dot org
 Status|ASSIGNED|NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237

[Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location

[drow at gcc dot gnu dot org]

--- Comment #2 from drow at gcc dot gnu dot org  2010-02-12 15:52 ---
The type of the class only contains one destructor.  If you have to pick one
for a debugger to call, in-charge makes the most sense.  For other debugger
purposes they all make equal sense (or nonsense).

If you want to represent all three in the debug info, then not only do we need
to know that they are clones of the same function, we also need to know which
one is the in-charge versus not-in-charge versus deleting destructor to call
the right one for debugger implementation of the delete statement.

I'm pretty sure that would require new debug info extensions and new debugger
support.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237

[Bug c++/43054] New: [C++0x] ambiguous overload from identical declarations using decltype

[redi at gcc dot gnu dot org]

template struct future { };

#ifndef NO_PROTO
template
 auto
 async(Fn&& fn, Args&&... args)
 -> future;
#endif

template
 auto
 async(Fn&& fn, Args&&... args)
 -> future;

int work2(int value);

void work(int value)
{
 auto handle = async(work2, value);
}

trunk gives this error:

$ g++45 -std=c++0x -c -fmessage-length=70 pr42819.min2.cc
pr42819.min2.cc: In function 'void work(int)':
pr42819.min2.cc:19:34: error: call of overloaded 'async(int (&)(int),
   int&)' is ambiguous
pr42819.min2.cc:6:2: note: candidates are: future async(Fn&&, Args&& ...) [with Fn = int
   (&)(int), Args = {int&}, decltype (fn(async::args ...)) = int]
pr42819.min2.cc:12:2: note: future async(Fn&&, Args&& ...) [with Fn = int
   (&)(int), Args = {int&}, decltype (fn(async::args ...)) = int]
pr42819.min2.cc:19:34: error: unable to deduce 'auto' from
   ''

The declarations are identical and the error goes away if you define NO_PROTO.


-- 
   Summary: [C++0x] ambiguous overload from identical declarations
using decltype
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: redi at gcc dot gnu dot org
OtherBugsDependingO 42819
 nThis:


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43054

[Bug middle-end/37130] warning: array subscript is above array bounds.

[scott dot gccbugs dot 2009 at scottrix dot co dot uk]

--- Comment #6 from scott dot gccbugs dot 2009 at scottrix dot co dot uk  
2010-02-12 16:16 ---
I get this on 4.4.3 for x86 32bit, is there a patch, or will I have to wait for
4.5 to be released ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37130

[Bug debug/43051] [4.5 Regression] VTA causes a stack living parameter unavailable in most of the function

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-02-12 16:44 ---
So, when vt_find_locations visits the second time bb 4 in bar, it copies bb 4's
out set (just mentioning the important items):
  name: c D.1235
offset 0
  (value/s/u:SI 30:3972 @0x211f100/0x214cfa0)
 (value/s/u:SI 30:3972 @0x211f100/0x214cfa0)
offset 0
  (reg:SI 0 ax)
  (mem/f/c/i:SI (value/s/u:SI 20:3962 @0x211f010/0x214cd50) [2 cD.1235+0 S4
A32])
 (value/s/u:SI 20:3962 @0x211f010/0x214cd50)
offset 0
  (plus:SI (value/s/u:SI 19:19 @0x211eff8/0x214cdb0)
(const_int 8 [0x8]))
 (value/s/u:SI 19:19 @0x211eff8/0x214cdb0)
offset 0
  (value/s/u:SI 2:2 @0x211ec68/0x21338b0)
 (value/s/u:SI 2:2 @0x211ec68/0x21338b0)
offset 0
  (reg/f:SI 6 bp)
  (value/s/u:SI 6:6 @0x211ecc8/0x21337e0)
  (value/s/u:SI 13:13 @0x211ee00/0x2133910)
  (value/s/u:SI 19:19 @0x211eff8/0x214cdb0)
and bb 3's out set:
  name: c D.1235
offset 0
  (value/s/u:SI 9:9 @0x211ed10/0x2133720)
 (value/s/u:SI 9:9 @0x211ed10/0x2133720)
offset 0
  (mem/f/c/i:SI (value/s/u:SI 8:3945 @0x211ecf8/0x2133750) [2 cD.1235+0 S4
A32])
 (value/s/u:SI 8:3945 @0x211ecf8/0x2133750)
offset 0
  (plus:SI (value/s/u:SI 2:2 @0x211ec68/0x21338b0)
(const_int 8 [0x8]))
 (value/s/u:SI 2:2 @0x211ec68/0x21338b0)
offset 0
  (reg/f:SI 6 bp)
  (value/s/u:SI 6:6 @0x211ecc8/0x21337e0)
  (value/s/u:SI 13:13 @0x211ee00/0x2133910)
But as the VALUEs are different and some values are embedded inside of the
MEMs/PLUSs, intersect_loc_chains doesn't figure out that value 9:9 is actually
equivalent to value 30:3972.  Wonder whether intersect_loc_chains needs to do a
for_each_rtx search, comparing stuff other than values right away and comparing
values using recursive intersect_loc_chains.  And whether this wouldn't be too
expensive.

Wonder if http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01016.html could make a
difference here (i.e. if the star canonicalization would help), but then
I haven't heard a response to my query in
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01490.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43051

[Bug c++/43033] [4.4/4.5 Regression] --enable-checking=valgrind C++ failures

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2010-02-12 17:00 ---
Your patch is correct; the default3.C failure is exposing a latent bug whereby
we fail to combine the default args from two templates, as we can see with this
testcase that fails without the patch:

template void g4(int, int);
template void g4(int, int = 0) {}

int main()
{
  g4(0);
}

This worked in 2.95, but does not in 3.4.  See also PR 15339. Go ahead and
apply your patch, XFAIL that test in default3.C, and make a note of it in that
PR.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43033

[Bug debug/43051] [4.5 Regression] VTA causes a stack living parameter unavailable in most of the function

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-02-12 17:02 ---
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01016.html (without the IMHO wrong
swapping of the two traverses) doesn't help this case at all.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43051

[Bug java/41802] When attempting to compile pdftk-1.41 my machine comes to a grind

[lucabon at interfree dot it]

--- Comment #11 from lucabon at interfree dot it  2010-02-12 17:18 ---
(In reply to comment #10)
> Does slackware provide packaging files to show how they build their gcc?

Yes, sure. It is a "standard" build, with ecj.jar placed in the top source
tree, and it is exactly the same build script between 32 and 64 bits (always
x86 architecture), but only 64 bits has the problem. I could try another x86_64
distribution, but I think the problem is into gcc java interpreter...

> Does your stock gcj compile simple java code like...
> with just 'gcj --main=testme -O testme.java'? 

Yes, the problem seems to be only if ecj.jar (run by ecj1/gij interpreter) has
to compile many .java source files and in the same time it has to keep in
memory many bytecode .class file (option -fzip-target), like in pdftk.
If you run ecj.jar by Sun java interpreter or if you fully compile ecj.jar with
gcj to build a complete ecj1 (not only a wrapper for gij), pdftk compilation
works fine.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41802

[Bug fortran/43050] -fopenmp causes segementation fault with large arrays

[rknochenmuss at gmx dot net]

--- Comment #3 from rknochenmuss at gmx dot net  2010-02-12 17:18 ---
Thanks guys. Apparently it is a stack limitation. Using ulimit -a, the default
is:
stack size (kbytes, -s) 8192

ulimit-s unlimited is not permitted. The largest value allowed is 2, this
isnt enough to avoid the segmentation fault.

Dominque's suggestion solved the problem, at least at first glance (not fully
tested yet). Adding -Wl,-stack_size,0x2000 as a link option prevents the
seg fault.


-- 

rknochenmuss at gmx dot net changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43050

[Bug c++/43033] [4.4/4.5 Regression] --enable-checking=valgrind C++ failures

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-02-12 17:26 ---
Subject: Bug 43033

Author: jakub
Date: Fri Feb 12 17:26:12 2010
New Revision: 156734

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156734
Log:
PR c++/43033
* name-lookup.c (pushdecl_maybe_friend): Check default args of t
instead of x.

* g++.dg/other/default3.C: Xfail g4 test.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/other/default3.C


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43033

[Bug c++/43033] [4.4/4.5 Regression] --enable-checking=valgrind C++ failures

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-02-12 17:27 ---
Subject: Bug 43033

Author: jakub
Date: Fri Feb 12 17:27:33 2010
New Revision: 156735

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156735
Log:
PR c++/43033
* name-lookup.c (pushdecl_maybe_friend): Check default args of t
instead of x.

* g++.dg/other/default3.C: Xfail g4 test.

Modified:
branches/gcc-4_4-branch/gcc/cp/ChangeLog
branches/gcc-4_4-branch/gcc/cp/name-lookup.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/default3.C


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43033

[Bug target/42982] regression in gcc.dg/profile-generate-3.c

[davek at gcc dot gnu dot org]

--- Comment #4 from davek at gcc dot gnu dot org  2010-02-12 17:35 ---
Subject: Bug 42982

Author: davek
Date: Fri Feb 12 17:35:18 2010
New Revision: 156736

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156736
Log:
2010-02-12  Dave Korn  
Jack Howarth  
Iain Sandoe 

PR target/42982
Partial revert of unintended change in fix for PR41605.
* gcc/config/darwin.h: Fix typo.
* gcc/config/darwin9.h: Same.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/darwin.h
trunk/gcc/config/darwin9.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42982

[Bug java/43055] New: 'jc1: internal compiler error: Segmentation fault' using gcj -fprofile-arcs

[eldenc at tucsonembedded dot com]

Appear to be a recurrence of an older 'fixed' bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8260
I will attempt to compile the latest version gcj and see if the problem exists
there as well.
 test.java 
public class test {
  public static void main(String[] args) {
System.out.println("Hi Elden");
  }
}

gcj -fprofile-arcs -g --main=test test.java



eldenlinux2: /e/junk $ gcj -v
Using built-in specs.
Reading specs from /usr/lib/gcc/i486-linux-gnu/4.4.1/libgcj.spec
rename spec startfile to startfileorig
rename spec lib to liborig
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-5ubuntu2'
--with-bugurl=file:///usr/share/doc/gcj-4.4/README.Bugs
--enable-languages=c,c++,java --prefix=/usr --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --disable-libmudflap --enable-java-awt=gtk
--enable-gtk-cairo --disable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.4/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.4
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.4
--with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.1 (Ubuntu 4.4.1-5ubuntu2)


-- 
   Summary: 'jc1: internal compiler error: Segmentation fault'
using gcj -fprofile-arcs
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eldenc at tucsonembedded dot com
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43055

[Bug java/43055] 'jc1: internal compiler error: Segmentation fault' using gcj -fprofile-arcs

[eldenc at tucsonembedded dot com]

--- Comment #1 from eldenc at tucsonembedded dot com  2010-02-12 18:17 
---
Created an attachment (id=19851)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19851&action=view)
compiling this helloworld with 'gcj -fprofile-arcs -g --main=test test.java'
seg faults


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43055

[Bug middle-end/41290] [4.5 regression] ICE: edge points to wrong declaration

[jamborm at gcc dot gnu dot org]

--- Comment #16 from jamborm at gcc dot gnu dot org  2010-02-12 18:29 
---
Created an attachment (id=19852)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19852&action=view)
Patch making call statement redirection based on cgraph edges clearer

You may (or may not) be seeing an issue that I ran into when working
on devirtualization.  The attached patch should address it.  Can you
please try to compile your source with a patched gcc and see whthr it
helps?  If so, I'll try to push this change to 4.5.  If not, I'll keep
it for 4.6. Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41290

[Bug target/43047] internal compiler error: in extract_insn, at recog.c:2048

[danny dot backx at scarlet dot be]

--- Comment #4 from danny dot backx at scarlet dot be  2010-02-12 19:07 
---
pavilion: {16} arm-wince-pe-gcc -v
Using built-in specs.
Target: arm-wince-pe
Configured with:
/home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/gcc-4.4.0/configure
--with-gcc --with-gnu-ld --with-gnu-as --target=arm-wince-pe
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --prefix=/tmp/mingw32ce
--disable-threads --disable-nls --enable-languages=c --disable-win32-registry
--disable-multilib --disable-shared --disable-interwork --without-newlib
--enable-checking : (reconfigured)
/home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/gcc-4.4.0/configure
--with-gcc --with-gnu-ld --with-gnu-as --target=arm-wince-pe
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --prefix=/tmp/mingw32ce
--disable-threads --disable-nls --enable-languages=c --disable-win32-registry
--disable-multilib --disable-shared --disable-interwork --without-newlib
--enable-checking
Thread model: single
gcc version 4.4.0 (GCC) 
pavilion: {17} pwd
/home/danny
pavilion: {18} arm-wince-pe-gcc -c -DCRASH k.c
k.c: In function 'ff_fill_linesize':
k.c:12: error: unrecognizable insn:
(insn 6 5 7 3 k.c:9 (set (reg/f:SI 136 [ av_pix_fmt_descriptors.0 ])
(symbol_ref:SI ("av_pix_fmt_descriptors") [flags 0x440] )) -1 (nil))
k.c:12: internal compiler error: in extract_insn, at recog.c:2048
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
pavilion: {19} 


-- 

danny dot backx at scarlet dot be changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43047

[Bug target/42894] [4.5 Regression] Invalid rtl sharing in Thumb1.

[raj dot khem at gmail dot com]

--- Comment #7 from raj dot khem at gmail dot com  2010-02-12 19:39 ---
you could try standalone target 

../sources/gcc-trunk/configure --target=arm-none-eabi
--prefix=/scratch/oss/baremetal/arm-none-eabi/tools --enable-languages=c,c++
--with-newlib

and make sure that you pass -O0 -mthumb -march=armv5te
to gcc when compiling the testcase.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42894

[Bug target/43047] internal compiler error: in extract_insn, at recog.c:2048

[danny dot backx at scarlet dot be]

--- Comment #5 from danny dot backx at scarlet dot be  2010-02-12 19:44 
---
Err, I used the wrong build tree with my last message.

This is the result with vanilla gcc-4.4.0 configured for arm-wince-pe :
different but still wrong.

Apologies for the fuckup.

pavilion: {37} arm-wince-pe-gcc -c -DCRASH k.c
k.c:2: warning: array 'av_pix_fmt_descriptors' assumed to have one element
k.c:12: internal compiler error: in assemble_variable, at varasm.c:2144
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
pavilion: {38} 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43047

[Bug c++/43054] [C++0x] ambiguous overload from identical declarations using decltype

[jason at gcc dot gnu dot org]

--- Comment #1 from jason at gcc dot gnu dot org  2010-02-12 19:46 ---
Subject: Bug 43054

Author: jason
Date: Fri Feb 12 19:46:29 2010
New Revision: 156737

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156737
Log:
PR c++/43054
* tree.c (cp_tree_equal): Correct CALL_EXPR logic, handle
EXPR_PACK_EXPANSION.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic99.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43054

[Bug c++/15339] [DR217] Adding default arguments to function templates in redeclartions should be forbidden

[jakub at gcc dot gnu dot org]

--- Comment #13 from jakub at gcc dot gnu dot org  2010-02-12 19:56 ---
default3.C g4 test has been XFAILed, for details see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43033#c3


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15339

[Bug c++/43054] [C++0x] ambiguous overload from identical declarations using decltype

[jason at gcc dot gnu dot org]

--- Comment #2 from jason at gcc dot gnu dot org  2010-02-12 20:09 ---
Fixed.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43054

[Bug c++/43054] [C++0x] ambiguous overload from identical declarations using decltype

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2010-02-12 20:15 
---
Many thanks Jason.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43054

[Bug fortran/43050] -fopenmp causes segementation fault with large arrays

[rknochenmuss at gmx dot net]

--- Comment #4 from rknochenmuss at gmx dot net  2010-02-12 20:22 ---
Removing the stack limitation is slightly more complicated than I reported
earlier:

I have found it is not only necessary to use the link option previously
suggested by Dominique, it may also be necessary to set this environment
variable:

export GOMP_STACKSIZE=

before launching the executable.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43050

[Bug target/42431] [4.5 Regression] wrong code for 200.sixtrack with vectorization and -fdata-sections

[janis at gcc dot gnu dot org]

--- Comment #5 from janis at gcc dot gnu dot org  2010-02-12 20:35 ---
Created an attachment (id=19853)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19853&action=view)
minimized executable testcase

Compile with "-m64 -O2 -maltivec -ftree-vectorize -fdata-sections".


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42431

[Bug target/42431] [4.5 Regression] wrong code for 200.sixtrack with vectorization and -fdata-sections

[janis at gcc dot gnu dot org]

--- Comment #6 from janis at gcc dot gnu dot org  2010-02-12 20:36 ---
In the attached testcase wrong code is generated for the loop in subroutine
sub3 that sets 12 of the elements of array k to zero.  While minimizing the
testcase I saw different kinds of bad code for that array, but with this
version it's:

vxor 31,31,31
ld 9,@toc(2)
ld 29,@toc(2)
li 0,16 
stvx 31,0,29
add 9,9,9
stvx 31,0,9
stvx 31,9.0

Needless to say, doubling the array address has bad consequences.  It would
make
 sense if the instruction were instead "add 9,29,0"

I'm planning to stare at dump files for awhile but won't complain if someone
else figures it out first.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42431

[Bug target/42839] [4.5 Regression] gcc.target/mips/octeon-bbit-2.c failing for -mabi=64

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-02-12 20:49 ---
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-02-12 20:49:15
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42839

[Bug lto/42776] LTO doesn't work on non-ELF platforms.

[steven at gcc dot gnu dot org]

--- Comment #20 from steven at gcc dot gnu dot org  2010-02-12 20:57 ---
What is the plan for this bug, fix it for GCC 4.5.0 or for later?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776

[Bug middle-end/30905] [4.3/4.4/4.5 Regression] Fails to cross-jump

[steven at gcc dot gnu dot org]

--- Comment #18 from steven at gcc dot gnu dot org  2010-02-12 21:11 ---
As far as I'm concerned, this is WONTFIX for all affected compilers.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|steven at gcc dot gnu dot   |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30905

[Bug fortran/38282] Add the remaining HPF bit intrinsics

[steven at gcc dot gnu dot org]

--- Comment #4 from steven at gcc dot gnu dot org  2010-02-12 21:37 ---
I'm not working on this => unassign.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|steven at gcc dot gnu dot   |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38282

[Bug middle-end/41290] [4.5 regression] ICE: edge points to wrong declaration

[foom at fuhm dot net]

--- Comment #17 from foom at fuhm dot net  2010-02-12 21:46 ---
Thanks, I will try doing that.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41290

[Bug tree-optimization/18316] Missed IV optimization

[steven at gcc dot gnu dot org]

--- Comment #14 from steven at gcc dot gnu dot org  2010-02-12 21:46 ---
On x86_64 the two functions still give different code:

;; Function strength_test2 (strength_test2)

strength_test2 (int * data)
{
  unsigned int ivtmp.12;
  int * pretmp.9;
  int * pretmp.7;
  int k;
  int D.2743;
  int D.2741;
  int * D.2740;
  long unsigned int D.2739;
  long unsigned int D.2738;
  int D.2737;

:
  k_3 = *data_2(D);
  pretmp.7_24 = data_2(D) + 8;
  pretmp.9_26 = data_2(D) + 4;
  ivtmp.12_25 = (unsigned int) k_3;

:
  # ivtmp.12_5 = PHI 
  D.2737_6 = *pretmp.7_24;
  D.2738_7 = (long unsigned int) D.2737_6;
  D.2739_8 = D.2738_7 * 4;
  D.2740_9 = data_2(D) + D.2739_8;
  *D.2740_9 = 2;
  D.2741_28 = (int) ivtmp.12_5;
  D.2743_13 = *pretmp.9_26;
  ivtmp.12_12 = ivtmp.12_5 + ivtmp.12_25;
  if (D.2743_13 > D.2741_28)
goto ;
  else
goto ;

:
  return;

}



;; Function strength_result2 (strength_result2)

strength_result2 (int * data)
{
  unsigned int D.2772;
  unsigned int D.2773;
  unsigned int D.2774;
  int * pretmp.21;
  int i;
  int k;
  int D.2735;
  int * D.2733;
  long unsigned int D.2732;
  long unsigned int D.2731;
  int D.2730;

:
  k_3 = *data_2(D);
  pretmp.21_22 = data_2(D) + 8;
  pretmp.21_23 = data_2(D) + 4;

:
  # i_1 = PHI <0(2), i_25(3)>
  D.2730_6 = *pretmp.21_22;
  D.2731_7 = (long unsigned int) D.2730_6;
  D.2732_8 = D.2731_7 * 4;
  D.2733_9 = data_2(D) + D.2732_8;
  *D.2733_9 = 2;
  D.2772_5 = (unsigned int) i_1;
  D.2773_11 = (unsigned int) k_3;
  D.2774_24 = D.2772_5 + D.2773_11;
  i_25 = (int) D.2774_24;
  D.2735_12 = *pretmp.21_23;
  if (D.2735_12 > i_25)
goto ;
  else
goto ;

:
  return;

}


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2005-12-21 03:39:56 |2010-02-12 21:46:26
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18316

[Bug middle-end/15147] A REG rtx can be smaller if register renaming is rewritten such that ORIGINAL_REGNO can go away

[steven at gcc dot gnu dot org]

--- Comment #3 from steven at gcc dot gnu dot org  2010-02-12 21:49 ---
Not worth pursuing, since RTL is only a tiny amount of memory these days (with
all GIMPLE function bodies and all DF info in memory also).


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15147

[Bug target/12395] Suboptimal code with global variables

[steven at gcc dot gnu dot org]

--- Comment #15 from steven at gcc dot gnu dot org  2010-02-12 21:58 ---
GCC still doesn't get it right for this PR. The .139t.optimized dump for trunk
r156706:

;; Function foo (foo)

foo ()
{
  int a.1;
  int a.0;

:
  a.0_1 = a;
  a.1_2 = a.0_1 + 1;
  a = a.1_2;
  if (a.1_2 != 0)
goto ;
  else
goto ;

:
  a.1_5 = a.1_2 + 1;
  a = a.1_5;

:
  return;

}


Assembly output on ix86 (with -O2 -fomit-frame-pointer):

foo:
movla, %edx
leal1(%edx), %eax
testl   %eax, %eax
movl%eax, a
je  .L1
addl$2, %edx
movl%edx, a
.L1:
rep
ret


And on x86_64 (-O2):

foo:
.LFB0:
.cfi_startproc
movla(%rip), %edx
leal1(%rdx), %eax
testl   %eax, %eax
movl%eax, a(%rip)
je  .L1
addl$2, %edx
movl%edx, a(%rip)
.L1:
rep
ret
.cfi_endproc


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2008-09-21 13:52:33 |2010-02-12 21:58:52
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12395

[Bug rtl-optimization/34503] Issues with constant/copy propagation implementation in gcse.c

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34503

[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)

[steven at gcc dot gnu dot org]

--- Comment #10 from steven at gcc dot gnu dot org  2010-02-12 22:01 ---
Waiting for a m68k maintainer to do something here...


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19201

[Bug target/19204] [m68k] pea can force reloads that cause inefficient code

[steven at gcc dot gnu dot org]

--- Comment #2 from steven at gcc dot gnu dot org  2010-02-12 22:02 ---
Waiting for a m68k maintainer to do something here...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19204

[Bug target/19204] [m68k] pea can force reloads that cause inefficient code

[steven at gcc dot gnu dot org]

--- Comment #3 from steven at gcc dot gnu dot org  2010-02-12 22:02 ---
Waiting for a m68k maintainer to do something here...


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19204

[Bug target/19205] [m68k] avoid converting INDEX to SI mode if a narrower mode suffices

[steven at gcc dot gnu dot org]

--- Comment #4 from steven at gcc dot gnu dot org  2010-02-12 22:03 ---
Waiting for a m68k maintainer to do something here...


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19205

[Bug middle-end/19206] [cc0] insn-output.c should optimize sign-tests better

[steven at gcc dot gnu dot org]

--- Comment #2 from steven at gcc dot gnu dot org  2010-02-12 22:04 ---
No test case. No action.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19206

[Bug middle-end/19202] [cc0] Potential problem with cc_status.value2 (from old PROBLEMS)

[steven at gcc dot gnu dot org]

--- Comment #2 from steven at gcc dot gnu dot org  2010-02-12 22:05 ---
No test case. No action.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19202

[Bug middle-end/19202] [cc0] Potential problem with cc_status.value2 (from old PROBLEMS)

[steven at gcc dot gnu dot org]

--- Comment #3 from steven at gcc dot gnu dot org  2010-02-12 22:06 ---
.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19202

[Bug rtl-optimization/42839] [4.5 Regression] gcc.target/mips/octeon-bbit-2.c failing for -mabi=64

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-02-12 22:12 ---
The problem shows up at the tree level and nothing cleans it up after expand
for MIPS.
Take:
int
g (int n, int i)
{
  int s = 0;
  for (i = 0; i < n; i++)
s += i;
  return s;
}
--- CUT ---
For the above code expand on x86_64-linux-gnu produces (I simplified the
branches though but otherwise it is the same as what expand produces):
  r64 = %edi # n
  r65 = %esi #i
  if ( r64 <= 0 ) goto L37

  r61 = 0
  r62 = 0

L19:
  r61 = r61 + r62
  r62 = r62 + 1
  if ( r62 != r64 ) goto L19

  goto L22

L37:
  r61 = 0

L22:
  r63 = r61
  goto L27

L27:
  %eax = r63
  return

-- CUT ---

Notice how we have r61 = 0 which could be moved before the first branch which
allows us to remove a BB.

For x86_64, ce1 moves the r61 above the first branch but does not do it for
mips.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|target  |rtl-optimization
  GCC build triplet|*-*-*   |
   GCC host triplet|*-*-*   |
 GCC target triplet|mips64-unknown-linux|


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42839

[Bug c++/43024] [4.4 Regression] ICE on template code with -O2 or -O3, regression from 4.4.2

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2010-02-12 22:19 ---
This is basically the same bug as PR 41183.

We crash when trying to do name lookup during template substitution during
mangling during compilation of a clone. Cloning doesn't copy cfun->language, so
current_binding_level tries to look inside it and SEGVs.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43024

[Bug c++/43024] [4.4 Regression] ICE on template code with -O2 or -O3, regression from 4.4.2

[jason at gcc dot gnu dot org]

--- Comment #5 from jason at gcc dot gnu dot org  2010-02-12 22:21 ---
Created an attachment (id=19854)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19854&action=view)
delta-reduced testcase

this testcase is a lot smaller, but still not as reduced as I'd like


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43024

[Bug c++/43024] [4.4 Regression] ICE on template code with -O2 or -O3, regression from 4.4.2

[jason at gcc dot gnu dot org]

--- Comment #6 from jason at gcc dot gnu dot org  2010-02-12 22:27 ---
Subject: Bug 43024

Author: jason
Date: Fri Feb 12 22:27:04 2010
New Revision: 156740

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156740
Log:
PR c++/43024
* name-lookup.h (current_binding_level): Check for null
cp_function_chain.

Modified:
branches/gcc-4_4-branch/gcc/cp/ChangeLog
branches/gcc-4_4-branch/gcc/cp/name-lookup.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43024

[Bug c++/43024] [4.4 Regression] ICE on template code with -O2 or -O3, regression from 4.4.2

[jason at gcc dot gnu dot org]

--- Comment #7 from jason at gcc dot gnu dot org  2010-02-12 22:27 ---
Subject: Bug 43024

Author: jason
Date: Fri Feb 12 22:27:14 2010
New Revision: 156741

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156741
Log:
PR c++/43024
* name-lookup.h (current_binding_level): Check for null
cp_function_chain.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43024

[Bug rtl-optimization/42839] [4.5 Regression] gcc.target/mips/octeon-bbit-2.c failing for -mabi=64

[steven at gcc dot gnu dot org]

--- Comment #3 from steven at gcc dot gnu dot org  2010-02-12 22:27 ---
Basically yet another example of why it is a REALLY BAD IDEA to use constants
as PHI arguments. If the constant from "s =0" would not be propagated into the
PHI, the statement would not be dead and removed, and no new "s=0" would have
to be inserted in the wrong place.

See bug 42906 for another example of exactly the same problem.

Allowing constants as PHI arguments is GCC's biggest design f*ck-up.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42839

[Bug libstdc++/42819] [DR 1315][C++0x] std::async fails to compile with simple tests, including N3000 example

[paolo at gcc dot gnu dot org]

--- Comment #30 from paolo at gcc dot gnu dot org  2010-02-12 22:31 ---
Subject: Bug 42819

Author: paolo
Date: Fri Feb 12 22:31:15 2010
New Revision: 156742

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156742
Log:
2010-02-12  Jonathan Wakely  
Paolo Carlini  

PR libstdc++/42819, DR 1315
* include/std/future (async): Use std::result_of for the template
argument of the std::future return type; adjust everywhere.
* testsuite/30_threads/async/42819.cc: New.
* testsuite/30_threads/packaged_task/cons/assign_neg.cc: Adjust
dg-error line number.
* testsuite/30_threads/packaged_task/cons/copy_neg.cc: Likewise.
* testsuite/30_threads/future/cons/assign_neg.cc: Likewise.
* testsuite/30_threads/future/cons/copy_neg.cc: Likewise.
* testsuite/30_threads/promise/cons/assign_neg.cc: Likewise.
* testsuite/30_threads/promise/cons/assign_neg.cc: Likewise.

Added:
trunk/libstdc++-v3/testsuite/30_threads/async/42819.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/future
trunk/libstdc++-v3/testsuite/30_threads/future/cons/assign_neg.cc
trunk/libstdc++-v3/testsuite/30_threads/future/cons/copy_neg.cc
trunk/libstdc++-v3/testsuite/30_threads/packaged_task/cons/assign_neg.cc
trunk/libstdc++-v3/testsuite/30_threads/packaged_task/cons/copy_neg.cc
trunk/libstdc++-v3/testsuite/30_threads/promise/cons/assign_neg.cc
trunk/libstdc++-v3/testsuite/30_threads/promise/cons/copy_neg.cc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42819

[Bug c++/43033] [4.4/4.5 Regression] --enable-checking=valgrind C++ failures

[jason at gcc dot gnu dot org]

--- Comment #6 from jason at gcc dot gnu dot org  2010-02-12 22:32 ---
Fixed.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43033

[Bug libstdc++/42819] [DR 1315][C++0x] std::async fails to compile with simple tests, including N3000 example

[paolo dot carlini at oracle dot com]

--- Comment #31 from paolo dot carlini at oracle dot com  2010-02-12 22:34 
---
Done.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42819

[Bug target/36712] Inefficient loop unrolling

[steven at gcc dot gnu dot org]

--- Comment #20 from steven at gcc dot gnu dot org  2010-02-12 22:46 ---
Bug 27016 is another example of poor IVOPTS due to poor choices in
arm_arm_address_cost


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||27016


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712

[Bug target/27016] [4.3/4.4/4.5 Regression] ARM optimizer produces severely suboptimal code

[steven at gcc dot gnu dot org]

--- Comment #7 from steven at gcc dot gnu dot org  2010-02-12 22:52 ---
If arm_arm_address_cost is "fixed" to return 1 unconditionally, the expected
code of comment #5 comes out at -Os, with the bonus of one less branch:

testme:
ldr r2, .L4
ldr r1, .L4+4
sub r3, r2, #400
.L2:
ldr r0, [r1], #4
str r0, [r3], #4
cmp r3, r2
bne .L2
bx  lr

This is actually a regression from GCC 3.4.6.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rearnsha at gcc dot gnu dot
   ||org
  Component|middle-end  |target
 GCC target triplet|arm-elf-unknown |arm-elf, arm-eabi
  Known to fail||4.4.0 4.5.0
  Known to work||3.4.6
Summary|ARM optimizer produces  |[4.3/4.4/4.5 Regression] ARM
   |severely suboptimal code|optimizer produces severely
   ||suboptimal code


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27016

[Bug rtl-optimization/42839] [4.5 Regression] gcc.target/mips/octeon-bbit-2.c failing for -mabi=64

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2010-02-12 22:56 ---
But that is not the cause of the problem here.  The issue comes down to we
simplify in 4.5 (subreg (sign_extend (reg N) ) ) into (reg N). fwprop1 is doing
that change on the trunk.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42839

[Bug rtl-optimization/42839] [4.5 Regression] gcc.target/mips/octeon-bbit-2.c failing for -mabi=64

[steven at gcc dot gnu dot org]

--- Comment #5 from steven at gcc dot gnu dot org  2010-02-12 23:08 ---
Can you explain how? It's not clear from the code of your comment #2 how a
simplification would cause the extra basic block.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42839

[Bug c++/43024] [4.4 Regression] ICE on template code with -O2 or -O3, regression from 4.4.2

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2010-02-12 23:09 ---
Created an attachment (id=19855)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19855&action=view)
ice16.ii

Slightly reduced testcase using some more delta, I'm afraid now needs some
manual work to help further reduction and don't have time for that right now.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43024

[Bug rtl-optimization/42839] [4.5 Regression] gcc.target/mips/octeon-bbit-2.c failing for -mabi=64

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2010-02-12 23:14 ---
(In reply to comment #5)
> Can you explain how? It's not clear from the code of your comment #2 how a
> simplification would cause the extra basic block.

sorry if I was not clear here but there are two different issues with this
testcase.  the extra basic block is there for 4.4 still; just it uses the
branch likely instruction which is what the testcase is trying to test for. 
(for those who don't know the MIPS ISA, branch likely says the delay slot is
only executed if the branch is taken).

The extra simplification is causing the branch likely instruction not to used
as there is a way to combine the sign extend with the addition.  So there is an
extra instruction introduced early on.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42839

[Bug target/42431] [4.5 Regression] wrong code for 200.sixtrack with vectorization and -fdata-sections

[pthaugen at gcc dot gnu dot org]

--- Comment #7 from pthaugen at gcc dot gnu dot org  2010-02-12 23:16 
---
This looks like an ira/reload bug.  The ira dump is where the offending insns
first show up.

(insn 17 26 244 3 pr42431.f:27 (set (mem:V4SI (reg/f:DI 29 29 [255]) [4 S16
A128])
(reg:V4SI 108 31 [269])) 942 {*altivec_movv4si} (expr_list:REG_EQUAL
(const_vector:V4SI [
(const_int 0 [0x0])
(const_int 0 [0x0])
(const_int 0 [0x0])
(const_int 0 [0x0])
])
(nil)))

(insn 244 17 245 3 pr42431.f:27 (set (reg:DI 9 9)
(mem/u/c:DI (plus:DI (reg:DI 2 2)
(const:DI (unspec:DI [
(symbol_ref/u:DI ("*.LC2") [flags 0x2])
] 49))) [7 S8 A8])) 373 {*movdi_internal64} (nil))

(insn 245 244 20 3 pr42431.f:27 (set (reg:DI 9 9)
(plus:DI (reg:DI 9 9)
(reg:DI 9 9))) 83 {*adddi3_internal1} (nil))

(insn 20 245 246 3 pr42431.f:27 (set (mem:V4SI (reg:DI 9 9) [4 S16 A128])
(reg:V4SI 108 31 [269])) 942 {*altivec_movv4si} (expr_list:REG_EQUAL
(const_vector:V4SI [
(const_int 0 [0x0])
(const_int 0 [0x0])
(const_int 0 [0x0])
(const_int 0 [0x0])
])
(nil)))


insns 244/245 are not present in the prior (sched1) dump. insn 245 should be
adding the constant 16 to gpr9 instead of adding r9.


-- 

pthaugen at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pthaugen at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42431

[Bug rtl-optimization/42839] [4.5 Regression] gcc.target/mips/octeon-bbit-2.c failing for -mabi=64

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2010-02-12 23:35 ---
(In reply to comment #4)
> But that is not the cause of the problem here.  The issue comes down to we
> simplify in 4.5 (subreg (sign_extend (reg N) ) ) into (reg N). fwprop1 is 
> doing
> that change on the trunk.

Going back to revision 151021 (one right before the fix for PR 41081), fixes
the regression as we no longer froward prop the simplification any more.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||amodra at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42839

[Bug lto/42776] LTO doesn't work on non-ELF platforms.

[davek at gcc dot gnu dot org]

--- Comment #21 from davek at gcc dot gnu dot org  2010-02-13 01:06 ---
(In reply to comment #20)
> What is the plan for this bug, fix it for GCC 4.5.0 or for later?

I don't really think I can argue that this is stage3 material, so the plan is
to fix it when trunk reopens for 4.6, and I have Richard G's
agreement-in-principle to then backport it from head to the 4.5 branch for
4.5.1


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776

[Bug libstdc++/31970] set<>::iterator vs type-safety

[paolo dot carlini at oracle dot com]

--- Comment #9 from paolo dot carlini at oracle dot com  2010-02-13 01:44 
---
Actually, this is a feature, not a bug:

  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2913.pdf


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31970

Memo: Coca cola email notification (REF NO: LT/7914290166/CTV, BATCH: LM/51390-0/WGP).

[Coca cola in collaboration with Cyberworld International Inc .]

Your Email won you $1,00 in the Coca Cola online promo. To claim your prize 
email your full name, address &  tel. no. to Dr Shawn Kelly at 
drshawnkel...@gmail.com or call +447011137303, +447031835069 
Congratulations,
M. Sayeed

[Bug testsuite/42854] [4.4/4.5 Regression] FAIL: gcc.dg/darwin-weakimport-[13].c scan-assembler-not *

[howarth at nitro dot med dot uc dot edu]

--- Comment #7 from howarth at nitro dot med dot uc dot edu  2010-02-13 
05:09 ---
The weak_import attribute is described fairly well in this technote

http://developer.apple.com/mac/library/technotes/tn2002/tn2064.html#SECTION2


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42854

[Bug testsuite/42854] [4.4/4.5 Regression] FAIL: gcc.dg/darwin-weakimport-[13].c scan-assembler-not *

[howarth at nitro dot med dot uc dot edu]

--- Comment #8 from howarth at nitro dot med dot uc dot edu  2010-02-13 
06:09 ---
On darwin, it would appear that the change in r155919 is unnecessary. Using...

--- /Users/howarth/gcc-4.5-20100211/gcc/varasm.c2010-01-20
18:46:25.0 -0500
+++ gcc/varasm.c2010-02-13 00:23:56.0 -0500
@@ -2345,7 +2345,9 @@
 for declarations that can be weak, it happens to be
 match.  */
   && !TREE_STATIC (decl)
+#ifndef __APPLE__
   && lookup_attribute ("weak", DECL_ATTRIBUTES (decl))
+#endif
   && value_member (decl, weak_decls) == NULL_TREE)
 weak_decls = tree_cons (NULL, decl, weak_decls);

@@ -5290,9 +5292,11 @@
 warning (0, "weak declaration of %q+D not supported", decl);

   mark_weak (decl);
+#ifndef __APPLE__
   if (!lookup_attribute ("weak", DECL_ATTRIBUTES (decl)))
 DECL_ATTRIBUTES (decl)
   = tree_cons (get_identifier ("weak"), NULL, DECL_ATTRIBUTES (decl));
+#endif
 }

I find that g++.dg/template/instantiate11.C doesn't produce weak symbols in
instantiate11.s. The problem with r155919 on darwin is that it forces the
weak_import attribute to become weak in declare_weak and drops the decls for
weak_imports in assemble_external since it looks only for the weak attribute
and not weak_import (which is set in darwin.c).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42854

[Bug fortran/32382] missed optimization in internal read

[jvdelisle at gcc dot gnu dot org]

--- Comment #8 from jvdelisle at gcc dot gnu dot org  2010-02-13 06:17 
---
Created an attachment (id=19856)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19856&action=view)
Prelinary patch to fix this

The attached patch is preliminary.  It borrows the existing gfc_trans_do code
and creates special versions just for implied do loops in I/O statements.  This
adds a simple test to exit the loop on iostat of END, EOR, or EOF.  The
overhead is light relative to the I/O.

Speeds up the testcase from:

real0m2.100s
user0m0.777s
sys 0m0.009s

to:

real0m0.013s
user0m0.000s
sys 0m0.004s

I plan to refactor the code to simplify it all.  This first patch is just proof
of principle and does pass regression tests.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32382

[Bug fortran/38199] missed optimization: I/O performance

[jvdelisle at gcc dot gnu dot org]

--- Comment #8 from jvdelisle at gcc dot gnu dot org  2010-02-13 06:39 
---
I am reopening this bug.  I stumbled upon it searching testcases from Manfred, 
Running the test case here with 4.5 has not substantially improved.  Time to
put on my thinking cap.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|DUPLICATE   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199

[Bug fortran/38199] missed optimization: I/O performance

[jvdelisle at gcc dot gnu dot org]

--- Comment #9 from jvdelisle at gcc dot gnu dot org  2010-02-13 06:40 
---
Assigning to myself.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|REOPENED|ASSIGNED
   Last reconfirmed|2008-11-20 14:04:55 |2010-02-13 06:40:14
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199