f2003/f2008, class/extends, multiple gemeric assignment

[Janus Weil]

Hi Paul,

thanks for opening the PR. However, after a closer look into the
Fortran standard, I came to the conclusion that your program is
invalid and gfortran is correct to reject it (for details see PR),
which would mean that ifort's acceptance of the code should be
regarded as a bug.

If ifort (and other compilers?) accept cases like this on purpose, one
might think about allowing it also in gfortran (as an extension), but
one has to be careful about how to decide which procedure should be
used for a specific call.

I would recommend to:
1) Try other compilers. ifort is known to be a bit 'sloppy' at times.
Other compilers like NAG often apply a rather strict interpretation of
the standard. (Possibly there are flags to make ifort apply a more
strict checking?)
2) Post your code at comp.lang.fortran. Some people there have a much
better knowledge of the Fortran standards than I have and could give
you a more qualified opinion on the validity.

Cheers,
Janus



2014/1/8 Paul Kapinos <kapinos@rz.rwth-aachen.de>:
> Hi Janus,
> done: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59720
>
>
>
> On 01/07/14 22:47, Janus Weil wrote:
>>
>> Hi Paul,
>>
>>> please take a look at the attached example. It cannot be compiled using
>>> the
>>> gfortran/4.8.1:
>>>
>>>> $ gfortran -c ___MOD_paul.f90
>>>> ___MOD_paul.f90:42.42:
>>>>
>>>>      generic            :: assignment(=) => assign2
>>>>                                            1
>>>> Error: 'ass_gf' and 'ass_en' for GENERIC '=' at (1) are ambiguous
>>>
>>>
>>> Actually this code piece is derived from an real world code which is
>>> developed using Intel compiler (may be compiled with ifort, runs OK) and
>>> the
>>> actual prevents from porting the code (being still in development) to
>>> 'gfortran'.
>>>
>>> Well, let's take a look at the code.
>>> - module 'kleiner' is no problem - can be compiled when in own file. Type
>>> 'mytype' is defined and '=' is bound to this type.
>>> - module 'grosser' is meant to be a subclass of 'kleiner': the type
>>> 'zwotype' extends the type 'mytype'. Again '=' should be bound to the new
>>> (derived) type 'zwotype' - and this fals.
>>>
>>> Well, as said the Intel's "ifort" compile this with no warnings and AFAIK
>>> the code also runs well. The question now is:
>>> - is that some Intel's extension, or
>>> - is that an Fortran 2003/2008 feature still not supported in gfortran,
>>> or
>>> - is the code in any way not Fortran-standard complying?
>>
>>
>> I think it's a bug in gfortran. Could you file a PR in bugzilla, please?
>>
>> Thanks,
>> Janus
>>
>
>
> --
> Dipl.-Inform. Paul Kapinos   -   High Performance Computing,
> RWTH Aachen University, Center for Computing and Communication
> Seffenter Weg 23,  D 52074  Aachen (Germany)
> Tel: +49 241/80-24915
>