[Bug driver/114813] New: powerpc64: Assembly option -many passed unconditionally, please drop, or make easily configurable

["nisse at lysator dot liu.se" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 114813
           Summary: powerpc64: Assembly option -many passed
                    unconditionally, please drop, or make easily
                    configurable
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: driver
          Assignee: unassigned at gcc dot gnu.org
          Reporter: nisse at lysator dot liu.se
  Target Milestone: ---

Hi,

my project includes C and assembly for a couple of different
architectures and cpu flavors (with some runtime selection of which
functions to use). I use the gcc driver for both .c and .s
(preprocessed assembly) files.

I would like each assembly file to declare the kind of processor it is
intended for, to get compile-time errors if I accidentally use
instructions not available for that processor.

For powerpc64, there are assembly pseudoops for that; docs are a bit
sketchy, but I think I should be able to use, e.g.,

  .machine "power8"

as annotation in the assembly input, and get an error from the
assembler if I use instructions introduced in later processor
versions. However, it turns out that gcc adds the command-line option
-many when processing assembly files, which allows all instructions, and I find
no easy way to
disable that. There may be a good reason for that option when
processing files generated by the gcc compiler (e.g., use of inline
asm for arbitrary processor variants), but it's unhelpful for my
usecase, where I pass an assembly file as input to gcc.

Example:

$ powerpc64le-linux-gnu-gcc -v no-such-file.s
Using built-in specs.
COLLECT_GCC=powerpc64le-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/powerpc64le-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: powerpc64le-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 12.2.0-14'
--with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12 --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--without-target-system-zlib --with-libphobos-druntime-only=yes
--enable-secureplt --enable-targets=powerpcle-linux --disable-multilib
--enable-multiarch --disable-werror --with-long-double-128
--enable-offload-targets=nvptx-none=/build/gcc-12-cross-7DlaPe/gcc-12-cross-15/gcc/debian/tmp-nvptx/usr
--enable-offload-defaulted --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=powerpc64le-linux-gnu
--program-prefix=powerpc64le-linux-gnu-
--includedir=/usr/powerpc64le-linux-gnu/include
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Debian 12.2.0-14) 
COLLECT_GCC_OPTIONS='-v' '-dumpdir' 'a-'

/usr/lib/gcc-cross/powerpc64le-linux-gnu/12/../../../../powerpc64le-linux-gnu/bin/as
-v -a64 -mpower8 -many -mlittle -o /tmp/ccncUIii.o no-such-file.s
GNU assembler version 2.40 (powerpc64le-linux-gnu) using BFD version (GNU
Binutils for Debian) 2.40
Assembler messages:
Error: can't open no-such-file.s for reading: No such file or directory

Note the "-many" on the assembler invocation close to the end. If I
look at the output of -dumpspecs, I see a "-many" at the end of the
"*asm_cpu:" section. I don't understand the syntax, but it appears at
the end with no qualifiers, and I guess that means it's unconditional.
I've checked that I get a different command line, without -many, if I
take that out from the specs section, and pass the modified specs file
to the gcc -specs option, but that's a rather cumbersome workaround.

Could the gcc driver drop the -many option, at least for the case that
its input is a .s (assembly) file?