]> git.ipfire.org Git - thirdparty/gcc.git/commit
[arm] PR target/86003 build failures with --with-cpu=xscale
authorrearnsha <rearnsha@138bc75d-0d04-0410-961f-82ee72b054a4>
Mon, 4 Jun 2018 08:41:45 +0000 (08:41 +0000)
committerrearnsha <rearnsha@138bc75d-0d04-0410-961f-82ee72b054a4>
Mon, 4 Jun 2018 08:41:45 +0000 (08:41 +0000)
commitf18d79595db4ae88dbd40d73bb2d1ea191a756a1
tree0ac8cd1182d136e9a80169378744355a95fca726
parentbaa4fd4bd0ac9780eda530d5c497ab01bd933737
[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.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@261140 138bc75d-0d04-0410-961f-82ee72b054a4
gcc/ChangeLog
gcc/config/arm/arm-cpus.in