[Bug libfortran/18857] New: MATMUL failing with ALLOCATED matrices, unless base indices given

[Bug libfortran/18857] New: MATMUL failing with ALLOCATED matrices, unless base indices given

[paulthomas2 at wanadoo dot fr]

The below fails with CYGWIN_NT_5.1 + Windows XP (SP2) on AMD Athlon XP2600+ (M)

assertion "a->base == 0" failed: file "../../../gcc-4.0-
20041205/libgfortran/generated/matmul_r8.c",
line 157
Aborted (core dumped)

This does not happen on my Athlon XP1700 machine, nor on a PIV. I have built 
the 20041205 cvs and tried various snapshots, all with the same result.


!unless matmul line is substituted
program test_matmul
INTEGER, parameter      ::  n=2,m=2
real(kind=8), dimension(:,:),allocatable    ::  unity,x,w
allocate(unity(N,N),x(N,M),w(N,M))
unity(:,1)=(/1,0/)    ;    x(:,1)    =(/1,2/)
unity(:,2)=(/0,1/)    ;    x(:,2)    =(/3,4/)
w=matmul(unity,x)                         !crashes
!w(1:,1:)=matmul(unity(1:,1:),x(1:,1:))   !does not
print *,all(w.eq.w)
deallocate(unity,x,w)
end program test_matmul

-- 
           Summary: MATMUL failing with ALLOCATED matrices, unless base
                    indices given
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libfortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: paulthomas2 at wanadoo dot fr
                CC: gcc-bugs at gcc dot gnu dot org


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

[Bug libfortran/18857] MATMUL failing with ALLOCATED matrices, unless base indices given

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-06 21:29 -------
Confirmed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-12-06 21:29:14
               date|                            |


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

[Bug libfortran/18857] MATMUL failing with ALLOCATED matrices, unless base indices given

[tobi at gcc dot gnu dot org]

------- Additional Comments From tobi at gcc dot gnu dot org  2004-12-08 23:44 -------
The error is precise a->base == 0 is not true, because we don't initialize it to
zero: from the t02.original dump:
  unity.data = 0B;
  w.data = 0B;
  x.data = 0B;
  {
    real8[] * * D.475;

    unity.dtype = 538;
    unity.dim[0].lbound = 1;
    unity.dim[0].ubound = 2;
    unity.dim[0].stride = 1;
    unity.dim[1].lbound = 1;
    unity.dim[1].ubound = 2;
    unity.dim[1].stride = 2;
    D.475 = &unity.data;
    _gfortran_allocate (D.475, 32, 0);
    unity.offset = -3;   <----------------------------------------
  }
and the same for w and x.

-- 


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

[Bug fortran/18857] MATMUL failing with ALLOCATED matrices, unless base indices given

[tkoenig at gcc dot gnu dot org]

------- Additional Comments From tkoenig at gcc dot gnu dot org  2005-04-19 18:51 -------
descriptor.offset (in the front end) aka descriptor->base
in the library is currently useless.

Look at this:

$ cat offset.f90
program main
  real :: a(2,2)
  real, allocatable :: b(:,:)
  real, pointer :: c(:,:)
  call foo(a)
  allocate(b(2,2),c(2,2))
  call foo(b)
  call foo(c)
contains
  subroutine foo(a)
    real, dimension(:,:) :: a
    a(1,1) = 1.0
  end subroutine foo
end program main
$ gfortran -fdump-tree-original offset.f90

>From the .original file:

foo (a)
{
  int4 ubound.0;
  int4 stride.1;
  int4 ubound.2;
  int4 stride.3;
  int4 offset.4;
  real4[0:] * a.0;

  {
    int4 D.484;

    D.484 = a->dim[0].stride;
    stride.1 = D.484 == 0 ? 1 : D.484;
    a.0 = (real4[0:] *) a->data;
    ubound.0 = a->dim[0].ubound - a->dim[0].lbound + 1;
    stride.3 = a->dim[1].stride;
    ubound.2 = a->dim[1].ubound - a->dim[1].lbound + 1;
    offset.4 = -stride.1 - NON_LVALUE_EXPR <stride.3>;
  }
  (*a.0)[NON_LVALUE_EXPR <stride.1> + NON_LVALUE_EXPR <stride.3> + offset.4] =
1.0e+0;
}

