Opened 9 days ago
Last modified 45 hours ago
#70710 new defect
gcc13 @13.3.0: error: non-private labels cannot appear between .cfi_startproc / .cfi_endproc pairs
Reported by: | Knapoc | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.10.1 |
Keywords: | sequoia arm64 | Cc: | markemer (Mark Anderson) |
Port: | gcc13 |
Description (last modified by ryandesign (Ryan Carsten Schmidt))
Logfile attached.
macOS 15.0 24A335 arm64
Xcode 16.0 16A242
Attachments (1)
Change History (11)
Changed 9 days ago by Knapoc
Attachment: | main.log.tar.br added |
---|
comment:1 Changed 9 days ago by ryandesign (Ryan Carsten Schmidt)
Description: | modified (diff) |
---|---|
Keywords: | arm64 added |
Summary: | gcc13 fails to build on sequoia → gcc13 @13.3.0: error: non-private labels cannot appear between .cfi_startproc / .cfi_endproc pairs |
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.
comment:2 Changed 8 days ago by 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.
comment:3 follow-up: 6 Changed 8 days ago by 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.
comment:4 Changed 8 days ago by ryandesign (Ryan Carsten Schmidt)
Cc: | markemer added |
---|
Mark, do you have that bug report URL?
comment:5 Changed 7 days ago by 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
comment:6 Changed 7 days ago by 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. Just by a quick search, Xcode's llvm should be based on this project:
And it seems that this fix was already merged and redone in early July: https://github.com/swiftlang/llvm-project/commit/94471e73fe3a6e5ddf700ed79941b1f1c8d2127b
comment:7 Changed 3 days ago by 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?
comment:8 Changed 3 days ago by razzfazz (Daniel Becker)
Cc: | razzfazz added |
---|
comment:9 Changed 3 days ago by razzfazz (Daniel Becker)
Cc: | razzfazz removed |
---|
comment:10 Changed 45 hours ago by ryandesign (Ryan Carsten Schmidt)
The ticket for this same error affecting clang-17 is #70779.
Logfile