--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.0 |4.2.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31994
--- Comment #11 from pault at gcc dot gnu dot org 2007-05-31 18:51 ---
Subject: Bug 31994
Author: pault
Date: Thu May 31 18:50:56 2007
New Revision: 125235
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125235
Log:
2007-05-31 Paul Thomas <[EMAIL PROTECTED]>
backport f
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31994
--- Comment #10 from pault at gcc dot gnu dot org 2007-05-21 14:21 ---
Fixed on trunk. The patch will be backported to 4.2, as soon as the dust has
settled on trunk and 4.2 is open again.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from pault at gcc dot gnu dot org 2007-05-21 14:16 ---
Subject: Bug 31994
Author: pault
Date: Mon May 21 13:16:06 2007
New Revision: 124903
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124903
Log:
2007-05-21 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #8 from pault at gcc dot gnu dot org 2007-05-21 10:13 ---
My patch for PR31867 fixes this in all its manifestations: see
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00961.html
The amusing thing is that I was hurting for testcases for this latter PR:)
It shows what a limite
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-05-20 17:08
---
I think it may have to do with the order of resolving, I think pr32002 is not
picking up the shape checking because the array variables are not resolved
before functions using them are resolved. I think somethin
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-05-20 15:43
---
(In reply to comment #5)
> What is more
> confusing is that I can't trigger this scalarization bug with other intrinsics
10 seconds after I hit the Commit button, I thought about another testcase, and
it does als
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-05-20 15:40
---
For some reason, the scalarization of conjg(transpose()) is messed up. The
following code:
complex :: a(1,1), b(1,1)
a = 0
b = conjg(transpose(a))
print *, b(1,1)
end
ends up as folllows:
int4 D
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-05-20 10:52 ---
b = transpose(conjg(a)) works (also translated into
the library call).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31994
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-05-19 10:11 ---
On
a = transpose(b)
a = transpose(conjg(b))
the TRANSPOSE intrinsic is translated via trans-intrinsic.c
(gfc_conv_intrinsic_funcall) and results in a library call
(_gfortran_transpose_c4), on
a = conjg(transpo
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-05-19 03:38
---
Adding FX to cc. This is not a regression relative to 4.1, but its sure ugly!
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-05-19 03:29
---
I see it here too. This is a frontend problem I think. Looks to me like its
the transpose portion looking at -fdump-tree-original.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed
13 matches
Mail list logo
