2017-09-29 16:08 GMT+02:00 Steve Kargl <s...@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
