[arm] PR target/86003 build failures with --with-cpu=xscale
authorRichard Earnshaw <rearnsha@arm.com>
Mon, 4 Jun 2018 08:41:45 +0000 (08:41 +0000)
committerRichard Earnshaw <rearnsha@gcc.gnu.org>
Mon, 4 Jun 2018 08:41:45 +0000 (08:41 +0000)
commit34a1d5c2c7ffd8f790da87f8e23180cf7d17b81b
tree0ac8cd1182d136e9a80169378744355a95fca726
parent261ef15d46a4220c0b7453ac55265c61cda171b1
[arm] PR target/86003 build failures with --with-cpu=xscale

The XScale cpu configuration in GCC has always been somewhat
non-conforming.  Although XScale isn't an architecture (it's simply an
implementation of ARMv5te), we do by tradition emit a specific
pre-define for it.  We achieve this effect by adding an additional
feature bit to the xscale CPU definition that isn't part of the base
architecture.

When I restructured the options last year I overlooked this oddity and
the result, of course, is that this configuration now fails to build
as intended.

What happens is that the driver (correctly) constructs an architecture
for the xscale cpu name (as armv5te) and passes it in addition to the
CPU name.  The backend code, on finding both a cpu and an architecture
specifies attempts to correlate the two and finds a difference due to
the additional feature bit and reports an inconsistency (fatally if
-werror is specified).

I think the best fix to this is to treat the xscale feature bit using
the same mechanism that we use for other 'quirks' in CPU
implementations and simply filter it out before comparing the
capabilities.  It has the additional benefit that it's also the
simplest fix.

PR target/86003
* config/arm/arm-cpus.in (ALL_QUIRKS): Add xscale feature to the list
of bits to ignore when comparing architectures.

From-SVN: r261140
gcc/ChangeLog
gcc/config/arm/arm-cpus.in