On Sun, Oct 01, 2017 at 07:42:09PM +0200, Janus Weil 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.
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.
> 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.
>> 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.
% 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.
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.
--
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow
