RISC-V V C Intrinsic API v1.0 release meeting reminder (December 4th, 2023)

[Eop Chen via Gcc]

Hi all,

A reminder that the next open meeting to discuss on the RISC-V V C Intrinsic 
API v1.0 is going to
be held on 2023/12/04 7AM (GMT -7) / 11PM (GMT +8).

The agenda can be found in the second page of the meeting slides (link 
).
Please join the calendar to be constantly notified - Google calender link 
,
 ICal 

We also have a mailing list now hosted by RISC-V International (link 
).

Regards,

eop Chen

contributor guidelines

[Bruno Haible]

Hi,

I was asked to post a patch for a bugzilla PR to gcc-patches@. Two questions
regarding https://gcc.gnu.org/contribute.html#testing :

1) This web page says:
   "For a normal native configuration, running

  make bootstrap
  make -k check

from the top level of the GCC tree (not the gcc subdirectory) will
accomplish this."

But what I get, from a git checkout of the GCC tree:

  $ make bootstrap
  make: *** No rule to make target 'bootstrap'.  Stop.

I think the instructions should be amended to read:

  ./configure [options]
  make bootstrap
  make -k check

Right?

2) That's what I did:

$ ./configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu 
--target=x86_64-pc-linux-gnu 
--prefix=/arch/x86_64-linux-gnu/gnu-inst-gcc/testing --enable-shared 
--enable-nls --enable-threads=posix --enable-__cxa_atexit --disable-multilib 
--with-as=/arch/x86_64-linux-gnu/gnu-inst-binutils/2.38/bin/as 
--with-ld=/arch/x86_64-linux-gnu/gnu-inst-binutils/2.38/bin/ld 
--with-gmp=/arch/x86_64-linux-gnu/gnu-inst-gcc/testing 
--with-mpfr=/arch/x86_64-linux-gnu/gnu-inst-gcc/testing 
--with-mpc=/arch/x86_64-linux-gnu/gnu-inst-gcc/testing 
--with-isl=/arch/x86_64-linux-gnu/gnu-inst-gcc/testing 
--enable-languages=c,c++,objc,obj-c++,lto,jit,fortran,go,d,m2 
--enable-host-shared 2>&1 | tee log0
$ make bootstrap 2>&1 | tee log1

and it fails like this:

/GCC/gcc/host-x86_64-pc-linux-gnu/gcc/xgcc 
-B/GCC/gcc/host-x86_64-pc-linux-gnu/gcc/ 
-B/arch/x86_64-linux-gnu/gnu-inst-gcc/testing/x86_64-pc-linux-gnu/bin/ 
-B/arch/x86_64-linux-gnu/gnu-inst-gcc/testing/x86_64-pc-linux-gnu/lib/ -isystem 
/arch/x86_64-linux-gnu/gnu-inst-gcc/testing/x86_64-pc-linux-gnu/include 
-isystem 
/arch/x86_64-linux-gnu/gnu-inst-gcc/testing/x86_64-pc-linux-gnu/sys-include   
-fno-checking -g -O2 -O2  -g -O2 -DIN_GCC   -W -Wall -Wno-narrowing 
-Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes 
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fpic 
-mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2 
-fbuilding-libgcc -fno-stack-protector  -fpic -mlong-double-80 -DUSE_ELF_SYMVER 
-fcf-protection -mshstk -I. -I. -I../../host-x86_64-pc-linux-gnu/gcc 
-I../.././libgcc -I../.././libgcc/. -I../.././libgcc/../gcc 
-I../.././libgcc/../include -I../.././libgcc/config/libbid 
-DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS  -DUSE_TLS  -o bid128_add.o -MT 
bid128_add.o -MD -MP -MF bid128_add.dep -c 
../.././libgcc/config/libbid/bid128_add.c
during RTL pass: expand
../.././libgcc/config/libbid/bid128_add.c: In function ‘__bid128_add’:
../.././libgcc/config/libbid/bid128_add.c:637:42: internal compiler error: 
Aborted
  637 |   else if (rnd_mode == ROUNDING_DOWN && x_sign != y_sign)
