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. -- H.J.
