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

            Bug ID: 116794
           Summary: gcc -pipe does not work on macOS with as from Xcode 16
                    (on macOS 15)
           Product: gcc
           Version: 14.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: driver
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mark at moxienet dot com
  Target Milestone: ---

On macOS, Xcode 16 has redone the way that its packaged `as` tool operates.
It’s now a shell script that delegates to `clang -x assembler -c`. One
consequence of this is that `as` no longer adheres to the convention that, in
the absence of a named input file, it will read from standard input.

`gcc -pipe` provides input to `as` via standard input. When `gcc -pipe` drives
Xcode 16 `as`, it does not give `as` an input file pathname on its command
line, causing `as`, which invokes `clang`, to produce this error and exit with
status 1:

% gcc -pipe -c -o ~/t.o ~/t.c
clang: error: no input files

This makes it impossible to use `gcc -pipe`.

It is apparent that the problem is `as`. Although this works in previous
versions of Xcode, with Xcode 16, it fails:

% as -o /dev/null <<< '.globl main'
clang: error: no input files

while this works:

% as -o /dev/null - <<< '.globl main'

Xcode 16 `as` will read its input from standard input if invoked with `-` as
the input path. Previous versions of `as` supplied by Apple, including Xcode 15
`as` and older cctools-based `as`, respect this convention as well (I tested
cctools-836 from the CLT 201211 on OS X 10.7.5 11G63), as should binutils
`gas`.

gcc has a macro, `AS_NEEDS_DASH_FOR_PIPED_INPUT`, which can be defined to
configure it to operate with `as` programs that require this convention.
Because it appears that any `as` likely to be used on any macOS/Darwin system
of any vintage can accept the `-` for this purpose, it ought to be possible to
define this for Darwin unconditionally.

This change should be taken on all live gcc branches (currently, 14, 13, and
12), as all are affected.

(There are other macOS 15/Xcode 16 compatibility concerns on gcc 13 and 12, and
other compatibility concerns even on gcc 14 for x86_64. This change alone,
however, is sufficient to make gcc work on macOS 15/Xcode 16 for arm64 using
either https://github.com/iains/gcc-darwin-arm64 or
https://github.com/iains/gcc-14-branch)

Also discussed at:
https://github.com/iains/gcc-darwin-arm64/issues/136
https://trac.macports.org/ticket/70641

Reply via email to