0x178a410 crash_signal
../.././gcc/toplev.cc:316
0x7fd115f1c51f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x7fd115f709fc __pthread_kill_implementation
./nptl/pthread_kill.c:44
0x7fd115f709fc __pthread_kill_internal
./nptl/pthread_kill.c:78
0x7fd115f709fc __GI___pthread_kill
./nptl/pthread_kill.c:89
0x7fd115f1c475 __GI_raise
../sysdeps/posix/raise.c:26
0x7fd115f027f2 __GI_abort
./stdlib/abort.c:79
0x110f4ff choose_mult_variant(machine_mode, long, algorithm*, mult_variant*, 
int)
../.././gcc/expmed.cc:3282
0x1149c12 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, 
expand_modifier)
../.././gcc/expr.cc:10225
0x114e729 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, 
expand_modifier, rtx_def**, bool)
../.././gcc/expr.cc:11216
0x1145ae1 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier, 
rtx_def**, bool)
../.././gcc/expr.cc:9408
0xf2ed74 expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)
../.././gcc/expr.h:313
0x11441c7 expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**, 
rtx_def**, expand_modifier)
../.././gcc/expr.cc:8986
0x114d793 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, 
expand_modifier)
../.././gcc/expr.cc:10987
0xf69453 expand_gimple_stmt_1
../.././gcc/cfgexpand.cc:3984
0xf6971f expand_gimple_stmt
../.././gcc/cfgexpand.cc:4045
0xf72801 expand_gimple_basic_block
../.././gcc/cfgexpand.cc:6101
0xf752b2 execute
../.././gcc/cfgexpand.cc:6836
Please submit a full bug report, with preprocessed source (by using 
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
make[3]: *** [Makefile:650: bid128_add.o] Error 1
make[3]: Leaving directory '/GCC/gcc/x86_64-pc-linux-gnu/libgcc'
make[2]: *** [Makefile:20611: all-stage1-target-libgcc] Error 2
make[2]: Leaving directory '/GCC/gcc'
make[1]: *** [Makefile:30945: stage1-bubble] Error 2
make[1]: Leaving directory '/GCC/gcc'
make: *** [Makefile:31282: bootstrap] Error 2

I am surprised to see such a failure, since x86_64-linux-gnu is the most
common platform.

What am 

Re: contributor guidelines

[Jonathan Wakely via Gcc]

On Mon, 4 Dec 2023 at 12:19, Bruno Haible wrote:
>
> Hi,
>
> I was asked to post a patch for a bugzilla PR to gcc-patches@. Two questions
> regarding https://gcc.gnu.org/contribute.html#testing :
>
> 1) This web page says:
>"For a normal native configuration, running
>
>   make bootstrap
>   make -k check
>
> from the top level of the GCC tree (not the gcc subdirectory) will
> accomplish this."
>
> But what I get, from a git checkout of the GCC tree:
>
>   $ make bootstrap
>   make: *** No rule to make target 'bootstrap'.  Stop.
>
> I think the instructions should be amended to read:
>
>   ./configure [options]
>   make bootstrap
>   make -k check
>
> Right?

No, don't configure in the source directory:
https://gcc.gnu.org/wiki/FAQ#configure

But otherwise yes, the fact you need to configure before running make
is so obvious that apparently we took it for granted :-)

And it hasn't been necessary to run 'make bootstrap' for years, just
running 'make' does exactly the same thing now.

>
> 2) That's what I did:
>
> $ ./configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu 
> --target=x86_64-pc-linux-gnu 
> --prefix=/arch/x86_64-linux-gnu/gnu-inst-gcc/testing --enable-shared 
> --enable-nls --enable-threads=posix --enable-__cxa_atexit --disable-multilib 
> --with-as=/arch/x86_64-linux-gnu/gnu-inst-binutils/2.38/bin/as 
> --with-ld=/arch/x86_64-linux-gnu/gnu-inst-binutils/2.38/bin/ld 
> --with-gmp=/arch/x86_64-linux-gnu/gnu-inst-gcc/testing 
> --with-mpfr=/arch/x86_64-linux-gnu/gnu-inst-gcc/testing 
> --with-mpc=/arch/x86_64-linux-gnu/gnu-inst-gcc/testing 
> --with-isl=/arch/x86_64-linux-gnu/gnu-inst-gcc/testing 
> --enable-languages=c,c++,objc,obj-c++,lto,jit,fortran,go,d,m2 
> --enable-host-shared 2>&1 | tee log0

