https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62254
--- Comment #11 from Arnd Bergmann <arnd at linaro dot org> --- (In reply to Nick Clifton from comment #10) > Created attachment 38118 [details] > This patch fixes your particular test case, but I am not sure if it will > handle all of the ICEs in the kernel. Please could you give it a try out and > let me know the results ? I've done some randconfig builds for RiscPC now and found a couple of remaining failures with the patch from comment #7, so far all in the same three files. Adding the patch from comment #10 fixes all of them. I'll let you know if anything else shows up later. > The patch is a bit of hack. (Well actually the both patches are hacks). > It seems likely that pre ARM v4t architecture support will be dropped in the > future. So I have to ask, is ARM v3 support really still of interest to > kernel developers ? We've had a discussion on the arm-kernel list about that. We have five ARMv4 platforms based on StrongARM or FA526 that are in active use (strongarm1100, ebsa110, footbridge/netwinder, Gemini and Moxa ART), and it looks like we can keep using them with future gcc versions by building for ARMv4T and linking with ld --fix-v4bx, I've proposed a patch for that already. The only reason we are still building with -march=armv3 is Russell King's RiscPC, which also has a StrongARM 110 but cannot do 16-bit memory accesses. It would be nice to get at least gcc-6 to work in that configuration before the support is getting removed, so gcc-4.9 is not the last working version. Ideally, we would have a way for a normal -march=armv4t build with another flag to avoid 16-bit load/store operations, but I'm guessing that is exactly the code that you want to kill off in the armv3 deprecation (aside from the non-interworking branches).
