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

Bug#611249: gcc-4.4: Fix PR44606 concerning powerpcspe architecture



>>>>> "Sebastian" == Sebastian Andrzej Siewior <bigeasy@linutronix.de> writes:

> * David Kuehling | 2011-01-27 11:57:58 [+0100]:
>> Hi, the attached .debdiff fixes PR44606 [1], a register-allocation
>> bug that (seldomly) miscompiles floating point code in the unofficial
>> powerpcspe port [2].
>> 
>> This is a backport of commit 168347 from GCC svn [3].
> Thanks for that. We have a few other patches which are part of trunk
> but not part of stable branches. So we need to consider those as well
> or we brake things what were working.

Thanks for pointing that out.

I got the GCC source to patch against from standard debian repository,
since debian-ports does not carry sources.  Now I realized, that there
is a .diff.gz in pool-powerpcspe/main/g/gcc-4.4/.  Is there some easy
and straight-forward way to grab corresponding source packages in a
powerpcspe system?

Going to try to build a fixed gcc via the ppcspe specific source.

Any plans to move your patches into the normal gcc package?

>> The patch modifies debian/rules.patch to only apply the patch on
>> powerpcspe, so there should be no side-effects on other
>> architectures.
> Not sure if this is wise. There is an _all package which containts the
> patched source. This source is used afaik for gcj. So this would work
> for +powerpcspe package but won't work in the official debian package.

Hmm, the complexity of debian's gcc building starts giving me headaches.
I saw that there were many arch-specific patches already in rules.patch,
so thought that was standard practice.  Are you sure this is a problem?
Are you sure patches are applied before building the _all package?
According to READEM.maintainers:

  When we build from the gcc-4.3 source package, we produce, among many
  others, a gcc-4.3-source binary package that contains the pristine
  upstream tarball and some Debian-specific patches.  Any user can then
  install this package on their Debian system, and will have the full
  souces in /usr/src/gcc-4.3/gcc-<timestamp>.tar.bz2, along with the
  Makefile snippets that unpack and patch them.

  [..]

  The second step is to unpack the GCC source tarball.  This tarball is
  either in the build directory (when building gcc-4.3), or in
  /usr/src/gcc-4.3/gcc-<timestamp>.tar.bz2 (when building the other
  source packages).

  The fourth step is to select which patches to apply (this is done in
  debian/rules.defs), and then to apply the selected patches (see
  debian/rules.patch).

So that sounds like most of the patches being applied on top of the
gcc-4.4-source package when building gcc, gcj etc.

>> I verified the patch to compile and be effective on a powerpcspe sid
>> installation running on a P2020RDB development board.
> cool.

>> I guess the same patch should go into gcc-4.3 as well, going to post
>> a corresponding bug report in the next days.
> No, I'm dropping gcc-4.3. There is little need in keeping it as all
> software compiles with 4.4+

Ok. I heared from colleagues, that gcc-4.3 were more stable then 4.4,
but maybe that's just broken code on our sides and I'll try to make sure
that we drop 4.3, too.

cheers,

David
-- 
GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205  D016 7DEF 5323 C174 7D40

Attachment: pgpOCFKXsuzHK.pgp
Description: PGP signature


Reply to: