https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92906
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jason at gcc dot gnu.org,
| |redi at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
One way to handle this would be a hack like:
--- gcc/cp/rtti.c.jj 2020-01-15 00:26:26.605526740 +0100
+++ gcc/cp/rtti.c 2020-01-20 16:56:50.600482313 +0100
@@ -1578,6 +1578,18 @@ emit_support_tinfos (void)
location_t saved_loc = input_location;
input_location = BUILTINS_LOCATION;
doing_runtime = 1;
+
+ /* For compatibility, emit DFP typeinfos even DFP isn't enabled,
+ because we've emitted that in the past. */
+ if (!targetm.decimal_float_supported_p ())
+ {
+ gcc_assert (dfloat32_type_node == NULL_TREE
+ && dfloat64_type_node == NULL_TREE
+ && dfloat128_type_node == NULL_TREE);
+ dfloat32_type_node = make_node (REAL_TYPE);
+ dfloat64_type_node = make_node (REAL_TYPE);
+ dfloat128_type_node = make_node (REAL_TYPE);
+ }
for (ix = 0; fundamentals[ix]; ix++)
emit_support_tinfo_1 (*fundamentals[ix]);
for (ix = 0; ix < NUM_INT_N_ENTS; ix ++)
unfortunately it doesn't work to clear dfloat*_type_node right after
emit_support_tinfo_1 call, because the mangling is done much later. I'd hope
that if the types aren't registered as builtin types and aren't complete it
might not cause that much harm. Or we could instead not touch
dfloat*_type_node at all, but have some GTY array of 3 trees (or put it into
C++ trees array) and emit_support_tinfo_1 for those instead and hack up
mangle.c to also check against those.
Yet another possibility is to create these in libsupc++ in assembly, but that
would need to be macroized.
Jason/Jonathan, thoughts on this?
