On Sun, Oct 1, 2017 at 8:42 PM, Janus Weil <ja...@gcc.gnu.org> wrote: > 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
Yes, it's documented, and Steve's patch would have removed those words so I presume he was aware of that. I think the crux was that yes, the existence of such an extension was documented, but not the semantics. Is the smaller kind variable sign-extended to match the larger kind? Or zero-extended? Or is the larger kind variable truncated (presumably not, due to the wording in the return value section)? Or something else? And are whatever semantics that are actually implemented guaranteed in some way or are they just accidents due to how the compiler internals happen to work without any thought into it? Furthermore, is such an extension useful? I don't see bitwise logical operations on different sized types making much sense, whatever semantics we ostensibly support. >> 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. Maybe handling both the standard-conforming BOZ semantics and different kind types would have made the patch significantly more complicated, so Steve opted to just delete the non-specified different-kinds extension? Personally, I'm be Ok with Steve's patch as is. -- Janne Blomqvist
