On Fri, Oct 11, 2019 at 05:57:04PM +0300, Janne Blomqvist wrote:
> On Sat, Sep 28, 2019 at 10:16 PM Steve Kargl
> <s...@troutmask.apl.washington.edu> wrote:
> >
> > The attached patch issues errors for a few mangled type-specs.
> > It has been regression tested on x86_64-*-freebsd. OK to commit?
> >
> > 2019-09-28 Steven G. Kargl <ka...@gcc.gnu.org>
> >
> > PR fortran/91714
> > * decl.c (gfc_match_decl_type_spec): Issue errors for a few
> > mangled types.
> >
> > 2019-09-28 Steven G. Kargl <ka...@gcc.gnu.org>
> >
> > PR fortran/91714
> > * gfortran.dg/dec_type_print_3.f90: Update dg-error regex.
> > * gfortran.dg/pr91714.f90: New test.
> >
> > A daunting task awaits a brave soul as gfc_match_decl_type_spec
> > is a minefield for bugs. This is dues to the fact the the functions
> > has grown by adding kludge upon kludge upon kludge. The first
> > thing to fix is the broken parsing that follows from the
> > matching of 'type('.
> >
> > --
> > Steve
>
> Ok.
>
This was committed as
r276270 | kargl | 2019-09-29 09:19:58 -0700 (Sun, 29 Sep 2019) | 12 lines
Again, I was getting a backlog of patches, and committed this
as somewhat obvious.
I will repeat that gfc_match_decl_type_spec has become a difficult
nightmare to work through. The complication comes from the new
TYPE(INTRINSIC-TYPE-SPEC) feature of either F2008 or F2018. In
developing this patch, I found that something like
type(character(len=1)
is accepted as valid, but it is missing the closing ')'. I cannot
find why the closing ')' in character is used twice!
A long range project would be to split the declaration matching into
gfc_match_type_decl_stmt and gfc_match_intrinsic_type_decl. Then, we
can refactor gfc_match_decl_type_spec as
gfc_match_decl_type_spec
gfc_match_type_decl_stmt
gfc_match_intrinsic_type_decl
<match nonstandard type, e.g., BYTE>
There are complication because TYPE is overloaded via TYPE(*)
TYPE(derive-type), and a nonstandard TYPE for IO.
--
Steve
