Hi Alfie, Yes, that's what I've been doing to test my previous patches, I just don't remember "make -k check" ever ending with an error message, and wasn't sure whether correct usable testsuite results even get produced when that happens. Should I proceed with compare_tests even though the testsuite make command ended with an error?
On Mon, Sep 28, 2026 at 10:48 AM Alfie Richards <[email protected]> wrote: > > Hi Kevin, > > Yes, there are frequently breakages in the test suite while in stage 1, for a > variety of reasons. > > For that reason, we normally use the `contrib/compare_tests` script to > compare test result runs from before and after your patch, check if any > regressions have been introduced. > > Thanks, > Alfie > > ________________________________ > From: Kevin Stefanov <[email protected]> > Sent: Sunday, 27 September 2026 17:52:25 > To: Andrea Pinski <[email protected]> > Cc: Alfie Richards <[email protected]>; [email protected] > <[email protected]> > Subject: Re: Mentoring for easy issue of week 52 > > 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: > > > > > > >>> > > > > > >
