On Sun, 20 Mar 2016, Bernd Edlinger wrote:

So I looked for a way to disable the asm code, and found it can be
done, but differently than for in-tree gmp. See the attached patch.

As noted in PR 67728, it seems that gcc's intrusive way of overriding
CFLAGS also breaks GMP itself, not just MPFR, by hiding the macro NO_ASM
that GMP tries to define through its own CFLAGS. So maybe Bernd's patch
should be duplicated to also apply to GMP?

I agree, the question is only when.  Passing -DNO_ASM in AM_CFLAGS would
just define NO_ASM twice for GMP-4.3.2 which would not make any problems
and fix the mis-compilation of GMP-6.1.0.  That might be possible in
stage4 if you like.

It is confusing that we are using the same names for stages in the release cycle and stages in bootstrap, for a bit I couldn't understand why this would only apply to that extra bootstrap stage :-(

I don't know if I *want* us to go there and pass -DNO_ASM, I think I'd rather have gcc call plain "make" without a gazillion variables appended, but if people care about those PRs, I am guessing that this would be less intrusive.

(I use linux where the system provides GMP so I never do in-tree builds and don't really care)

OTOH there are more things that indicate problems with gmp-4.3.2 and
should be changed, maybe in gcc-7.

I think that's rather independent.

See PR 69881 where gmp header files define __need_size_t and include
<cstddef> which caused undefined behavior with c++14.

So I think we should update gmp, mpfr and mpc in gcc-7.

Once we do that we can of course also replace the host=none
with --disable-assembly flag, which would of course break
the gmp-4.3.2 in-tree configuration because that was not yet
invented.

My point is that even if you use the latest GMP with --disable-assembly, gcc will still manage to break things because it calls make CFLAGS=-g, which bypasses the GMP mechanism for defining NO_ASM. We might change that mechanism at some point in the future in GMP:
https://gmplib.org/list-archives/gmp-devel/2016-March/004257.html
but that's not for right now.

--
Marc Glisse

Reply via email to