User account creation filtered due to spam.
> > > From what I've seen, one of the main problems with Fortran and
> > > aliasing is the pass-by-reference rule in Fortran. This often tricks
> > > alias analysis into overstating the amount of call-clobbered variables.
> > Can we do something in the frontend to overcome the pass-by-reference
> > rule? Can some of the analysis be done where we have the information
> > and the variables be marked up ins some way?
> We need middle-end support to annotate function parameters as read-only
> and/or non-escaping.
Fortran allows to specify that certain arguments of procedures (functions and subroutines) have "intent(in)", i.e. are not modified by the procedure, or to be "intent(out)", i.e. their value on entry might be undefined.
Additionally, there exist PURE functions, which may not modify any of the passed arguments nor global variables. This is actually also true for many functions provided by the Fortran library, e.g. matrix products ("matmul()") or dot_product()s; while for simple cases they are inlined, for more complicated ones (e.g. several dimensions with strides) they are not but a call to the Fortran library is generated.
Even if a temporary variable is created, one can do optimizations:
D.14354 = foo; // Not needed for intent(out)
foo = D.14354; // Not needed for intent(in)
(In Fortran code: "call bar(foo)" where bar is defined, e.g., as:
"subroutine bar(a); real, intent(in) :: a")
Isn't this similar to
and other functions that we know for sure don't modify their arguments. It seems a missed optimisation not only for Fortran.
Actually, that is for Wuninitialized. For a missed optimisation:
char str = "Hola";
c = str;
We're (slowly) working on this.
See also my mail http://gcc.gnu.org/ml/fortran/2009-08/msg00200.html
about this issue.
Perhaps that's somehow related to the issue described in this message:
Is this PR fixed by revision 165559 or not?
Not sure - the middle-end now has the 'fn spec' attribute, so middle-end support
is ready. The revision in question only marks IO library calls properly,
not as requested user functions with INTENT(IN)/INTENT(OUT) (?)
So, closing the middle-end part as fixed (this was a middle-end bug).
Eventually a Fortran bug still needs to be opened.