This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug fortran/32131] knowing that stride==1 when using allocated arrays and escaping allocatable arrays



------- Comment #7 from jb at gcc dot gnu dot org  2007-06-27 15:56 -------
(In reply to comment #5)
> I can see two ways to address this issue (both of them worth pursuing):
> 
> a) For allocatable arrays, we can always assume stride=1.

But this helps only locally in the procedure where the array is declared. If
you call another procedure with an explicit interface, that procedure cannot
assume that stride==1. I wonder, would it make sense to generate code like

if (stride ==1) then
  some array operation, simplified for the case stride==1
else
  general case
end if

Then at least the stride==1 case could be vectorized, and presumably that is
also the overwhelmingly common case. Of course it would imply some code bloat.
Or is this something the middle-end could do for us?

Of course, with IPA this problem could be solved by looking at all the
callers.. :)

> b) We can tell the middle-end that our random number generator doesn't
>    modify the array descriptor (similar to PR 20165).  Once we've fixed
>    PR 20165, this should be easy, but I don't see anybody working on it.

Another question, do we at the moment tell the middle-end anything about
Fortran aliasing rules? E.g. that after the call to random_number (or any other
procedure) the a->data is not reachable via some other variable? Or is this
another manifestation of the pointer escaping thing from PR 20165? But I would
assume some support exists for C99 restrict, which is similar?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32131


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]