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.
Or at least it should not affect --disable-multilib (IMO with --disable-
multilib the spec hack should be disabled completely). Note that for --
enable-multilib we may use --with-default-multilib=lp64d/march=native,
but (1) this is hard to remember (2) this is not usable with --disable-
multilib.
--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?
--
Xi Ruoyao <xry...@xry111.site>
School of Aerospace Science and Technology, Xidian University
