gcc13 @13.3.0: error: non-private labels cannot appear between .cfi_startproc / .cfi_endproc pairs

[Knapoc]

Logfile attached.

macOS 15.0 24A335 arm64
Xcode 16.0 16A242

[Knapoc]

Logfile

[ryandesign (Ryan Carsten Schmidt)]

Looks like the error is:

<instantiation>:5:1: error: non-private labels cannot appear between .cfi_startproc / .cfi_endproc pairs
___aarch64_cas1_relax:
^
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc13/gcc13/work/gcc-13.3.0/libgcc/config/aarch64/lse.S:220:1: note: while in macro instantiation
STARTFN __aarch64_cas1_relax
^
<instantiation>:4:2: error: previous .cfi_startproc was here
 .cfi_startproc
 ^
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc13/gcc13/work/gcc-13.3.0/libgcc/config/aarch64/lse.S:220:1: note: while in macro instantiation
STARTFN __aarch64_cas1_relax
^

I found a reference to this issue here: ​https://github.com/NixOS/nixpkgs/issues/309365 . It provides a link to the intentional llvm change that causes this gcc build failure. There is no reference to a gcc bug report. Have you tried a newer version of gcc to see if the problem is already fixed? Try the gcc14 or gcc-devel ports.

[Knapoc]

gcc14 builds fine, as long as configurepipe is set to no. It's just that the port I'm trying to build is not supporting newer compiler versions.

Thanks for the insights.

[markemer (Mark Anderson)]

I've run into this - it's actually a bug in clang that was rolled back in upstream clang - you might want to try again with the Xcode RC, it probably has the fix. That said, gcc14 does build fine as long as configurepipe is set to no.

[ryandesign (Ryan Carsten Schmidt)]

Mark, do you have that bug report URL?

[markemer (Mark Anderson)]

I think this is it, but I have a lot - this keeps getting re-implemented and reverted

​https://github.com/llvm/llvm-project/issues/97116

More context: ​https://reviews.llvm.org/D155245#4657375

[Knapoc]

Replying to markemer:

you might want to try again with the Xcode RC, it probably has the fix.

the Xcode version im running is the latest RC.

And it seems that this fix was already merged in Apple's llvm-fork and redone in early July: ​https://github.com/swiftlang/llvm-project/commit/94471e73fe3a6e5ddf700ed79941b1f1c8d2127b

[markemer (Mark Anderson)]

I confirmed it's still broken in my RC as well. Clang-17 may have this same issue, gonna try again and open a ticket if need be. I wonder the best way to work around this would be?

[ryandesign (Ryan Carsten Schmidt)]

The ticket for this same error affecting clang-17 is #70779.

[markmentovai (Mark Mentovai)]

​https://github.com/iains/gcc-darwin-arm64/issues/137

[markmentovai (Mark Mentovai)]

The same problem affects gcc12 too.

[markmentovai (Mark Mentovai)]

​https://github.com/macports/macports-ports/pull/26234

[markmentovai (Mark Mentovai)]

In 4ba0a58106305c74b760af62300054f23137e20d/macports-ports (master):

gcc13: update to include latest upstream unreleased patches

This adds patches from ​https://github.com/iains/gcc-13-branch, from
branch gcc-13-3-darwin (2024-10-17), after tag gcc-13.3-darwin-r1. It
includes macOS 15 (and macOS 14 with Xcode 16) compatibility patches,
similar to 048f899dce5f and 40a267e1c326 for gcc14. gcc13 required an
additional fix beyond what gcc14 needed, included here as the 0006
patch.

This additionally improves macOS 15/Xcode 16 compatibility by disabling
the ld-classic workaround with those tools, like 2453011ee18c and
771b2dab4689 did for gcc14.

Closes: #70710