[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

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.


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

Attachment: pgpGsgcjHJsRX.pgp
Description: PGP signature

Reply to: