From the upstream bug posted, there is an issue with the GCC 4.5.0 ARM backend which causes it to generate invalid code. GCC itself builds fine (after applying the "fix" of changing --disable-checking to --enable-checking=release) however some packages fail to build with the following error: scanelf: /var/tmp/portage/dev-libs/libpcre-8.00/image//usr/lib/libpcre.so: Invalid section header info (2) Applying the patch from upstream fixes this issue. The patch can also be found more easily at : http://ssvb.name/files/20100411/overlay/sys-devel/gcc/files/PR43698-fix.patch Reproducible: Always Steps to Reproduce: Actual Results: Packages that I know fail to compile with this: dev-libs/libpcre-8.00 dev-libs/libusb-0.1.12-r7 sys-apps/acl-2.2.49 sys-apps/util-linux-2.17.2 sys-libs/cracklib-2.8.15 sys-libs/e2fsprogs-libs-1.41.11 sys-libs/libcap-2.19 sys-libs/pam-1.1.1-r2 sys-libs/readline-6.1_p2 I'm not changing the severity since GCC 4.5.0 is not keyworded for any arches, but conceivably this would be a blocker, since we cannot generate valid code for a lot of applications. (The default arm stages use CFLAGS="-Os -pipe -march=armv7-a -mfpu=vfp -mfloat-abi=softfp" for the arm 7)
Just a minor clarification. Miscompilation happens with -O2 option too (I confirmed this later, but the initial investigation was done for -Os problem). Most likely any optimizations level is affected for armv6 processors and newer (those which have REV instruction).
Now in the 4.5.0 patchset.
This needs to be reopened. Gentoo patchset for gcc 4.5.0 got a newer revision of PR43698 fix, which does not solve the problem for some reason: http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00365.html The older patch was is a bit different, and it did the job: http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00401.html
the difference I see is -(define_insn "arm_rev" +(define_insn "*arm_rev" Beside that looks the same
This is a bit weird. I tried the latest PR43698 patch with 4.5 gcc branch SVN and a manually built crosscompiler, it seems to be fine. Now I'm trying to figure out what went wrong when gcc 4.5.0 was emerged (armin76 also had problems).
OK, now everything is clear. The second revision of the patch which got into gentoo patchset is really not a good one, it does not work right. There is actually *another* different revision of the fix which was finally committed to gcc trunk today (and it seems to be working fine): http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43698#c13 Can PR43698 fix be replaced with the final version in the gentoo 4.5.0 patchset?
Fixed in p1.4.
