On Sat, Sep 09, 2023 at 01:56:57PM +0800, Xi Ruoyao wrote:
> On Sat, 2023-09-09 at 10:46 +0800, Yang Yujie wrote:
> > The next option I can think of would be MULTILIB_EXTRA_OPTS, where
> > -fmultiflags
> > fit in nicely. However, these options won't reach the toplevel builds, and
> > tweaking config-ml.in for getting it there would be quite tedious and
> > perhaps
> > unreliable:
>
> I don't think the spec tweak should affect toplevel (or default, if you
> hate the concept of toplevel) library build.
>
> When I build GCC for a specific machine I usually use:
>
> OPT="-O3 -march=native -pipe ..."
> make {STAGE1,BOOT}_CFLAGS="$OPT" {C,CXX}FLAGS_FOR_TARGET="$OPT -g"
>
> If the spec tweak affects the toplevel library build it will eat -march=
> etc. in {C,CXX}FLAGS_FOR_TARGET silently, and I don't want this.
Sorry I didn't make this clear -- Yes, I am removing the spec tweak
*completely*, because I agree it should not affect bootstrapping /
toplevel builds / --disable-multilib builds.
This is achieved by defining MULTILIB_EXTRA_OPTS as -fmultiflags,
which triggers the multilib build options in driver spec rules
-- so nothing happens to the bootstrapping and --disable-multilib
builds.
What I'm explaining is, MULTILIB_EXTRA_OPTS won't be nicely received
by the toplevel (which is exactly the purpose), so in this solution,
multilib-enabled builds still have to exclude the toplevel. This means
I will have to bring back (at least part of) my v1 patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627275.html
I remember you were against it because you think non-multilib users
would be punished because the libdir layout changes (no toplevel).
However this directory should be (mostly) private to each gcc instance,
so I don't see real consequences to this unless you have a build script
that relieas on the path of libgcc.a / startfile, which can still (and
should) be revised using $(gcc --print-multi-dir).
> --disable-multilib *should just work*. Why should a non-multilib user
> be punished by the cost of supporting the complex multilib
> configuration, esp. today most LoongArch users don't need multilib at
> all?
It should *just work*. I am testing the new patch and will deliver it
as soon as all the test passes.
