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