[gfortran, testsuite] Fix bounds checking for substrings, enable bounds chekcing in dg testsuite, assorted fixes

Tobias Schlüter tobias.schlueter@physik.uni-muenchen.de
Sat Nov 25 13:19:00 GMT 2006

FX Coudert <fxcoudert@gmail.com> wrote on Sat, 25 Nov 2006:

>> 3. it fixes a number of out-of-bound accesses in testcases.  The   
>> case in char_transpose_1.f90 I couldn't verify even though it is   
>> what lead to this patch, because this testcase is broken on   
>> i686-darwin due to unrelated reasons.  OTOH this is the same as in   
>> char_spread_1.f90, which I could verify.  g77/dnrm2.f is a bit   
>> special, because it uses the widespread syntax to imitate   
>> assumed-length arrays
>>      dimension a(100)
>>      call s(100, a)
>>      ...
>>      subroutine s(n,a)
>>      dimension a(1)
>>      do i=1,n
>>         a(i) = ...
>>      end do
>>      end subroutine
>> Maybe our bounds checking is overzealous here?
> No, we're right to flag it if the user requested out-of-bounds
> checking. The thing is that we probably want to support it (without
> -fbounds-check) because it's a syntax used in so much legacy code... I
> think what we need is a way to tell the testsuite not to run a
> particular case with -fbounds-check.

It looks like -fno-bounds-check is supported.  So instead of fixing  
the testcase I could add this as a dg-option.

> Hum, why used -fno-repack-arrays? Isn't it the default behaviour
> anyway? And next one: why not use -ftree-vectorize when it makes sense?
> It has been shown to spot a large number of problems in both the
> front-end and the middle-end.

I agree that -ftree-vectorize sounds like an interesting option.   
Replacing -fno-repack-arrays by -ftree-vectorize yields no new  
failures in the testsuite on i686-darwin.

I forgot to mention in my original mail that -fbounds-check leads to a  
weird failure in allocatable_functions_1.f90, which I already  
forwarded to Erik and Paul to look into.

- Tobi

This message was sent using IMP, the Internet Messaging Program.

More information about the Gcc-patches mailing list