On Thu, Jul 1, 2021 at 11:49 PM Joseph Myers <jos...@codesourcery.com> wrote: > > 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.
Agreed. > > 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
