[Bug driver/86003] New: [8 Regression] GCC fails to build when configured --with-cpu=xscale

[stilor at att dot net]

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