--- Comment #9 from pault at gcc dot gnu dot org 2007-12-09 09:19 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #8 from pault at gcc dot gnu dot org 2007-12-09 09:17 ---
Subject: Bug 32129
Author: pault
Date: Sun Dec 9 09:17:24 2007
New Revision: 130719
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130719
Log:
2007-12-09 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #7 from dominiq at lps dot ens dot fr 2007-12-08 20:45 ---
Now works as advertized without regression on i686-apple-darwin9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32129
--- Comment #6 from pault at gcc dot gnu dot org 2007-12-07 13:46 ---
(In reply to comment #5)
> This is just regtesting but I think that it will be OK.
Famous last words! It regresses in elemental_subroutine_2.f90. It should all
be fixable witout much effort, though.
Paul
--
ht
--- Comment #5 from pault at gcc dot gnu dot org 2007-12-07 11:48 ---
Created an attachment (id=14707)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14707&action=view)
Fix for the PR
This is just regtesting but I think that it will be OK.
Note that this expression type was gettin
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-11-21 13:51
---
I think this is valid code. The reduced testcase is:
$ cat y.f90
program testCode
implicit none
type vec
real, dimension(1) :: coords
end type
integer :: i
real, dimension(1,1), parameter :: vy = 1.
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-10-21 03:29
---
The original test case here no longer gives an ICE.
The case on Comment #2 does ICE
pr32129-a.f90: In function MAIN__:
pr32129-a.f90:11: internal compiler error: in gfc_trans_call, at
fortran/trans-stmt.c:320
--- Comment #2 from mikael dot morin at tele2 dot fr 2007-06-02 00:06
---
Here is an other test case.
program testCode
implicit none
type vec
real, dimension(3) :: coords
end type
integer, parameter :: n = 5
integer :: i
real, d
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-28 18:13 ---
Some debugging shows:
resolve_call calls resolve_actual_arglist, which fails.
resolve_call propagates the failure to resolve_where, which does not check for
errors.
In resolve_actual_arglist it fails here:
i
10 matches
Mail list logo
