[Fortran] Disambiguate A(I,...) and A(I+1,...)

[Tim Prince]

MOENE Toon wrote:
> Roger,
> 
>> The middle-end assumes that pointer arithmetic doesn't
>> overflow, which I believe is also reasonable in fortran array index
>> expressions (perhaps a language lawyer can comment).
> 
> 
> Yes, you can assume that - it's what allows us to "promote" the 32-bit 
> index
> calculations to 64 bit on 64-bit targets; it doesn't matter if they'd 
> overflow
> 32-bit calculations, because that wouldn't be possible in a legal 
> Fortran program.
> 
> (Strictly speaking, the standard doesn't discuss the size of integers, but
> overflowing is not part of the valid computations you can do with them).
> 
If I am going too far off topic, let me know, but I'm curious:
Is the middle-end shared with g++ ?  Could that limit what gfortran can 
assume?
My colleagues who are C++ language lawyers maintain that it is necessary 
for code to handle pointer overflow, even though it can't be done 
portably.  That is a major inhibitor of C++ optimization.  STL typically 
generates loops in a form
for(T *p=a; p != b; p++)
with nothing to prevent the ill-behaved case a>b.  C, at least, doesn't 
force programmers into that style, but there is the implication that it 
should be supported.
This ignores the insight of the f77 committee, who designed Fortran to 
facilitate countable loops.  To me, that does imply that legal Fortran 
index calculations don't overflow, but compiler writers usually consider 
C++ more important than Fortran in the design of middle-end and back-end.
I recall some gnashing of teeth when we suggested that 64-bit Fortran 
indices should not prevent loop optimization on a 32-bit machine.