--- Comment #11 from pault at gcc dot gnu dot org 2006-08-20 17:48 ---
Fixed on trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pault at gcc dot gnu dot org 2006-08-20 08:21 ---
Subject: Bug 28660
Author: pault
Date: Sun Aug 20 08:20:26 2006
New Revision: 116269
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116269
Log:
2006-08-20 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/2
--- Comment #9 from pault at gcc dot gnu dot org 2006-08-20 05:46 ---
Subject: Bug 28660
Author: pault
Date: Sun Aug 20 05:45:43 2006
New Revision: 116268
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116268
Log:
2006-08-20 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/28
--- Comment #8 from patchapp at dberlin dot org 2006-08-11 19:55 ---
Subject: Bug number PR28660
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00378.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #7 from pault at gcc dot gnu dot org 2006-08-11 17:17 ---
> The attached runs the testcase below correctly and regtests, except for
> gfortran.fortran-torture/execute/entry_5.f90, on Cygwin_NT/PIV.
I have tracked down the cause of this - it's just building tonto-2.3 at
pres
--- Comment #6 from paul dot richard dot thomas at cea dot fr 2006-08-11
14:08 ---
Created an attachment (id=12066)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12066&action=view)
Prototype fix
The attached runs the testcase below correctly and regtests, except for
gfortran.for
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-08-11
08:06 ---
Try this one! No matter what you rename 'r' as, the order of execution is
wrong.
program runoptf90
implicit none
real :: x(10)
call simulated_annealing (x)
contains
subroutine simula
--- Comment #4 from pault at gcc dot gnu dot org 2006-08-10 04:29 ---
(In reply to comment #3)
> order the declarations or something.
>
> Paul
>
Having slept on it, I realise that this will not work because the statement
order should not matter. I think that there will have to be
--- Comment #3 from pault at gcc dot gnu dot org 2006-08-09 17:47 ---
uuuhhh! This is horrible and is a reflection of the symtree being ordered as a
binary tree. If 'r' is renamed 'zr', the order of translation is changed and
the code runs correctly; albeit still with an unrequited ub
--- Comment #2 from erik dot edelmann at iki dot fi 2006-08-09 10:54
---
(In reply to comment #1)
> Actually this is worse than what is said here, this is wrong code. In a
> prerelease of 4.1.0, we allocate r after we allocate x so the size of x is not
> know at the time we allocate r.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-09 10:20 ---
Actually this is worse than what is said here, this is wrong code. In a
prerelease of 4.1.0, we allocate r after we allocate x so the size of x is not
know at the time we allocate r.
--
pinskia at gcc dot gnu do
11 matches
Mail list logo
