On Mon, Mar 23, 2026 at 2:38 PM H.J. Lu <[email protected]> wrote: > > On Sun, Mar 22, 2026 at 9:44 AM Jeffrey Law > <[email protected]> wrote: > > > > > > > > On 2/27/2026 4:42 PM, H.J. Lu wrote: > > > On Sat, Feb 28, 2026 at 7:32 AM Jeffrey Law > > > <[email protected]> wrote: > > >> > > >> > > >> On 2/25/2026 5:52 PM, H.J. Lu wrote: > > >> > > >> On Thu, Feb 26, 2026 at 8:39 AM H.J. Lu <[email protected]> wrote: > > >> > > >> TARGET_PROMOTE_PROTOTYPES is an optimization, not an ABI requirement. > > >> TARGET_PROMOTE_FUNCTION_MODE should be used for ABI requirement. Like > > >> xtensa, mcore ABI requires sign extension of signed 8/16-bit integer > > >> arguments to 32 bits and zero extension of unsigned integer 8/16-bit > > >> arguments to 32 bits: > > >> > > >> 1. Rename xtensa_promote_function_mode to > > >> default_promote_function_mode_sign_extend to sign-extend signed 8/16-bit > > >> integer arguments to 32 bits and zero-extend of unsigned 8/16-bit > > >> integer arguments to 32 bits. > > >> 2. Replace xtensa_promote_function_mode with > > >> default_promote_function_mode_sign_extend. > > >> 3. Remove TARGET_PROMOTE_PROTOTYPES for mcore and define > > >> TARGET_PROMOTE_FUNCTION_MODE with > > >> default_promote_function_mode_sign_extend to properly extend 8/16-bit > > >> arguments to 32 bits. > > >> > > >> Targets with the same ABI requirement should define > > >> TARGET_PROMOTE_FUNCTION_MODE with > > >> default_promote_function_mode_sign_extend. > > >> > > >> gcc/ > > >> > > >> PR target/119979 > > >> PR target/120888 > > >> * targhooks.cc (default_promote_function_mode_sign_extend): New. > > >> * targhooks.h (default_promote_function_mode_sign_extend): > > >> Likewise. > > >> * config/mcore/mcore.cc (TARGET_PROMOTE_FUNCTION_MODE): Use > > >> default_promote_function_mode_sign_extend. > > >> (TARGET_PROMOTE_PROTOTYPES): Removed. > > >> * config/xtensa/xtensa.cc (xtensa_promote_function_mode): Removed. > > >> (TARGET_PROMOTE_FUNCTION_MODE): Use > > >> default_promote_function_mode_sign_extend. > > >> > > >> gcc/testsuite/ > > >> > > >> PR target/119979 > > >> PR target/120888 > > >> * gcc.target/xtensa/pr120888-1.c: Removed to ... > > >> * gcc.dg/zero-extend.c: This. Enable for mcore and xtensa. > > >> * gcc.target/xtensa/pr120888-2.c: Removed to ... > > >> * gcc.dg/sign-extend.c: This. Enable for mcore and xtensa. > > >> > > >> > > >> -- > > >> H.J. > > >> > > >> Add the missing patch. > > >> > > >> Note you broke mcore-elf in new and interesting ways. > > >> > > >> Tests that now fail, but worked before (2 tests): > > >> > > >> mcore-sim: gcc: gcc.dg/tree-ssa/pr84436-5.c execution test > > >> mcore-sim: gcc: gcc.dg/tree-ssa/pr84436-5.c execution test > > > How does it fail? > > So what is the final resolution on the mcore failures? I believe: > > > > 1. You have a patch which fixes that regression. > > 2. There is a larger question about the correctness of the > > PROMOTE_MODE (pr124467) > > > > Given we're just a few weeks away from a release, I would not be > > inclined to change PROMOTE_MODE. So can you please do the right thing > > WRT your patch for the pr84436-5 regression? > > I have identified that PROMOTE_MODE is the root cause. Have you > tried > > https://gcc.gnu.org/bugzilla/attachment.cgi?id=63911 > > > > > > >> And you broke iq2000-elf: Tests that now fail, but worked before (99 > > >> tests): > > >> > > >> iq2000-sim: gcc: c-c++-common/pr111309-1.c -Wc++-compat execution test > > >> [ ... ] > > > This patch doesn't change iq2000. > > I had a patch (from you I believe) which fixed an earlier set of iq2000 > > regressions from your original promotion patch. That changed > > TARGET_PROMOTE_FUNCTION_MODE from > > default_promote_function_mode_always_promote to > > default_promote_function_mode. That patch was never submitted AFAICT > > Since I didn't get any feedbacks, I didn't submit it. Here is the updated > patch: > > https://patchwork.sourceware.org/project/gcc/list/?series=59102 > > > and thus you left iq2000 regressed and it was so long ago that we've > > totally lost state on whatever tests were failing that caused you to > > send me that patch. > >\ > > The right thing to do here would be for you go go all the way back to > > the point before you integrated those promotion changes, get a build & > > test of the iq2000 port, apply your promotion patch, see what breaks and > > fix it. You'd need to make sure you've got the simulator in place, > > newlib built, dejagnu baseboard file to enable execution testing, etc to > > get real results. > > > > The overall point being you broke things in the ABI space for a couple > > ports, but haven't really been proactive on getting them fixed and thus > > here we are 11 months later with two ports still showing correctness > > problems due to your patch. I acked your original patch on the > > assumption that you would handle any fallout. I'm not likely to do that > > again for target independent work, particularly in the ABI space. > > > > Jeff > > I have commented in the bug report: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119979 > > But the feedback is quite slow.
Maybe it helps to CC the maintainer of the port. Nick, you are listed, are you really up to it still? If the port is unmaintained the option is always to deprecated it and remove it next stage1. Richard. > -- > H.J.
