[Bug fortran/88227] ICE in gfc_convert_boz, at fortran/target-memory.c:788

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88227

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Harald Anlauf from comment #2)
> There is no suitable integer kind for -m32 to represent a real(kind=16).
> 
> target-memory.c:
> 801       for (index = 0; gfc_integer_kinds[index].kind != 0; ++index)
> 802         if ((unsigned) gfc_integer_kinds[index].bit_size >= ts_bit_size)
> 803           break;
> 804
> 805       expr->ts.kind = gfc_integer_kinds[index].kind;
> 806       buffer_size = MAX (buffer_size, size_integer (expr->ts.kind));
> (gdb) p expr->ts.kind
> $13 = 0
> 
> So shall we reject the conversion of the BOZ?

No. Someday, I'll get around to fixing BOZ in gfortran.

The correct solution is to define a basic type of BT_BOZ.
In the gfc_expr structure, we add a new boz member and
assign it the string literal.  Thus, one has

e->ts.type = BT_BOZ;
e->boz = "z'1234'";

gfc_convert_boz then needs to accept a boz expression and
convert to either REAL or INTEGER with the appropriate kind.
A REAL type should never need to go through an INTEGER
intermediate.

Note, the requirements on BOZ varies in an inconsistent
manner between the various standards.  The current behaviors
goes way back to f95 where a BOZ can only technically be
in a DATA statement.  That BOZ is converted to an INTEGER
with the widest range irrespective of what the data-object
was.  Way back then, INTEGER(16) was the largest possible
INTEGER for gfortran on any architecture, so it was decided
to convert the BOZ into an INTEGER with at most 128-bits.

I had a patch that implemented most of the BT_BOZ concept, 
but it has collected too much dust.