https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
Iain Sandoe <iains at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target|x86_64-apple-darwin19.6.0 |x86_64-apple-darwin* Summary|Possible 10.3 bad code |[10.3, 11, 12 Regression] |generation regression from |[Darwin, X86] used |10.2/9.3 on Mac OS 10.15.7 |caller-saved register not |(Catalina) |preserved across a call. Known to fail| |10.3.0 Target Milestone|--- |10.4 --- Comment #24 from Iain Sandoe <iains at gcc dot gnu.org> --- O1: movl $0, %ebx L756: movl 0(%rbp,%rbx,4), %esi movq %r14, %rdi call ____UTF_8_put movq %rbx, %rax addq $1, %rbx cmpq %rax, %r13 jne L756 works OK because %rbx is callee saved. ---- O2: xorl %r10d, %r10d .p2align 4,,10 .p2align 3 L938: movl 0(%rbp,%r10,4), %esi call ____UTF_8_put movq %r10, %rax addq $1, %r10 cmpq %rax, %r12 jne L938 fails because %r10 is not callee saved and is clobbered by the lazy symbol resolver. 10-2 uses rbx at O2, and so does Linux (it is of course hard to be 100% sure that the same problem "could not occur" on other platforms; there is relatively little Darwin-specific code in the x86 backend, especially for x86_64). I did see a fail [wrong code] with 11.1 (and would expect that to be present in master too) - whether the code crashes will depend on which reg happens to be used - e.g. r8 could survive the call (even tho it is not saved) but r10 will always be clobbered by the lazy symbol resolver. A workaround is to build c_intf.o with -O1. Unfortunately, the configuration for the project does not allow selection of the RTS optimisation level - it is jammed on at the highest level found. Adding or modifying a rule for that object will work in the short-term. Locally, I added a --enable-c-opt-rts to allow testing, you're welcome to that patch if it's helpful. Next will be to try and bisect to find the change that caused this - but obv. that is not going to be done before 10.4 / 11.2 so the workaround is probably needed.