--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
05:43 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From paulthomas2 at wanadoo dot fr 2004-11-15
14:58 ---
Looking at the source of SPREAD, I note that it does not assert the rank of the
output matrix. Thus, in the fragment from the LLNL test it should be possible
to output the calls to SPREAD to temporary arra
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-09
23:33 ---
This looks very much like a front end bug. The
"along" parameter gets the wrong value.
Look at this:
$ cat test_spread.f90
program test_spread
implicit none
integer, parameter :: N = 1000
int
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-03-25
05:44 ---
(In reply to comment #4)
It should be noted that reshape also suffers from the same disorder. To my
mind, this makes the PR rather high priority - after all, the vectorized
functions are among the features
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-08
15:28 ---
Yet another SPREAD problem:
! Original bug-report by Walt Brainerd, The Fortran Company
integer,dimension(2) :: mi1 = 1
integer,dimension(1,1) :: s
s = spread(mi1,1,2)
end
I agree those intrinsic
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-04-13
10:01 ---
The program test_spread from the original bug report
is bogus. dim=1000 doesn't make sense (which invalidates
my comment #5 and makes this particular case a diagnostics
issue).
Thomas
--
http://gcc.gnu
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-04-13
19:47 ---
Can anybody point me to the actual source of the
benchmark that exposed the failure? From the
description, I can't see what's wrong.
Thomas
--
What|Removed |Added
-
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-04-13
21:27 ---
Subject: Re: Intrinisc function SPREAD is broken
tkoenig at gcc dot gnu dot org wrote:
>--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-04-13
>10:01 ---
>The program test_spread
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-04-14
21:49 ---
Created an attachment (id=8634)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8634&action=view)
Proposed fix for PR 18495.
This appears to fix the benchmark in question.
--
What|Remov
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-04-15
05:07 ---
Subject: Re: Intrinisc function SPREAD is broken
>
>
>This appears to fix the benchmark in question.
>
>
>
I believe that reshape needs the same/similar fix.
Is ret->data = NULL guaranteed for temporarie
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-04-15
11:29 ---
(In reply to comment #13)
> I believe that reshape needs the same/similar fix.
> Is ret->data = NULL guaranteed for temporaries?
ret->data = NULL is what the front end generates when
it doesn't know enough
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-04-15
17:24 ---
There's something rotten in the state of Denmark.
I've slightly modified Paul's test program with my patch, and
this is what I got:
program test_spread
implicit none
integer, parameter :: N = 100
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-04-15
19:39 ---
Spread putting its result into temporary
arrays does indeed do something strange, even if
the front end is providing the space. This is with
an unpatched spread_generic.c:
program test_spread
implicit n
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-15
20:06 ---
Subject: Bug 18495
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-15 20:06:17
Modified files:
libgfortran: ChangeLog
libgfortran/intrin
--- Additional Comments From tobi at gcc dot gnu dot org 2004-12-02 20:56
---
Looking at the code it seems to me that the return array isn't allocated
anywhere. I don't know the scalarizer well enough, though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18495
--- Additional Comments From tobi at gcc dot gnu dot org 2004-12-02 21:05
---
I think I know now how the return array is allocated. This is not the error.
An additional error seems to be that a scalar source is not special cased, as
for PACK, see PR17283:
[EMAIL PROTECTED] tests]$ cat s
16 matches
Mail list logo