On Sat, Oct 07, 2017 at 12:37:03PM +0200, Dominique d'Humières wrote:
> (1) Typo in gcc/fortran/array.c
>
> + /* If an array contains a BT_BOZ, then array elements need to be converted
> + an INTEGER. This is an GNU Fortran extension. Mixing BOZ and non-BOZ
> missing ‘to’?
Thanks. I'll fix this
>
> (2) Compiling
>
> integer :: i = 1, j = 2
> print *, ble(i,j), blt(z'ff',z'fa')
> end
>
> gives an ICE
>
> f951: internal compiler error: in compare_bitwise, at fortran/simplify.c:1516
>
> which is
>
> gcc_assert (i->ts.type == BT_INTEGER);
> gcc_assert (j->ts.type == BT_INTEGER);
Whoops. Forgot to check the bge, blt, etc simplification routines.
>
> (3) Compiling (variant of pr54072)
>
> USE, INTRINSIC :: ISO_C_BINDING
> IMPLICIT NONE
> INTEGER, PARAMETER :: GLbitfield=C_INT
> INTEGER(GLbitfield), PARAMETER :: GL_CURRENT_BIT = INT(z'00000001') !
> 0x00000001
> INTEGER(GLbitfield), PARAMETER :: GL_CLIENT_ALL_ATTRIB_BITS = &
> transfer(z'ffffffff',GL_CURRENT_BIT) ! 0xffffffff
This is nonconforming code. A BOZ cannot appear as an arg to transfer.
> print *, GLbitfield, GL_CURRENT_BIT, GL_CLIENT_ALL_ATTRIB_BITS
> END
>
> gives an ICE
>
> f951: internal compiler error: Invalid expression in gfc_element_size.
I'll need to check how we get to gfc_element size from the BOZ
in transfer.
>
> (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
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.
>
> (5) Compiling
>
> print *, real(z'ffffffff',4)
> end
>
> gives
>
> print *, real(z'ffffffff',4)
> 1
> Error: Arithmetic NaN converting REAL(4) to REAL(4) at (1).i
> This check can be disabled with the option '-fno-range-check’
>
> Why not a warning?
Ask Tobias. I retained his gfc_convert_boz function. He
calls range_check() at the end. You get this error prior
to my patch.
> (6) Compiling
>
> print *, storage_size(z'FFFFFFFF')
> end
>
> gives an ICE
>
> f951: internal compiler error: Invalid expression in gfc_element_size.
>
> The code is probably invalid, but I don’t know how to parse
Nonconforming code. A BOZ cannot be an actual arg to storage_size.
In F2008/2015, a BOZ is a typeless and kindless entity.
16.9.184 STORAGE_SIZE (A [, KIND])
A shall be a data object of any type.
7.1.2 Type classification
A type is either an intrinsic type or a derived type.
This document defines five intrinsic types: integer, real, complex,
character, and logical.
A derived type is one that is defined by a derived-type definition
(7.5.2) or by an intrinsic module.
7.7 Binary, octal, and hexadecimal literal constants
A binary, octal, or hexadecimal constant (boz-literal-constant) is a
sequence of digits that represents an ordered sequence of bits. Such a
constant has no type.
>
> Without the patch it returns 128 at run time.
>
That's because 13 to 15 years, I made gfortran convert a BOZ
to INTEGER(gfc_max_integer_kind) when a BOZ was parsed. The
internal representation a BOZ is INTEGER, so storage_size
thinks it is an integer.
--
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow
