Hi Richi and Joseph, on 2024/5/24 20:23, Richard Biener wrote: > On Fri, May 24, 2024 at 12:20 PM Kewen.Lin <li...@linux.ibm.com> wrote: >> btw, the attached patch is bootstrapped and regtested on >> powerpc64-linux-gnu and powerpc64le-linux-gnu with all >> languages on, cross cc1 built well for affected ports. > > Looks reasonable to me - I'd split language changes out but > keep target and middle-end together. The middle-end parts > look good to me - I'm always a bit nervous when using > size and precision exchangably, esp. for FP, but it seems > this has been done before.
Thanks for the suggestion! I'll split them into a patch series as components soon and follow this suggestion when committing (some preparation language changes go first and squash the others together). on 2024/5/29 05:06, Joseph Myers wrote: > On Fri, 24 May 2024, Kewen.Lin wrote: > >> Following your suggestion and comments, I made this patch >> for mode_for_floating_type first, considering this touches >> a few FE and port specific code, I think I have to split >> it into a patch series. Before making that, I'd like to >> ensure this meets what you expected, and also seek for the > > The general idea seems reasonable (I haven't reviewed it in detail). > Note that when removing a target macro, it's a good idea to add it to the > "Old target macros that have moved to the target hooks structure." list > (of #pragma GCC poison) in system.h to ensure any new target that was > originally written before the change doesn't accidentally get into GCC > while still using the old macros. > Thanks for the comments on target macro removal! I found it means that we can't use such macros any more even if they have become port specific. For some targets such as pa, they redefine these macros in some subtarget headers, or these macros get used in other macro definitions. Considering leaving them can have better readability, I didn't try to change them in this RFC/PATCH, I'll update them with target prefix in the following patch series. BR, Kewen