>>>>> "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:
pgpGsgcjHJsRX.pgp
Description: PGP signature