Re: [PATCH] Fix fortran/81509

[Janus Weil <janus@gcc.gnu.org>]

2017-09-29 16:08 GMT+02:00 Steve Kargl <sgk@troutmask.apl.washington.edu>:
> On Fri, Sep 29, 2017 at 11:15:47AM +0200, Janus Weil wrote:
>> Hi Steve,
>>
>> > As aside effect, the patch removes a questionable GNU Fortran
>> > extension that allowed arguments to IAND, IOR, and IEOR to have
>> > different kind type parameters.  The behavior of this extension
>> > was not documented.
>>
>> I don't really like that part. We were using the nice and convenient
>> mechanism of gfc_notify_std here, which allows the developer to choose
>> via the -std flag whether to strictly adhere to a chosen Fortran
>> standard or to allow GNU extensions etc. You're taking away that
>> flexibility and replacing it by an unconditional error. I don't
>> actually think that's a good idea.
>>
>> In general one can argue about whether or not it's a good idea to use
>> non-std extensions. But I think gfortran should rather leave the
>> choice to its users, whether they want to use 'dirty and covenient'
>> code or have very strict checking. We have nice mechanisms for this,
>> and I do think we should keep them.
>>
>
> It is undefined behavior.

... with regards to the F08 standard, which forbids it, yes. I guess
that is the nature of a "non-standard extension". It can still give a
meaningful result, after the smaller kind is implicitly converted to
the larger kind.

Btw, contrary to your earlier claim, the extension is actually
documented: https://gcc.gnu.org/onlinedocs/gfortran/IAND.html


> I withdraw the patch.

Why? It does fix a rejects-valid bug after all, doesn't it? I
completely agree with Paul's earlier review that this is good and
necessary.

All I'm saying is that I don't think it's a good idea to turn the
gfc_notify_std into a gfc_error. If you keep the gfc_notify_std, the
patch is ok for trunk from my side.

Cheers,
Janus