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)

main.log.tar.br (131.1 KB) - added by Knapoc 9 days ago.
Logfile

Download all attachments as: .zip

Change History (11)

Changed 9 days ago by Knapoc

Attachment: main.log.tar.br added

Logfile

comment:1 Changed 9 days ago by ryandesign (Ryan Carsten Schmidt)

Description: modified (diff)
Keywords: arm64 added
Summary: gcc13 fails to build on sequoiagcc13 @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 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 in reply to:  3 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

Version 0, edited 7 days ago by Knapoc (next)

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.

Note: See TracTickets for help on using tickets.