Hi Richard,
On 11/21/19 3:09 PM, Richard Biener wrote:
So I think what you'd need to do is make 'i' marked as TYPE_RESTRICT
then. I think we don't yet handle it but it means that bar() may not
modify 'i' but via 'i' (but it doesn't get 'i' as a parameter).
Okay, that would be then the attached patch. – I can confirm that it
does not work.
Tobias
diff --git a/gcc/fortran/trans-types.c b/gcc/fortran/trans-types.c
index 82666c48bec..2ffb8cf7529 100644
--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -3056,7 +3056,16 @@ gfc_get_function_type (gfc_symbol * sym, gfc_actual_arglist *actual_args)
type = build_pointer_type (type);
}
else
- type = gfc_sym_type (arg);
+ {
+ type = gfc_sym_type (arg);
+ /* FIXME: There can be some fine tuning, see fine print regarding
+ argument handling in the Fortran standard. Check whether
+ CLASS is handle correctly; check whether something goes wrong
+ if used with asynchronous I/O or ... */
+ if (!arg->attr.target && !arg->attr.pointer
+ && !arg->attr.asynchronous && !arg->attr.codimension)
+ type = build_qualified_type (type, TYPE_QUAL_RESTRICT);
+ }
/* Parameter Passing Convention
real function foo(i, y)
implicit none (type, external)
interface
subroutine print_i(i); integer, intent(in) :: i; end
subroutine bar(); end
end interface
integer :: i
real :: y
foo = 0.0
call print_i(i)
i = 5
call bar() ! < this prevents optimizing the sin(y) away
if (i == 5) return
foo = sin(y)
end