This seems unnecessarily overcomplicated. Most of those options are
just restating the defaults.


> $ make bootstrap 2>&1 | tee log1
>
> and it fails like this:
>
> /GCC/gcc/host-x86_64-pc-linux-gnu/gcc/xgcc 
> -B/GCC/gcc/host-x86_64-pc-linux-gnu/gcc/ 
> -B/arch/x86_64-linux-gnu/gnu-inst-gcc/testing/x86_64-pc-linux-gnu/bin/ 
> -B/arch/x86_64-linux-gnu/gnu-inst-gcc/testing/x86_64-pc-linux-gnu/lib/ 
> -isystem 
> /arch/x86_64-linux-gnu/gnu-inst-gcc/testing/x86_64-pc-linux-gnu/include 
> -isystem 
> /arch/x86_64-linux-gnu/gnu-inst-gcc/testing/x86_64-pc-linux-gnu/sys-include   
> -fno-checking -g -O2 -O2  -g -O2 -DIN_GCC   -W -Wall -Wno-narrowing 
> -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes 
> -Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fpic 
> -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2 
> -fbuilding-libgcc -fno-stack-protector  -fpic -mlong-double-80 
> -DUSE_ELF_SYMVER -fcf-protection -mshstk -I. -I. 
> -I../../host-x86_64-pc-linux-gnu/gcc -I../.././libgcc -I../.././libgcc/. 
> -I../.././libgcc/../gcc -I../.././libgcc/../include 
> -I../.././libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS  
> -DUSE_TLS  -o bid128_add.o -MT bid128_add.o -MD -MP -MF bid128_add.dep -c 
> ../.././libgcc/config/libbid/bid128_add.c
> during RTL pass: expand
> ../.././libgcc/config/libbid/bid128_add.c: In function ‘__bid128_add’:
> ../.././libgcc/config/libbid/bid128_add.c:637:42: internal compiler error: 
> Aborted
>   637 |   else if (rnd_mode == ROUNDING_DOWN && x_sign != y_sign)
> 0x178a410 crash_signal
> ../.././gcc/toplev.cc:316

I don't see this error when building master on x86_64-pc-linux-gnu.
This might be a local problem, caused by your host compiler, or the
versions of GMP, MPFR, or MPC, or something else.


> I am surprised to see such a failure, since x86_64-linux-gnu is the most
> common platform.
>
> What am I supposed to do?
>   - Use the latest release tag (13.2.0) instead of the tip of 'master',
> and test my contribution there?
>   - Wait a few days, do a 'git pull', and retry?
>   - Something else?

Re: Debugging the tree object constructed by cp_parser

[Stan Srednyak via Gcc]

Hi David, thanks for your email. I really appreciate it.

Your notes are certainly of help, but I also had a specific question: how
to access the trees as they are being constructed by the front end. Do you
have an answer to this?

I looked into GCC internals docs. The section on the front  end (sec 5) is
wonderfully concise, of course, but it does not answer this question. Do
you know any sources where this is documented?

best regards,
Stan

On Sun, Dec 3, 2023 at 1:00 PM David Malcolm  wrote:

> On Sat, 2023-12-02 at 17:41 -0500, Stan Srednyak via Gcc wrote:
> > Dear GCC community,
> >
> > I am assigned the task to debug the trees as being produced by the
> > cp_parser. I was able to print some of the trees using the
> > debug_tree()
> > function. But I am still confused as to where is the tree object that
> > corresponds to the translation unit being parsed. There is no such
> > field in
> > cp_parser, and in the few tiers of functions calls starting from
> > parse_file() function that I followed so far, I was not able to find
> > any
> > variable remotely similar to the AST of functions/structs etc. that
> > must be
> > constructed by this great piece of software. I would very much
> > appreciate
> > any explanation from the great experts in gcc on this mailing list. I
> > posted a thread at gcc-help, but apparently it is too obvious of a
> > question
> > to be addressed there.
>
> Hi Stan
>
> FWIW I've written some notes on debugging GCC:
> https://gcc-newbies-guide.readthedocs.io/en/latest/debugging.html
>
> and in particular you might find the following useful:
>
> https://gcc-newbies-guide.readthedocs.io/en/latest/debugging.html#how-do-i-find-where-a-particular-tree-was-created
>
> Hope this is helpful
> Dave
>
>

Re: Debugging the tree object constructed by cp_parser

[David Malcolm via Gcc]

On Mon, 2023-12-04 at 10:09 -0500, Stan Srednyak wrote:
> Hi David, thanks for your email. I really appreciate it.
> 
> Your notes are certainly of help, but I also had a specific question:
> how
> to access the trees as they are being constructed by the front end.
> Do you
> have an answer to this?

You could try putting a breakpoint on "make_node", and then
conditionalizing it so it only fires when code ==
TRANSLATION_UNIT_DECL:

(gdb) break make_node
Breakpoint 5 at 0x1675250: file ../../src/gcc/tree.cc, line 1188.

(gdb) cond 5 code==TRANSLATION_UNIT_DECL

(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y

[...snip...]

Breakpoint 5, make_node (code=TRANSLATION_UNIT_DECL) at
../../src/gcc/tree.cc:1188
1188{

(gdb) bt
#0  make_node (code=TRANSLATION_UNIT_DECL) at
../../src/gcc/tree.cc:1188
#1  0x01675aae in build_decl (loc=0,
code=TRANSLATION_UNIT_DECL, name=, type=)
at ../../src/gcc/tree.cc:5379
#2  0x0169644c in build_translation_unit_decl (name=) at ../../src/gcc/tree.cc:5432
#3  0x00b1e181 in cxx_init_decl_processing () at
../../src/gcc/tree.h:3749
#4  0x00b6b904 in cxx_init () at ../../src/gcc/cp/lex.cc:336
#5  0x00a4e23a in lang_dependent_init (name=0x34bd820
"/tmp/t.c") at ../../src/gcc/toplev.cc:1838
#6  do_compile () at ../../src/gcc/toplev.cc:2136
#7  toplev::main (this=this@entry=0x7fffdd6e, argc=,
argc@entry=22, argv=, argv@entry=0x7fffde78)
at ../../src/gcc/toplev.cc:2307
#8  0x00a502f5 in main (argc=22, argv=0x7fffde78) at
../../src/gcc/main.cc:39


Dave

> 
> I looked into GCC internals docs. The section on the front  end (sec
> 5) is
> wonderfully concise, of course, but it does not answer this question.
> Do
> you know any sources where this is documented?
> 
> best regards,
> Stan
> 
> On Sun, Dec 3, 2023 at 1:00 PM David Malcolm 
> wrote:
> 
> > On Sat, 2023-12-02 at 17:41 -0500, Stan Srednyak via Gcc wrote:
> > > Dear GCC community,
> > > 
> > > I am assigned the task to debug the trees as being produced by
> > > the
> > > cp_parser. I was able to print some of the trees using the
> > > debug_tree()
> > > function. But I am still confused as to where is the tree object
> > > that
> > > corresponds to the translation unit being parsed. There is no
> > > such
> > > field in
> > > cp_parser, and in the few tiers of functions calls starting from
> > > parse_file() function that I followed so far, I was not able to
> > > find
> > > any
> > > variable remotely similar to the AST of functions/structs etc.
> > > that
> > > must be
> > > constructed by this great piece of software. I would very much
> > > appreciate
> > > any explanation from the great experts in gcc on this mailing
> > > list. I
> > > posted a thread at gcc-help, but apparently it is too obvious of
> > > a
> > > question
> > > to be addressed there.
> > 
> > Hi Stan
> > 
> > FWIW I've written some notes on debugging GCC:
> > https://gcc-newbies-guide.readthedocs.io/en/latest/debugging.html
> > 
> > and in particular you might find the following useful:
> > 
> > https://gcc-newbies-guide.readthedocs.io/en/latest/debugging.html#how-do-i-find-where-a-particular-tree-was-created
> > 
> > Hope this is helpful
> > Dave
> > 
> > 

RE: [RISC-V][tech-rvv-intrinsics] RISC-V V C Intrinsic API v1.0 release meeting reminder (December 4th, 2023)

[Rich Fuhler via Gcc]

Hi eop,

When I checked the calendar, https://tech.riscv.org/calendar/, last night, the 
meeting was scheduled for 6am PT, which was a conflict in my schedule. Could 
any meeting times or cancelation notifications go out at least a day ahead of 
time?



-rich



 Original message 
