[Vm-dev] Removing UB to make SmallFloat handling gcc 4.9.2 -O2
compatible [WAS: first 64 bits windows VM Running]
nicolas.cellier.aka.nice at gmail.com
Thu Jul 21 17:58:29 UTC 2016
2016-07-21 2:41 GMT+02:00 Andres Valloud <avalloud at smalltalk.comcastbiz.net>
> Or better: eliminate Undefined Behavior which is most probably the
>> cause of problems
> This is a good start for a default debugging procedure.
> Note: i've successfully compiled Squeak stack spur 64 bits with gcc
>> 4.9.2 -02 and restored the correct behavior for SmallFloat:
>> 2.0*3.0 correctly answer 6.0 instead of 4.0...
>> Why is memcpy less evil than pointer aliasing?
>> With pointer aliasing any other write into a long integer could modify
>> This completely defeat optimization - the holy grail of C people, they
>> can't bother that FORTRAN compilers are faster than theirs ;). With
>> great wisdom they declared this construct as undefined behavior, giving
>> priority to optimization rather than backward compatibility or
>> programmers' intentions...
>> memcpy is less evil because it's localized (one shot).
> The GCC manual warns of potential issues with memcpy(), and recommends
> using unions instead. The union method worked on every HPS compilation
> environment, across multiple optimization levels. Whenever I checked, the
> resulting assembly code was optimal.
The problem you cite about memcpy is because it might be defined as a
macro, and this restrict the possible constructs indeed
(No #if directive into macros in some old versions of compilers).
For VMMaker this is not a problem yet.
If it would be, we would see a compiler error, and would then workaround by
rephrasing the slang and avoiding such construct...
A compiler error is a lot easier to fix than an invisibly stricking UB
answering the unexpected result.
The usage of union for type-punning is indeed authorized and well defined -
at least in C99.
But it has been controversial.
especially the arcane comments about interpretation of the standard !
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev