Hi Steve, >> >> 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. > > F95 and F03 have > > IAND(I,J) > > Arguments. > > I shall be of type integer. > J shall be of type integer with the same kind type parameter as I. > > and F08 has > > I shall be of type integer or a boz-literal-constant. > J shall be of type integer or a boz-literal-constant. If both I and J > are of type integer, they shall have the same kind type parameter. > I and J shall not both be boz-literal-constants. > > If a user wants to mix the kind type parameters, then the user > can use AND, OR, and XOR.
... which are non-standard, just as differing kinds in IAND. Why would AND(i4,i8) be any 'better' than IAND(i4, i8) from your point of view? >> Btw, contrary to your earlier claim, the extension is actually >> documented: https://gcc.gnu.org/onlinedocs/gfortran/IAND.html > > A parenthetical remark hardly counts as documentation. It is pretty much better than nothing I'd say. Lack of documentation is not a good motivation for removing a feature (but rather for enhancing the documentation). >>> 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. > > gfortran should encourage users to write standard conforming code. I absolutely fully agree here. But it should not do this by unimplementing non-standard features, but rather by providing a mechanism to let the user choose between * "I want my code to strictly comply with my favorite Fortran standard" and * "I need to use this or that non-standard feature, for this or that reason. I know that Steve doesn't like it, but quite frankly it's not his decision to make." Note that such a mechanism is very nicely provided by the flag "-std=...", which is certainly one of the stronger points of gfortran. https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html > % cat a.f90 > program foo > integer(4) :: i = 4 > integer(8) :: j = 5 > print *, iand(i,j) > end program foo > % gfortran6 -Wall -c a.f90 > % gfortran6 -Wconversion -c a.f90 > % gfortran6 -Wall -Wextra -c a.f90 > % gfortran6 -Wall -Wextra -Wsurprising -c a.f90 > > There is no mechanism available to warn the user of nonstandard code. Of course there is: $ gfortran -std=f2008 a.f90 a.f90:4:17: print *, iand(i,j) 1 Error: GNU Extension: Different type kinds at (1) > Finally, I have neither the time nor energy to debate the merits of > a dubious undocumented bug/feature. I have supplied a patch. An > objection has been raised. I withdraw the patch. If every patch submitter would withdraw his patches after getting a review, gfortran wouldn't be going anywhere I guess. I never claimed that your patch is all bullshit. I told told you one detail I don't like about it, and I think that's my good right (or even my duty) as a reviewer. It's actually very simple to fix, but you already got two OKs, so you can just as well ignore my opinion and commit your patch as posted. Cheers, Janus
