https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #25 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #24)
> Hi,
> actually it won't help since C has only one bool type and not bools in
> different sizes (why would one need that?).
"Because it's in the Fortran language standard" is probably a good
answer as any. For example, the standard specifies that default
logical and default integer have to have the same size, and
it specifies all the other logical kinds.
> I guess it would be easiest to turn Fortran frontend to use integers here.
Easiest for this case, yes.
However, this is far from the only case where integer vs. logical
is a problem in libgfortran - to reduce code size, we've been treating
them interchangeably for quite some time.
Really, it would be easiest if there was a way to tell the middle
end that logical(kind=4) and integer(kind=4) could alias.
There is another, possibly even worse, case. To reduce combinatorical
explosion of some functions, we have been using this idiom
mask_kind = GFC_DESCRIPTOR_SIZE (mask);
if (mask_kind == 1 || mask_kind == 2 || mask_kind == 4 || mask_kind == 8
#ifdef HAVE_GFC_LOGICAL_16
|| mask_kind == 16
#endif
)
{
/* Do not convert a NULL pointer as we use test for NULL below. */
if (mptr)
mptr = GFOR_POINTER_TO_L1 (mptr, mask_kind);
}
else
runtime_error ("Funny sized logical array");
where GFOR_POINTER_TO_L1 computes an offset between little- and big-endian
systems, and we then access the value bytewise.
If we made this more cleanly, we would add 1505 more functions to the
libgfortran library (rough count).
On the plus side, all of the pointers involved are restrict.