You can see that offset.4 is calculated without a reference to a->offset.
This is a good thing, because the offset is only calculated correctly
for static arrays:

MAIN__ ()
{
  struct array2_real4 c;
  real4 a[4];
  struct array2_real4 b;
  static void foo (struct array2_real4 &);

  c.data = 0B;
  b.data = 0B;
  {
    struct array2_real4 parm.5;

    parm.5.dtype = 282;
    parm.5.dim[0].lbound = 1;
    parm.5.dim[0].ubound = 2;
    parm.5.dim[0].stride = 1;
    parm.5.dim[1].lbound = 1;
    parm.5.dim[1].ubound = 2;
    parm.5.dim[1].stride = 2;
    parm.5.data = (real4[0:] *) (real4[0:] *) &a[0];
    parm.5.offset = 0;
             ^^^^^^^^^^
             This is wrong.
    foo (&parm.5);
  }

For allocated and pointer arrays, this is done correctly:
 {
    real4[0:] * * D.504;

    b.dtype = 282;
    b.dim[0].lbound = 1;
    b.dim[0].ubound = 2;
    b.dim[0].stride = 1;
    b.dim[1].lbound = 1;
    b.dim[1].ubound = 2;
    b.dim[1].stride = 2;
    D.504 = &b.data;
    _gfortran_allocate (D.504, 16, 0);
    b.offset = -3;
             ^^^^^^^
             correct
  }
  {
    real4[0:] * * D.505;

    c.dtype = 282;
    c.dim[0].lbound = 1;
    c.dim[0].ubound = 2;
    c.dim[0].stride = 1;
    c.dim[1].lbound = 1;
    c.dim[1].ubound = 2;
    c.dim[1].stride = 2;
    D.505 = &c.data;
    _gfortran_allocate (D.505, 16, 0);
    c.offset = -3;
             ^^^^^^
             correct
  }
  foo (&b);
  foo (&c);

The assert is therefore false and should be removed.

The question remains: What to do with the offset field?
Fix it in the front end for static arrays, or remove it
altogether?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Thomas dot Koenig at online
                   |                            |dot de


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

[Bug fortran/18857] MATMUL failing with ALLOCATED matrices, unless base indices given

[tobi at gcc dot gnu dot org]

------- Additional Comments From tobi at gcc dot gnu dot org  2005-04-25 14:13 -------
(In reply to comment #3)
> The question remains: What to do with the offset field?
> Fix it in the front end for static arrays, or remove it
> altogether?

The offset field is used for something like this:
  REAL, POINTER :: a(:), c(:)
  REAL, TARGET :: b(25)
  a => b(5:)
  c => a(3:)
  end

I'm not sure this could be done without it, especially in the multi-dimensional
case.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tobi at gcc dot gnu dot org


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

[Bug fortran/18857] MATMUL failing with ALLOCATED matrices, unless base indices given

[paulthomas2 at wanadoo dot fr]

------- Additional Comments From paulthomas2 at wanadoo dot fr  2005-04-25 15:35 -------
Subject: Re:  MATMUL failing with ALLOCATED matrices, unless base indices given

>> The question remains: What to do with the offset field?
>> Fix it in the front end for static arrays, or remove it
>> altogether?
>
> The offset field is used for something like this:
>  REAL, POINTER :: a(:), c(:)
>  REAL, TARGET :: b(25)
>  a => b(5:)
>  c => a(3:)
>  end
>
Nonetheless, matmul is the only case where this assertion is imposed in the 
m4 functions.  It doesn't do anything, except assert the "pathological 
case".

I was going to consider all the variants tonight, including your example. 
Your message has spurred me on.

Paul 




-- 


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

[Bug fortran/18857] MATMUL failing with ALLOCATED matrices, unless base indices given

[paulthomas2 at wanadoo dot fr]

------- Additional Comments From paulthomas2 at wanadoo dot fr  2005-04-25 20:31 -------
Subject: Re:  MATMUL failing with ALLOCATED matrices, unless base indices given

Tobi,

Does this do it for you? - it works with those assertions eliminated.

!{ dg-do run }
! Test MATMUL for various kinds of array.
! provided by Paul Thomas - pault@gcc.gnu.org

Program test_matmul
  integer, parameter                                :: N = 5
  integer, parameter                                :: T = 4
  real(kind=T), dimension(:,:), allocatable, Target :: a, b, c
  real(kind=T), dimension(:,:), POINTER             :: d, e
  real(kind=T), dimension(N,N)                      :: x, y, z

  allocate (a(2*N, N), b(N, N), c(2*N, N))
  a = 1.0_T
  a(1:N,:) = 2.0_T
  b = 4.0_T
  x = 1.0_T
  y = 2.0_T

  z = 0.0_T
  z = matmul (x, y)
  if (sum (z) /= 250.0_T) call abort ()

  c = 0.0_T
  c = matmul (a, b)
  if (sum (c) /= 1500.0_T) call abort ()

  c = 0.0_T
  d => a(1 : N, 1:N)
  c = matmul (d, b)
  if (sum (c) /= 1000.0_T) call abort ()

  c = 0.0_T
  d => a(N+1 : 2*N, 1:N)
  c = matmul (d, b)
  if (sum (c) /= 500.0_T) call abort ()

  c = 0.0_T
  e => c(N+1 : 2*N, 1 : N)
  e = matmul (d, b)
  if (sum (c(1 : N, 1 : N)) /= 0.0_T) call abort ()
  if (sum (c(N+1 : 2*N, 1 : N)) /= 500.0_T) call abort ()

  call doitagain (a ,b ,c ,x ,y ,z )

  deallocate (a, b, c)

contains

  subroutine doitagain (a ,b ,c ,x ,y ,z )
    real(kind=T), dimension(5:, 5:)    ::  a ,b ,c ,x ,y ,z

    z = 0.0_T
    z = matmul (x, y)
    if (sum (z) /= 250.0_T) call abort ()

    c = 0.0_T
    c = matmul (a, b)
    if (sum (c) /= 1500.0_T) call abort ()

  end subroutine doitagain

end program test_matmul




-- 


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

[Bug fortran/18857] MATMUL failing with ALLOCATED matrices, unless base indices given

[Tobias dot Schlueter at physik dot uni-muenchen dot de]

------- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de  2005-04-25 20:47 -------
Subject: Re:  MATMUL failing with ALLOCATED matrices, unless
 base indices given

paulthomas2 at wanadoo dot fr wrote:
> Does this do it for you? - it works with those assertions eliminated.

It doesn't work for me,
   a.out: ../../../gcc-clean/libgfortran/generated/matmul_r4.c:161: matmul_r4:
   Assertion `a->base == 0' failed.
   Aborted
but I'm not sure if understood your question.

I'm kinda surprised it works with the assertions removed, as I don't see
anything in the implementation which deals with a->base != 0.  Does it also
work if you change the lower bound in the second dimension in one of the
pointer assignments?


-- 


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

[Bug fortran/18857] MATMUL failing with ALLOCATED matrices, unless base indices given

[paulthomas2 at wanadoo dot fr]

------- Additional Comments From paulthomas2 at wanadoo dot fr  2005-04-26 12:53 -------
Tobi,

The component base is almost completely redundant - especially, where C indices 
are used, such as in matmul.  It can always be calculated from the bounds and 
the stride, in any case.  Most of the operations where speed is of the essence 
will do the indexing in the same way as matmul.

I think that I would be inclined to do away with it.

As to changing the range of the second index: it works fine with the insertions 
removed.

Paul T

-- 


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

[Bug libfortran/18857] MATMUL failing with ALLOCATED matrices, unless base indices given

[paulthomas2 at wanadoo dot fr]

------- Additional Comments From paulthomas2 at wanadoo dot fr  2005-04-29 09:51 -------
Tobi,

The reason that it works is that the value of *data that is passed to matmul 
points to the first element of the array or subarray.  matmul then calculates 
the number of elements from {stride, lbound, ubound} and C-indexing is used for 
athe aritmetic.  *base is therefore never needed.  This is illustrated by the 
following example:

Program pr18857a
  integer, parameter                                :: N = 5
  integer, parameter                                :: T = 4
  real(kind=T), dimension(:,:), allocatable, Target :: a, b, c
  real(kind=T), dimension(:,:), POINTER             :: d, e
  real(kind=T), dimension(N,N)                      :: x, y, z

  allocate (a(2*N, N), b(N, N), c(2*N, N))
  a = 1.0_T
  a(1:N,:) = 2.0_T
  b = 4.0_T
  x = 1.0_T
  y = 2.0_T

  z = 0.0_T
  z = matmul (x, y)
  if (sum (z) /= 250.0_T) call abort ()

  c = 0.0_T
  c = matmul (a(:,3:N), b(3:N,:))
  if (sum (c) /= 900.0_T) call abort ()

  deallocate (a, b, c)

end program pr18857a

I will not pollute Bugzilla with the entire tree dump but limit myself to 
reproducing the part just before and including the second call to matmul (lines 
384-386 of pr18857a.f90.t02.original)

    parm.21.data = (real4[0:] *) (real4[0:] *) &(*b.data)[(3 - b.dim[0].lbound) 
* D.595 + (D.588 - b.dim[1].lbound) * D.596];
    parm.21.offset = 0;
    _gfortran_matmul_r4 (&c, &parm.20, &parm.21);

The (3 - b.dim[0].lbound) provides the offset to the data being multiplied. 
Earlier on in the tree dump, D.588 = b.dim[1].lbound;, so the second part of 
the offset is zero.  By some miracle, the front end does this correctly for 
every case that I can find. 
 

-- 


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

[Bug libfortran/18857] MATMUL failing with ALLOCATED matrices, unless base indices given

[tobi at gcc dot gnu dot org]

------- Additional Comments From tobi at gcc dot gnu dot org  2005-04-29 10:28 -------
Thanks for investigating, I had an exchange with Paul Brook about this yesterday
on the mailing list, and I think I understand what's happening now.  Basically,
some of the information in the array descriptor is redundant.

An array element can be accessed in either of the following two ways:
   data[offset + index0*stride0 + index1*stride1 + index2*stride2]
and
   data[(index0-lbound0)*stride0 + (index1-lbound1)*stride1]

The library uses the latter way, so the offset is not needed there.

BTW this also answers the question of ssize_t vs size_t we were dicussing
before: correct overflow only plays a role when one uses the first way, and this
is only used in compiler-generated code.

The library only uses the latter kind of indexing and therefore using ssize_t
should work correctly under all circumstances. 

-- 


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

[Bug libfortran/18857] MATMUL failing with ALLOCATED matrices, unless base indices given

[paulthomas2 at wanadoo dot fr]

------- Additional Comments From paulthomas2 at wanadoo dot fr  2005-04-29 14:59 -------
Subject: Re:  MATMUL failing with ALLOCATED matrices, unless base indices given

Tobi,

> The library uses the latter way, so the offset is not needed there.
>
Exactly - I was aware of this because the namelist functions do not use 
base/offset at all.

> BTW this also answers the question of ssize_t vs size_t we were dicussing
> before: correct overflow only plays a role when one uses the first way, 
> and this
> is only used in compiler-generated code.

Yes, that is the point that Thomas was making, when he raised it in the 
first place.

>
> The library only uses the latter kind of indexing and therefore using 
> ssize_t
> should work correctly under all circumstances.

Again, exactly.

As for the care that I am taking - after the business with namelist, I feel 
like the monkey and the billiard ball- I'll see if I can find it on the web. 
You will see why it is appropriate.

Paul




-- 


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

[Bug libfortran/18857] MATMUL failing with ALLOCATED matrices, unless base indices given

[Tobias dot Schlueter at physik dot uni-muenchen dot de]

------- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de  2005-04-29 16:29 -------
Subject: Re:  MATMUL failing with ALLOCATED matrices,
 unless base indices given

paulthomas2 at wanadoo dot fr wrote:
> ------- Additional Comments From paulthomas2 at wanadoo dot fr  2005-04-29 14:59 -------
> Exactly - I was aware of this because the namelist functions do not use 
> base/offset at all.
> Yes, that is the point that Thomas was making, when he raised it in the 
> first place.
> Again, exactly.

Looks like I'm really slow :-) I'm all in favor of Thomas ssize_t patch now.

> As for the care that I am taking - after the business with namelist, I feel 
> like the monkey and the billiard ball- I'll see if I can find it on the web. 
> You will see why it is appropriate.

I broke the bootstrap yesterday, I guess I'm in no position to judge how
careful other people are :-)

- Tobi


-- 


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

[Bug libfortran/18857] [4.0 only] MATMUL failing with ALLOCATED matrices, unless base indices given

[tkoenig at gcc dot gnu dot org]

------- Additional Comments From tkoenig at gcc dot gnu dot org  2005-05-24 21:55 -------
This has been fixed on mainline, still outstanding in 4.0

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |4.0.1
      Known to work|                            |4.1.0
            Summary|MATMUL failing with         |[4.0 only] MATMUL failing
                   |ALLOCATED matrices, unless  |with ALLOCATED matrices,
                   |base indices given          |unless base indices given
   Target Milestone|---                         |4.0.1


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

[Bug libfortran/18857] [4.0 only] MATMUL failing with ALLOCATED matrices, unless base indices given

[mmitchel at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.0.1                       |4.0.2


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

[Bug libfortran/18857] [4.0 only] MATMUL failing with ALLOCATED matrices, unless base indices given

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-07-15 20:47 -------
Subject: Bug 18857

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-4_0-branch
Changes by:	tkoenig@gcc.gnu.org	2005-07-15 20:47:40

Modified files:
	libgfortran    : ChangeLog 
	libgfortran/m4 : matmul.m4 
	libgfortran/generated: matmul_c4.c matmul_c8.c matmul_i4.c 
	                       matmul_i8.c matmul_r4.c matmul_r8.c 
	gcc/testsuite  : ChangeLog 
	gcc/testsuite/gfortran.fortran-torture/execute: 
	                                                intrinsic_matmul.f90 
Added files:
	gcc/testsuite/gfortran.dg: matmul_1.f90 

Log message:
	2005-07-15  Thomas Koenig  <Thomas.Koenig@online.de>
	
	Backport from mainline.
	PR libfortran/21926
	PR libfortran/18857
	* m4/matmul.m4:  Correct zeroing of result for non-packed
	arrays with lowest stride is one.
	Remove incorrect assertions (original patch by pault@gcc.gnu.org).
	* generated/matmul_c4.c:  Regenerated.
	* generated/matmul_c8.c:  Regenerated.
	* generated/matmul_i4.c:  Regenerated.
	* generated/matmul_i8.c:  Regenerated.
	* generated/matmul_r4.c:  Regenerated.
	* generated/matmul_r8.c:  Regenerated.
	
	2005-07-15  Thomas Koenig  <Thomas.Koenig@online.de>
	
	Backport from mainline.
	PR libfortran/21926
	PR libfortran/18857
	* gfortran.fortran-torture/execute/intrinsic_matmul.f90:
	Test case where the return array has lowest stride one,
	but isn't packed.
	* gfortran.dg/matmul_1.f90: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.163.2.62&r2=1.163.2.63
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/m4/matmul.m4.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.9&r2=1.9.12.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/matmul_c4.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.8&r2=1.8.12.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/matmul_c8.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.8&r2=1.8.12.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/matmul_i4.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.8&r2=1.8.12.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/matmul_i8.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.8&r2=1.8.12.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/matmul_r4.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.8&r2=1.8.12.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/matmul_r8.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.8&r2=1.8.12.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.279&r2=1.5084.2.280
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/matmul_1.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.10.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/intrinsic_matmul.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.2&r2=1.2.46.1



-- 


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

[Bug libfortran/18857] [4.0 only] MATMUL failing with ALLOCATED matrices, unless base indices given

[tkoenig at gcc dot gnu dot org]

------- Additional Comments From tkoenig at gcc dot gnu dot org  2005-07-15 20:48 -------
Fixed in 4.0.

-- 


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

[Bug libfortran/18857] [4.0 only] MATMUL failing with ALLOCATED matrices, unless base indices given

[tkoenig at gcc dot gnu dot org]

------- Additional Comments From tkoenig at gcc dot gnu dot org  2005-07-15 20:50 -------
Fixed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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