On Thu, 1 Jul 2021, Richard Biener via Gcc-patches wrote: > > C++ FE doesn't support _FLoat16, and the place float/double are > > handled is in convert.c(which is GENERIC?), that's why I decided to do > > it in the backend.
I think there ought to be a preliminary patch series adding whatever _FloatN support is relevant to the C++ front end - covering at least those types that have modes different from float / double / long double, even if you don't cover all the _FloatN / _FloatNx types (e.g. _Float32 as distinct from float), and ensuring the corresponding constant suffixes are also accepted in C++ in whatever way makes sense for that language. (As I noted in bug 85518, there are ICEs in name mangling when such types escape into C++ code at present.) When this was discussed on the gcc list in March, Jonathan Wakely at least supported making _Float16 available in C++ <https://gcc.gnu.org/pipermail/gcc/2021-March/234982.html> <https://gcc.gnu.org/pipermail/gcc/2021-March/235008.html>, even if no C++ front-end maintainers contributed to that discussion. > Yes, but we can easily add a pattern to match.pd, sth like > > (for sq (SQRT) > (simplify > (convert (sq@1 (convert @0))) > (if (types_match (type, TREE_TYPE (@0)) > && TYPE_PRECISION (TREE_TYPE (@1)) > TYPE_PRECISION (TREE_TYPE (@0)) (With a more complicated precision condition, see convert.c for details.) -- Joseph S. Myers jos...@codesourcery.com
