gcc-13.3 and gcc-12.4 targeting arm64 don’t bootstrap with Xcode 16 (macOS 15): “error: non-private labels cannot appear between .cfi_startproc / .cfi_endproc pairs” while assembling gcc/libgcc/config/aarch64/lse.S

[markmentovai]

This is on mac-arm64 running macOS 15.0 24A335 with Xcode 16.0 16A242d. I expect that this would also occur targeting mac-arm64 on macOS 14 as long as Xcode 16 is used.

While bootstrapping gcc-13.3 from iains/gcc-13-branch gcc-13-3-darwin at fa196a8618c6 (I think that this is gcc-13.3-darwin-r1 but there’s no tag for that release):

${BUILD}/./gcc/xgcc -B${BUILD}/./gcc/ -B${PREFIX}/aarch64-apple-darwin24/bin/ -B${PREFIX}/aarch64-apple-darwin24/lib/ -isystem ${PREFIX}/aarch64-apple-darwin24/include -isystem ${PREFIX}/aarch64-apple-darwin24/sys-include    -g -O2 -O2  -g -O2 -DIN_GCC   -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include   -mmacosx-version-min=11 -mmacosx-version-min=11.0 -fno-common -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -mmacosx-version-min=11 -mmacosx-version-min=11.0 -fno-common -I. -I. -I../.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/. -I../../../gcc/libgcc/../gcc -I../../../gcc/libgcc/../include -I../../../gcc/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_EMUTLS  -o cas_16_1.o -MT cas_16_1.o -MD -MP -MF cas_16_1.dep -DL_cas -DSIZE=16 -DMODEL=1 -c ../../../gcc/libgcc/config/aarch64/lse.S
<instantiation>:5:1: error: non-private labels cannot appear between .cfi_startproc / .cfi_endproc pairs
___aarch64_cas1_relax:
^
../../../gcc/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
 ^
../../../gcc/libgcc/config/aarch64/lse.S:220:1: note: while in macro instantiation
STARTFN __aarch64_cas1_relax
^
make[2]: *** [cas_1_1.o] Error 1
make[1]: *** [all-target-libgcc] Error 2
make: *** [all] Error 2

This also occurs while bootstrapping gcc-12.4 from iains/gcc-14-branch gcc-12-4-darwin at e300c1337a48.

MacPorts bug 70710 tracks this bug.

STARTFN NAME(cas) makes use of the STARTFN macro, defined as:

.macro	STARTFN name
	.text
	.balign	16
	.private_extern	_\name
	.cfi_startproc
_\name:
	BTI_C
.endm

Since llvm d506aa4edfa6, in Xcode 16, the llvm assembler insists that the _\name: label precede the .cfi_startproc directive.

This is not a problem in gcc-14 or trunk, which does not use the STARTFN macro in its lse.S as of gcc-14.2-darwin-r1 (via this commit) or trunk cbfd46038c50 (via this commit).

It would be straightforward to move the _\name: label up above the .cfi_startproc on the gcc-13-branch and gcc-12-branch.

@iains

[iains]

This is on mac-arm64 running macOS 15.0 24A335 with Xcode 16.0 16A242d. I expect that this would also occur targeting mac-arm64 on macOS 14 as long as Xcode 16 is used.

While bootstrapping gcc-13.3 from iains/gcc-13-branch gcc-13-3-darwin at fa196a8618c6 (I think that this is gcc-13.3-darwin-r1 but there’s no tag for that release):

let me look at that - the release might still be pending and I forgot to do it...

${BUILD}/./gcc/xgcc -B${BUILD}/./gcc/ -B${PREFIX}/aarch64-apple-darwin24/bin/ -B${PREFIX}/aarch64-apple-darwin24/lib/ -isystem ${PREFIX}/aarch64-apple-darwin24/include -isystem ${PREFIX}/aarch64-apple-darwin24/sys-include    -g -O2 -O2  -g -O2 -DIN_GCC   -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include   -mmacosx-version-min=11 -mmacosx-version-min=11.0 -fno-common -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -mmacosx-version-min=11 -mmacosx-version-min=11.0 -fno-common -I. -I. -I../.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/. -I../../../gcc/libgcc/../gcc -I../../../gcc/libgcc/../include -I../../../gcc/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_EMUTLS  -o cas_16_1.o -MT cas_16_1.o -MD -MP -MF cas_16_1.dep -DL_cas -DSIZE=16 -DMODEL=1 -c ../../../gcc/libgcc/config/aarch64/lse.S
<instantiation>:5:1: error: non-private labels cannot appear between .cfi_startproc / .cfi_endproc pairs
___aarch64_cas1_relax:
^
../../../gcc/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
 ^
