Re: [PATCH] Fix fortran/81509

[Janus Weil <janus at gcc dot gnu dot org>]

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