<div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Nicolas,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 11, 2019 at 11:58 AM Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div>Hi all, Eliot, Pablo,</div><div>we should review all the pointer aliasing that we are still depending upon, because it can strike anytime soon...</div><div>The recommended way is memcpy, so let's use that.</div><div>The alternative is type puning via union, but it's not legal on C++. If wanting to support exotic compiler (MSVC) which is mainly focused on C++, not modern C, it's safer to use memcpy.<br></div></div></blockquote><div><br></div><div>Agreed.  I just went through all the uses of casts to int * and verified that all the other uses are legitimate (they're typically cases of firstIndexableField:, so of something in memory, not something that may be in a register).</div><div><br></div><div>That's what this issue is really about.  In the olden days for a C compiler to put something in a register one had to use the register type qualifier, and taking the address of an automatic variable (C's name for a local variable) would raise an error.  Then (quite rightly) gcc started ignoring the register qualifier and (at my request) added the asm("register name") form for specifying global register variables. Taking the address of an automatic variable then marked it as a variable that couldn't be assigned to a variable.  So tat was fine.  One could perfectly legally play the usual memory punning tricks without having to resort to writing a union.</div><div><br></div><div>When 64-bit computing went mainstream the need was for C compilers to generate good code for int variables and so lots of previously valid code was redefined to be undefined behavior.  See Chris Lattner's excellent blog post <a href="http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html">http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html</a>.  (While this is a really good post I don't endorse the position taken by C compilers; IMO this is an example of the tail wagging the dog; compilers could still do what they did in the '90's and stack allocate something whose address is taken).  Anyway, we don't control this world so we have to adapt.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 11 déc. 2019 à 20:00, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> a écrit :</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
> On Dec 11, 2019, at 9:09 AM, "<a href="mailto:tesonep@gmail.com" target="_blank">tesonep@gmail.com</a>" <<a href="mailto:tesonep@gmail.com" target="_blank">tesonep@gmail.com</a>> wrote:<br>
> <br>
> Hi Eliot, you can use PT as initials (I don't if there is a clash or<br>
> ptesone) and the timestamp is just today.<br>
<br>
Thanks.  And I’ll include your email on the GCC SSA.  Thanks for tracking this down.  This has been biting us for some time.  There was a similar issue with accessing the two 32-bit halves of the 64-bit object header in Spur that meant I had to use a rewrite.  I’ll try and dig it out.  Perhaps we could collaborate on performing the same analysis and verifying that there is an issue with this header access code in gcc.<br>
<br>
> <br>
> Thanks<br>
> <br>
>> On Wed, Dec 11, 2019 at 6:02 PM Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:<br>
>> <br>
>> <br>
>> <br>
>> <br>
>>>> On Dec 11, 2019, at 8:45 AM, "<a href="mailto:tesonep@gmail.com" target="_blank">tesonep@gmail.com</a>" <<a href="mailto:tesonep@gmail.com" target="_blank">tesonep@gmail.com</a>> wrote:<br>
>>> <br>
>>> <br>
>>> Hi Ken,<br>
>>> this is a problem in an optimization of GCC 8.3 (I am not sure what<br>
>>> other versions are impacted).<br>
>>> Basically it is generating bad a function, removing code that assumes<br>
>>> that is dead code.<br>
>>> Even though this is a bug in GCC, because there is not actual reason<br>
>>> to remove the code.<br>
>>> It is produced because the code is not written in a nice way.<br>
>>> <br>
>>> Basically, if someone wants to fix it in the VM code is modifying a<br>
>>> single method:<br>
>>> <br>
>>> Spur64BitMemoryManager >> fetchLong32: fieldIndex ofFloatObject: oop<br>
>>>   "index by word size, and return a pointer as long as the word size"<br>
>>> <br>
>>>   | bits |<br>
>>>   (self isImmediateFloat: oop) ifFalse:<br>
>>>       [^self fetchLong32: fieldIndex ofObject: oop].<br>
>>>   bits := self smallFloatBitsOf: oop.<br>
>>>   ^ fieldIndex = 0<br>
>>>       ifTrue: [bits bitAnd: 16rFFFFFFFF]<br>
>>>       ifFalse: [bits >> 32]<br>
>> <br>
>> Thank you, Pablo.  I’ll integrate this quickly.  Can you possibly give me initials and time stamp?  It’s not necessary but helps that the code is marked as being your fix.<br>
>> <br>
>>> <br>
>>> The old method had a handwritten piece of C code to replace the last if:<br>
>>> <br>
>>> (self cCoerceSimple: (self addressOf: bits) to: #'int *') at: fieldIndex<br>
>>> <br>
>>> I assume it was done to handle a different kind of endianness, but the<br>
>>> single sender of this message is already doing the handling and having<br>
>>> different behavior depending on the endianness.<br>
>>> <br>
>>> With this fix the build can still be executed with -O2 optimization in GCC 8.3<br>
>>> <br>
>>> Cheers,<br>
>>> <br>
>>>> On Sat, Dec 7, 2019 at 4:20 PM <<a href="mailto:ken.dickey@whidbey.com" target="_blank">ken.dickey@whidbey.com</a>> wrote:<br>
>>>> <br>
>>>> <br>
>>>>> Have you tried switching off compiler optimisations?<br>
>>>> <br>
>>>> Ah!  I had forgotten that one.  I thought that was changed in mvm.<br>
>>>> <br>
>>>> Image works fine noe (but more slowly!) on aarch64 Alpine Linux<br>
>>>> (musl+busybox).<br>
>>>> <br>
>>>> I am just out the door fir a couple of days but will try fdlib on<br>
>>>> return.<br>
>>>> <br>
>>>> Thanks again to all!<br>
>>>> -KenD<br>
>>> <br>
>>> <br>
>>> <br>
>>> --<br>
>>> Pablo Tesone.<br>
>>> <a href="mailto:tesonep@gmail.com" target="_blank">tesonep@gmail.com</a><br>
> <br>
> <br>
> <br>
> -- <br>
> Pablo Tesone.<br>
> <a href="mailto:tesonep@gmail.com" target="_blank">tesonep@gmail.com</a><br>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div></div>