On Monday, December 4th, 2023 at 5:37 AM, Jonathan Wakely via Gcc <gcc@gcc.gnu.org> 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 compiler error: tree check: expected class 'type', have 'declaration' (template_decl) in get_originating_module_decl, at cp/module.cc:18661) libitm.c++/dropref.C -B /home/waffl3x/projects/gcc-dev/bootstrap/obj/xobj-next-2/ x86_64-pc-linux-gnu/./libitm/../libstdc++-v3/src/.libs execution test Old tests that failed, that have disappeared (4 tests): (Eeek!) g++.dg/modules/xtreme-header-4_b.C -std=c++2b (internal compiler error: tree check: expected class 'type', have 'declaration' (template_decl) in get_originating_module_decl, at cp/module.cc:18659) libitm.c++/dropref.C -B /home/waffl3x/projects/gcc-dev/bootstrap/obj/pristine-gcc14-2/ x86_64-pc-linux-gnu/./libitm/../libstdc++-v3/src/.libs execution test ``` Note the line number in the xtreme-header-4_b.C test, this is due to me adding 2 whole lines in modules.cc. In the libitm test you'll notice it includes the full path in the test log, that's what causes that one. ``` New tests that PASS (18 tests): libitm.c++/dropref.C -B /home/waffl3x/projects/gcc-dev/bootstrap/obj/ xobj-next-2/x86_64-pc-linux-gnu/./libitm/../libstdc++-v3/src/.libs (test for excess errors) Old tests that passed, that have disappeared (18 tests): (Eeek!) libitm.c++/dropref.C -B /home/waffl3x/projects/gcc-dev/bootstrap/obj/ pristine-gcc14-2/x86_64-pc-linux-gnu/./libitm/../libstdc++-v3/src/.libs (test for excess errors) ``` As you can see, this also happens for tests that pass too. So if you encounter something like this, it's nothing to be concerned about. This cost me some time when I encountered it so hopefully you can avoid it with this warning. Additionally, here is a list of options to reduce build times for when you need to build frequently. It was passed down to me and now I'll pass it down to you. However, do take note that you STILL NEED TO DO A FULL BOOTSTRAP before submitting your patch, this is just to expedite the initial "make change, test, repeat" phase. --disable-analyzer --disable-bootstrap --disable-cet --disable-default-pie --disable-default-ssp --disable-fixincludes --disable-gcov --disable-libada --disable-libatomic --disable-libgomp --disable-libitm --disable-libquadmath --disable-libsanitizer --disable-libssp --disable-libstdcxx-pch --disable-libvtv --disable-lto --disable-multilib --disable-nls --disable-objc-gc --disable-systemtap --disable-werror --enable-languages=c,c++ --prefix= *REPLACE WITH YOUR INSTALL DIRECTORY* --with-checking=yes,extra,rtl --without-isl --without-zstd --with-system-zlib In case it wasn't obvious, these are the settings I use for development of the C++ front end. If you're doing work on a different part of GCC you'll need different flags, I can't tell you exactly which ones you need unfortunately but hopefully this is useful information for you. I'm sorry if any of this came off as condescending, you seem like you're more proficient with a terminal than I but I didn't want to make any assumptions on what could be left out and what couldn't be. Hopefully this answers all your questions! If it doesn't I doubt I'll be able to answer them as this is about the limit of my experience so far, but I'll be happy to try if you do have more. Alex
