diff options
| author | Jakub Jelinek <jakub@redhat.com> | 2022-09-30 18:40:35 +0200 |
|---|---|---|
| committer | Jakub Jelinek <jakub@redhat.com> | 2022-09-30 18:41:15 +0200 |
| commit | a6d8c61a498e9daa1bc7fe419055ae44ad8289cc (patch) | |
| tree | 3f09f79f74289d48455809b61a3caabfa58906dd /gcc/config/rs6000 | |
| parent | fe8264bb9bb1d989c54e55c7a267c2922aa489d9 (diff) | |
| download | gcc-a6d8c61a498e9daa1bc7fe419055ae44ad8289cc.zip gcc-a6d8c61a498e9daa1bc7fe419055ae44ad8289cc.tar.gz gcc-a6d8c61a498e9daa1bc7fe419055ae44ad8289cc.tar.bz2 | |
i386, rs6000, ia64, s390: Fix C++ ICEs with _Float64x or _Float128 [PR107080]
The following testcase ICEs on x86 as well as ppc64le (the latter
with -mabi=ieeelongdouble), because _Float64x there isn't mangled as
DF64x but e or u9__ieee128 instead.
Those are the mangling that should be used for the non-standard
types with the same mode or for long double, but not for _Float64x.
All the 4 mangle_type targhook implementations start with
type = TYPE_MAIN_VARIANT (type);
so I think it is cleanest to handle it the same in all and return NULL
before the switches on mode or whatever other tests.
s390 doesn't actually have a bug, but while I was there, having
type = TYPE_MAIN_VARIANT (type);
if (TYPE_MAIN_VARIANT (type) == long_double_type_node)
looked useless to me.
Note, there is one further problem on aarch64/arm, types with HFmode
(_Float16 and __fp16) are there mangled as Dh (which is standard
Itanium mangling:
::= Dh # IEEE 754r half-precision floating point (16 bits)
::= DF <number> _ # ISO/IEC TS 18661 binary floating point type _FloatN (N bits)
so in theory is also ok, but DF16_ is more specific. Should we just
change Dh to DF16_ in those backends, or should __fp16 there be distinct
type from _Float16 where __fp16 would mangle Dh and _Float16 DF16_ ?
And there is csky, which mangles __fp16 (but only if type's name is __fp16,
not _Float16) as __fp16, that looks clearly invalid to me as it isn't
valid in the mangling grammar. So perhaps just nuke csky's mangle_type
and have it mangled as DF16_ by the generic code?
2022-09-30 Jakub Jelinek <jakub@redhat.com>
PR c++/107080
* config/i386/i386.cc (ix86_mangle_type): Always return NULL
for float128_type_node or float64x_type_node, don't check
float128t_type_node later on.
* config/ia64/ia64.cc (ia64_mangle_type): Always return NULL
for float128_type_node or float64x_type_node.
* config/rs6000/rs6000.cc (rs6000_mangle_type): Likewise.
Don't check float128_type_node later on.
* config/s390/s390.cc (s390_mangle_type): Don't use
TYPE_MAIN_VARIANT on type which was set to TYPE_MAIN_VARIANT
a few lines earlier.
* g++.dg/cpp23/ext-floating11.C: New test.
Diffstat (limited to 'gcc/config/rs6000')
| -rw-r--r-- | gcc/config/rs6000/rs6000.cc | 9 |
1 files changed, 4 insertions, 5 deletions
diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc index b9496d7..d2743f7 100644 --- a/gcc/config/rs6000/rs6000.cc +++ b/gcc/config/rs6000/rs6000.cc @@ -20276,13 +20276,12 @@ rs6000_mangle_type (const_tree type) if (type == bool_int_type_node) return "U6__booli"; if (type == bool_long_long_type_node) return "U6__boolx"; + if (type == float128_type_node || type == float64x_type_node) + return NULL; + if (SCALAR_FLOAT_TYPE_P (type) && FLOAT128_IBM_P (TYPE_MODE (type))) return "g"; - if (SCALAR_FLOAT_TYPE_P (type) - && FLOAT128_IEEE_P (TYPE_MODE (type)) - /* _Float128 should mangle as DF128_ (done in generic code) - rather than u9__ieee128 (used for __ieee128 and __float128). */ - && type != float128_type_node) + if (SCALAR_FLOAT_TYPE_P (type) && FLOAT128_IEEE_P (TYPE_MODE (type))) return "u9__ieee128"; if (type == vector_pair_type_node) |