On Mon, Oct 09, 2017 at 06:48:33PM +0200, Dominique d'Humières wrote:
>
> > Le 7 oct. 2017 à 17:48, Steve Kargl <s...@troutmask.apl.washington.edu> a
> > écrit :
> >
> > On Sat, Oct 07, 2017 at 12:37:03PM +0200, Dominique d'Humières wrote:
> >> (4) Compiling
> >>
> >> print *, INT(z'ffffffff',4)
> >> end
> >>
> >> gives
> >>
> >> print *, INT(z'ffffffff',4)
> >> 1
> >> Error: Arithmetic overflow converting INTEGER(-1) to INTEGER(4)
> >> at (1). This check can be disabled with the option '-fno-range-check’
> >>
> >> Should not it be -1?
> >
> > Maybe. :-)
> >
> > See my note to Jerry about needing to implement F2015 16.3.3 correctly.
> > Upon sleeping on this deficiency, I realized that 16.3.3 without stating
> > allows one to set the sign-bit. We find in 16.3.1 the statement
>
> s/16/13/?
Yes. F2008 is 13. F2015 is 16.
> >
> > The interpretation of a negative integer as a sequence of bits
> > is processor dependent.
> >
> > There is the bit model and integer model numbers. F2015 contrasts the
> > models and concludes with
> >
> > In particular, whereas the models are identical for r = 2 and
> > $w_{z-1}$ = 0, they do not correspond for r = 2 or $w_{z-1} = 1$
> > and the interpretation of bits in such objects is processor dependent.
>
> I am not sure this is relevant. The problem here is not about bit
> interpretation, but how you fill 32 bits with a 32-bit pattern.
>
> IMO 'INT(z'ffffffff',4)' should return an integer(4) with all its
> bits set to one.
Yes, of course, but one of those bits is a sign-bit. What gfortran
does at the moment is take a boz, converts it to an mpz_t entity
and sets the kind to gfc_max_integer_kind. The mpz_t entity is
nonnegative. When the boz is used in the context of an INTEGER,
gfortran does a conversion (if necessary), and then typically calls
range_check(). gfortran will issue an error. However, because
the interpretation of a sing-bit is processori dependent, the error
is not needed nor desired for under F2008 and F2015. Likewise, I
think the error can be removed for nan = real(z'fffffff',4).
>
> (7) libgomp/testsuite/libgomp.fortran/aligned1.f03 should be changed as
> gcc/testsuite/gfortran.dg/graphite/id-26.f03:
>
> --- ../_clean/libgomp/testsuite/libgomp.fortran/aligned1.f03 2017-09-28
> 11:35:02.000000000 +0200
> +++ libgomp/testsuite/libgomp.fortran/aligned1.f03 2017-10-09
> 18:29:25.000000000 +0200
> @@ -52,11 +52,11 @@
> ! Attempt to create 64-byte aligned allocatable
> do i = 1, 64
> allocate (c(1023 + i))
> - if (iand (loc (c(1)), 63) == 0) exit
> + if (iand (int(loc (c(1)), 8), 63_8) == 0) exit
> deallocate (c)
> allocate (b(i)%a(1023 + i))
> allocate (c(1023 + i))
> - if (iand (loc (c(1)), 63) == 0) exit
> + if (iand (int(loc (c(1)), 8), 63_8) == 0) exit
> deallocate (c)
> end do
> if (allocated (c)) then
>
> otherwise it fails with -m64.
I don't use -m32 and -m64. Using these options with the testsuite
is silly. Once, my patch hits the tree if this failure is still
present, then you can fix it with
if (iand (int(loc (c(1)), kind(63)), 63) == 0) exit
Note, loc() returns an integer with a kind defined by
gfc_index_integer_kind = get_int_kind_from_name (PTRDIFF_TYPE);
I'm not surprised that PTRDIFF_TYPE may change depending of the
underlying pointer type.
> (8) In gfortran.dg/unf_io_convert_2.f90, why is
>
> integer(1), parameter :: b1 = z'11’, …
This is a GNU Fortran extension. I retained the extension
as I worked on the patch. b1 is a named constant, and the
rhs side is an initialization expression that reduces to a
constant. Here, the constant is a boz and one can easily
grab the type and kind from the LHS. Note, this patch isn't
strictly needed any longer, because I've found a way to allow
a BOZ to be used in an array constructor (another dubious
extension).
>
> valid, but not
>
> integer(1) :: b1
> b1 = z’11’
>
GNU Fortran has a dubious extension that allows a BOZ in
an expression. This may be an accident from my ~13 year
old decision (primary -r95643) to convert a boz to
integer(gfc_max_integer_kind) when a boz is matched. A boz
is a typeless and kindless entity (in F2008 and F2015). The
RHS of an expression is evaluated without reference to the LHS.
What type and kind should be used for z'11'. For
b1 = z'11' + 0
I allow mixed-mode math to convert z'11' to the type and kind
of 0. This expression is basically b1 = int(int(z'11',kind(0))+0,kind(b1)).
If we want to retain the extension the resolve.c probably
needs an update to handle UNARY_PLUS and UNARY_MINUS.
--
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow
