[Bug driver/116794] New: gcc -pipe does not work on macOS with as from Xcode 16 (on macOS 15)

[Bug driver/116794] New: gcc -pipe does not work on macOS with as from Xcode 16 (on macOS 15)

[mark at moxienet dot com]

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

[Bug driver/116794] gcc -pipe does not work on macOS with as from Xcode 16 (on macOS 15)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
   Target Milestone|---                         |15.0
         Resolution|---                         |FIXED

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed by r15-3737-g33ccc1314dcdb0b988a9276ca6b6ce9b07bea21e .

[Bug driver/116794] gcc -pipe does not work on macOS with as from Xcode 16 (on macOS 15)

[egallager at gcc dot gnu.org]

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

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-09-21
           Assignee|unassigned at gcc dot gnu.org      |iains at gcc dot gnu.org
     Ever confirmed|0                           |1
         Resolution|FIXED                       |---
             Status|RESOLVED                    |REOPENED

--- Comment #2 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> Fixed by r15-3737-g33ccc1314dcdb0b988a9276ca6b6ce9b07bea21e .

Reopening because Iain said he wanted to backport the change to older branches.