[Bug target/100152] New: Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[Bug target/100152] New: Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[lucier at math dot purdue.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

            Bug ID: 100152
           Summary: Possible 10.3 bad code generation regression from
                    10.2/9.3 on Mac OS 10.15.7 (Catalina)
           Product: gcc
           Version: 10.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: lucier at math dot purdue.edu
  Target Milestone: ---

With this compiler:

[Bradleys-Mac-mini:~] lucier% /usr/local/gcc-10.3.0/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-10.3.0/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-10.3.0/libexec/gcc/x86_64-apple-darwin19.6.0/10.3.0/lto-wrapper
Target: x86_64-apple-darwin19.6.0
Configured with: ../../gcc-10.3.0/configure --prefix=/usr/local/gcc-10.3.0
--enable-languages=c --disable-multilib --enable-checking=release
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.3.0 (GCC) 

and these compiler options:

/usr/local/gcc-10.3.0/bin/gcc -save-temps -g -O3 -Wno-unused -Wno-write-strings
-Wdisabled-optimization -fwrapv -fno-strict-aliasing -fno-trapping-math
-fno-math-errno -fschedule-insns2 -fomit-frame-pointer -fPIC -fno-common -mpc64
  -I"../include" -c -o c_intf.o -I. -DHAVE_CONFIG_H
-D___GAMBITDIR="\"/usr/local/Gambit\""
-D___GAMBITDIR_USERLIB="\"~/.gambit_userlib\""
-D___GAMBITDIR_INSTLIB="\"~~userlib\"" -D___SYS_TYPE_CPU="\"x86_64\""
-D___SYS_TYPE_VENDOR="\"apple\"" -D___SYS_TYPE_OS="\"darwin19.6.0\""
-D___CONFIGURE_COMMAND="\"./configure 'CC=/usr/local/gcc-10.3.0/bin/gcc
-save-temps -g' '--enable-single-host' '--enable-shared'"\"
-D___OBJ_EXTENSION="\".o\"" -D___EXE_EXTENSION="\"\"" -D___BAT_EXTENSION="\"\""
-D___PRIMAL c_intf.c -D___LIBRARY

on Mac OS 10.5.7 (Catalina), I get a runtime failure, with console message:

Exception Type:        EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes:       0x000000000000000c, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Illegal instruction: 4
Termination Reason:    Namespace SIGNAL, Code 0x4
Terminating Process:   exc handler [98080]

Application Specific Information:
dyld2 mode

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libgambit.dylib                     0x000000010dfaf010
___SCMOBJ_to_NONNULLSTRING + 1520 (c_intf.c:3280)

The disassembly (with arrow pointing to the noted instruction) is: 

(lldb) di -s 0x0000000103d60000 -c 10
libgambit.dylib`___SCMOBJ_to_NONNULLSTRING:
    0x103d60000 <+1504>: jl     0x103d60026               ; <+1542> at
c_intf.c:3282:9
    0x103d60002 <+1506>: orb    %al, 0x31(%rbp)
    0x103d60005 <+1509>: shlb   %cl, 0x2e(%rsi)
    0x103d60008 <+1512>: nopl   (%rax,%rax)
->  0x103d60010 <+1520>: movl   (%rbp,%r10,4), %esi
    0x103d60015 <+1525>: callq  0x103fba9a0               ; symbol stub for:
___UTF_8_put
    0x103d6001a <+1530>: movq   %r10, %rax
    0x103d6001d <+1533>: addq   $0x1, %r10
    0x103d60021 <+1537>: cmpq   %r12, %rax
    0x103d60024 <+1540>: jne    0x103d60010               ; <+1520> at
c_intf.c:3280:173

I'll add the .i and .s files.  I apologize for their length, I don't know how
much I can cut out and still keep them relevant.

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[lucier at math dot purdue.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #1 from lucier at math dot purdue.edu ---
Created attachment 50638
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50638&action=edit
preprocessed source file

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[lucier at math dot purdue.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #2 from lucier at math dot purdue.edu ---
Created attachment 50639
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50639&action=edit
Gzipped assembly file

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |iains at gcc dot gnu.org

--- Comment #3 from Iain Sandoe <iains at gcc dot gnu.org> ---
thanks for the report.
please could you check the uploaded assembly file, it seems to be truncated?

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #4 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #3)


> please could you check the uploaded assembly file, it seems to be truncated?

Ignore that - decompressor glitch.

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[lucier at math dot purdue.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #5 from lucier at math dot purdue.edu ---
I didn't have this trouble with 10.2 or 9.3; should I add these to the "Known
to work" field?

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #6 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to lucier from comment #5)
> I didn't have this trouble with 10.2 or 9.3; should I add these to the
> "Known to work" field?

yes please - also the original source, if that's OK?

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[lucier at math dot purdue.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #7 from lucier at math dot purdue.edu ---
(In reply to Iain Sandoe from comment #6)

> yes please - also the original source, if that's OK?

It's highly macrofied C code with a lot of "includes"; is the .i file not
enough?

Brad

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #8 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to lucier from comment #7)
> (In reply to Iain Sandoe from comment #6)
> 
> > yes please - also the original source, if that's OK?
> 
> It's highly macrofied C code with a lot of "includes"; is the .i file not
> enough?

enough for me to replicate the assembly produced, yes.

would it be possible to set a breakpoint on the function itself and step
through - the reported "invalid insn" seems odd, for sure.

the values of rbp. r10 and esi would be interesting too.

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[lucier at math dot purdue.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #9 from lucier at math dot purdue.edu ---
(In reply to Iain Sandoe from comment #8)
> (In reply to lucier from comment #7)
> > (In reply to Iain Sandoe from comment #6)
> > 
> > > yes please - also the original source, if that's OK?
> > 
> > It's highly macrofied C code with a lot of "includes"; is the .i file not
> > enough?
> 
> enough for me to replicate the assembly produced, yes.
> 
> would it be possible to set a breakpoint on the function itself and step
> through - the reported "invalid insn" seems odd, for sure.

I'll look into this---the way the program is called is not simple, it's a
Scheme->C compiler building a "module", so it's hidden behind a number of
scripts.

> the values of rbp. r10 and esi would be interesting too.

This is from the console crash report:

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x00007fff924cfba8  rbx: 0x0000000000000001  rcx: 0x000000010e4bdf90 
rdx: 0x000000010e4bdca0
  rdi: 0x00007ffee1c853a8  rsi: 0x000000000000002f  rbp: 0x00007fdf00595ec0 
rsp: 0x00007ffee1c853a0
   r8: 0x0000000000000460   r9: 0x0000000000000466  r10: 0x00007fff924cfba9 
r11: 0x000000010dfab920
  r12: 0x0000000000000042  r13: 0x00007ffee1c853f8  r14: 0x000000010e4bdca0 
r15: 0x00000000000006d8
  rip: 0x000000010dfaf010  rfl: 0x0000000000010206  cr2: 0x000000010dfaea20

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[lucier at math dot purdue.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #10 from lucier at math dot purdue.edu ---
(In reply to Iain Sandoe from comment #8)
> (In reply to lucier from comment #7)
> > (In reply to Iain Sandoe from comment #6)
> > 
> > > yes please - also the original source, if that's OK?
> > 
> > It's highly macrofied C code with a lot of "includes"; is the .i file not
> > enough?
> 
> enough for me to replicate the assembly produced, yes.

OK, the .i file is also attached to this bug report.

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #11 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to lucier from comment #10)
> (In reply to Iain Sandoe from comment #8)
> > (In reply to lucier from comment #7)
> > > (In reply to Iain Sandoe from comment #6)
> > > 
> > > > yes please - also the original source, if that's OK?
> > > 
> > > It's highly macrofied C code with a lot of "includes"; is the .i file not
> > > enough?
> > 
> > enough for me to replicate the assembly produced, yes.
> 
> OK, the .i file is also attached to this bug report.

indeed, thanks.

is this specific to macOS? (or is it unknown if the effect would also show on
Linux)?

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[lucier at math dot purdue.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #12 from lucier at math dot purdue.edu ---
(In reply to Iain Sandoe from comment #11)

> is this specific to macOS? (or is it unknown if the effect would also show
> on Linux)?

It does not show up on Linux with gcc-10.3.0.

I forgot to mention one thing that may be important---it shows up only when
configuring and building a shared library, not when building a static library.

I'm sorry, I should have just included the entire console crash report, here it
is.

Process:               gsc [98080]
Path:                  /Users/USER/*/gsc
Identifier:            gsc
Version:               0
Code Type:             X86-64 (Native)
Parent Process:        bash [98061]
Responsible:           X11.bin [3613]
User ID:               502

Date/Time:             2021-04-19 20:46:16.292 -0400
OS Version:            Mac OS X 10.15.7 (19H524)
Report Version:        12
Bridge OS Version:     5.2 (18P4346)
Anonymous UUID:        502BD235-3A7B-DBA1-5FD5-B92502CEE0D5

Sleep/Wake UUID:       7F858BB5-C456-41BC-888B-282D50F0E93B

Time Awake Since Boot: 2500000 seconds
Time Since Wake:       2100000 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes:       0x000000000000000c, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Illegal instruction: 4
Termination Reason:    Namespace SIGNAL, Code 0x4
Terminating Process:   exc handler [98080]

Application Specific Information:
dyld2 mode

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libgambit.dylib                     0x000000010dfaf010
___SCMOBJ_to_NONNULLSTRING + 1520 (c_intf.c:3280)

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x00007fff924cfba8  rbx: 0x0000000000000001  rcx: 0x000000010e4bdf90 
rdx: 0x000000010e4bdca0
  rdi: 0x00007ffee1c853a8  rsi: 0x000000000000002f  rbp: 0x00007fdf00595ec0 
rsp: 0x00007ffee1c853a0
   r8: 0x0000000000000460   r9: 0x0000000000000466  r10: 0x00007fff924cfba9 
r11: 0x000000010dfab920
  r12: 0x0000000000000042  r13: 0x00007ffee1c853f8  r14: 0x000000010e4bdca0 
r15: 0x00000000000006d8
  rip: 0x000000010dfaf010  rfl: 0x0000000000010206  cr2: 0x000000010dfaea20

Logical CPU:     4
Error Code:      0x00000000
Trap Number:     12


Binary Images:
       0x10df75000 -        0x10df80ff7 +gsc (0)
<E4961F37-9789-36C1-A8A1-7E8652B8EC2C> /Users/USER/*/gsc
       0x10df9b000 -        0x10e21afff +libgambit.dylib (0)
<8B13D756-0995-39A9-A32E-6A42E6D0635A> /Users/USER/*/libgambit.dylib
       0x10e726000 -        0x10e9f1fff +libgambitgsc.dylib (0)
<C7AD4EB8-9648-346C-935B-44457DE073B5> /Users/USER/*/libgambitgsc.dylib
       0x10f027000 -        0x10f03efff +libgcc_s.1.dylib (1)
<8BF2E6A1-4FDE-3DAB-B58E-45A8624D3FA1>
/usr/local/gcc-10.3.0/lib/libgcc_s.1.dylib
       0x112a0b000 -        0x112a9cf47  dyld (750.6)
<326C6480-04F4-3164-A363-53079A148E2F> /usr/lib/dyld
    0x7fff68dc9000 -     0x7fff68dcafff  libSystem.B.dylib (1281.100.1)
<C49167AD-722B-3DF3-9031-7D6B59FC2A06> /usr/lib/libSystem.B.dylib
    0x7fff690af000 -     0x7fff69101fff  libc++.1.dylib (902.1)
<59A8239F-C28A-3B59-B8FA-11340DC85EDC> /usr/lib/libc++.1.dylib
    0x7fff69102000 -     0x7fff69117ffb  libc++abi.dylib (902)
<E692F14F-C65E-303B-9921-BB7E97D77855> /usr/lib/libc++abi.dylib
    0x7fff6ac29000 -     0x7fff6ac5cfde  libobjc.A.dylib (787.1)
<6DF81160-5E7F-3E31-AA1E-C875E3B98AF6> /usr/lib/libobjc.A.dylib
    0x7fff6bbc6000 -     0x7fff6bbcbff3  libcache.dylib (83)
<AF488D13-9E89-35E0-B078-BE37CC5B8586> /usr/lib/system/libcache.dylib
    0x7fff6bbcc000 -     0x7fff6bbd7fff  libcommonCrypto.dylib (60165.120.1)
<C7912BE5-993E-3581-B2A0-6AABDC8C5562> /usr/lib/system/libcommonCrypto.dylib
    0x7fff6bbd8000 -     0x7fff6bbdffff  libcompiler_rt.dylib (101.2)
<49B8F644-5705-3F16-BBE0-6FFF9B17C36E> /usr/lib/system/libcompiler_rt.dylib
    0x7fff6bbe0000 -     0x7fff6bbe9ff7  libcopyfile.dylib (166.40.1)
<3C481225-21E7-370A-A30E-0CCFDD64A92C> /usr/lib/system/libcopyfile.dylib
    0x7fff6bbea000 -     0x7fff6bc7cfdb  libcorecrypto.dylib (866.140.1)
<60567BF8-80FA-359A-B2F3-A3BAEFB288FD> /usr/lib/system/libcorecrypto.dylib
    0x7fff6bd89000 -     0x7fff6bdc9ff0  libdispatch.dylib (1173.100.2)
<CD9C059C-91D9-30E8-8926-5B9CD0D5D4F5> /usr/lib/system/libdispatch.dylib
    0x7fff6bdca000 -     0x7fff6be00fff  libdyld.dylib (750.6)
<789A18C2-8AC7-3C88-813D-CD674376585D> /usr/lib/system/libdyld.dylib
    0x7fff6be01000 -     0x7fff6be01ffb  libkeymgr.dylib (30)
<DB3337BE-01CA-3425-BD0C-87774FC0CDC0> /usr/lib/system/libkeymgr.dylib
    0x7fff6be0f000 -     0x7fff6be0fff7  liblaunch.dylib (1738.140.2)
<7200E214-9B4D-3B22-9844-4C7892FC890B> /usr/lib/system/liblaunch.dylib
    0x7fff6be10000 -     0x7fff6be15ff7  libmacho.dylib (959.0.1)
<AA613A9C-961A-3B67-B696-4622FA59FC4E> /usr/lib/system/libmacho.dylib
    0x7fff6be16000 -     0x7fff6be18ff3  libquarantine.dylib (110.40.3)
<F234E51D-FD0B-3EE4-B679-AE3EE9C536C3> /usr/lib/system/libquarantine.dylib
    0x7fff6be19000 -     0x7fff6be1aff7  libremovefile.dylib (48)
<7C7EFC79-BD24-33EF-B073-06AED234593E> /usr/lib/system/libremovefile.dylib
    0x7fff6be1b000 -     0x7fff6be32ff3  libsystem_asl.dylib (377.60.2)
<1563EE02-0657-3B78-99BE-A947C24122EF> /usr/lib/system/libsystem_asl.dylib
    0x7fff6be33000 -     0x7fff6be33ff7  libsystem_blocks.dylib (74)
<0D53847E-AF5F-3ACF-B51F-A15DEA4DEC58> /usr/lib/system/libsystem_blocks.dylib
    0x7fff6be34000 -     0x7fff6bebbfff  libsystem_c.dylib (1353.100.2)
<BBDED5E6-A646-3EED-B33A-91E4331EA063> /usr/lib/system/libsystem_c.dylib
    0x7fff6bebc000 -     0x7fff6bebfffb  libsystem_configuration.dylib
(1061.141.1) <0EE84C33-64FD-372B-974A-AF7A136F2068>
/usr/lib/system/libsystem_configuration.dylib
    0x7fff6bec0000 -     0x7fff6bec3fff  libsystem_coreservices.dylib (114)
<A199156E-058D-3ABB-BCE9-4B9F20DCED0F>
/usr/lib/system/libsystem_coreservices.dylib
    0x7fff6bec4000 -     0x7fff6beccfff  libsystem_darwin.dylib (1353.100.2)
<5B12B5DB-3F30-37C1-8ECC-49A66B1F2864> /usr/lib/system/libsystem_darwin.dylib
    0x7fff6becd000 -     0x7fff6bed4fff  libsystem_dnssd.dylib (1096.100.3)
<EBB4C2C2-E031-3094-B40A-E67BF261D295> /usr/lib/system/libsystem_dnssd.dylib
    0x7fff6bed5000 -     0x7fff6bed6ffb  libsystem_featureflags.dylib (17)
<29FD922A-EC2C-3F25-BCCC-B58D716E60EC>
/usr/lib/system/libsystem_featureflags.dylib
    0x7fff6bed7000 -     0x7fff6bf24ff7  libsystem_info.dylib (538)
<8A321605-5480-330B-AF9E-64E65DE61747> /usr/lib/system/libsystem_info.dylib
    0x7fff6bf25000 -     0x7fff6bf51ff7  libsystem_kernel.dylib (6153.141.16)
<05E98124-C845-374E-A323-8D6CFB60926F> /usr/lib/system/libsystem_kernel.dylib
    0x7fff6bf52000 -     0x7fff6bf99fff  libsystem_m.dylib (3178)
<00F331F1-0D09-39B3-8736-1FE90E64E903> /usr/lib/system/libsystem_m.dylib
    0x7fff6bf9a000 -     0x7fff6bfc1fff  libsystem_malloc.dylib (283.100.6)
<8549294E-4C53-36EB-99F3-584A7393D8D5> /usr/lib/system/libsystem_malloc.dylib
    0x7fff6bfc2000 -     0x7fff6bfcfffb  libsystem_networkextension.dylib
(1095.140.2) <F06C65C5-2CBE-313C-96E1-A09240F9FE57>
/usr/lib/system/libsystem_networkextension.dylib
    0x7fff6bfd0000 -     0x7fff6bfd9ff7  libsystem_notify.dylib (241.100.2)
<FA22F928-D91B-3AA5-96BB-3186AC0FB264> /usr/lib/system/libsystem_notify.dylib
    0x7fff6bfda000 -     0x7fff6bfe2fef  libsystem_platform.dylib (220.100.1)
<009A7C1F-313A-318E-B9F2-30F4C06FEA5C> /usr/lib/system/libsystem_platform.dylib
    0x7fff6bfe3000 -     0x7fff6bfedfff  libsystem_pthread.dylib (416.100.3)
<62CB1A98-0B8F-31E7-A02B-A1139927F61D> /usr/lib/system/libsystem_pthread.dylib
    0x7fff6bfee000 -     0x7fff6bff2ff3  libsystem_sandbox.dylib (1217.141.2)
<051C4018-4345-3034-AC98-6DE42FB8273B> /usr/lib/system/libsystem_sandbox.dylib
    0x7fff6bff3000 -     0x7fff6bff5fff  libsystem_secinit.dylib (62.100.2)
<F80872AA-E1FD-3D7E-8729-467656EC6561> /usr/lib/system/libsystem_secinit.dylib
    0x7fff6bff6000 -     0x7fff6bffdffb  libsystem_symptoms.dylib (1238.120.2)
<702D0910-5C34-3D43-9631-8BD215DE4FE1> /usr/lib/system/libsystem_symptoms.dylib
    0x7fff6bffe000 -     0x7fff6c014ff2  libsystem_trace.dylib (1147.120.1)
<BC141783-66D9-3137-A783-211B38E49ADB> /usr/lib/system/libsystem_trace.dylib
    0x7fff6c016000 -     0x7fff6c01bff7  libunwind.dylib (35.4)
<42B7B509-BAFE-365B-893A-72414C92F5BF> /usr/lib/system/libunwind.dylib
    0x7fff6c01c000 -     0x7fff6c051ffe  libxpc.dylib (1738.140.2)
<54EEF402-42C7-3995-BADE-93C48EFC4452> /usr/lib/system/libxpc.dylib

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 314754339
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=403.5M resident=0K(0%)
swapped_out_or_unallocated=403.5M(100%)
Writable regions: Total=201.4M written=0K(0%) resident=0K(0%)
swapped_out=0K(0%) unallocated=201.4M(100%)

                                VIRTUAL   REGION 
REGION TYPE                        SIZE    COUNT (non-coalesced) 
===========                     =======  ======= 
Kernel Alloc Once                    8K        1 
MALLOC                           137.1M       37 
Stack                             64.0M        2 
__DATA                            7316K       45 
__DATA_CONST                       196K        4 
__LINKEDIT                       393.5M      205 
__OBJC_RO                         32.3M       17 
__OBJC_RW                         1908K        2 
__TEXT                            10.1M       46 
shared memory                        8K        2 
===========                     =======  ======= 
TOTAL                            646.1M      361

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[lucier at math dot purdue.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #13 from lucier at math dot purdue.edu ---
(In reply to Iain Sandoe from comment #8)
> the values of rbp. r10 and esi would be interesting too.

I'm not really familiar with assembler, don't know what register esi is, here's
what lldb says:

(lldb) register read -a
General Purpose Registers:
       rax = 0x00007fff924cfba8  sGlobalMutex + 32
       rbx = 0x0000000000000001
       rcx = 0x000000010426ef90  libgambit.dylib`___gstate0 + 752
       rdx = 0x000000010426eca0  libgambit.dylib`___gstate0
       rdi = 0x00007ffeebed73d8
       rsi = 0x000000000000002f
       rbp = 0x00007fa600595ec0
       rsp = 0x00007ffeebed73d0
        r8 = 0x000000000000045c
        r9 = 0x0000000000000462
       r10 = 0x00007fff924cfba9  sGlobalMutex + 33
       r11 = 0x0000000103d5c920  libgambit.dylib`___UTF_8_put at c_intf.c:407:6
       r12 = 0x0000000000000042
       r13 = 0x00007ffeebed7428
       r14 = 0x000000010426eca0  libgambit.dylib`___gstate0
       r15 = 0x00000000000006d8
       rip = 0x0000000103d60010  libgambit.dylib`___SCMOBJ_to_NONNULLSTRING +
1520 at c_intf.c:3280:173
    rflags = 0x0000000000010206
        cs = 0x000000000000002b
        fs = 0x0000000000000000
        gs = 0x0000000000000000

Floating Point Registers:
       fcw = 0x0005
       fsw = 0x0000
       ftw = 0x83
       fop = 0x0000
        ip = 0x25ff5699
        cs = 0x8670
        dp = 0x0000027f
        ds = 0x0000
     mxcsr = 0x00000000
  mxcsrmask = 0x00000000
     stmm0 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xa0 0x1f}
     stmm1 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xff 0xff}
     stmm2 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
     stmm3 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
     stmm4 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
     stmm5 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
     stmm6 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xff 0xff}
     stmm7 = {0xc8 0x5f 0x59 0x02 0x00 0x00 0x00 0x00 0xff 0xff}
      xmm0 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
      xmm1 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
      xmm2 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
      xmm3 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
      xmm4 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
      xmm5 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
      xmm6 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
      xmm7 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
      xmm8 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
      xmm9 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
     xmm10 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
     xmm11 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
     xmm12 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
     xmm13 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
     xmm14 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
     xmm15 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}

