https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86003
Bug ID: 86003
Summary: [8 Regression] GCC fails to build when configured
--with-cpu=xscale
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: stilor at att dot net
Target Milestone: ---
Created attachment 44215
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44215&action=edit
Script to reproduce the issue
I am seeing the following failure when building a crosstool-NG configuration
which configures GCC for XScale CPU. The warning is:
cc1: warning: switch -mcpu=xscale conflicts with -march=armv5te switch
But during the build of libatomic, -Werror is thrown in, so the warning becomes
an error. The failing command is:
libtool: compile:
/home/avn/work/ctng/crosstool-ng/.build/armeb-unknown-linux-uclibcgnueabi/build/build-cc-gcc-final/./gcc/xgcc
-B/home/avn/work/ctng/crosstool-ng/.build/armeb-unknown-linux-uclibcgnueabi/build/build-cc-gcc-final/./gcc/
-B/home/avn/x-tools/armeb-unknown-linux-uclibcgnueabi/armeb-unknown-linux-uclibcgnueabi/bin/
-B/home/avn/x-tools/armeb-unknown-linux-uclibcgnueabi/armeb-unknown-linux-uclibcgnueabi/lib/
-isystem
/home/avn/x-tools/armeb-unknown-linux-uclibcgnueabi/armeb-unknown-linux-uclibcgnueabi/include
-isystem
/home/avn/x-tools/armeb-unknown-linux-uclibcgnueabi/armeb-unknown-linux-uclibcgnueabi/sys-include
-DHAVE_CONFIG_H
-I/home/avn/work/ctng/crosstool-ng/.build/armeb-unknown-linux-uclibcgnueabi/src/gcc/libatomic/config/arm
-I/home/avn/work/ctng/crosstool-ng/.build/armeb-unknown-linux-uclibcgnueabi/src/gcc/libatomic/config/linux/arm
-I/home/avn/work/ctng/crosstool-ng/.build/armeb-unknown-linux-uclibcgnueabi/src/gcc/libatomic/config/posix
-I/home/avn/work/ctng/crosstool-ng/.build/armeb-unknown-linux-uclibcgnueabi/src/gcc/libatomic
-I. -Wall -Werror -pthread -g -O2 -g -Os -MT init.lo -MD -MP -MF .deps/init.Tpo
-c
/home/avn/work/ctng/crosstool-ng/.build/armeb-unknown-linux-uclibcgnueabi/src/gcc/libatomic/config/linux/arm/init.c
-fPIC -DPIC -o .libs/init.o
A reproduction script (including the configuration for GCC and all the
prerequisites) is attached; for the sake of reducing the build time, it just
builds the GCC and runs the compiler on an empty source file.
The problem, as far as I can see, is that the driver executes cc1 with the
flags defined in
#define OPTION_DEFAULT_SPECS \
{"arch", "%{!march=*:%{!mcpu=*:-march=%(VALUE)}}" }, \
{"cpu", "%{!march=*:%{!mcpu=*:-mcpu=%(VALUE)}}" }, \
{"tune", "%{!mcpu=*:%{!mtune=*:-mtune=%(VALUE)}}" }, \
{"float", "%{!mfloat-abi=*:-mfloat-abi=%(VALUE)}" }, \
{"fpu", "%{!mfpu=*:-mfpu=%(VALUE)}"}, \
{"abi", "%{!mabi=*:-mabi=%(VALUE)}"}, \
{"mode", "%{!marm:%{!mthumb:-m%(VALUE)}}"}, \
{"tls", "%{!mtls-dialect=*:-mtls-dialect=%(VALUE)}"},
Which evaluates to:
-mcpu=xscale -mfloat-abi=soft -mtls-dialect=gnu -marm -march=armv5te
added to the arguments from the command line (there were no -march= or -mcpu=
specified explicitly in the failing command).
Then, cc1 discovers that -mcpu=xscale and -march=armv5te are not exactly
compatible:
(gdb) p arm_selected_cpu->common.isa_bits
$17 = {isa_bit_armv3m, isa_bit_mode32, isa_bit_notm, isa_bit_xscale,
isa_bit_armv4, isa_bit_armv5e, isa_bit_armv5, isa_bit_thumb, isa_nobit <repeats
36 times>}
(gdb) p arm_selected_arch->common.isa_bits
$18 = {isa_bit_armv3m, isa_bit_mode32, isa_bit_notm, isa_bit_armv4,
isa_bit_armv5e, isa_bit_armv5, isa_bit_thumb, isa_nobit <repeats 37 times>}
Because they differ in the presence of isa_bit_xscale (and that bit is not
listed as a quirk that's ignored during comparison), cc1 complains.
Received the following response on the mailing list [1]:
> OK, got it. Xscale isn't really an architecture in its own right, so
> having an architectural bit for is is somewhat of an anomaly. Given
> that this is only used to cause some pre-defines to occur, perhaps the
> simplest thing to do is to convert the architecture bit into a tuning
> flag. That will then avoid the conflicting state.
>
> Could you raise a bugzilla ticket please and mark it as a regression.
[1] https://gcc.gnu.org/ml/gcc-help/2018-05/msg00172.html
