On 22/09/2026 09:49, Kevin Stefanov wrote:
Okay, I'm now trying to reproduce the emitted assembly code,
so I can test whether my change will actually be working or not,
but I had GCC tell me that -march=armv9.5-a is a bad option.

I figured this was because I had built a gcc capable of targeting
x86, not ARM, so I tried bootstrapping a cross compiler for
ARM from current trunk sources after Claude gave me some
setup instructions, but it didn't work. I looked on the GNU
webpages but I couldn't find exact instructions for this either.
I'm doing this on an x86_64 laptop running Fedora natively.
The steps from Claude that I tried:

sudo dnf -y install sysroot-aarch64-fc$(rpm -E %fedora)-glibc
sudo dnf -y install binutils-aarch64-linux-gnu

Then from my build directory separate from the source dir:

../gcc/configure \
     --target=aarch64-linux-gnu \
     --prefix=$HOME/GCC-CLONED-ARM \
     --with-sysroot=/usr/aarch64-redhat-linux/sys-root/fc44 \
     --enable-languages=all \
     --disable-multilib

This generates a Makefile all good, but then "make" fails
after a while. Is there any hope to set this cross compiler
testing on my x64 laptop or do I have to get on one of the
aarch64 farm machines and test my changes on it?

Hi Kevin,

I'm by no means a gcc build system expert, but I will just say quickly that there is no need to bootstrap the compiler while in development. It will just slow down your incremental builds a lot.

You can add --disable-bootstrap to the configure command and it will likely simplify getting a cross compiler build setup.

Bootstrap is not really required for what you likely need to do for this, and will be more useful as part of testing, and to check you don't have any warnings. So it will need to be done before posting the patch to the mailing list.

From my experience a bootstrap build is easiest natively. So either the cfarm, or an emulated VM (this will also be required for regression testing). You should also test a native x86_64 build which will be easier.

Kind regards, and good luck!
Alfie




On Thu, Sep 17, 2026 at 10:11 PM Andrea Pinski
<[email protected]> wrote:

On Thu, Sep 17, 2026 at 11:51 AM Kevin Stefanov
<[email protected]> wrote:

Hi all,

I got assigned Easy Issue of Week 52 a while back and have now
started digging in.

After looking around in simplify-rtx.cc for a while, I believe the
code for this simplification should be added under the "case SMAX:"
switch case, before the simplify_associative_operation call on
line 5038, correct?

Hi Kevin,
   First off thanks for taking a stab at a rtl change.
Yes that is the correct location where this matching/simplification
would be placed.


Also, could somebody point me to some example code I could have a
look at, that would help me understand how the check for operand
pattern (a, -a) and the operation's actual conversion to abs(a)
would look like?

At the very beginning of the
simplify_context::simplify_binary_operation_1 function, there is one
for PLUS and conversion to NEG:
       /* (~a) + 1 -> -a */
       if (INTEGRAL_MODE_P (mode)
           && GET_CODE (op0) == NOT
           && trueop1 == const1_rtx)
         return simplify_gen_unary (NEG, mode, XEXP (op0, 0), mode);
Which can be used as a model.  The only thing is you want to use
rtx_equal_p to compare if 2 rtls are the same (see below for an
example).

Perhaps something along the lines of
"return gen_rtx_ABS(int_mode, op1)" ?

So for RTL, the operands in this function would be op1 and op0.  You
need to first check if one of them is an NEG RTL and then check if the
first operand of that is the same as the other original operand.
To get the operand of a NEG, you use XEXP.  The  index is the saying
(in this case) the first operand of NEG.
So something like:
if (GET_CODE (op0) == NEG && rtx_equal_p (XEXP (op0, 0), op1))

Also you need to check for an integer mode here since SMAX can be used
with floating point as described in rtl.def:
```
The signed variants should be used
    with floating point.  Further, if both operands are zeros, or if either
    operand is NaN, then it is unspecified which of the two operands is
    returned as the result.  */
```
The check would be using INTEGRAL_MODE_P (see machine-mode.h) on the
mode argument.

And then you need to generate ABS:
The easiest way is to use simplify_gen_unary:
simplify_gen_unary (ABS, mode, op1, mode);

And then you need to do the same for the swapped operands snice it is
symmetrical.



Bugzilla page:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126726

Kev

Reply via email to