From: "eop Chen via lists.riscv.org" 
Date: 12/4/23 1:29 AM (GMT-08:00)
To: tech-rvv-intrins...@lists.riscv.org, tech-vector-...@lists.riscv.org, 
gcc@gcc.gnu.org, sig-toolcha...@lists.riscv.org
Subject: [RISC-V][tech-rvv-intrinsics] RISC-V V C Intrinsic API v1.0 release 
meeting reminder (December 4th, 2023)

Hi all,

A reminder that the next open meeting to discuss on the RISC-V V C Intrinsic 
API v1.0 is going to
be held on 2023/12/04 7AM (GMT -7) / 11PM (GMT +8).

The agenda can be found in the second page of the meeting slides 
(link).
Please join the calendar to be constantly notified - Google calender 
link,
 
ICal
We also have a mailing list now hosted by RISC-V International 
(link).

Regards,

eop Chen
_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online 
(#100) | Reply To 
Group
 | Reply To 
Sender
 | Mute This Topic | New 
Topic
Your 
Subscription | 
Contact Group Owner | 
Unsubscribe
 [rfuh...@andestech.com]

_._,_._,_

RE: [RISC-V][tech-rvv-intrinsics] RISC-V V C Intrinsic API v1.0 release meeting reminder (December 4th, 2023)

[Rich Fuhler via Gcc]

Apologies to the other groups. I missed that this went to multiple other groups.



-rich



 Original message 
From: Rich Fuhler 
Date: 12/4/23 11:42 AM (GMT-08:00)
To: tech-rvv-intrins...@lists.riscv.org, tech-vector-...@lists.riscv.org, 
gcc@gcc.gnu.org, sig-toolcha...@lists.riscv.org
Subject: RE: [RISC-V][tech-rvv-intrinsics] RISC-V V C Intrinsic API v1.0 
release meeting reminder (December 4th, 2023)

Hi eop,

When I checked the calendar, https://tech.riscv.org/calendar/, last night, the 
meeting was scheduled for 6am PT, which was a conflict in my schedule. Could 
any meeting times or cancelation notifications go out at least a day ahead of 
time?



-rich



 Original message 
From: "eop Chen via lists.riscv.org" 
Date: 12/4/23 1:29 AM (GMT-08:00)
To: tech-rvv-intrins...@lists.riscv.org, tech-vector-...@lists.riscv.org, 
gcc@gcc.gnu.org, sig-toolcha...@lists.riscv.org
Subject: [RISC-V][tech-rvv-intrinsics] RISC-V V C Intrinsic API v1.0 release 
meeting reminder (December 4th, 2023)

Hi all,

A reminder that the next open meeting to discuss on the RISC-V V C Intrinsic 
API v1.0 is going to
be held on 2023/12/04 7AM (GMT -7) / 11PM (GMT +8).

The agenda can be found in the second page of the meeting slides 
(link).
Please join the calendar to be constantly notified - Google calender 
link,
 
ICal
We also have a mailing list now hosted by RISC-V International 
(link).

Regards,

eop Chen
_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online 
(#100) | Reply To 
Group
 | Reply To 
Sender
 | Mute This Topic | New 
Topic
Your 
Subscription | 
Contact Group Owner | 
Unsubscribe
 [rfuh...@andestech.com]

_._,_._,_

Re: contributor guidelines

[waffl3x via Gcc]

On Monday, December 4th, 2023 at 5:37 AM, Jonathan Wakely via Gcc 
 wrote:


> 
> 
> On Mon, 4 Dec 2023 at 12:19, Bruno Haible wrote:
> 
> > Hi,
> > 
> > I was asked to post a patch for a bugzilla PR to gcc-patches@. Two questions
> > regarding https://gcc.gnu.org/contribute.html#testing :
> > 
> > 1) This web page says:
> > "For a normal native configuration, running
> > 
> > make bootstrap
> > make -k check
> > 
> > from the top level of the GCC tree (not the gcc subdirectory) will
> > accomplish this."
> > 
> > But what I get, from a git checkout of the GCC tree:
> > 
> > $ make bootstrap
> > make: *** No rule to make target 'bootstrap'. Stop.
> > 
> > I think the instructions should be amended to read:
> > 
> > ./configure [options]
> > make bootstrap
> > make -k check
> > 
> > Right?
> 
> 
> No, don't configure in the source directory:
> https://gcc.gnu.org/wiki/FAQ#configure
> 
> But otherwise yes, the fact you need to configure before running make
> is so obvious that apparently we took it for granted :-)
> 
> And it hasn't been necessary to run 'make bootstrap' for years, just
> running 'make' does exactly the same thing now.

