Hi Alfie, thank you for the suggestion. I added --disable-bootstrap to the configure command but "make" ended with an error again: make: *** [Makefile:1109: all] Error 2
I scrolled up for a while but couldn't spot any actual error message that says what went wrong. Yes, so far for my patches I've always done my testsuite results comparison on a native x86_64 bootstrapped GCC build with: ../gcc/configure --prefix=$HOME/GCC-CLONED --enable-languages=all --disable-multilib make -j$(nproc) make -j$(nproc) -k check cd .. gcc/contrib/compare_tests objdir objdir-contrib On Tue, Sep 22, 2026 at 12:08 PM Alfie Richards <[email protected]> wrote: > > 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 >
