gfortran to gfc comparison using gfortran testsuite

[Craig Powers]

François-Xavier Coudert wrote:
>
> Well, I can quote at least a few areas where bugs are blocking many
> real-life codes:
>
>    -- modules: gfortran is a bit weak on that (see for example PR
> 16861 and the number of  Cc: added to it)
>    -- namelists: this may get better with the proposed patches
>    -- arrays: ubound and forall are buggy in some cases, and there
> are many bugs filed with code like "a(/4,1,2/)".

[...]

> But real-life complex codes are a bit out of reach right now.

Aside from trouble with attempted compile-time evaluation of *bound on
derived type arrays (PR19479 IIRC) (which I kludged around in the snapshot
that I downloaded a week or two back) and an instance of complaining about
leaving out a comma in a format string (which I fixed in the fortran
source), gfortran successfully compiles my research group's MC/MD code
(successfully as in generates an executable).  FWIW.  I haven't tried
running it yet, the first time I need to run something I'll try to do a
parallel run with a gfortran-compiled version so that I can compare results.

Speaking of which, PR19479 /may/ be one that someone relatively familiar
with the front-end could fix quickly, depending on whose fault it is that
the compile-time evaluation code is misusing data -- gfc_simplify_bound for
looking in the wrong place or elsewhere in the front-end for putting it in
the wrong place.