[M3devel] m3_load/store using bitfields for everything

[Tony Hosking]

Don't worry --- I found one.

On 22 May 2009, at 11:38, Tony Hosking wrote:

> I think my old PPC_DARWIN installs are pre-LONGINT.  Is there a  
> LONGINT-capable bootstrap archive for PPC_DARWIN lying around  
> anywhere?
>
> On 22 May 2009, at 11:18, Tony Hosking wrote:
>
>> PPC_DARWIN did work for me at one point.  I can check it.
>>
>> On 22 May 2009, at 10:09, Jay wrote:
>>
>>>
>>> Yes I will test some variations, esp. targets not historically  
>>> affected by the bitfield behavior but that haven't passed -O3 yet,  
>>> since they are easier for a few reasons and more numerous  
>>> (PPC_DARWIN, PPC_LINUX, AMD64_FREEBSD, etc.)
>>>
>>>
>>> ARM_DARWIN is a little wierd due to the 4.2 base, MIPS64_OPENBSD I  
>>> haven't booted the machine in months and it is very slow (my / 
>>> plan/ is to get all of MIPS{32,64}_{OPENBSD,NETBSD,IRIX,LINUX},  
>>> but it's slow going, I had difficulty installing some of them,  
>>> only got Irix and OpenBSD running, and some of those combinations  
>>> are invalid e.g. MIPS32_OPENBSD -- OpenBSD never
>>> has "biarch" systems, only ever pure 32bit or pure 64bit).
>>>
>>>
>>> Moving ARM_DARWIN forward to 4.3 isn't impossible but I think  
>>> easier to track and wait for Apple here than anything else.
>>>
>>>
>>> I ran an AMD64_LINUX test on birch but didn't wait for it.
>>>
>>>
>>> SPARC32_LINUX also has a wierd problem that I can retest.
>>> When I compile with -fPIC I get I think crashes during  
>>> initialization.
>>> I haven't figured out the problem.
>>> Without -fPIC works ok, even for shared libraries, surprising.
>>>
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> CC: m3devel at elegosoft.com
>>>> From: hosking at cs.purdue.edu
>>>> To: jay.krell at cornell.edu
>>>> Subject: Re: m3_load/store using bitfields for everything
>>>> Date: Fri, 22 May 2009 09:45:08 +1000
>>>>
>>>> Jay, can you try these again with the latest fix I put in place?
>>>>
>>>> On 20 May 2009, at 09:14, Jay wrote:
>>>>
>>>>>
>>>>> m3_load/store using bitfields for everything caused module-global
>>>>> references to disappear on MIPS64_OPENBSD (all MIPS?). I worked
>>>>> around that by declaring that the module-globals are at least of
>>>>> size 2 * biggest_alignment.
>>>>>
>>>>> It caused module-global references to disappear on ARM_DARWIN as  
>>>>> well.
>>>>> I hardcoded RTLinker.traceInit to true, and Flush's len := 0  
>>>>> didn't
>>>>> occur and PutChar eventually failed an array bounds check.
>>>>>
>>>>> Is this just too fragile and the failsafe form should always be  
>>>>> used?
>>>>>
>>>>> Or, it fails spectacularly consistently enough that it must also  
>>>>> be
>>>>> working consistently enough and leave it?
>>>>>
>>>>> Would "component ref" (ie: struct) and declaring more type
>>>>> information about module segments be a good compromise maybe?
>>>>> Probably.
>>>>>
>>>>> - Jay
>>>>