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