I managed to get on cfarm185, I cloned a pristine gcc,
configured the build with:
../gcc/configure --prefix=$HOME/gcc-build-output-pristine \
--enable-languages=all --disable-multilib \
--target=aarch64-linux-gnu
but I think the machine needs its bison version updated,
my build crashes with:
bison -o cobol/cdf.cc -Werror -Wmidrule-values \
-Wno-yacc --debug --verbose \
--defines=cobol/cdf.h --report-file=cobol/cdf.out \
../../gcc/gcc/cobol/cdf.y
../../gcc/gcc/cobol/cdf.y:363.10-16: error: require bison 3.8.2, but have 3.0.4
%require "3.8.2" // for C++ output
^^^^^^^
make[3]: *** [../../gcc/gcc/cobol/Make-lang.in:159: cobol/cdf.cc] Error 63
I believe I read somewhere that I can't update or download
packages by myself and I need the cfarm admins to do that
for me, right? Should I email them?
Also, does it matter which machine I get on, or can I just pick any
machine whose usage graphs show it's not currently being
oversaturated and used by too many people?
On Wed, Sep 23, 2026 at 6:45 PM Andrea Pinski
<[email protected]> wrote:
>
> On Wed, Sep 23, 2026 at 7:51 AM Kevin Stefanov
> <[email protected]> wrote:
> >
> > Hi all,
> >
> > Good news, I wrote the RTL optimization code snippet in
> > simplify-rtx.cc right before the simplify_associative_operation call:
> > ```
> > if (INTEGRAL_MODE_P (mode))
> > {
> > if (GET_CODE (op0) == NEG && rtx_equal_p (XEXP (op0, 0), op1))
> > return simplify_gen_unary (ABS, mode, op1, mode);
> > else if (GET_CODE (op1) == NEG && rtx_equal_p (XEXP (op1, 0), op0))
> > return simplify_gen_unary (ABS, mode, op0, mode);
> > }
> > ```
>
> This looks correct.
>
> > and compiled the GIMPLE code from the bugzilla page with:
> > ```
> > ../../objdir-contrib-arm/gcc/xgcc -B../../objdir-contrib-arm/gcc/ \
> > -fgimple -S -O2 -march=armv9.5-a \
> > RTL-smax-optimization.c -o RTL-smax-optimization.asm
> > ```
> > using the original statement:
> > _3 = __MAX (t_2, a_1(D));
> > and also compiled with the __MAX operands reversed so I
> > can test the code for the second case and they both emitted:
> > ```
> > .LFB0:
> > .cfi_startproc
> > abs w0, w0
> > ret
> > .cfi_endproc
> > ```
> >
> > This is the result we wanted, right?
> Yes it is exactly the results we want.
>
>
> > If so, is my next step to
> > apply for access to the cfarm and get assigned a machine
> > and a directory on it for me to work in, so I can do the usual
> > full bootstrap GCC build targeting aarch64, with and without
> > my changes, run the full testsuite with both and compare results
> > to ensure I didn't introduce any regressions, then send the patch?
>
> Yes that is correct.
>
> Thanks,
> Andrea
>
> >
> > On Tue, Sep 22, 2026 at 4:57 PM Alfie Richards <[email protected]>
> > wrote:
> > >
> > > On 22/09/2026 14:49, Kevin Stefanov wrote:
> > > > Thanks Alfie, that was really helpful.
> > > >
> > > > I reran the make command and the error was trivial
> > > > to spot that time. I then ran "make -j$(nproc) all-gcc"
> > > > and the built GCC was finally able to compile my
> > > > GIMPLE code and emit the arm assembly code
> > > > show on the bugzilla page. I can get to adding the
> > > > RTL optimization now.
> > >
> > > Ah fab!
> > >
> > > >
> > > > For a full aarch64 bootstrap setup when I get to
> > > > the stage of running the testsuite, I'll still have to
> > > > get on a cfarm machine and test my patch on it?
> > >
> > > Yes (mostly). It's a lot easier for setting up a bootstrap build, but
> > > also parts of the testsuite require the ability to compile then run
> > > code. You can setup emulators for that, but all together its normally
> > > significantly easier to use a native environment if you can get one.
> > >
> > > You can use the cfarm (https://portal.cfarm.net/users/new/)
> > >
> > > Or you can use software like QEMU to emulate an entire aarch64 linux VM
> > > on your x68_64 machine which is normally surprisingly performant (in my
> > > opinion).
> > >
> > > Kind regards,
> > > Alfie
> > >
> > > >
> > > > On Tue, Sep 22, 2026 at 2:27 PM Alfie Richards <[email protected]>
> > > > wrote:
> > > >>
> > > >> On 22/09/2026 11:20, Kevin Stefanov wrote:
> > > >>> 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.
> > > >>
> > > >> Ah yes, would definitely be helpful to find, from my experience there
> > > >> will be one somewhere, but often not trivial to find.
> > > >> If you try running the command again (without changing anything) it is
> > > >> often easier, as all the previous successful jobs will be skipped so
> > > >> the
> > > >> log will be shorter and often just contain the failure. Especially if
> > > >> you use -j 1.
> > > >>
> > > >> Regardless, for this situation, I would suggest using
> > > >> `make -j$(nproc) all-gcc`
> > > >>
> > > >> As this will avoid building runtime libraries and will likely be enough
> > > >> for what you need.
> > > >>
> > > >> It is likely you don't have a working aarch64 assembler, linker, and
> > > >> libc. To successfully compiler runtime libs (which is part of `make
> > > >> all`) you would need those. (But I think you likely don't need to do
> > > >> `make all`)
> > > >>
> > > >> Hope this helps,
> > > >> Alfie
> > > >>>
> > > >>> Yes, so far for my patches I've always done my testsuite results
> > > >>> comparison on a native x86_64 bootstrapped GCC build with:
> > > >>>
> > >
