On January 5, 2016 2:20:42 PM GMT+01:00, Bernd Edlinger 
<bernd.edlin...@hotmail.de> wrote:
>Hi,
>
>On 05.01.2016 13:58, Bernd Schmidt wrote:
>> On 01/05/2016 09:44 AM, Bernd Edlinger wrote:
>>> an in-tree mpfr build enables inline asm code, which makes the 
>>> mips-bootstrap fail,
>>> because at least mpfr 2.4.2 uses the "=h" constraint but in 
>>> config/mips/constraints.md
>>> we find: "Formerly the @code{hi} register.  This constraint is no 
>>> longer supported.".
>>>
>>> Using asm code is generally not desirable for in-tree mpfr builds.
>>
>> Why not?
>
>for the same reason why we disable the asm code for in-tree gmp.
>
>If we think mpfr is fine to use assembler, why don't we let gmp use the
>
>assember code too?

IIRC the logic at some point at least used host CPU detection to select asm.  
That's undesirable if you want to run binaries on different hosts.  Not sure if 
this is still the case with newer gmp/mpfr, but as long as we allow the ancient 
ones we should continue w/o asm.

Richard.

>When we boot-strap to a different architecture we certainly do not want
>
>to fiddle with inline-assember bugs, unless absolutely necessary.
>
>
>>
>>> 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.
>>
>> Fix mpfr instead not to use that constraint?
>>
>
>I don't think we should start to patch mpfr release-tarballs.
>
>The only alternative I see, how a mips-compiler could be boot-strapped 
>today would be to set CFLAGS="-g -O2 -DNO_ASM" on the gcc configure 
>line, but this will then be used everywhere, and I have no idea if that
>
>define has some side effects on libgcc for instance (my boot-strap did 
>not reach that point).
>
>
>Bernd.


Reply via email to