Exception State Registers:
    trapno = 0x00000000
       err = 0x00000000
  faultvaddr = 0x0000000000000000

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[gabravier at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

Gabriel Ravier <gabravier at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gabravier at gmail dot com

--- Comment #14 from Gabriel Ravier <gabravier at gmail dot com> ---
(In reply to lucier from comment #13)
> (In reply to Iain Sandoe from comment #8)
> > the values of rbp. r10 and esi would be interesting too.
> 
> I'm not really familiar with assembler, don't know what register esi is
>
> [...]
> 
>        rsi = 0x000000000000002f

As a side note, if you want to know, esi is the lower 32 bits of rsi, which in
this case would be 0x2f (same as rsi since the upper 32 bits are 0s).

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #15 from Iain Sandoe <iains at gcc dot gnu.org> ---
I have to try and figure out a way to be able to reproduce the run-time error.

Yes, the assembler output is different between 10.2 and 10.3 - but that insn is
not apparently in error (and I checked that the assembler gives the same bit
pattern for it with GAS and LLVM - it would probably have been astonishing if
that was wrong... but)

Is there a usable work-around while we try to figure this out?
- what happens if you remove "-fschedule-insns2" ?

You mentioned that "the way the program is called is not simple, it's a
Scheme->C compiler building a "module", so it's hidden behind a number of
scripts." 

I assume it is not some kind of JIT?

FWIW, I don't believe that there were Darwin-specific changes to scheduling and
insn output between 10.2 and 10.3, although it is possible that some other
change exposed a latent problem, of course.

Do you know if this failure persists with a trunk or 11 branch compiler?
(sorry for all the questions, but since I can't actually reproduce the runtime
fail yet)

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[lucier at math dot purdue.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #16 from lucier at math dot purdue.edu ---
I have figured out how to build and then run the app in lldb to reliably
reproduce the error.

To configure and build Gambit, the Scheme->C compiler:

    51  8:56    mkdir gambit-test
    52  8:56    cd gambit-test
    53  8:56    git clone https://github.com/gambit/gambit.git
    54  8:57    cd gambit
    55  9:00    ./configure 'CC=/usr/local/gcc-10.3.0/bin/gcc -save-temps -g'
'--enable-single-host' '--enable-shared'
    56  9:01    make -j12

After a few minutes the "make -j12" should end with the message:

*** to compile the builtin modules you should: make modules

Then in the same directory I ran a command to just print the version number and
configuration information of Gambit; I ran the interpreter gsi instead of the
compiler gsc:

[Bradleys-Mac-mini:~/programs/gambit-test/gambit] lucier% lldb gsi/gsi
(lldb) target create "gsi/gsi"
Current executable set to '/Users/lucier/programs/gambit-test/gambit/gsi/gsi'
(x86_64).
(lldb) process launch -v DYLD_LIBRARY_PATH=./lib:./gsi:./gsc -- 
-:~~bin=./bin,~~lib=./lib,~~include=./include -v
Process 39231 launched: '/Users/lucier/programs/gambit-test/gambit/gsi/gsi'
(x86_64)
Process 39231 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION
(code=12, subcode=0x0)
    frame #0: 0x000000010012d010
libgambit.dylib`___SCMOBJ_to_NONNULLSTRING(obj=<unavailable>,
x=0x00007ffeefbfa6b8, arg_num=<unavailable>, char_encoding=<unavailable>,
fudge=<unavailable>) at c_intf.c:3280:173
   3277          p = r;
   3278  
   3279          for (i=0; i<n; i++)
-> 3280            ___UTF_8_put (&p, ___INT(___STRINGREF(obj,___FIX(i))));
   3281  
   3282          *p = 0;
   3283  
Target 0: (gsi) stopped.


This is my first time running lldb, so I'm a bit slow.

To your other questions: It's not JIT-generated code, and I'll work on building
a mainline compiler to test it, too.

Hope this helps.

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-04-21
             Status|UNCONFIRMED                 |NEW

--- Comment #17 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to lucier from comment #16)
> I have figured out how to build and then run the app in lldb to reliably
> reproduce the error.

> To configure and build Gambit, the Scheme->C compiler:
> 
>     51  8:56    mkdir gambit-test
>     52  8:56    cd gambit-test
>     53  8:56    git clone https://github.com/gambit/gambit.git

$ git log -1 --oneline
bb05af0a (HEAD -> master, origin/master, origin/HEAD) Fix missing return
address when using (declare (not optimize-dead-local-variables) (not
interrupts-enabled))

>     54  8:57    cd gambit
>     55  9:00    ./configure 'CC=/usr/local/gcc-10.3.0/bin/gcc -save-temps
> -g' '--enable-single-host' '--enable-shared'

> Hope this helps.

[so far on Darwin16 / macOS 10.12 ]

Yes it does -  can confirm that a 10.2 build works and 10.3 fails but the error
I get is different:

$ DYLD_LIBRARY_PATH=lib:gsi:gsc gsi/gsi
-:~~bin=./bin,~~lib=./lib,~~include=./include -v
Bus error: 10

lldb -- gsi/gsi -:~~bin=./bin,~~lib=./lib,~~include=./include -v
(lldb) env DYLD_LIBRARY_PATH=lib:gsi:gsc
(lldb) r

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=2, address=0x1000a88f0)
    frame #0: 0x00000001000a3475
libgambit.dylib`___release_rc(ptr=0x00000001000a8900) at mem.c:724
   721      {
   722        ___rc_header *h = ___CAST(___rc_header*,ptr) - 1;
   723  
-> 724        if (--h->refcount == 0)
   725          {
   726            ___rc_header *prev = h->prev;

I will try later on 10.15,

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[lucier at math dot purdue.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #18 from lucier at math dot purdue.edu ---
I can't see to build mainline on this machine, it fails with

../../../gcc-mainline/gcc/rtl.h:4547:42: error: use of undeclared identifier
'TARGET_ISA_64BIT'
      && GET_MODE_PRECISION (int_mode) < BITS_PER_WORD)
                                         ^
../../../gcc-mainline/gcc/defaults.h:485:40: note: expanded from macro
'BITS_PER_WORD'
#define BITS_PER_WORD (BITS_PER_UNIT * UNITS_PER_WORD)
                                       ^
../../../gcc-mainline/gcc/config/i386/i386.h:663:26: note: expanded from macro
'UNITS_PER_WORD'
#define UNITS_PER_WORD          (TARGET_64BIT ? 8 : 4)
                                 ^
../../../gcc-mainline/gcc/config/i386/darwin.h:29:22: note: expanded from macro
'TARGET_64BIT'
#define TARGET_64BIT TARGET_ISA_64BIT
<stuff omitted>
54 warnings and 1 error generated.
make[3]: *** [build/genpreds.o] Error 1
make[2]: *** [all-stage1-gcc] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2

This is with

[Bradleys-Mac-mini:~/programs/gcc/gcc-mainline] lucier% git log -1 --oneline
5445da1a94b (HEAD -> master, origin/trunk, origin/master, origin/HEAD)
[libstdc++] Add missing _M_try_acquire() to __platform_semaphore


and configuring with

    78  13:51   ../../gcc-mainline/configure --prefix=/usr/local/gcc-mainline
--enable-languages=c --disable-multilib
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk


and then make.

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #19 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to lucier from comment #18)
> I can't see to build mainline on this machine, it fails with
> 
> ../../../gcc-mainline/gcc/rtl.h:4547:42: error: use of undeclared identifier
> 'TARGET_ISA_64BIT'
>       && GET_MODE_PRECISION (int_mode) < BITS_PER_WORD)
>                                          ^
> ../../../gcc-mainline/gcc/defaults.h:485:40: note: expanded from macro
> 'BITS_PER_WORD'
> #define BITS_PER_WORD (BITS_PER_UNIT * UNITS_PER_WORD)
>                                        ^
> ../../../gcc-mainline/gcc/config/i386/i386.h:663:26: note: expanded from
> macro 'UNITS_PER_WORD'
> #define UNITS_PER_WORD          (TARGET_64BIT ? 8 : 4)
>                                  ^
> ../../../gcc-mainline/gcc/config/i386/darwin.h:29:22: note: expanded from
> macro 'TARGET_64BIT'
> #define TARGET_64BIT TARGET_ISA_64BIT
> <stuff omitted>
> 54 warnings and 1 error generated.
> make[3]: *** [build/genpreds.o] Error 1
> make[2]: *** [all-stage1-gcc] Error 2
> make[1]: *** [stage1-bubble] Error 2
> make: *** [all] Error 2

Yeah, there have been some patches pushed in early to GCC12 that have
destabilised things - I haven't tried to build master since Saturday (which was
OK).

11.1 branch should be OK.

in the meantime - let see see if I can figure out how to fix master :(

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #20 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #17)
> (In reply to lucier from comment #16)
> > I have figured out how to build and then run the app in lldb to reliably
> > reproduce the error.

> I will try later on 10.15,

... which does reproduce the fail as you describe.

- now it's interesting that different compilers fail in different places, and
different OS versions fail with different symptoms.

have to try an find a pattern to this.

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #21 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #19)
> (In reply to lucier from comment #18)
> > I can't see to build mainline on this machine, it fails with

> Yeah, there have been some patches pushed in early to GCC12 that have
> destabilised things - I haven't tried to build master since Saturday (which
> was OK).

master should be OK after r12-50-ga44895ce7ffbc26b4d765c40b5b346f8c9a9b762
let me know if you still see problems.

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #22 from Iain Sandoe <iains at gcc dot gnu.org> ---
so it looks like the contents of r10 are being trashed by the call to
___UTF_8_put (the first call goes through the dylib lazy symbol resolution and
that leaves r10 with a value pointing to some mutex).

When we return from ___UTF_8_put there's a test for the loop iteration which is
expecting that to be the value in r10.  The test is for equality which fails
for the silly value now in r10 and we try a second loop iteration.

That starts with the "movl   (%rbp,%r10,4), %esi" - but r10 now has a value
that can't be used.

So .... I don't know if this is a new problem or an old problem that has been
exposed by changes in the RA .. 

.. if there's any easy way to amend the build process to attempt modifications
of the build flags to that file - this could give you a work-around in the
short term.

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[lucier at math dot purdue.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #23 from lucier at math dot purdue.edu ---
With the mainline compiler

git log -1 --oneline
0c0bdcc60cf (HEAD -> master, origin/trunk, origin/master, origin/HEAD)
libgomp.fortran/depobj-1.f90: Fix omp_depend_kind

the Gambit build runs to completion, makes all modules, passes "make check" and
does what's expected in lldb:

lldb -- gsi/gsi -:~~bin=./bin,~~lib=./lib,~~include=./include -v
(lldb) target create "gsi/gsi"
Current executable set to '/Users/lucier/programs/gambit-test/gambit/gsi/gsi'
(x86_64).
(lldb) settings set -- target.run-args 
"-:~~bin=./bin,~~lib=./lib,~~include=./include" "-v"
(lldb) env DYLD_LIBRARY_PATH=lib:gsi:gsc
(lldb) r
Process 94836 launched: '/Users/lucier/programs/gambit-test/gambit/gsi/gsi'
(x86_64)
v4.9.3-1376-gbb05af0a 20210421130354 x86_64-apple-darwin19.6.0 "./configure
'CC=/usr/local/gcc-mainline/bin/gcc -save-temps -g' '--enable-single-host'
'--enable-shared'"
Process 94836 exited with status = 0 (0x00000000)

[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]

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.

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

[lucier at math dot purdue.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #25 from lucier at math dot purdue.edu ---
Thanks, I'll just use an older compiler for building Gambit.

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

[feeley at iro dot umontreal.ca]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

Marc Feeley <feeley at iro dot umontreal.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |feeley at iro dot umontreal.ca

--- Comment #26 from Marc Feeley <feeley at iro dot umontreal.ca> ---
Thanks for the thorough analysis and the time you have spent on this.  Please
send me a patch (or a PR on github) for the --enable-c-opt-rts configure option
as this may be of general utility.

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

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org
            Summary|[10.3, 11, 12 Regression]   |[10.3, 11, 12 Regression]
                   |[Darwin, X86] used          |used caller-saved register
                   |caller-saved register not   |not preserved across a
                   |preserved across a call.    |call.

--- Comment #27 from Iain Sandoe <iains at gcc dot gnu.org> ---
this is caused by, or exposed by,
r10-9246-geddcb627ccfbd97e025cf366cc3f3bad76211785

since that's a change in tree optimisation, the problem might not be confined
to Darwin, but I wasn't able to get the preprocessed source attached here to
produce wrong code on Linux.

For x86_64, the Darwin ABI is supposed to be same as Linux - and as noted,
there is not so much Darwin-specific back end code (but, of course, there is
some).

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

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #28 from Iain Sandoe <iains at gcc dot gnu.org> ---
reduced test case:
___UTF_8_put(char *a, int b) {
  char *c = a;
  int bytes;
  if (b <= 15)
    bytes = 2;
  else if (b <= 255)
    bytes = 4;
  else if (b <= 4095)
    bytes = 5;
  else
    bytes = 6;
  c = *a = c;
  switch (bytes) {
  case 6:
    *--c = b >>= 6;
  case 5:
    *--c = b;
    b >>= 6;
  }
  *c = bytes + b;
}

___SCMOBJ_to_NONNULLSTRING(d) {
  {
    unsigned long g, h;
    char c;
    h = ((long *)1)[1];
    g = 0;
    for (; g < h; g++)
      i();
    g = 0;
    for (; g < h; g++)
      ___UTF_8_put(c, (long)*((unsigned *)d + (g << 2 >> 2)) << 2 >> 2);
  }
}

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

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #29 from Iain Sandoe <iains at gcc dot gnu.org> ---
what is also somewhat peculiar is that replacing the first function in the
reduced test case with "extern void ___UTF_8_put(char *a, int b);" changes the
code-gen for the second function.

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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
            Summary|[10.3, 11, 12 Regression]   |[10/11/12 Regression] used
                   |used caller-saved register  |caller-saved register not
                   |not preserved across a      |preserved across a call.
                   |call.                       |
           Keywords|                            |ra

--- Comment #30 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #29)
> what is also somewhat peculiar is that replacing the first function in the
> reduced test case with "extern void ___UTF_8_put(char *a, int b);" changes
> the code-gen for the second function.

That might hint at IPA RA which you can try disabling via -fno-ipa-ra which
in turn hints at a target issue.  I'm seeing whether a cross reproduces the
issue on your reduced testcase.

Btw, the GIMPLE optimization change just exposes the issue - it can have no
influence on the used registers.

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

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #31 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #30)
> (In reply to Iain Sandoe from comment #29)
> > what is also somewhat peculiar is that replacing the first function in the
> > reduced test case with "extern void ___UTF_8_put(char *a, int b);" changes
> > the code-gen for the second function.
> 
> That might hint at IPA RA which you can try disabling via -fno-ipa-ra which
> in turn hints at a target issue.  

yeah, it does switch back to using rbx, at least on the reduced test case.

> Btw, the GIMPLE optimization change just exposes the issue - it can have no
> influence on the used registers.

indeed, it seemed more likely to be "exposed by".

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

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #32 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #31)
> (In reply to Richard Biener from comment #30)
> > (In reply to Iain Sandoe from comment #29)
> > > what is also somewhat peculiar is that replacing the first function in the
> > > reduced test case with "extern void ___UTF_8_put(char *a, int b);" changes
> > > the code-gen for the second function.
> > 
> > That might hint at IPA RA which you can try disabling via -fno-ipa-ra which
> > in turn hints at a target issue.  
> 
> yeah, it does switch back to using rbx, at least on the reduced test case.

(also on the original).

I wonder if the problem is that IPA can't "see" the lazy symbol resolver, so it
just sees a call to ___UTF_8_put and doesn't know that this will be resolved
indirectly.

.. but something similar must apply to PLT and targets with linker veneers ?

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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vmakarov at gcc dot gnu.org

--- Comment #33 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #32)
> (In reply to Iain Sandoe from comment #31)
> > (In reply to Richard Biener from comment #30)
> > > (In reply to Iain Sandoe from comment #29)
> > > > what is also somewhat peculiar is that replacing the first function in the
> > > > reduced test case with "extern void ___UTF_8_put(char *a, int b);" changes
> > > > the code-gen for the second function.
> > > 
> > > That might hint at IPA RA which you can try disabling via -fno-ipa-ra which
> > > in turn hints at a target issue.  
> > 
> > yeah, it does switch back to using rbx, at least on the reduced test case.
> 
> (also on the original).
> 
> I wonder if the problem is that IPA can't "see" the lazy symbol resolver, so
> it just sees a call to ___UTF_8_put and doesn't know that this will be
> resolved indirectly.
> 
> .. but something similar must apply to PLT and targets with linker veneers ?

I don't know how IPA RA works in detail but obviously the target has to
expose this detail.  It looks like IPA RA causes us to add some notes to
call insns which are supposed to describe those details and there's
collect_fn_hard_reg_usage which looks at the target function (but likely
does not include the ABI details of the call itself, in this case the
resolver).

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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #34 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #33)
> (In reply to Iain Sandoe from comment #32)
> > (In reply to Iain Sandoe from comment #31)
> > > (In reply to Richard Biener from comment #30)
> > > > (In reply to Iain Sandoe from comment #29)
> > > > > what is also somewhat peculiar is that replacing the first function in the
> > > > > reduced test case with "extern void ___UTF_8_put(char *a, int b);" changes
> > > > > the code-gen for the second function.
> > > > 
> > > > That might hint at IPA RA which you can try disabling via -fno-ipa-ra which
> > > > in turn hints at a target issue.  
> > > 
> > > yeah, it does switch back to using rbx, at least on the reduced test case.
> > 
> > (also on the original).
> > 
> > I wonder if the problem is that IPA can't "see" the lazy symbol resolver, so
> > it just sees a call to ___UTF_8_put and doesn't know that this will be
> > resolved indirectly.
> > 
> > .. but something similar must apply to PLT and targets with linker veneers ?
> 
> I don't know how IPA RA works in detail but obviously the target has to
> expose this detail.  It looks like IPA RA causes us to add some notes to
> call insns which are supposed to describe those details and there's
> collect_fn_hard_reg_usage which looks at the target function (but likely
> does not include the ABI details of the call itself, in this case the
> resolver).

@deftypevr {Target Hook} bool TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS
Set to true if each call that binds to a local definition explicitly
clobbers or sets all non-fixed registers modified by performing the call.
That is, by the call pattern itself, or by code that might be inserted by the
linker (e.g.@: stubs, veneers, branch islands), but not including those
modifiable by the callee.  The affected registers may be mentioned explicitly
in the call pattern, or included as clobbers in CALL_INSN_FUNCTION_USAGE.
The default version of this hook is set to false.  The purpose of this hook
is to enable the fipa-ra optimization.
@end deftypevr

might be relevant - though when compiling for a shared library the call
to ___UTF_8_put does not bind locally (but then IPA RA shouldn't apply
either I guess).  So, does ___UTF_8_put bind locally?

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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #35 from Richard Biener <rguenth at gcc dot gnu.org> ---
Which means another possible candidate for the "bug" is darwin_binds_local_p

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

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #36 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #35)
> Which means another possible candidate for the "bug" is darwin_binds_local_p

yeah... see below.

> > > .. but something similar must apply to PLT and targets with linker veneers ?
> > 
> > I don't know how IPA RA works in detail but obviously the target has to
> > expose this detail.  It looks like IPA RA causes us to add some notes to
> > call insns which are supposed to describe those details and there's
> > collect_fn_hard_reg_usage which looks at the target function (but likely
> > does not include the ABI details of the call itself, in this case the
> > resolver).


> @deftypevr {Target Hook} bool TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS
> Set to true if each call that binds to a local definition explicitly
> clobbers or sets all non-fixed registers modified by performing the call.
> That is, by the call pattern itself, or by code that might be inserted by the
> linker (e.g.@: stubs, veneers, branch islands), but not including those
> modifiable by the callee.  The affected registers may be mentioned explicitly
> in the call pattern, or included as clobbers in CALL_INSN_FUNCTION_USAGE.
> The default version of this hook is set to false.  The purpose of this hook
> is to enable the fipa-ra optimization.
> @end deftypevr

thanks for the pointer, I'll take a look at that when i have some cycles.
I guess it was never added at the time the IPA stuff was done... and somehow we
"got away with it" mostly.

> might be relevant - though when compiling for a shared library the call
> to ___UTF_8_put does not bind locally (but then IPA RA shouldn't apply
> either I guess).  So, does ___UTF_8_put bind locally?

extern void ___UTF_8_put
   (char* *ptr, unsigned int c)

If it does, then that's also a bug :), will have to check (sometime later).

(we are always building with fPIC for x86_64, snd don't specifically identify
that the result will be a shlib [all Darwin exes are DSOs too] -  although
Linux does identify shlibs as something special).

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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #37 from Richard Biener <rguenth at gcc dot gnu.org> ---
Oh, and FYI a cc1 cross from x86_64 to x86_64-apple-darwin19.6.0 doesn't seem
to reproduce the issue with the reduced testcase (I seee no call to
___UTF_8_put remaining with -O3 -fPIC -fno-strict-aliasing -fwrapv).

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

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #38 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #37)
> Oh, and FYI a cc1 cross from x86_64 to x86_64-apple-darwin19.6.0 doesn't seem
> to reproduce the issue with the reduced testcase (I seee no call to
> ___UTF_8_put remaining with -O3 -fPIC -fno-strict-aliasing -fwrapv).

I think my interestingness test isn't strict enough - the creduced code
resulting doesn't have an extern for ___UTF_8_put and only seems to not inline
that fn because the interface has been mangled. [ so that the fn is
legitimately binds_localP as the pasted case ].

if you still have the build around, out of curiosity, does it fail on the
original .i file attached here?

and with -fno-trapping-math -fno-math-errno -fschedule-insns2
-fomit-frame-pointer

( I only need O2 to get a fail ).

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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #39 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #38)
> (In reply to Richard Biener from comment #37)
> > Oh, and FYI a cc1 cross from x86_64 to x86_64-apple-darwin19.6.0 doesn't seem
> > to reproduce the issue with the reduced testcase (I seee no call to
> > ___UTF_8_put remaining with -O3 -fPIC -fno-strict-aliasing -fwrapv).
> 
> I think my interestingness test isn't strict enough - the creduced code
> resulting doesn't have an extern for ___UTF_8_put and only seems to not
> inline that fn because the interface has been mangled. [ so that the fn is
> legitimately binds_localP as the pasted case ].
> 
> if you still have the build around, out of curiosity, does it fail on the
> original .i file attached here?
> 
> and with -fno-trapping-math -fno-math-errno -fschedule-insns2
> -fomit-frame-pointer
> 
> ( I only need O2 to get a fail ).

Yes, with -O2 -fno-trapping-math -fno-math-errno -fschedule-insns2
-fomit-frame-pointer it produces the problematical

        .align 4,0x90
L945:
        movl    0(%rbp,%r10,4), %esi
        call    ____UTF_8_put
        movq    %r10, %rax
        addq    $1, %r10
        cmpq    %rax, %r12
        jne     L945

code.  But then ___UTF_8_put isn't interposable so I wonder why the linker
even has to resolve anything.  Adding -fPIC OTOH should definitely make the
symbol interposable but the same code is still generated ...

Note the 'extern' declaration shouldn't change anything, only that we
see a definition is relevant.

breaking on darwin_binds_local_p I see ___UTF_8_put is considered binding
local even with -fPIC.  So GCC thinks there will be no linker stub involved.

Note 'shlib' is passed as false to default_binds_local_p_3 computed as

3140         on earlier system versions, and with a TODO to complete.  */
3141      bool force_overridable = TARGET_KEXTABI && DARWIN_VTABLE_P (decl);
3142      return default_binds_local_p_3 (decl, force_overridable /* shlib */,
3143                                      false /* weak dominate */,

and default_binds_local_p_3 would do

  /* If PIC, then assume that any global name can be overridden by
     symbols resolved from other modules.  */
  if (shlib)
    return false;

ix86_binds_local_p simply passes flag_shlib != 0 as this argument.

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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #40 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #39)
> (In reply to Iain Sandoe from comment #38)
> > (In reply to Richard Biener from comment #37)
> > > Oh, and FYI a cc1 cross from x86_64 to x86_64-apple-darwin19.6.0 doesn't seem
> > > to reproduce the issue with the reduced testcase (I seee no call to
> > > ___UTF_8_put remaining with -O3 -fPIC -fno-strict-aliasing -fwrapv).
> > 
> > I think my interestingness test isn't strict enough - the creduced code
> > resulting doesn't have an extern for ___UTF_8_put and only seems to not
> > inline that fn because the interface has been mangled. [ so that the fn is
> > legitimately binds_localP as the pasted case ].
> > 
> > if you still have the build around, out of curiosity, does it fail on the
> > original .i file attached here?
> > 
> > and with -fno-trapping-math -fno-math-errno -fschedule-insns2
> > -fomit-frame-pointer
> > 
> > ( I only need O2 to get a fail ).
> 
> Yes, with -O2 -fno-trapping-math -fno-math-errno -fschedule-insns2
> -fomit-frame-pointer it produces the problematical
> 
>         .align 4,0x90
> L945:
>         movl    0(%rbp,%r10,4), %esi
>         call    ____UTF_8_put
>         movq    %r10, %rax
>         addq    $1, %r10
>         cmpq    %rax, %r12
>         jne     L945
> 
> code.  But then ___UTF_8_put isn't interposable so I wonder why the linker
> even has to resolve anything.  Adding -fPIC OTOH should definitely make the
> symbol interposable but the same code is still generated ...
> 
> Note the 'extern' declaration shouldn't change anything, only that we
> see a definition is relevant.
> 
> breaking on darwin_binds_local_p I see ___UTF_8_put is considered binding
> local even with -fPIC.  So GCC thinks there will be no linker stub involved.
> 
> Note 'shlib' is passed as false to default_binds_local_p_3 computed as
> 
> 3140         on earlier system versions, and with a TODO to complete.  */
> 3141      bool force_overridable = TARGET_KEXTABI && DARWIN_VTABLE_P (decl);
> 3142      return default_binds_local_p_3 (decl, force_overridable /* shlib
> */,
> 3143                                      false /* weak dominate */,
> 
> and default_binds_local_p_3 would do
> 
>   /* If PIC, then assume that any global name can be overridden by
>      symbols resolved from other modules.  */
>   if (shlib)
>     return false;
> 
> ix86_binds_local_p simply passes flag_shlib != 0 as this argument.

So it looks like darwin should pass

  flag_shlib != 0 || force_overridable

instead?

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

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #41 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #40)
> (In reply to Richard Biener from comment #39)
> > (In reply to Iain Sandoe from comment #38)
> > > (In reply to Richard Biener from comment #37)
> > > > Oh, and FYI a cc1 cross from x86_64 to x86_64-apple-darwin19.6.0 doesn't seem
> > > > to reproduce the issue with the reduced testcase (I seee no call to
> > > > ___UTF_8_put remaining with -O3 -fPIC -fno-strict-aliasing -fwrapv).

> > code.  But then ___UTF_8_put isn't interposable so I wonder why the linker
> > even has to resolve anything.  Adding -fPIC OTOH should definitely make the
> > symbol interposable but the same code is still generated ...

Darwin x86_64 is always PIC (fPIC is a NOP, and is added if no other PIC mode
is given).

user-mode code is invalid without it.

> > breaking on darwin_binds_local_p I see ___UTF_8_put is considered binding
> > local even with -fPIC.  So GCC thinks there will be no linker stub involved.

which is the immediate bug here...

>   flag_shlib != 0 || force_overridable

I want to check on the indirection rules to be sure [they are not exactly the
same as Linux]  (and that flag_shlib is set appropriately).

The other possible bug might be irrelevant (missing information to IPA about
the lazy resolver) - but I still need to think about the various cases.

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

[iains at gcc dot 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 Milestone|10.4                        |8.5

--- Comment #42 from Iain Sandoe <iains at gcc dot gnu.org> ---
actually, it seems clear that this case was just exposing a latent problem and
the fix is needed on all open branches (and by distros if they care about it on
older branches).

Adjusting the target milestone.

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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #43 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>:

https://gcc.gnu.org/g:b6600392bf71c4a9785f8f49948b611425896830

commit r12-103-gb6600392bf71c4a9785f8f49948b611425896830
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Sat Apr 24 13:34:49 2021 +0100

    Darwin : Adjust darwin_binds_local_p for PIC code [PR100152].

    Darwin's dynamic linker supports interposition and lazy symbol binding.
    If we are generating PIC code and a symbol is public, then it could
    potentially be indirected via a lazy-resolver stub; we cannot tell at
    compile-time if this will be done (since the indirection can be the
    result of adding a -flat-namespace option at link-time).  Here we are
    conservative and assume that any such symbol cannot bind locally.
    The default implementation for binds_local_p handles undefined, weak and
    common symbols which are always indirected (for mdynamic-no-pic also).

    gcc/ChangeLog:

            PR target/100152
            * config/darwin.c (darwin_binds_local_p): Assume that any
            public symbol might be interposed for PIC code. Update function
            header comment to reflect current Darwin capability.

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

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #44 from Iain Sandoe <iains at gcc dot gnu.org> ---
unfortunately, wider testing showed sanitiser fails - so this has been reverted
for now.

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

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #45 from Iain Sandoe <iains at gcc dot gnu.org> ---
the i386 backend code already sets : 

TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS to  true unconditionally.

So, it seems that it might be necessary to find some way to adjust
CALL_INSN_FUNCTION_USAGE.

because...

===

Simply setting an override to PIC or (PIC && !PIE) results
  * in a large number of testsuite regressions
  * and doesn't seem to match the behaviour of the system compiler (a.k.a.
clang).

Noting that x86_64 Darwin is _always_ PIC.

clang does not discriminate between PIC and PIE code in the compiler, the
driver maps both to -mrelocation-model pic 2 (and that's the default anyway).

The static linker does act upon PIE - to the extent that it defaults to PIE for
executables, although that can be overridden with -Wl,-no_pie (which we use to
allow PCH to work in GCC).

====

it seems [from looking at clang's output ] that we want this to be the
behaviour in a dylib:

.. foo () { ... }

.. bar () { ... foo () ... }

When we have a sufficient optimisation level to allow inlining - then we want
foo to be inlined into bar (for the default case of PIC).

When the static linker acts - it will make both foo and bar available publicly
- and an external caller to those will use lazy symbol resolution.

If foo is not suitable for inlining then the call to it from bar() will be
indirected through the lazy symbol binder if the dylib is built with
-flat_namespace, (which was the case in the gambit scenario here, I think).

====

I suppose the argument is that if we call a specific implementation of bar(),
we expect the complete implementation (including *that* library's version of
foo() and not some mixture of that and some interposed one) and therefore it's
logical to allow the inlining.

If one wants to guarantee that foo can be interposed [including in any case
like bar()], then either one needs to build -fno-inline or mark foo as
__attribute__((__noinline__)) [or weak]

TBH this seems quite fragile to me - but OTOH people interposing libraries
better know what they are doing - going to ask the Apple ABI folks to confirm
my hypothesis.

=====

Anyway .. we can't fix the problem quickly by applying PIC && !PIE - because
that is too big a hammer for Darwin.

I think what will be needed is to append r10 and r11 to the Call clobbered
registers .. but I've not figured out exactly where to do this yet.  [ setting
CALL_INSN_FUNCTION_USAGE somewhere, or so ]

It doesn't seem that i386 has this problem (but needs double-checking).

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

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #46 from Iain Sandoe <iains at gcc dot gnu.org> ---
Created attachment 50737
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50737&action=edit
trial patch for testing

looking at the way other ports handle things like use of registers in veneers
etc. it seems that adding to clobbers in the call lowering is a usable
mechanism.  This patch does seem the DTRT on gcc-10.3 when tested against the
original code (although the patch is against master).

Otherwise, this is as yet untested ..

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

[lucier at math dot purdue.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #47 from lucier at math dot purdue.edu ---
I downloaded

[Bradleys-Mac-mini:~/programs/gcc/gcc-mainline] lucier% git log -1 --oneline
2254b3233b5 (HEAD -> master, origin/trunk, origin/master, origin/HEAD) PR
middle-end/100325 - missing warning with -O0 on sprintf overflow with pointer
plus offset

configured with

 ../../gcc-mainline/configure --prefix=/usr/local/gcc-mainline
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

and "make; make -k check". I then applied the patch, configured, "make; make -k
check" and the make check always stops with

<stuff removed>
Running
/Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp
...
WARNING: program timed out.

Sorry, I don't know what's going on.

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

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #48 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to lucier from comment #47)
> I downloaded

> [Bradleys-Mac-mini:~/programs/gcc/gcc-mainline] lucier% git log -1 --oneline
> 2254b3233b5 (HEAD -> master, origin/trunk, origin/master, origin/HEAD) PR
> middle-end/100325 - missing warning with -O0 on sprintf overflow with
> pointer plus offset
> 
> configured with
> 
>  ../../gcc-mainline/configure --prefix=/usr/local/gcc-mainline
> --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
> 
> and "make; make -k check". 

Which, presumably, succeeded [repeatably?] (also presumably with some failing
tests, since we don't have a clean testsuite on macOS).

I then applied the patch, configured, "make; make
> -k check" and the make check always stops with
> 
> <stuff removed>
> Running
> /Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/testsuite/libstdc++-dg/
> conformance.exp ...
> WARNING: program timed out.

There's not quite enough information here - it would be useful to know which
test(s) timed out - running "make check -jN -k" (where N is some sensible
number for the cores on your machine) would help since that will then print
which tests timeout.

> Sorry, I don't know what's going on.

The proposed patch is experimental - I haven't had an opportunity to test it
across the range of platforms - it might be incomplete or incorrect.

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

[lucier at math dot purdue.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #49 from lucier at math dot purdue.edu ---

> > and "make; make -k check". 
> 
> Which, presumably, succeeded [repeatably?] (also presumably with some
> failing tests, since we don't have a clean testsuite on macOS).

It gave reasonable results, the summary is here

https://gcc.gnu.org/pipermail/gcc-testresults/2021-May/691571.html

> 
> I then applied the patch, configured, "make; make
> > -k check" and the make check always stops with
> > 
> > <stuff removed>
> > Running
> > /Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/testsuite/libstdc++-dg/
> > conformance.exp ...
> > WARNING: program timed out.
> 
> There's not quite enough information here - it would be useful to know which
> test(s) timed out - running "make check -jN -k" (where N is some sensible
> number for the cores on your machine) would help since that will then print
> which tests timeout.

I had previously tried "make -j20 -k check" and "make -j30 -k check", which
both gave the same "WARNING: program timed out." message, but where, precisely,
it timed out I couldn't tell.  That's why I did it serially, let it run for a
few days, and that's the last thing that printed, immediately after

Running
/Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp
...


> 
> > Sorry, I don't know what's going on.
> 
> The proposed patch is experimental - I haven't had an opportunity to test it
> across the range of platforms - it might be incomplete or incorrect.

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

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #50 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to lucier from comment #49)

> > > Running
> > > /Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/testsuite/libstdc++-dg/
> > > conformance.exp ...
> > > WARNING: program timed out.
> > 
> > There's not quite enough information here - it would be useful to know which
> > test(s) timed out - running "make check -jN -k" (where N is some sensible
> > number for the cores on your machine) would help since that will then print
> > which tests timeout.
> 
> I had previously tried "make -j20 -k check" and "make -j30 -k check", which
> both gave the same "WARNING: program timed out." message, but where,
> precisely, it timed out I couldn't tell.  That's why I did it serially, let
> it run for a few days, and that's the last thing that printed, immediately
> after
> 
> Running
> /Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/testsuite/libstdc++-dg/
> conformance.exp ...

hmm, there was a modification made to the testsuite output that relates
timeouts to the test that failed.  However there are buggy versions of expect
on some darwin versions, which might well defeat that.  I have a patched
version of expect which I use in conjunction with dejagnu 1.6.2 and
tcl-8.6(.9).

If you look at x86_64-apple-darwin19/libstdc++/testsuite/libstdc++.log, then
perhaps you can see the last test that was run in the serialised case.

FWIW I see some timeout fails with unpatched master on x86_64-darwin19 (on two
systems, one with corei5 and one with xeon w) - threads/barrier and randomly
threads/latch.  There are some known limitations with the implementations there
that are planned to be addressed in GCC12.

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

[lucier at math dot purdue.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #51 from lucier at math dot purdue.edu ---
I'm running fink:

 i      expect  5.45-206        Tool for automatic interactive applications
 i      dejagnu 1.6.1-1 Framework for testing other programs
 i      tcltk   1:8.6.10-2      Tool Command Language and the Tk toolkit

If you suggest they upgrade, I'll pass along the suggestion.

The end of x86_64-apple-darwin19/libstdc++/testsuite/libstdc++.log is

spawn -ignore SIGHUP /Users/lucier/programs/gcc/objdirs/gcc-test/./gcc/xg++
-shared-libgcc -B/Users/lucier/programs/gcc/objdirs/gcc-test/./gcc -nostdinc++
-L/Users/lucier/programs/gcc/objdirs/gcc-test/x86_64-apple-darwin19.6.0/libstdc++-v3/src
-L/Users/lucier/programs/gcc/objdirs/gcc-test/x86_64-apple-darwin19.6.0/libstdc++-v3/src/.libs
-L/Users/lucier/programs/gcc/objdirs/gcc-test/x86_64-apple-darwin19.6.0/libstdc++-v3/libsupc++/.libs
-B/usr/local/gcc-mainline/x86_64-apple-darwin19.6.0/bin/
-B/usr/local/gcc-mainline/x86_64-apple-darwin19.6.0/lib/ -isystem
/usr/local/gcc-mainline/x86_64-apple-darwin19.6.0/include -isystem
/usr/local/gcc-mainline/x86_64-apple-darwin19.6.0/sys-include -fchecking=1
-B/Users/lucier/programs/gcc/objdirs/gcc-test/x86_64-apple-darwin19.6.0/./libstdc++-v3/src/.libs
-fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2
-DLOCALEDIR="." -nostdinc++
-I/Users/lucier/programs/gcc/objdirs/gcc-test/x86_64-apple-darwin19.6.0/libstdc++-v3/include/x86_64-apple-darwin19.6.0
-I/Users/lucier/programs/gcc/objdirs/gcc-test/x86_64-apple-darwin19.6.0/libstdc++-v3/include
-I/Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/libsupc++
-I/Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/include/backward
-I/Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/testsuite/util
/Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/testsuite/29_atomics/atomic_integral/wait_notify.cc
-std=gnu++2a -pthread -fdiagnostics-plain-output ./libtestc++.a -liconv
-L/Users/lucier/programs/gcc/objdirs/gcc-test/x86_64-apple-darwin19.6.0/libstdc++-v3/src/filesystem/.libs
-lm -o ./wait_notify.exe^M
PASS: 29_atomics/atomic_integral/wait_notify.cc (test for excess errors)
Setting LD_LIBRARY_PATH to
:/Users/lucier/programs/gcc/objdirs/gcc-test/gcc:/Users/lucier/programs/gcc/objdirs/gcc-test/x86_64-apple-darwin19.6.0/./libstdc++-v3/../libatomic/.libs:/Users/lucier/programs/gcc/objdirs/gcc-test/x86_64-apple-darwin19.6.0/./libstdc++-v3/../libgomp/.libs:/Users/lucier/programs/gcc/objdirs/gcc-test/x86_64-apple-darwin19.6.0/./libstdc++-v3/src/.libs::/Users/lucier/programs/gcc/objdirs/gcc-test/gcc:/Users/lucier/programs/gcc/objdirs/gcc-test/x86_64-apple-darwin19.6.0/./libstdc++-v3/../libatomic/.libs:/Users/lucier/programs/gcc/objdirs/gcc-test/x86_64-apple-darwin19.6.0/./libstdc++-v3/../libgomp/.libs:/Users/lucier/programs/gcc/objdirs/gcc-test/x86_64-apple-darwin19.6.0/./libstdc++-v3/src/.libs
Execution timeout is: 300
spawn [open ...]^M
WARNING: program timed out.

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

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #52 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to lucier from comment #51)

> /Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/testsuite/29_atomics/
> atomic_integral/wait_notify.cc -std=gnu++2a -pthread
> -fdiagnostics-plain-output ./libtestc++.a -liconv
> -L/Users/lucier/programs/gcc/objdirs/gcc-test/x86_64-apple-darwin19.6.0/
> libstdc++-v3/src/filesystem/.libs -lm -o ./wait_notify.exe^M
> PASS: 29_atomics/atomic_integral/wait_notify.cc (test for excess errors)
> Setting LD_LIBRARY_PATH to

I do see this test timeout (randomly) on un-patched Darwin19 (at least on
corei7), however I will re-try and compare binaries with / without the 100152
proposed patch.

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

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #53 from Iain Sandoe <iains at gcc dot gnu.org> ---
on macOS 10.15 (Darwin19) with r12-637-g56103737 comparing unpatched / patched.

-WARNING: 29_atomics/atomic_float/wait_notify.cc execution test program timed
out.
-FAIL: 29_atomics/atomic_float/wait_notify.cc execution test
+PASS: 29_atomics/atomic_float/wait_notify.cc execution test

i.e. the test failed before the patch and passed after.
the "29_atomics/atomic_integral/wait_notify.cc" did not fail in either case for
my test.

So, this seems consistent with other observations (and the known fact that the
implementation for this part of the standard library needs some work for some
non-Linux platforms).

I didn't see any other change in test results for an all languages build
(including Ada).

--- 

However, a similar test needs to be carried out for all Darwin versions
supported and also some builds of larger projects using the compiler.

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

[lucier at math dot purdue.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #54 from lucier at math dot purdue.edu ---
After an update to Fink's dejagnu, I got similar results.

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|8.5                         |10.4
                 CC|                            |jakub at gcc dot gnu.org

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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #55 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>:

https://gcc.gnu.org/g:41bd1b190358fce213f5add8396faf14a32d5c23

commit r12-2226-g41bd1b190358fce213f5add8396faf14a32d5c23
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Mon May 3 08:22:53 2021 +0100

    Darwin, X86: Adjust call clobbers to allow for lazy-binding [PR 100152].

    We allow public functions defined in a TU to bind locally for PIC
    code (the default) on 64bit Mach-O.

    If such functions are not inlined, we cannot tell at compile-time if
    they might be called via the lazy symbol resolver (this can depend on
    options given at link-time).  Therefore, we must assume that the lazy
    resolver could be used which clobbers R11 and R10.

    Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>

    gcc/ChangeLog:

            PR target/100152
            * config/i386/i386-expand.c (ix86_expand_call): If a call is
            to a non-local-binding, or local but to a public symbol, then
            assume that it might be indirected via the lazy symbol binder.
            Mark R10 and R10 as clobbered in that case.

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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #56 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Iain D Sandoe
<iains@gcc.gnu.org>:

https://gcc.gnu.org/g:383295aaada04b02b733ab6b9e069dfb020d47b3

commit r11-8784-g383295aaada04b02b733ab6b9e069dfb020d47b3
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Mon May 3 08:22:53 2021 +0100

    Darwin, X86: Adjust call clobbers to allow for lazy-binding [PR 100152].

    We allow public functions defined in a TU to bind locally for PIC
    code (the default) on 64bit Mach-O.

    If such functions are not inlined, we cannot tell at compile-time if
    they might be called via the lazy symbol resolver (this can depend on
    options given at link-time).  Therefore, we must assume that the lazy
    resolver could be used which clobbers R11 and R10.

    Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>

    gcc/ChangeLog:

            PR target/100152
            * config/i386/i386-expand.c (ix86_expand_call): If a call is
            to a non-local-binding, or local but to a public symbol, then
            assume that it might be indirected via the lazy symbol binder.
            Mark R10 and R10 as clobbered in that case.

    (cherry picked from commit 41bd1b190358fce213f5add8396faf14a32d5c23)

[Bug target/100152] [10 Regression] used caller-saved register not preserved across a call.

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[10/11/12 Regression] used  |[10 Regression] used
                   |caller-saved register not   |caller-saved register not
                   |preserved across a call.    |preserved across a call.

--- Comment #57 from Iain Sandoe <iains at gcc dot gnu.org> ---
so fixed on master (12) and for 11.2 so far.

Note the problem is present on closed branches too.

[Bug target/100152] [10 Regression] used caller-saved register not preserved across a call.

[lucier at math dot purdue.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #58 from lucier at math dot purdue.edu ---
Thanks.  Brad

[Bug target/100152] [10 Regression] used caller-saved register not preserved across a call.

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #59 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Iain D Sandoe
<iains@gcc.gnu.org>:

https://gcc.gnu.org/g:b6a762bf4645d495ea2218dbabcebd0c15eb60fc

commit r10-10797-gb6a762bf4645d495ea2218dbabcebd0c15eb60fc
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Mon May 3 08:22:53 2021 +0100

    Darwin, X86: Adjust call clobbers to allow for lazy-binding [PR 100152].

    We allow public functions defined in a TU to bind locally for PIC
    code (the default) on 64bit Mach-O.

    If such functions are not inlined, we cannot tell at compile-time if
    they might be called via the lazy symbol resolver (this can depend on
    options given at link-time).  Therefore, we must assume that the lazy
    resolver could be used which clobbers R11 and R10.

    Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>

    gcc/ChangeLog:

            PR target/100152
            * config/i386/i386-expand.c (ix86_expand_call): If a call is
            to a non-local-binding, or local but to a public symbol, then
            assume that it might be indirected via the lazy symbol binder.
            Mark R10 and R10 as clobbered in that case.

    (cherry picked from commit 41bd1b190358fce213f5add8396faf14a32d5c23)

[Bug target/100152] [10 Regression] used caller-saved register not preserved across a call.

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #60 from Iain Sandoe <iains at gcc dot gnu.org> ---
fixed on open branches (likely the fault is latent on earlier branches, despite
the 'known to work' reports).