<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><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">eliot.miranda@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br>
<br>
<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>