[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: PPC/PPC64 disabled in Koji for dist-f13



On Thu, Oct 01, 2009 at 11:32:59AM +0200, Kevin Kofler wrote:
> Tom Lane wrote:
> > > [ ppc64 horror story snipped ]
> >
> > Well, I'm by no means wedded to ppc64; I just want *some* BE
> > architecture in the primary set.  Maybe a reasonable compromise would be
> > to include ppc but not ppc64?  That would cover basic BE portability
> > issues, if not the occasional BE-and-64-bit bug.  And it would halve the
> > present workload of the PPC builders, which might help the build time
> > issue.
> 
> Well, AFAIK ppc32 also has this "TOC" mess I was complaining about, it just 
> has room for twice as many entries because pointers are half the size, so in 
> practice projects trigger the awfully low ppc64 limit first.

And many other targets have similar limitations.  Even x86-64 has them, just
big enough that you rarely notice (you need to go over 2GB of code/data to
start having issues there, and even then there are code models that allow
larger code).  In some cases it is just -fpic vs. -fPIC, but in other cases
the limitations are more severe.  Most of the limitations are related to the
encoding of instructions, what immediates they allow and what addressing
modes they support.

It is actually very desirable if developers don't think all the world is
i386/x86_64, that leads to horribly unportable code and many bugs go
unnoticed.  In the OpenBabel case just using an array, or changing the
generator to spit more smaller sources, etc. would be desirable for
portability.

So I think making PPC a secondary arch is a very bad idea and will hurt
Fedora quality.

	Jakub


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]