Error assembling some label/goto with last Darwin clang assembler

[Fred vS]

Hello.

While trying to compile a application for Darwin and his last clang assembler, there is that error for few label/goto code:

Code: Pascal  [Select][+][-]

1. (9009) Assembling msedrawtext
2. units/msedrawtext.s:3362:1: error: non-private labels cannot appear between .cfi_startproc / .cfi_endproc pairs
3. _$MSEDRAWTEXT$_Lj446:
4. ^
5. units/msedrawtext.s:2865:1: error: previous .cfi_startproc was here
6. .cfi_startproc
7. ^

I did not find why some of the label/goto make the new assembler not happy (it was ok before).
The lot of other label/goto dont give problems.

So all the problematic label/goto were replaced with equivalent "traditional" pascal code.
There was only 12 to replace for all msegui so it was not a disaster and all is assembling/working ok.

But, for the light, I would be happy to find why those labels are not ok and all others yes.

Thanks.

[EDIT] The problem is bigger than I was thinking. 
For zeoslib there is a montain of label/goto that are not accepted, idem for units that use label/goto.

Fre;D

[TRon]

https://gitlab.com/freepascal.org/fpc/source/-/issues/41045

[Fred vS]

https://gitlab.com/freepascal.org/fpc/source/-/issues/41045

Thanks TRon! 

OK, I hope it will be fixed in the very soon release of fpc 3.2.4. (even if I dont need it now, all the problematic "label/goto" were replaced by traditional pascal code).

(But I did not catch why those 12 "label/goto" used by MSEgui are not accepted and all the 286 others are ok, for the Zeos lib project that uses 301 "label/goto", the majority is not accepted.)

Fre;D

[TRon]

You're welcome Fred vS

OK, I hope it will be fixed in the very soon release of fpc 3.2.4. (even if I dont need it now, all the problematic "label/goto" were replaced by traditional pascal code).

Why do you think there isn't a release of 3.2.4 yet ? This issue is amongst others one of the reasons.

If you click on the link to the merge request in that issue report then you'll be able to find the details regarding the issue when following the discussion.

Rest assured that there is not really any thumb-fiddling going about and the issue is on the radar 

[Fred vS]

You're welcome Fred vS

OK, I hope it will be fixed in the very soon release of fpc 3.2.4. (even if I dont need it now, all the problematic "label/goto" were replaced by traditional pascal code).

Why do you think there isn't a release of 3.2.4 yet ? This issue is amongst others one of the reasons.

If you click on the link to the merge request in that issue report then you'll be able to find the details regarding the issue when following the discussion.

Rest assured that there is not really any thumb-fiddling going about and the issue is on the radar 

I have to confess that I am not a fan of  "label/goto" and never used it in my code.

[wcage03]

I know there is a lot of work being done to resolve this going forward into the next release, but I am curious if there is a release that I can downgrade to that would eliminate the problem? I am on MacOS 15.3.1, FPC 3.2.2, and Lazarus 3.8. My needs are not bleeding edge (my skills are even less so) so I am inclined to retreat and wait out the experts in their quest to solve the problem. FPCUpdeluxe gives this problem, but it might be that I have FPC 3.2.2 installed on my machine already, otherwise, I would just blow through the combinations until I found one that worked. Any insight is much appreciated.

[TRon]

... but I am curious if there is a release that I can downgrade to that would eliminate the problem?

Yes. You can downgrade your MacOS or Clang compiler. Compiler should be < v18. No idea what MacOS version that corresponds to.

[dbannon]

Why do you think there isn't a release of 3.2.4 yet ? This issue is amongst others one of the reasons.

Wow, thank you for making that public TRon !  I have wondered what the "significant platform / issue" was.

When I was doing my degree, a very long time ago, we were told about goto but informed that any project or assignment containing a goto would automatically get a zero mark. That approach has remained with me ....

Code: Bash  [Select][+][-]

1. dbannon@dell:~/bin/FPC/SRC/fpc-3.2.4$ grep -niR " goto " * 2>/dev/null | wc -l
2. 627

If the plan is to remove all of them, could be a big job !  Or is there some characteristic that makes some worse than others ?

Does there appear to be any mechanism for ordinary users to help in some way ?

Davo