Re: [PATCH, fortran-dev] Fix regexps

[Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>]

Dear All,

I have now fixed mvbits_7.f90 and we are down to 3 failures:
Running target unix
...snip...
Running /home/svn/fortran-dev/gcc/testsuite/gfortran.dg/dg.exp ...
FAIL: gfortran.dg/wextra_1.f  -O   (test for warnings, line 4)
...snip...
Running /home/svn/fortran-dev/gcc/testsuite/gfortran.dg/vect/vect.exp ...
FAIL: gfortran.dg/vect/vect-gems.f90  -O   scan-tree-dump-times vect
"vectorized 1 loops" 1
FAIL: gfortran.dg/vect/fast-math-vect-8.f90 scan-tree-dump-times vect
"vectorized 1 loops" 1
...snip...
# of expected passes        45762
# of unexpected failures    3
# of expected failures        38
# of unsupported tests        71

The first is showing the same behaviour with trunk. Adding -Wall to
the dg-options fixes the problem.  The other two I will ignore for the
time being (i) because I do not have the expertise on the
vectorization; and (ii) because they might well go away as I clean up
the changes.

Note that I have no idea whether the modification to pr48636 indicates
a degradation or not. I would be happy to leave it as it is so that
the failure continues to flag up the need for attention. Please
advise.

The next steps are:
(i) To reinstate the part of the patch that is enclosed by #if
0....#endif.  This breaks all the tests of the 'span' mechanism for
associate variables and subref_arrays.  These are easily fixed by
using sm[0] for span, rather than elem_len;
(ii) I will then eliminate the 'span' mechanism completely to use the
new array descriptor correctly in gfc_build_array_ref. I hope that I
can fix all the associated PRs to make this branch wholly F90
compliant; and
(iii) I will eliminate all mention of descriptor_ubound|stride and the
associated functions in trans-array.c.

At this point, it will be time to do some performance comparisons.
Under (ii) I will try to only use pointer arithmetic where it is
necessary and to try to retain array indexing where possible, in order
to maximise the opportunities for optimization.

Obviously, when we try to eliminate the offset, we should see if this
degrades performance.

I will commit tomorrow night unless I receive advice to the contrary.

2014-06-02  Paul Thomas  <pault@gcc.gnu.org>

    * trans-array.c (gfc_conv_expr_descriptor): Use the type of the
    expression for the type of the array. The element length should
    be set initially to the descriptor element type so that the
    stride measure is calculated correctly. Finally (removed from
    compilation at this stage) the descriptor element length is set
    to that of the expression type.
    * trans-stmt.c (gfc_conv_elemental_dependencies): Use the type
    of the elements of the descriptor for 'temptype'. Change the
    comment accordingly.

2014-06-02  Paul Thomas  <pault@gcc.gnu.org>

    * gfortran.dg/pr48636.f90 : Change the expected numbers of
    'phi predicate' predicate from 5 to 7.

Cheers

Paul

On 26 May 2014 11:46, Paul Richard Thomas <paul.richard.thomas@gmail.com> wrote:
> Dear All,
>
> I have analysed the problem with mvbits_7.f90:
>
> It emanates from trans-stmt.c(gfc_conv_elemental_dependencies) and is
> indicative of:
> (i) a problem in gfc_conv_expr_descriptor that "subref array"
> references (eg my_var(:)%my_comp) are not be correctly handled.
> (ii) The element length is correctly being set to that of the
> component but the stride measure is also using this, rather than that
> of the element type of the array.
> (iii) This is similarly true of the argument 'temptype' being fed to
> gfc_trans_create_temp_array.
> (iv) Just to add to the woes, the wrong array 'kind' is being fed to
> pack/unpack.
>
> It's no wonder that this testcase fails and that mvbits_8.f90 has
> valgrind problems!
>
> If is_subref_array (expr) is used to return directly from
> gfc_conv_elemental_dependencies, mvbits_7 runs correctly, which is
> indicative that the analysis is OK.
>
> I am onto it
>
> Cheers
>
> Paul
>
> On 24 May 2014 14:03, Dominique Dhumieres <dominiq@lps.ens.fr> wrote:
>> Dear Paul,
>>
>>> I only find mvbits_7.f90 failing and not *_8.f90.
>>
>> Me too, but valgrind complains:
>>
>> ==47281== Invalid read of size 4
>> ==47281==    at 0xEA254: _gfortran_mvbits_i4 (in /opt/gcc/gcc4.10d/lib/libgfortran.4.dylib)
>> ==47281==    by 0x100000D5B: MAIN__ (mvbits_8.f90:23)
>> ==47281==    by 0x100000E28: main (mvbits_8.f90:26)
>> ==47281==  Address 0x1000137e8 is 0 bytes after a block of size 8 alloc'd
>> ==47281==    at 0x7011: malloc (vg_replace_malloc.c:295)
>> ==47281==    by 0x100000C39: foobar.2332 (mvbits_8.f90:33)
>> ==47281==    by 0x100000D5B: MAIN__ (mvbits_8.f90:23)
>> ==47281==    by 0x100000E28: main (mvbits_8.f90:26)
>> ==47281==
>> ==47281== Invalid write of size 4
>> ==47281==    at 0xEA262: _gfortran_mvbits_i4 (in /opt/gcc/gcc4.10d/lib/libgfortran.4.dylib)
>> ==47281==    by 0x100000D5B: MAIN__ (mvbits_8.f90:23)
>> ==47281==    by 0x100000E28: main (mvbits_8.f90:26)
>> ==47281==  Address 0x1000137e8 is 0 bytes after a block of size 8 alloc'd
>> ==47281==    at 0x7011: malloc (vg_replace_malloc.c:295)
>> ==47281==    by 0x100000C39: foobar.2332 (mvbits_8.f90:33)
>> ==47281==    by 0x100000D5B: MAIN__ (mvbits_8.f90:23)
>> ==47281==    by 0x100000E28: main (mvbits_8.f90:26)
>>
>> and IIRC Tobias sees the test failing.
>>
>>> pr48636.f90 needs the number of occurrences of "phi predicate" updating to 7.
>>
>> Is it expected? If yes, I'll adjust the test.
>>
>>> The missed optimizations are somewhat astonishing  ...
>>
>> In one of his mails, Tobias said that gfortran (fortran-dev) is passing
>> code that confuse the middle-end. Also the graphite people are complaining
>> that gfortran (trunk) does not pass arrays in a form allowing optimization
>> (pr61000, comment 1), see also pr54852, comment 3.
>>
>>> Am going to take a break and benefit from the sun.....
>>
>> Enjoy your fine weather! We have a lot of showers here.
>>
>> Cheers,
>>
>> Dominique
>
>
>
> --
> The knack of flying is learning how to throw yourself at the ground and miss.
>        --Hitchhikers Guide to the Galaxy



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy

Attachment: patch020614.diff
Description: Text document