mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Vincent Lefevre]

On 2018-03-13 15:34:26 +0100, Torbjorn Granlund wrote:
> nisse at lysator.liu.se (Niels Möller) writes:
>   If we can make this thread safe with C11, I think it's fine to document
>   that mini-gmp requires C11 for thread safety. (I'd still prefer the
>   simpler way of reying on float.h constants, though).
> 
> Let's remind ourselves that we are not executing GMP on a standards
> document, but on actual computer systems.  :-)
> 
> Store reordering is an actual problem which we should keep in mind (but
> note that x86 implements total store ordering).  Non-atomic loads/stores
> is not as long as we keep to short types.

As I've said, I think that too short types can be a problem if,
in order to modify a variable v, the generated code must do:

1. Load data containing v (and other things).
2. Modify a part of the data (only the variable v).
3. Store the data back to memory.

For instance:

* A 32-bit variable on a CPU that has 64-bit stores but not 32-bit
  stores. (FYI, in the past, something like that had to be done on
  ARM with 16-bit "short int". I don't know about the other CPU's.
  Perhaps DEC Alpha, now obsolete.)

* Loading a variable v may also load a cache line. For CPU's where
  cache consistency is not enforced, this may also be an issue if
  this must be handled with specific instructions and the compiler
  optimizes based on undefined behavior (i.e. assuming that data
  race is not possible).

What you need in such a case is probably a short type inside a large
enough structure, where the other data are not used.

Alternatively, if C11 and the use of _Atomic can optionally be
supported (e.g. via the __STDC_VERSION__ and __STDC_NO_ATOMICS__
macros), this would ensure correctness on such platforms. On the
other platforms, it would be up to the user to check...

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)