--- Comment #20 from burnus at gcc dot gnu dot org 2010-05-19 07:24 ---
(In reply to comment #18)
> Patch was applied to trunk about 6 weeks ago - how are the backporting plans?
Thanks for the reminder!
Thorsten: Thanks for the bug report.
As I do not intent to backport it to 4.4.x: Cl
--- Comment #19 from burnus at gcc dot gnu dot org 2010-05-19 07:22 ---
Subject: Bug 43591
Author: burnus
Date: Wed May 19 07:22:00 2010
New Revision: 159556
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159556
Log:
2010-05-19 Tobias Burnus
PR fortran/43591
--- Comment #18 from dfranke at gcc dot gnu dot org 2010-05-18 22:36
---
(In reply to comment #17)
> Fixed on the trunk (4.6). Planned to be committed also to GCC 4.5.1.
Patch was applied to trunk about 6 weeks ago - how are the backporting plans?
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #17 from burnus at gcc dot gnu dot org 2010-04-10 14:27 ---
Fixed on the trunk (4.6). Planned to be committed also to GCC 4.5.1.
Patch: http://gcc.gnu.org/ml/fortran/2010-04/msg00093.html
Thanks for the bug report!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43591
--- Comment #16 from burnus at gcc dot gnu dot org 2010-04-10 14:25 ---
Subject: Bug 43591
Author: burnus
Date: Sat Apr 10 14:24:46 2010
New Revision: 158191
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158191
Log:
2010-04-10 Tobias Burnus
PR fortran/43591
--- Comment #15 from dominiq at lps dot ens dot fr 2010-04-08 07:48 ---
With the patch in comment #14, the test in comment #1 compiles and gives:
evt= 234, flv= 1, col= 2, hel= 3, -0.122E-13 + i* 0.675E-14 ~ 0.267E-02
evt= 234, flv= 1, col= 2, hel= 6, -0.122E-13 + i*-0.675E-14
--- Comment #14 from burnus at gcc dot gnu dot org 2010-04-07 10:20 ---
Looked at the wrong check. The following (lightly tested) should work:
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (revision 158042)
+++ gcc/
--- Comment #13 from burnus at gcc dot gnu dot org 2010-04-07 09:38 ---
I somehow miss the setting of
expr->value.function.esym and thus expr->value.function.esym->attr
for PPC in resolve.c (e.g. in resolve_expr_ppc). Contrary to resolve_compcall,
where on has:
e->value.function.esym
--- Comment #12 from burnus at gcc dot gnu dot org 2010-04-06 20:58 ---
(In reply to comment #11)
> Internal Error at (1):
> gfc_is_constant_expr(): Unknown expression type
Try the following patch; however, as written in comment 8 the PURE attribute is
lost somewhere thus the patch is n
--- Comment #11 from dominiq at lps dot ens dot fr 2010-04-01 15:57 ---
The patch in comment #8 fixes the ICEs for the various reduced tests, however
for the original code I get
ward.f90:405.19:
end module ward_lib
1
Internal Error at (1):
gfc_is_constant_expr(): Unk
--- Comment #10 from ohl at physik dot uni-wuerzburg dot de 2010-04-01
12:45 ---
(In reply to comment #8)
> That's not valid either as you have not defined "p1_type" - replacing it by
> INTEGER should work, though. -- Well, it actually does not as specification
> expressions need to be
--- Comment #9 from burnus at gcc dot gnu dot org 2010-04-01 12:36 ---
(In reply to comment #7)
> (In reply to comment #6)
> > What is invaild about the code is that t1%p1() and t2%p2() are not
> > initialization expressions. Everthing works fine, when the tables are
> > allocatable.
>
--- Comment #8 from burnus at gcc dot gnu dot org 2010-04-01 12:28 ---
(In reply to comment #6)
> But that's not the problem:
> type t
> procedure(p1_type), nopass, pointer :: p1 => NULL()
> procedure(p2_type), nopass, pointer :: p2 => NULL()
That's not valid either as you h
--- Comment #7 from dominiq at lps dot ens dot fr 2010-04-01 12:17 ---
(In reply to comment #6)
> What is invaild about the code is that t1%p1() and t2%p2() are not
> initialization expressions. Everthing works fine, when the tables are
> allocatable.
That was the origin of my question
--- Comment #6 from ohl at physik dot uni-wuerzburg dot de 2010-04-01
11:47 ---
(In reply to comment #5)
> Well, using
> type omega_procedures
> procedure(number_particles_out), nopass, pointer :: number_particles_out
> => NULL()
> end type omega_procedures
>
> is definitely
--- Comment #5 from burnus at gcc dot gnu dot org 2010-04-01 09:26 ---
(In reply to comment #3)
> Reduced test:
[...]
(In reply to comment #4)
> Further reduced test that does not give an ICE, but several errors:
> Although gfortran should not give an ICE, I have doubts about the validit
--- Comment #4 from dominiq at lps dot ens dot fr 2010-03-30 19:55 ---
Further reduced test that does not give an ICE, but several errors:
[macbook] f90/bug% cat pr43591_red_1.f90
module ward_lib
implicit none
type omega_procedures
procedure(number_particles_out), nopass, poi
17 matches
Mail list logo
