[Bug c++/104052] Modules ICE on powerpc64le-linux with -mabi=ieeelongdouble

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I bet we don't reach this because modules.cc has:
/* Global trees.  */
static const std::pair<tree *, unsigned> global_tree_arys[] =
  {
    std::pair<tree *, unsigned> (sizetype_tab, stk_type_kind_last),
    std::pair<tree *, unsigned> (integer_types, itk_none),
    std::pair<tree *, unsigned> (global_trees, TI_MODULE_HWM),
    std::pair<tree *, unsigned> (c_global_trees, CTI_MODULE_HWM),
    std::pair<tree *, unsigned> (cp_global_trees, CPTI_MODULE_HWM),
    std::pair<tree *, unsigned> (NULL, 0)
  };
and special cases those somehow.  So e.g. long_double_type_node and others
#define float_type_node                 global_trees[TI_FLOAT_TYPE]
#define double_type_node                global_trees[TI_DOUBLE_TYPE]
#define long_double_type_node           global_trees[TI_LONG_DOUBLE_TYPE]
or
#define float128_type_node              global_trees[TI_FLOAT128_TYPE]
all go through that.  But modules.cc doesn't know about types the backend
creates
like __ibm128.  __int24 etc. is probably ok due to integer_types
containing
  itk_intN_0,
  itk_unsigned_intN_0,
  itk_intN_1,
  itk_unsigned_intN_1,
  itk_intN_2,
  itk_unsigned_intN_2,
  itk_intN_3,
  itk_unsigned_intN_3,
So, one way through this would be to reserve one or more global_trees for the
extra backend floating point types.