[PATCH] Fix fortran/81509

[Steve Kargl]

On Sun, Oct 01, 2017 at 07:42:09PM +0200, Janus Weil wrote:
> 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.

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