Quote:
Henes wrote:
AROS and MorphOS do not rely on horrible and giant compiler patches breaking the SystemV ABI and such.
Are you talking about __libcall__? The funny thing is that this extension causes
no problems with new GCC versions. Th old GCC2 modifications apply to ALL later versions. Go figure..
Quote:
Our diffs are much smaller (or even non-existant...) and can be applied in no time.
Are we talking about the same diffs? FWIW, the binutils patches (at least for 2.9.1) contain
lots of unrelated crap! One of these hunks was the reason for non-working code until Piru disabled it... It could have been removed without trouble. The same applies to the GCC patches, lots of unrelated stuff. Altivec support is different with newer binutils/GCC versions (different argument names, maybe even the syntax changed). And looking the AltiVec MOS-GCC version I can easily spot questionable changes in rs6000.c/rs6000_stack_info.
Quote:
there is no patch to apply to get a working MorphOS compiler. Just grab GCC source, configure&make and you get a working MorphOS compiler :-)
Without all the fancy stuff like __varargs68k, __saveds and all the target options that got added to the 2.95.x sources. And what about the SDATA_BREL?
Quote:
On MorphOS and AROS, there is no need to patch anything and any standard compiler works.
Does configure know MorphOS? Don't you need the GET_MIN_[MODE,TYPE]_ALIGNMENT changes?
