> 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/?
>
> 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.
(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.
(8) In gfortran.dg/unf_io_convert_2.f90, why is
integer(1), parameter :: b1 = z'11’, …
valid, but not
integer(1) :: b1
b1 = z’11’
?
Dominique
> --
> Steve
> 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
> 20161221 https://www.youtube.com/watch?v=IbCHE-hONow
