------- 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
