Spec 2005 and gfortran

[THOMAS Paul Richard 169137]

Toby,

Thank you sir.  I will clear all the remaining PRs tonight.

> 
> I've gone ahead & closed it. There's another, dependent, bug,
> PR20663, which is also now fixed. I can't close that since
> I wasn't the submitter.
> 
> The identifying feature of 20482 is that it
> involved overloading an existing function, while 18108
> only involved overloading user-written functions.
> 
> 20663 involves a generic name for a user-written function
> which happens to have the same name as a fortran statement.
> 
> From the little I know of gfortran internals, I don't think 
> these actually warrant a separate testcase, but it's easy 
> enough to create one if anyone thinks it's worth it.

I am not sure that you are right, although I will have a think about it. The
mechanism that was failing was that of the host association of generic
interfaces; ie those interfaces that one way or another provide a single
call to a number of functions, selected by their interface.  Over-riding
intrinsic or module functions is different in its detail, so I should
probably provide testcases; if for no other reason than to make sure that
the testsuite covers potential, future regressions.

Thanks

Paul Thomas