../../../gcc/libgcc/config/aarch64/lse.S:220:1: note: while in macro instantiation
STARTFN __aarch64_cas1_relax
^
make[2]: *** [cas_1_1.o] Error 1
make[1]: *** [all-target-libgcc] Error 2
make: *** [all] Error 2

This also occurs while bootstrapping gcc-12.4 from iains/gcc-14-branch gcc-12-4-darwin at e300c1337a48.

MacPorts bug 70710 tracks this bug.

STARTFN NAME(cas) makes use of the STARTFN macro, defined as:

.macro	STARTFN name
	.text
	.balign	16
	.private_extern	_\name
	.cfi_startproc
_\name:
	BTI_C
.endm

Since llvm d506aa4edfa6, in Xcode 16, the llvm assembler insists that the _\name: label precede the .cfi_startproc directive.

This is not a problem in gcc-14 or trunk, which does not use the STARTFN macro in its lse.S as of gcc-14.2-darwin-r1 (via this commit) or trunk cbfd46038c50 (via this commit).

It would be straightforward to move the _\name: label up above the .cfi_startproc on the gcc-13-branch and gcc-12-branch.

yeah - that seems like the right action - I need to queue up some back ports to 13 and 12 - probably can pick that up at the same time - unless it's burning anyone badly short-term? (as always juggling priorities and use of test h.w here)

[iains]

While bootstrapping gcc-13.3 from iains/gcc-13-branch gcc-13-3-darwin at fa196a8618c6 (I think that this is gcc-13.3-darwin-r1 but there’s no tag for that release):

let me look at that - the release might still be pending and I forgot to do it...

The reason it was never pushed was that gcc-13.3-darwin-r1 is actually a NOP (there was confusion with reported issues with fixincludes - that had already been fixed on the gcc-13-3-darwin branch).

For the sake of avoiding confusion - I've pushed the tag now - but r0 and r1 are essentially NFC identical (there are some automatically-generated comment changes in the generated fixincludes)

[markmentovai]

#137 (comment):

yeah - that seems like the right action - I need to queue up some back ports to 13 and 12 - probably can pick that up at the same time - unless it's burning anyone badly short-term? (as always juggling priorities and use of test h.w here)

I’m not one to say how badly this might be impacting others, but I certainly hope you wouldn’t reprioritize other things based just on this report. I get the feeling that the gcc-14 stuff is a higher priority, and that expectations are naturally lower around gcc-13 and gcc-12.

[iains]

This is now fixed on trunk, and I have pushed an edition of gcc-14-2-darwin with it too - I have not released the latter (it is not yet tested widely enough). If we have problems with 14 please open a new issue there.

[markmentovai]

Apologies for this, but there are a few things in flight at once, and I’m just trying to make sure that nothing slips through the cracks.

#137 (comment):

This is now fixed on trunk, and I have pushed an edition of gcc-14-2-darwin with it too - I have not released the latter (it is not yet tested widely enough). If we have problems with 14 please open a new issue there.

The bug reported here, error: non-private labels cannot appear between .cfi_startproc / .cfi_endproc pairs, was observed on your branches of gcc-13 and gcc-12, and it occurs in gcc-11 as well. I don’t see any changes on those branches, and there’s nothing to fix on gcc-14 or trunk.

I think this one should still be open?

[iains]

you are absolutely correct, this one needs looking at still - I did not get back this far yet.

[markmentovai]

Thanks. This one’s pretty straightforward, but if it would help, I can send a pull request. I know there’s a lot going on right now.

[iains]

Thanks. This one’s pretty straightforward, but if it would help, I can send a pull request. I know there’s a lot going on right now.

as you say the coding is not the issue here - it does look quite simple ..

(apart from $dayjob being manic) the main issue is in test box availability - my plan is to try and work backwards with the patches needed for xcode-16/macOS 15 - so trunk is almost storted out and I expect to start a test run for 14 soon - thence to 13, 12 and 11 (and eventually 10)

[rhdtownsend]

For those who can't wait, here's an utterly trivial patch for gcc 13.3 that appears to work.

gcc-13.3-darwin-r0-fix-cfi-startproc-error.txt