[Bug target/101284] New: conflicting arch/fpu result in unexpected preprocessor defines

[Bug target/101284] New: conflicting arch/fpu result in unexpected preprocessor defines

[clyon at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101284

            Bug ID: 101284
           Summary: conflicting arch/fpu result in unexpected preprocessor
                    defines
           Product: gcc
           Version: 9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Compiling with -march=armv8.1-m.main+mve.fp -mfpu=neon-fp16 -mfloat-abi=softfp
produces no warning and generates the following defines:
#define __ARM_NEON__ 1
#define __ARM_NEON 1
#define __ARM_NEON_FP 6
#define __ARM_FEATURE_MVE 3

which I didn't expect.

This also means that TARGET_HAVE_MVE is defined in the compiler as well as
TARGET_NEON. So vectorization code that has to do different things for Neon and
MVE can quite easily ICE if you provide all these flags on the command-line.

(I wanted to compare vectorization with MVE and Neon on one testcase and hoped
to override the MVE FPU by just adding -mfpu=neon-fp16 and the end of the
command-line).

[Bug target/101284] conflicting arch/fpu result in unexpected preprocessor defines

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101284

--- Comment #1 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
I think this combination of options should result in an error.  As we move away
from -mfpu to permitting only the 'auto' model, we are increasingly adding
'fpu' features that cannot be expressed via this option since we are not adding
new fpu names any more.

So in some ways, this is an invalid use case, but it does highlight we should
emit a diagnostic in this case.