On Tue, Oct 03, 2017 at 04:27:15PM +0200, Janus Weil wrote:
> >>
> >> ... 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?
You are correct that AND, OR, and XOR are not specified in any Fortran
standard. However, the Fortran standards permit an implementation to
include additional intrinsic subprograms not specified in a standard.
Fortran 95 has
A standard-conforming processor may allow additional forms
and relationships provided that such additions do not conflict
with the standard forms and relationships. However, a standard-
conforming processor may allow additional intrinsic procedures
even though this could cause a conflict with the name of a procedure
in a standard-conforming program. If such a conflict occurs and
involves the name of an external procedure, the processor is permitted
to use the intrinsic procedure unless the name is given an interface
body or the EXTERNAL attribute in the same scoping unit (14).
Similar language appears in F03 and F08. The gfortran implementation
and documentation for AND, OR, and XOR defined their behavior.
> >>> 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."
You are correct it is not my decision. You raised an objection.
You and I have a difference of opinion on the correct action to
take. So, I withdraw the patch to maintain the status quo.
Since you're adamant about maintaining nonstandard behavior.
Then, please do not cherry-pick from my patch to enforce F2008
semantics for
program foo
print '(I0)', iand(z'1234',b'1010101')
end program foo
which currently gives
% gfortran6 -static -o z a.f90 && ./z
20
The above nonstandard semantics are currently permitted, and therefore
cannot be changed because someone must have code that uses this feature.
In fact, gfortran current permits
program foo
x = abs(z'7F7FFFFF')
print *, x
end program foo
% gfcx -o z -std=f2008 -Wall a.f90 && ./z
a.f90:3:7:
x = abs(z'7F7FFFFF')
1
Warning: Change of value in conversion from 'INTEGER(16)' to 'REAL(4)'
at (1) [-Wconversion]
2.13909504E+09
Please do not change gfortran's behavior of allowing boz-literal-constants
in all intrinsic routines that accept INTEGER(16) as actual argument(s).
> 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)
>
Reread what I wrote. There is NO MECHANISM TO WARN the user.
-std=f2008 does not produce a WARNING. It produces an ERROR.
For the record, I am aware that -std=f2008 produces an (un)desirable
result for AND, OR, and XOR. However, if someone is inclined to
use -std=f2008, then that someone is likely to not use AND, OR, XOR.
That someone will use IAND, IOR, and IEOR with correctly typed
arguments.
--
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow
