Hi Jakub & Andrew, on 2023/12/12 22:42, Jakub Jelinek wrote: > On Tue, Dec 12, 2023 at 09:33:38AM -0500, Andrew MacLeod wrote: >> I leave this for the release managers, but I am not opposed to it for this >> release... It would be nice to remove it for the next release > > I can live with it for GCC 14, so ok, but it is very ugly.
Thanks, pushed as r14-6478-gfda8e2f8292a90. And yes, I strongly agree that we should get rid of this in next release. > > We should fix it in a better way for GCC 15+. > I think we shouldn't lie, both on the mode precisions and on type > precisions. The middle-end already contains some hacks to make it > work to some extent on 2 different modes with same precision (for BFmode vs. > HFmode), on the FE side if we need a target hook the C/C++ FE will use > to choose type ranks and/or the type for binary operations, so be it. > It would be also great if rs6000 backend had just 2 modes for 128-bit > floats, one for IBM double double, one for IEEE quad, not 3 as it has now, > perhaps with TFmode being a macro that conditionally expands to one or the > other. Or do some tweaks in target hooks to keep backwards compatibility > with mode attribute and similar. Thanks for all the insightful suggestions, I just filed PR112993 for further tracking and self-assigned it. BR, Kewen
