>  With his change the tests pass so I think the change is reasonable.

>I disagree.  If I am right that the inline asm is correct, changing it
>to avoid triggering a compiler bug is not a reasonable change.  But
>perhaps I am wrong and the inline asm is buggy, but then somebody needs
>to explain in what way it is buggy.
 
>Torbjörn


Of course I do not want to hide a compiler error here and disturb other 
platforms. If this turns out to be a compiler error that would be a nice 
finding as well!


I looked in https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html

>6.47.2.6 Clobbers and Scratch Registers
>....
>Rather than allocating fixed registers via clobbers to provide scratch 
>registers for an asm statement, an alternative is to define a variable and 
>make it an early-clobber output.

I think that is done in the inline assembler code with the variables 
USItype __umul_tmp1, __umul_tmp2;

To make them an "early clobber output" the & sign has to be written before the 
d as it has been done for __umul_tmp2.

>6.47.2.3 Output Operands
>Use the ‘&’ constraint modifier (see Modifiers) on all output operands that 
>must not overlap an input. Otherwise, GCC may allocate the output operand in 
>the same register as an unrelated >input operand, on the assumption that the 
>assembler code consumes its inputs before producing outputs. This assumption 
>may be false if the assembler code actually consists of more than one 
>instruction.

If you look at the nice compiler explorer at 
https://franke.ms/cex/z/oG53bK
you see the code generated for -O1 and -O0. If you add the % sign in the left 
window you will imediatelly see the changed code in the middle window.

Can you explain why __umul_tmp1 should not be an "early-clobber output"?

Btw,
Could you tell me what the "%2" at the input parameters line means? I did not 
find that in the Extended-Asm.html document.

: "%2" ((USItype)(a)), "d" ((USItype)(b)));

Kind regards Alexander
_______________________________________________
gmp-bugs mailing list
[email protected]
https://gmplib.org/mailman/listinfo/gmp-bugs

Reply via email to