It falls under the weird paradox region imo, the one where it's such
common knowledge that it doesn't get written down anywhere, so it makes
it really hard for a newbie to figure out. As long as you have a mentor
or are brave enough to ask questions it's rarely an issue but I love
this little paradox. So easy that it's arcane to the uninitiated.

I've been writing `make bootstrap` myself, I'm surprised to hear it's
unnecessary. Perhaps we should update some of these documents a bit? 

> > 2) That's what I did:
> > 
> > $ ./configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu 
> > --target=x86_64-pc-linux-gnu 
> > --prefix=/arch/x86_64-linux-gnu/gnu-inst-gcc/testing --enable-shared 
> > --enable-nls --enable-threads=posix --enable-__cxa_atexit 
> > --disable-multilib 
> > --with-as=/arch/x86_64-linux-gnu/gnu-inst-binutils/2.38/bin/as 
> > --with-ld=/arch/x86_64-linux-gnu/gnu-inst-binutils/2.38/bin/ld 
> > --with-gmp=/arch/x86_64-linux-gnu/gnu-inst-gcc/testing 
> > --with-mpfr=/arch/x86_64-linux-gnu/gnu-inst-gcc/testing 
> > --with-mpc=/arch/x86_64-linux-gnu/gnu-inst-gcc/testing 
> > --with-isl=/arch/x86_64-linux-gnu/gnu-inst-gcc/testing 
> > --enable-languages=c,c++,objc,obj-c++,lto,jit,fortran,go,d,m2 
> > --enable-host-shared 2>&1 | tee log0
> 
> 
> This seems unnecessarily overcomplicated. Most of those options are
> just restating the defaults.
> 
> > $ make bootstrap 2>&1 | tee log1
> > 
> > and it fails like this:
> > 
> > *snip*
> 
> 
> I don't see this error when building master on x86_64-pc-linux-gnu.
> This might be a local problem, caused by your host compiler, or the
> versions of GMP, MPFR, or MPC, or something else.
> 

I would suggest just trying again with a out of tree build, in tree
builds are not supported. I can definitely imagine an in tree build
causing some wild errors like you described.

So for example, if you had your git repo in a folder named workspace,
like so.

workspace/gcc

You want another folder where you build in, this is frequently referred
to as the object directory.

workspace/obj

When in the object directory, workspace/obj you configure in there.

[obj]$ ../gcc/configure
THEN you do the rest.
(NOTE: -j16 sets the amount of threads to use in case you don't know)
[obj]$ make -j16 bootstrap

As jwakely said, bootstrap isn't required anymore, but this is how I've
done it and I don't wanna change it for my example, just in case.

After it's done, while still in the obj directory you do

[obj]$ make -j16 -k check

You'll notice that there's a surprising amount of test failures, the
only real way I know of to check for regressions is to have a pristine
version without your patch applied that you compare against.

My layout looks something like this right now.
workspace/bootstrap/obj/pristine-gcc14
workspace/bootstrap/obj/my-patch-gcc14
workspace/bootstrap/src/pristine-gcc14
workspace/bootstrap/src/my-patch-gcc14

Once you've ran the testsuite on both your pristine bootstrapped build
and your patched bootstrapped build, you can compare them like so.

[workspace]$ gcc/contrib/compare_tests /bootstrap/obj/pristine-gcc14/
 /bootstrap/obj/my-patch-gcc14/ > results

This is just how I do it, there might be a better way, I'm still pretty
green so don't take it as gospel, but on the off chance it's helpful I
wanted to share my process that has worked for me. Besides, this is a
great excuse for me to get criticism of my workflow. :^)

Oh and one other thing to note, when using this workflow, you'll get
some bizarre results where some tests will be listed as both new and
having disappeared. This is because some of the tests either
incorrectly include the full patch, or include the line number. Here's
examples of each of these from my latest comparison.
```
New tests that FAIL (4 tests):

g++.dg/modules/xtreme-header-4_b.C -std=c++2b (internal