Re: [Patch, fortran] PR30922 , PR30883 and PR30870 - rejects-valid bugs

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

Thanks, Jerry.

I realise that for copyright reasons, that I had better acknowledge
Metcalfe, Reid and Cohen in the IMPORT testcase.  Is there any legal
formula for this or is a straight citation enough?

Is anybody prepared to have a go at reviewing the patch for PRs 30531
and 31086?  I consider getting derived type association sorted out to
be a high priority activity - I just regret that I am making such a
meal of it:)  Touch wood, I think that this patch gets us there:
http://gcc.gnu.org/ml/fortran/2007-03/msg00207.html  It certainly
stands up to the codes that usually break derived types.

Best regards

Paul

On 3/14/07, Jerry DeLisle <jvdelisle@verizon.net> wrote:
> Paul Richard Thomas wrote:
> > :ADDPATCH fortran:
> >
> > These three PRs have quite lightweight fixes, which are certainly
> > straightforward:
> >
> > PR30922:
> >
> > This involves IMPORT and interfaces and the part in resolve.c is due
> > to Tobias; to which I objected at the time:)  I was worried that by
> > preventing the test for blocking of host association by same name
> > symbols that this would allow host association into interfaces.
> > Fortunately, there are other mechanisms that prevent this and the test
> > only concerns derived types, anyway.  In addition to Tobias'
> > contribution, I have added a fix in decl.c that prevents gfortran from
> > compiling the only example on IMPORT in Metcalfe, Reid and Cohen.
> > Interfaces, within procedures, need to access the parent namespace via
> > the proc_name symbol.  The testcase is based on the reporter's
> > original with fig. 18.4 from Metcalfe, Cohen and Reid.
> >
> > PR30870:
> >
> > This PR is concerned with data values in DATA statements.  gfortran is
> > presently unable to use derived type components, either for the repeat
> > counts or the data.  The fix uses gfc_match_rvalue and a test for
> > EXPR_STRUCTURE to do the matching, before going on to try to match a
> > name.  The test is the reporter's.
> >
> > PR30870:
> >
> > gfortran currently rejects a generic actual argument, even if there is
> > a specific interface with the same name.  This is fixed by going
> > through the generic interface to look for a specific interface with
> > the same name.  If this is found, an error is not flagged.  The
> > testcase is the reporter's.
> >
> > Bootstrapped and regtested on x86_ia64/FC5 - OK for trunk and, when
> > unblocked, 4.2?
> >
> > Paul
> >
> > 2007-03-12  Tobias Burnus  <burnus@gcc.gnu.org>
> >         Paul Thomas  <pault@gcc.gnu.org>
> >
> >     PR fortran/30922
> >     * decl.c (gfc_match_import): If the parent of the current name-
> >     space is null, try looking for an imported symbol in the parent
> >     of the proc_name interface.
> >     * resolve.c (resolve_fl_variable): Do not check for blocking of
> >     host association by a same symbol, if the symbol is in an
> >     interface body.
> >
> > 2007-03-12  Paul Thomas  <pault@gcc.gnu.org>
> >
> >     PR fortran/30883
> >     * decl.c (match_data_constant): Before going on to try to match
> >     a name, try to match a structure component.
> >
> >     PR fortran/30870
> >     * resolve.c (resolve_actual_arglist): Do not reject a generic
> >     actual argument if it has a same name specific interface.
> >
> > 2007-03-12  Paul Thomas  <pault@gcc.gnu.org>
> >
> >     PR fortran/30922
> >     * gfortran.dg/import5.f90.f90: New test.
> >
> >     PR fortran/30883
> >     * gfortran.dg/data_components_1.f90: New test.
> >
> >     PR fortran/30870
> >     * gfortran.dg/generic_13.f90: New test.
> >
> >
> Paul,
>
> This is OK for trunk and 4.2 after freeze.
>
> Regards,
>
> Jerry


--
Anon: "Ignorantibus veritatem dicere semper utile est."

Abraham Lincoln: "It is better to be thought a fool than to speak and
remove all doubt."