[Cryptography] GCC bug 30475

[Tom Mitchell]

On Fri, May 2, 2014 at 3:02 PM, Nemo <nemo at self-evident.org> wrote:
> Jerry Leichter <leichter at lrw.com> writes:
>
>> "Some" implementations?  This is the original x86 FPU semantics, the
>> ones present on every 32-bit x86 CPU ever built.  I haven't had any
>> reason to keep up, and I don't know if the most recent FP instruction
>> sets still do the same thing; I suspect they might very well.
>
> Only if your compiler actually emits x87 instructions, which it probably
> will not unless you ask for a "long double" and/or target very old CPUs.
>
> Modern x86/x86_64 processors have SSE (or AVX) instructions, which
> operate on 2 (or 4) 64-bit doubles at a time with very low latency and
> proper IEEE-754 behavior. Modern compilers tend to emit such
> instructions, which are both faster and avoid the "extra precision".
>
> Still, C and C++ are arguably too under-specified for serious numerical
> work.
>
>> Initially both x and y are 0
>> Thread 1      Thread 2
>> x = 1;          print x;
>> y = 1;          print y;
>>
>> What can thread 2 print?  There are three obvious possibilities:
>>
>> 0 0     - Thread 2 completes before thread 1
>> 1 1     - Thread 1 completes before thread 2
>> 1 0     - Thread 1 executes its first statement, then thread 2 completes
>>
>> But 0 1 is impossible.

Lacking real code and input data there is a 4th possibility (or more).

Iff all the operations on the variables being printed are constant
in the code it might be legal for the compiler to evaluate x and y,
eliminate the
assignments and emit print code that contains the result of constant expression
evaluation.

This is kin to compilers tossing computations that are discarded
and never used.  Silly timing loops can vanish....

Threaded code has many potential races.  Shared variables need
protection.  Some variables (symbols) also need to be forced out
of registers to memory where the sharing can take place.  Registers
are not shared and not in a cache domain.

Prediction is not possible for some thread races because the
conflicts are in the system and not in the code and visible to
the author.  i.e. Some system libraries have locks to minimize I/O
confusion (especially where dusty deck code needs them).






-- 
  T o m    M i t c h e l l