Thank you, that fixed my build, it passes now. For some reason, "make -k check" is giving me issues now, even without my changes, on pristine sources, the testsuite run keeps running for a few hours, then ending with:
make: *** [Makefile:2720: do-check] Error 2 make: Target 'check' not remade because of errors Both on my x86_64 Fedora laptop and on cfarm185. Is there a known temporary unavailability or breakage of the testsuite? Or is this nothing to be worried about? On Sat, Sep 26, 2026 at 2:24 AM Andrea Pinski <[email protected]> wrote: > > On Fri, Sep 25, 2026 at 12:38 AM Kevin Stefanov > <[email protected]> wrote: > > > > 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 > > I normally use --enable-languages=c,c++,fortran . Especially on > cfarm185 which has an older distro on it. > > > > > 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: > > > > > >>> > > > > >
