[M3devel] gcc 4.5.0?

[Jay K]

eh, ok, I'll try that then.


Have you noticed what I did for OpenBSD?
Perhaps easier to just commit those diffs?
In order to facilitate merging?
Tedious either way of course.


What I did for OpenBSD -- commited long ago, been working -- is that there are diffs out there, like in the OpenBSD port system.
   OpenBSD apparently sticks with patched 2.95 for some systems, patched 3.x mostly, and OpenBSD isn't quite supported by mainline gcc.
Largely they aren't relevant, like to c-*.c.
Largely they are trivial. Just configure/makefile snippets.
Anyway, I took the ones we needed, possibly edited them to compile, checked them in.
We apply them during our build, in m3makefile.


Another wasteful but lazy option is import gcc-4.5.0 as a new directory and
only shift targets to it upon (minimal) testing. That way I can put off the OpenBSD thing.
And commit with minimal testing instead of a big matrix.


But it bloats the source tree a lot.


I'd also like to somehow reduce how often gmp and mpfr are built.
They are a huge fraction of the time.
And 4.5.0 adds another similar library, mpc.
  "c" for complex numbers..more stuff we don't use...


It seems our main changes are:
  introducing of static chain for nested procedures
  Doesn't Ada have them? I've noticed that Ada "looks like" Modula-3.
  Or Pascal? I mean..do we have to add our own?

  small hacks to inhibit optimization 


  the little makefile machinery 


Also, have you noticed that 4.5.0 has a "plugin" interface?
Perhaps we can just use that, and just distribute a small .so file.
At least once 4.5.0 is in wide use.


 - Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Thu, 20 May 2010 09:10:03 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] gcc 4.5.0?
>
> Unfortunately, it has never been as easy as import release, merge to head. Usually there are many differences that need to be resolved by hand. But, that is how it should be done.
>
> And in past releases (from v3 to v4) things have changed so drastically in gcc that it has been practically a full report.
>
> As can be seen from the history I previously used the approach you mention last: diff against the reference release and roll the diffs forward into the new version by reapplying the diffs. To be honest I find that better because it forces you to look at every diff in context, so you catch any incompatible changes.
>
> On 20 May 2010, at 07:50, Jay K wrote:
>
>>
>> Tony, what is involved in upgrading to gcc 4.5.0?
>>
>> Import unchanged gcc.4-5.0 to the "gcc-releases" branch?
>>
>> Merge it to the "gcc" branch?
>>
>> And then to head?
>>
>>
>>
>>
>> I mean, you know..there are all the directions out there for managing
>> external trees, but I think the main missing detail is what
>> branches/tag names to use to match previous history, and it isn't
>> immediately clear to me..from, um, reading the history (which imho is
>> yet another indictment of CVS -- I can't figure out what happened).
>>
>>
>> I have gone through the exercise a very small number of times, like once, of importing foreign source into cvs.
>> But I haven't ever updated it.
>> e.g. cvsup.
>>
>>
>> I can also easily enough diff our tree against gcc-4.3.0, overwrite with 4.5.0, and reapply the diffs.
>> The diffs are quite small.
>> But I know that's not considered the right way.
>>
>>
>> (I'm still hoping to switch, like to mercurial or maybe git or maybe monotone..)
>>
>>
>> - Jay
>>
>>
>