* [Bug fortran/47240] segfault with procedure pointer component
2011-01-10 9:10 [Bug fortran/47240] New: segfault with procedure pointer component m.a.hulsen at tue dot nl
@ 2011-01-10 9:37 ` burnus at gcc dot gnu.org
2011-01-10 10:54 ` [Bug fortran/47240] [F03] " janus at gcc dot gnu.org
` (15 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-01-10 9:37 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47240
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu.org,
| |janus at gcc dot gnu.org
--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-01-10 09:10:34 UTC ---
Seemingly the TREE generation does not honor that "coefficients%tfunc1(1)%p" is
a pointer.
If one has:
subroutine evaluate_tensor_coefficient (tfunc, ...
procedure (dum_tfunc) :: tfunc
Using
call evaluate_tensor_coefficient (dum_tfunc, ... )
works while
call evaluate_tensor_coefficient (coefficients%tfunc1(1)%p, ...)
fails.
However, if one make the dummy argument a POINTER, it works:
subroutine evaluate_tensor_coefficient (tfunc, ...
procedure (dum_tfunc), POINTER :: tfunc
when calling
call evaluate_tensor_coefficient (coefficients%tfunc1(1)%p, ...)
One also sees this if one looks at the dump:
(*(struct tfunc_p[0:] * restrict)
coefficients.tfunc1.data)[coefficients.tfunc1.offset + 1].p = dum_tfunc;
Assigns the address of "dum_tfunc" to the function pointer
"coefficients%tfunc1(1)%p"
but in the call the again the address is taken - rather than passing the
pointer as is - the first "&" should only appear if the argument is a function
pointer and not just a function.
evaluate_tensor_coefficient (&(*(struct tfunc_p[0:] * restrict)
coefficients->tfunc1.data)[coefficients->tfunc1.offset + 1].p, &parm.17);
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47240] [F03] segfault with procedure pointer component
2011-01-10 9:10 [Bug fortran/47240] New: segfault with procedure pointer component m.a.hulsen at tue dot nl
2011-01-10 9:37 ` [Bug fortran/47240] " burnus at gcc dot gnu.org
@ 2011-01-10 10:54 ` janus at gcc dot gnu.org
2011-01-10 20:34 ` janus at gcc dot gnu.org
` (14 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu.org @ 2011-01-10 10:54 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47240
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
Status|UNCONFIRMED |NEW
Last reconfirmed| |2011.01.10 09:23:36
Summary|segfault with procedure |[F03] segfault with
|pointer component |procedure pointer component
Ever Confirmed|0 |1
--- Comment #2 from janus at gcc dot gnu.org 2011-01-10 09:23:36 UTC ---
Confirmed. There is an additional problem with the following variant:
module element_defs_m
type tfunc_p
procedure (dum_tfunc), pointer, nopass :: p => null()
end type tfunc_p
contains
function dum_tfunc ( n, x )
integer, intent(in) :: n
real, intent(in), dimension(:) :: x
real, dimension(n,n) :: dum_tfunc
dum_tfunc = 0
end function dum_tfunc
end module element_defs_m
program t
use element_defs_m
type(tfunc_p) :: tfunc1
real :: coef (2,2)
tfunc1%p => dum_tfunc
call evaluate_tensor_coefficient (tfunc1%p, coef )
print *, coef
contains
subroutine evaluate_tensor_coefficient ( tfunc, coef )
interface
function tfunc ( n, x )
integer, intent(in) :: n
real, intent(in), dimension(:) :: x
real, dimension(n,n) :: tfunc
end function tfunc
end interface
real, dimension(:,:), intent(out) :: coef
real :: x(2)=0
coef = tfunc( n=2, x=x )
end subroutine evaluate_tensor_coefficient
end program t
This gives me:
call evaluate_tensor_coefficient (tfunc1%p, coef )
1
Error: Rank mismatch in argument 'tfunc' at (1) (rank-2 and scalar)
(although the code is valid).
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47240] [F03] segfault with procedure pointer component
2011-01-10 9:10 [Bug fortran/47240] New: segfault with procedure pointer component m.a.hulsen at tue dot nl
2011-01-10 9:37 ` [Bug fortran/47240] " burnus at gcc dot gnu.org
2011-01-10 10:54 ` [Bug fortran/47240] [F03] " janus at gcc dot gnu.org
@ 2011-01-10 20:34 ` janus at gcc dot gnu.org
2011-01-10 21:55 ` janus at gcc dot gnu.org
` (13 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu.org @ 2011-01-10 20:34 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47240
--- Comment #3 from janus at gcc dot gnu.org 2011-01-10 20:27:29 UTC ---
Reduced test case:
type t
procedure (fun), pointer, nopass :: p
end type
type(t) :: x
x%p => fun
print *, evaluate (x%p)
contains
real function fun ()
fun = 0
end function
real function evaluate ( dummy )
procedure(fun) :: dummy
evaluate = dummy ()
end function
end
Like the original test case, this gives a segfault at runtime. Looking at the
dump, the wrong part is
D.1540 = evaluate (&x.p);
We should not take the address of x.p here, but just pass it as is.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47240] [F03] segfault with procedure pointer component
2011-01-10 9:10 [Bug fortran/47240] New: segfault with procedure pointer component m.a.hulsen at tue dot nl
` (2 preceding siblings ...)
2011-01-10 20:34 ` janus at gcc dot gnu.org
@ 2011-01-10 21:55 ` janus at gcc dot gnu.org
2011-01-11 11:55 ` janus at gcc dot gnu.org
` (12 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu.org @ 2011-01-10 21:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47240
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
--- Comment #4 from janus at gcc dot gnu.org 2011-01-10 21:50:21 UTC ---
The following patch fixes the wrong-code issue as well as the rejects-valid
problem from comment #2:
Index: gcc/fortran/trans-expr.c
===================================================================
--- gcc/fortran/trans-expr.c (revision 168617)
+++ gcc/fortran/trans-expr.c (working copy)
@@ -3043,8 +3043,9 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol *
&& fsym->attr.flavor != FL_PROCEDURE)
|| (fsym->attr.proc_pointer
&& !(e->expr_type == EXPR_VARIABLE
- && e->symtree->n.sym->attr.dummy))
- || (e->expr_type == EXPR_VARIABLE
+ && e->symtree->n.sym->attr.dummy))
+ || (fsym->attr.proc_pointer
+ && e->expr_type == EXPR_VARIABLE
&& gfc_is_proc_ptr_comp (e, NULL))
|| fsym->attr.allocatable))
{
Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c (revision 168618)
+++ gcc/fortran/resolve.c (working copy)
@@ -4858,6 +4858,9 @@ expression_rank (gfc_expr *e)
for (ref = e->ref; ref; ref = ref->next)
{
+ if (ref->type == REF_COMPONENT)
+ rank = ref->u.c.component->as ? ref->u.c.component->as->rank : 0;
+
if (ref->type != REF_ARRAY)
continue;
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47240] [F03] segfault with procedure pointer component
2011-01-10 9:10 [Bug fortran/47240] New: segfault with procedure pointer component m.a.hulsen at tue dot nl
` (3 preceding siblings ...)
2011-01-10 21:55 ` janus at gcc dot gnu.org
@ 2011-01-11 11:55 ` janus at gcc dot gnu.org
2011-01-11 14:23 ` dominiq at lps dot ens.fr
` (11 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu.org @ 2011-01-11 11:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47240
--- Comment #5 from janus at gcc dot gnu.org 2011-01-11 11:48:52 UTC ---
(In reply to comment #4)
> Index: gcc/fortran/trans-expr.c
> ===================================================================
> --- gcc/fortran/trans-expr.c (revision 168617)
> +++ gcc/fortran/trans-expr.c (working copy)
> @@ -3043,8 +3043,9 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol *
> && fsym->attr.flavor != FL_PROCEDURE)
> || (fsym->attr.proc_pointer
> && !(e->expr_type == EXPR_VARIABLE
> - && e->symtree->n.sym->attr.dummy))
> - || (e->expr_type == EXPR_VARIABLE
> + && e->symtree->n.sym->attr.dummy))
> + || (fsym->attr.proc_pointer
> + && e->expr_type == EXPR_VARIABLE
> && gfc_is_proc_ptr_comp (e, NULL))
> || fsym->attr.allocatable))
> {
This part is fine and regtests cleanly, however ...
> Index: gcc/fortran/resolve.c
> ===================================================================
> --- gcc/fortran/resolve.c (revision 168618)
> +++ gcc/fortran/resolve.c (working copy)
> @@ -4858,6 +4858,9 @@ expression_rank (gfc_expr *e)
>
> for (ref = e->ref; ref; ref = ref->next)
> {
> + if (ref->type == REF_COMPONENT)
> + rank = ref->u.c.component->as ? ref->u.c.component->as->rank : 0;
> +
> if (ref->type != REF_ARRAY)
> continue;
... this produces loads of regressions.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47240] [F03] segfault with procedure pointer component
2011-01-10 9:10 [Bug fortran/47240] New: segfault with procedure pointer component m.a.hulsen at tue dot nl
` (4 preceding siblings ...)
2011-01-11 11:55 ` janus at gcc dot gnu.org
@ 2011-01-11 14:23 ` dominiq at lps dot ens.fr
2011-01-11 14:55 ` janus at gcc dot gnu.org
` (10 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: dominiq at lps dot ens.fr @ 2011-01-11 14:23 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47240
--- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-01-11 14:21:26 UTC ---
> > Index: gcc/fortran/resolve.c
> > ...
> > continue;
>
> ... this produces loads of regressions.
Confirmed;-(
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47240] [F03] segfault with procedure pointer component
2011-01-10 9:10 [Bug fortran/47240] New: segfault with procedure pointer component m.a.hulsen at tue dot nl
` (5 preceding siblings ...)
2011-01-11 14:23 ` dominiq at lps dot ens.fr
@ 2011-01-11 14:55 ` janus at gcc dot gnu.org
2011-01-11 23:15 ` dominiq at lps dot ens.fr
` (9 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu.org @ 2011-01-11 14:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47240
--- Comment #7 from janus at gcc dot gnu.org 2011-01-11 14:43:52 UTC ---
(In reply to comment #5)
> > Index: gcc/fortran/resolve.c
> > ===================================================================
> > --- gcc/fortran/resolve.c (revision 168618)
> > +++ gcc/fortran/resolve.c (working copy)
> > @@ -4858,6 +4858,9 @@ expression_rank (gfc_expr *e)
> >
> > for (ref = e->ref; ref; ref = ref->next)
> > {
> > + if (ref->type == REF_COMPONENT)
> > + rank = ref->u.c.component->as ? ref->u.c.component->as->rank : 0;
> > +
> > if (ref->type != REF_ARRAY)
> > continue;
>
> ... this produces loads of regressions.
... but the following variant doesn't:
Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c (revision 168655)
+++ gcc/fortran/resolve.c (working copy)
@@ -4858,6 +4858,9 @@ expression_rank (gfc_expr *e)
for (ref = e->ref; ref; ref = ref->next)
{
+ if (ref->type == REF_COMPONENT && !ref->next)
+ rank = ref->u.c.component->as ? ref->u.c.component->as->rank : 0;
+
if (ref->type != REF_ARRAY)
continue;
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47240] [F03] segfault with procedure pointer component
2011-01-10 9:10 [Bug fortran/47240] New: segfault with procedure pointer component m.a.hulsen at tue dot nl
` (6 preceding siblings ...)
2011-01-11 14:55 ` janus at gcc dot gnu.org
@ 2011-01-11 23:15 ` dominiq at lps dot ens.fr
2011-01-12 21:00 ` janus at gcc dot gnu.org
` (8 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: dominiq at lps dot ens.fr @ 2011-01-11 23:15 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47240
--- Comment #8 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-01-11 21:38:46 UTC ---
(In reply to comment #7)
> > ...
> > ... this produces loads of regressions.
>
> ... but the following variant doesn't:
> ...
Confirmed, however the following code
[macbook] f90/bug% cat pr35971_red.f90
module other_fun
use ISO_C_BINDING
implicit none
private
! Message to be returned by procedure pointed to
! by the C_FUNPTR
character, allocatable, save :: my_message(:)
! Interface block for the procedure pointed to
! by the C_FUNPTR
public abstract_fun
abstract interface
function abstract_fun(x)
use ISO_C_BINDING
import my_message
implicit none
integer(C_INT) x(:)
character(size(my_message),C_CHAR) abstract_fun(size(x))
end function abstract_fun
end interface
contains
! Procedure to store the message and get the C_FUNPTR
function gp(message) bind(C,name='BlAh')
! procedure(abstract_fun) make_mess
character(kind=C_CHAR) message(*)
type(C_FUNPTR) gp
integer(C_INT64_T) i
i = 1
do while(message(i) /= C_NULL_CHAR)
i = i+1
end do
my_message = message(int(1,kind(i)):i-1)
gp = get_funloc(make_mess,aux)
! gp = aux(make_mess)
end function gp
! Intermediate procedure to pass the function and get
! back the C_FUNPTR
function get_funloc(x,y)
procedure(abstract_fun) x
type(C_FUNPTR) y
external y
type(C_FUNPTR) get_funloc
get_funloc = y(x)
end function get_funloc
! Procedure to convert the function to C_FUNPTR
function aux(x)
interface
subroutine x() bind(C)
end subroutine x
end interface
type(C_FUNPTR) aux
aux = C_FUNLOC(x)
end function aux
! Procedure pointed to by the C_FUNPTR
function make_mess(x)
integer(C_INT) x(:)
character(size(my_message),C_CHAR) make_mess(size(x))
make_mess = transfer(my_message,make_mess(1))
end function make_mess
end module other_fun
end
gives at -O2 and above
[macbook] f90/bug% gfc -O2 pr35971_red.f90
pr35971_red.f90: In function 'gp':
pr35971_red.f90:67:0: error: non-trivial conversion at assignment
void (*<T64>) (void)
void (*<T49d>) (struct array1_unknown &, integer(kind=4), struct
array1_integer(kind=4) & restrict)
__result_gp_72 = make_mess;
pr35971_red.f90:67:0: internal compiler error: verify_stmts failed
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47240] [F03] segfault with procedure pointer component
2011-01-10 9:10 [Bug fortran/47240] New: segfault with procedure pointer component m.a.hulsen at tue dot nl
` (7 preceding siblings ...)
2011-01-11 23:15 ` dominiq at lps dot ens.fr
@ 2011-01-12 21:00 ` janus at gcc dot gnu.org
2011-01-12 21:21 ` dominiq at lps dot ens.fr
` (7 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu.org @ 2011-01-12 21:00 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47240
--- Comment #9 from janus at gcc dot gnu.org 2011-01-12 20:00:37 UTC ---
(In reply to comment #8)
> [macbook] f90/bug% gfc -O2 pr35971_red.f90
> pr35971_red.f90: In function 'gp':
> pr35971_red.f90:67:0: error: non-trivial conversion at assignment
> void (*<T64>) (void)
> void (*<T49d>) (struct array1_unknown &, integer(kind=4), struct
> array1_integer(kind=4) & restrict)
> __result_gp_72 = make_mess;
>
> pr35971_red.f90:67:0: internal compiler error: verify_stmts failed
sorry, I can not reproduce this at r168655 (plus patch from comment #7), at
least not on x86_64-unknown-linux-gnu. Do you only get this error with the
patch, or also with a clean trunk? I would expect that my patch should not have
any impact on your test case ...
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47240] [F03] segfault with procedure pointer component
2011-01-10 9:10 [Bug fortran/47240] New: segfault with procedure pointer component m.a.hulsen at tue dot nl
` (8 preceding siblings ...)
2011-01-12 21:00 ` janus at gcc dot gnu.org
@ 2011-01-12 21:21 ` dominiq at lps dot ens.fr
2011-01-12 21:54 ` burnus at gcc dot gnu.org
` (6 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: dominiq at lps dot ens.fr @ 2011-01-12 21:21 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47240
--- Comment #10 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-01-12 20:59:31 UTC ---
> sorry, I can not reproduce this at r168655 (plus patch from comment #7), at
> least not on x86_64-unknown-linux-gnu. Do you only get this error with the
> patch, or also with a clean trunk? I would expect that my patch should not have
> any impact on your test case ...
I am rebuilding a clean tree with only the following patch
diff -up ../_clean/gcc/fortran/resolve.c gcc/fortran/resolve.c
--- ../_clean/gcc/fortran/resolve.c 2011-01-09 22:13:56.000000000 +0100
+++ gcc/fortran/resolve.c 2011-01-12 21:49:39.000000000 +0100
@@ -4858,6 +4858,9 @@ expression_rank (gfc_expr *e)
for (ref = e->ref; ref; ref = ref->next)
{
+ if (ref->type == REF_COMPONENT && !ref->next)
+ rank = ref->u.c.component->as ? ref->u.c.component->as->rank : 0;
+
if (ref->type != REF_ARRAY)
continue;
diff -up ../_clean/gcc/fortran/trans-expr.c gcc/fortran/trans-expr.c
--- ../_clean/gcc/fortran/trans-expr.c 2011-01-08 20:18:07.000000000 +0100
+++ gcc/fortran/trans-expr.c 2011-01-12 21:49:39.000000000 +0100
@@ -3044,7 +3044,8 @@ gfc_conv_procedure_call (gfc_se * se, gf
|| (fsym->attr.proc_pointer
&& !(e->expr_type == EXPR_VARIABLE
&& e->symtree->n.sym->attr.dummy))
- || (e->expr_type == EXPR_VARIABLE
+ || (fsym->attr.proc_pointer
+ && e->expr_type == EXPR_VARIABLE
&& gfc_is_proc_ptr_comp (e, NULL))
|| fsym->attr.allocatable))
{
(your patch for trans-expr.c does not apply cleanly with a copy&past from
safari, so I hope I got it right).
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47240] [F03] segfault with procedure pointer component
2011-01-10 9:10 [Bug fortran/47240] New: segfault with procedure pointer component m.a.hulsen at tue dot nl
` (9 preceding siblings ...)
2011-01-12 21:21 ` dominiq at lps dot ens.fr
@ 2011-01-12 21:54 ` burnus at gcc dot gnu.org
2011-01-12 22:40 ` dominiq at lps dot ens.fr
` (5 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-01-12 21:54 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47240
--- Comment #11 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-01-12 21:49:23 UTC ---
(In reply to comment #9)
> > pr35971_red.f90:67:0: internal compiler error: verify_stmts failed
I can reproduce this with a clean trunk on x86-64-linux with both -m32 and
-m64.
> I can not reproduce this at r168655 (plus patch from comment #7)
How do you configure gfortran? (I did a full bootstrap and did *not* use
--enable-checking=release.)
* * *
Regarding the test case: I think it is invalid:
function aux(x)
interface
subroutine x() bind(C)
end subroutine x
end interface
but you pass as actual argument the function (!) "make_mess" which take also
arguments to "aux". (In get_funloc everything is still fine - the actual
argument has the proper type: "abstract_fun".)
I believe that the argument mismatch is invalid. And the compiler has no chance
to detect this at (front-end) compile time as you use a dummy "external y"
instead of the explicit interface of "aux".
Like always: A compiler can tolerate to a certain extend argument mismatches -
but especially with higher optimization values, it trusts the user that (s)he
knows what he is doing - and that (s)he stays within what the standard allows.
(The same is true for alias analysis.)
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47240] [F03] segfault with procedure pointer component
2011-01-10 9:10 [Bug fortran/47240] New: segfault with procedure pointer component m.a.hulsen at tue dot nl
` (10 preceding siblings ...)
2011-01-12 21:54 ` burnus at gcc dot gnu.org
@ 2011-01-12 22:40 ` dominiq at lps dot ens.fr
2011-01-13 6:25 ` jvdelisle at gcc dot gnu.org
` (4 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: dominiq at lps dot ens.fr @ 2011-01-12 22:40 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47240
--- Comment #12 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-01-12 22:18:35 UTC ---
> I can reproduce this with a clean trunk on x86-64-linux with both -m32 and
> -m64.
I confirm that the ICE is not due to the patch.
> Regarding the test case: I think it is invalid:
I have never said that it was valid (it is not mine and you have probably
recognized the style!-). Nevertheless there was no ICE at revision 168625 (I
saw it at revision 168653) and even invalid codes should not give ICE.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47240] [F03] segfault with procedure pointer component
2011-01-10 9:10 [Bug fortran/47240] New: segfault with procedure pointer component m.a.hulsen at tue dot nl
` (11 preceding siblings ...)
2011-01-12 22:40 ` dominiq at lps dot ens.fr
@ 2011-01-13 6:25 ` jvdelisle at gcc dot gnu.org
2011-01-13 18:58 ` dominiq at lps dot ens.fr
` (3 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2011-01-13 6:25 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47240
Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jvdelisle at gcc dot
| |gnu.org
--- Comment #13 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-01-13 05:28:03 UTC ---
Confirmed at 168737
$ gfc -c -O2 red.f90
red.f90: In function ‘gp’:
red.f90:67:0: error: non-trivial conversion at assignment
void (*<T64>) (void)
void (*<T496>) (struct array1_unknown &, integer(kind=4), struct
array1_integer(kind=4) & restrict)
__result_gp_72 = make_mess;
red.f90:67:0: internal compiler error: verify_stmts failed
Looks like an optimization bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47240] [F03] segfault with procedure pointer component
2011-01-10 9:10 [Bug fortran/47240] New: segfault with procedure pointer component m.a.hulsen at tue dot nl
` (12 preceding siblings ...)
2011-01-13 6:25 ` jvdelisle at gcc dot gnu.org
@ 2011-01-13 18:58 ` dominiq at lps dot ens.fr
2011-01-18 23:21 ` janus at gcc dot gnu.org
` (2 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: dominiq at lps dot ens.fr @ 2011-01-13 18:58 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47240
--- Comment #14 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-01-13 18:43:27 UTC ---
> I have never said that it was valid (it is not mine and you have probably
> recognized the style!-). Nevertheless there was no ICE at revision 168625 (I
> saw it at revision 168653) and even invalid codes should not give ICE.
I did not read my logs correctly!-(the ICE is due to revision 168665, see
pr47281). Note that otherwise the patch summarized in comment #10 works as
advertised.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47240] [F03] segfault with procedure pointer component
2011-01-10 9:10 [Bug fortran/47240] New: segfault with procedure pointer component m.a.hulsen at tue dot nl
` (13 preceding siblings ...)
2011-01-13 18:58 ` dominiq at lps dot ens.fr
@ 2011-01-18 23:21 ` janus at gcc dot gnu.org
2011-01-18 23:21 ` janus at gcc dot gnu.org
2011-01-19 8:57 ` m.a.hulsen at tue dot nl
16 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu.org @ 2011-01-18 23:21 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47240
--- Comment #15 from janus at gcc dot gnu.org 2011-01-18 22:40:38 UTC ---
Author: janus
Date: Tue Jan 18 22:40:33 2011
New Revision: 168973
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168973
Log:
2011-01-18 Janus Weil <janus@gcc.gnu.org>
PR fortran/47240
* resolve.c (expression_rank): Fix rank of procedure poiner components.
* trans-expr.c (gfc_conv_procedure_call): Take care of procedure
pointer components as actual arguments.
2011-01-18 Janus Weil <janus@gcc.gnu.org>
PR fortran/47240
* gfortran.dg/proc_ptr_comp_29.f90: New.
Added:
trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_29.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47240] [F03] segfault with procedure pointer component
2011-01-10 9:10 [Bug fortran/47240] New: segfault with procedure pointer component m.a.hulsen at tue dot nl
` (14 preceding siblings ...)
2011-01-18 23:21 ` janus at gcc dot gnu.org
@ 2011-01-18 23:21 ` janus at gcc dot gnu.org
2011-01-19 8:57 ` m.a.hulsen at tue dot nl
16 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu.org @ 2011-01-18 23:21 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47240
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #16 from janus at gcc dot gnu.org 2011-01-18 23:09:31 UTC ---
Fixed with r168973. Closing.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47240] [F03] segfault with procedure pointer component
2011-01-10 9:10 [Bug fortran/47240] New: segfault with procedure pointer component m.a.hulsen at tue dot nl
` (15 preceding siblings ...)
2011-01-18 23:21 ` janus at gcc dot gnu.org
@ 2011-01-19 8:57 ` m.a.hulsen at tue dot nl
16 siblings, 0 replies; 18+ messages in thread
From: m.a.hulsen at tue dot nl @ 2011-01-19 8:57 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47240
--- Comment #17 from Martien Hulsen <m.a.hulsen at tue dot nl> 2011-01-19 08:34:21 UTC ---
(In reply to comment #16)
> Fixed with r168973.
Indeed. Thanks. All my test problems for my FEM code run correctly now with
gfortran.
^ permalink raw reply [flat|nested] 18+ messages in thread