On Sat, Aug 19, 2023 at 10:25:50AM +0100, Jonathan Wakely wrote:
> On Fri, 18 Aug 2023 at 20:08, FX Coudert via Gcc <gcc@gcc.gnu.org> wrote:
> >
> > Hello,
> >
> > On the WIP aarch64-darwin port of GCC 
> > (https://github.com/iains/gcc-darwin-arm64), there are some C++ testsuite 
> > failures which are due to the following:
> >
> > 1. The testsuite check_effective_target_has_q_floating_suffix check tries 
> > to compile the code "float dummy = 1.0q;” to determine if the q suffix is 
> > allowed on floating-point types.
> >
> > 2. The check should pass on aarch64-darwin, and indeed the code compiles, 
> > because the q suffix matches the _Float128 type.
> >
> > 3. However, a warning is emitted which makes the test fail:
> >
> > a.cpp:1:15: warning: converting to 'float' from '_Float128' with greater 
> > conversion rank
> >     1 | float dummy = 1.0q;
> >       |               ^~~~
> >
> >
> > 4. Therefore, the expectations of the different tests fail.
> >
> >
> > Now, I am not sure why other targets are not affected in the same way, for 
> > example, x86_64-linux or x86_64-darwin. Also, I am unsure: is the warning 
> > warranted here? If so, we should adjust the check to silence warnings, or 
> > use a cast. Or is the warning emitted in error?
> 
> It's probably because 1.0q produces __float128 on those targets, not
> _Float128. In C++23 _Float128 (and _Float32 etc.) have special rules
> about implicit conversions to other floating-point types.
> 
> I don't know why 1.0q is _Float128 on aarch64 instead of __float128.

That seems like a bug in the aarch64-darwin port.
1.0q should definitely be __float128 rather than _Float128.

The c-lex.cc code has:
        /* For Q suffix, prefer float128t_type_node (__float128) type
           over float128_type_node (_Float128) type if they are distinct.  */
        if (type == float128_type_node && float128t_type_node)
          type = float128t_type_node;
Now, the generic tree.cc initialization will initialize float128_type_node
(i.e. _Float128) to some floating point type if there is IEEE quad mode
backend support, and float128t_type_node (i.e. __float128) to 
float128_type_node,
and c-family/c-common.cc later on will:
  /* For C, let float128t_type_node (__float128 in some backends) be the
     same type as float128_type_node (_Float128), for C++ let those
     be distinct types that mangle and behave differently.  */
  if (c_dialect_cxx ())
    float128t_type_node = NULL_TREE;
i.e. __float128 and _Float128 are the same type for C and for C++ distinct,
then i386, ia64 and rs6000 backends create their own float128t_type_node
as distinct types.
q/w suffixes aren't supported at all unless the backend overrides
c.mode_for_suffix target hook, and besides the above 3 arches only
aarch64 and pa do that. pa does that iff it it registers __float128
type as an alias to long double and aarch64 except for Darwin does that as
well.  So, if aarch64-darwin wants 64-bit long double, the question is if
it should have __float128 support and q suffix support at all.  If it
should, then it needs to initialize float128t_type_node to a distinct type
if NULL like i386, ia64 and rs6000 backends do (i.e. for C++).

        Jakub

Reply via email to