Re: [Patch, Fortran, OOP] PR 56261: seg fault call procedure pointer on polymorphic array

[Janus Weil <janus at gcc dot gnu dot org>]

2013/4/12 Tobias Burnus <burnus@net-b.de>:
> Am 12.04.2013 00:17, schrieb Janus Weil:
>
>>> Hmm, I think I'd prefer to have for the arguments only a warning with
>>> -std=gnu - except for the function result value, which should always be
>>> an
>>> error. And also the "requires an explicit interface" checks should always
>>> use an error.
>>
>> Why the distinction (apart from: NAG does it this way)?
>
> Well, gfortran currently does likewise, as do g95 and crayftn. pathf95 and
> sunf95 only warns for both examples. PGI accepts both. Intel accepts both,
> except with "-warn all" - then it prints an error.
>
> In addition, results-variable types lead definitely to wrong code while
> argument mismatches are effectively fine if one does not touch the argument
> or one can play tricks by explicitly passing arguments of the wrong size
> which has the same storage size. I concur that those tricks are dirty.
>
>
>> The nice thing about the current patch is that it just relies on the
>> full machinery of "gfc_compare_interfaces". Making distinctions about
>> where to give an error or warning probably requires again a certain
>> amount of code-duplication from interface.c. Or do you see a
>> technically simple way to do this?
>
> Well, the issue only occurs with the function result, i.e. just checking the
> result type for the error should be simple. The rest - including the string
> length - could then be left to gfc_compare_interfaces. With string lengths
> not that much can go wrong - compared to wrong types+ranks.

Ok, that's what the patch does now: Always error for wrong result
type, then do the full interface check, but only give a warning with
-std=gnu and -std=legacy, and an error otherwise.

Will do another regtest now. Are you okay with this version?

Cheers,
Janus

Attachment: pr56261_v8.diff
Description: Binary data