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.
