[M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)

[Jay K]

I don't think anything I've been fiddling with has been dropped by gcc, yet.
 I might have depended on Irix o32 to get up to a working gcc, but no matter.
 I agree if they drop it, we have to.
 Though we could also keep multiple gcc versions if there was really something we wanted,
  but that's not likely.
 A C generating backend also solves this.


I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
But I won't guarantee that now and am very willing to undo them if there is a problem.
 (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).


 I don't remember about div/mod.
 While it seems "obvious" that the change is correct, it could be that that part of
 gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?


I'm also not optimizing at all.


I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
easily, and I'm also not keen on the huge testing matrix.
(I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)


If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.


Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
 SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).


 - Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Fri, 14 May 2010 09:59:02 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>
> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>
> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>
> On 14 May 2010, at 06:27, Jay K wrote:
>
>>
>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>> Then I'll have to narrow it down some -- there are two main sets of changes:
>> - my changes to set operations
>> - my change to div/mod
>> - Tony's to bit field operations
>>
>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>
>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>> to keep them if they don't work.
>> (Well, hopefully the NT386 versions can stay. :) )
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: m3devel at elegosoft.com
>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>
>>>
>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>> PPC_DARWIN, SOLsun, I386_LINUX
>>> I'll figure it out. Hopefully soon.
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: m3devel at elegosoft.com
>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>>
>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>
>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>
>>>>
>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>> I think it used to mostly work since I deleted some install I had there.
>>>>
>>>>
>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>> (gdb) disassem
>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>> 0x00000000004bd02c : nop
>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>
>>>>
>>>> This seems like it'll be tough going. :(
>>>>
>>>>
>>>> I think I'll try with PIC turned off.
>>>>
>>>> - Jay
>>>>
>>>>
>>>
>>
>