https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #26 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 6 Jun 2019, tkoenig at gcc dot gnu.org wrote: > 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. I think that's reasonably easy to do for LTO. We'd want to keep the default boolean_type_node size BOOLEAN_TYPEs separate but can glob larger ones with integer types in the canonical type merging. We can probably do the same in non-LTO but that might not be required. Honza? > 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). If the "bytewise" access uses character types (or uint8_t) then TBAA wise that should be fine. If the pointers are restrict you don't lose optimization either.
