On 28/09/2026 09:12, Kevin Stefanov wrote:
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?
Hmm to be honest it has been a while since I ran tests manually rather
than with a script. In this case it's hard to know what's going on
without seeing the error message or log.
You should still be able to compare, if some of the tests didn't end up
running you'll notice many "missing test" reports.
You may also get away with just doing `make check-gcc` for this patch as
its a back-end only patch (though you should disclose that in the email
and it's up to the maintainers/reviewers).
Thanks,
Alfie
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:
