Compatibility of array indexing for gcc 3.4.6 and gcc 4.4.7?

[Janus Weil]

Hi guys,

>> of course you are right, the problem results from code which is not
>> written properly (although in the original code this problem is much
>> less obvious).
>>
>> Still, I would like to understand where that behavoir (of returning
>> the first element on gcc 3.4.6 and giving the segmentation fault in
>> gcc.4.4.7) originates from, and why it was defined like that.

well, where the segmentation fault originates from is pretty obvious I
guess (you access an array outside of its bounds!). Btw, when
compiling with -fcheck=all you get a much more informative error
message:

At line 14 of file arraycompat.f90
Fortran runtime error: Index '-2147483647' of dimension 1 of array
'table' below lower bound of 1

Where the g77 behavior originates from I have no idea. Many compilers
allow weird things as an extension to the Fortran standard.


>> Naively, I would have expected the code to give a segmentation fault
>> right away, even with the old compiler.

... then why are you unhappy about the behavior of gfortran?


>> However, this was not the
>> case, and the problem stayed undetected for many years (we use that
>> software for many years on various computer systems).

This is clearly a good reason for switching to a modern compiler like
gfortran (which may be a bit more strict than g77 in some ways, but
can be very useful in debugging your code).

Cheers,
Janus




>> On Fri, 1 Nov 2013, Adam Hirst wrote:
>>
>>> On 01/11/13 10:50, Stefan Schmitt wrote:
>>>>
>>>> when using a large negative integer as an array index, the code
>>>> produced by the old compiler would silently return the first
>>>> element of the array. The code produced by the new compiler
>>>> instead results in a segmentation fault. Some example code is
>>>> attached below. My question is: is there a way to restore the old
>>>> way of treating the large negative array indexes, perhaps using
>>>> some special compiler option?
>>>
>>>
>>> Someone please do correct me if I'm wrong, but am I right in
>>> thinking that behaviour like this is more-or-less utterly
>>> standards non-compliant (and entirely implementation-dependent)?
>>>
>>> ~ Adam