[Bug target/100152] [10.3, 11, 12 Regression] [Darwin, X86] used caller-saved register not preserved across a call.

["iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.