[Bug target/62254] [4.9/5/6 Regression] gcc-4.9 ICEs on linux kernel zlib for armv3

[arnd at linaro dot org]

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).