https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62254
Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ramana at gcc dot gnu.org
--- Comment #12 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to Arnd Bergmann from comment #11)
> (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).
Yes this is code we'd like killed off with the armv3 deprecation. This is
probably a tail of the original bug fix with 62254 but in the future could we
please have new bug reports for these issues ?
