public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/100152] New: Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
@ 2021-04-20 13:48 lucier at math dot purdue.edu
2021-04-20 13:48 ` [Bug target/100152] " lucier at math dot purdue.edu
` (60 more replies)
0 siblings, 61 replies; 62+ messages in thread
From: lucier at math dot purdue.edu @ 2021-04-20 13:48 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
2021-04-20 13:48 [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
@ 2021-04-20 13:48 ` lucier at math dot purdue.edu
2021-04-20 13:50 ` lucier at math dot purdue.edu
` (59 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: lucier at math dot purdue.edu @ 2021-04-20 13:48 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
2021-04-20 13:48 [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
2021-04-20 13:48 ` [Bug target/100152] " lucier at math dot purdue.edu
@ 2021-04-20 13:50 ` lucier at math dot purdue.edu
2021-04-20 14:33 ` iains at gcc dot gnu.org
` (58 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: lucier at math dot purdue.edu @ 2021-04-20 13:50 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
2021-04-20 13:48 [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
2021-04-20 13:48 ` [Bug target/100152] " lucier at math dot purdue.edu
2021-04-20 13:50 ` lucier at math dot purdue.edu
@ 2021-04-20 14:33 ` iains at gcc dot gnu.org
2021-04-20 14:36 ` iains at gcc dot gnu.org
` (57 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-04-20 14:33 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
2021-04-20 13:48 [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
` (2 preceding siblings ...)
2021-04-20 14:33 ` iains at gcc dot gnu.org
@ 2021-04-20 14:36 ` iains at gcc dot gnu.org
2021-04-20 14:40 ` lucier at math dot purdue.edu
` (56 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-04-20 14:36 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
2021-04-20 13:48 [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
` (3 preceding siblings ...)
2021-04-20 14:36 ` iains at gcc dot gnu.org
@ 2021-04-20 14:40 ` lucier at math dot purdue.edu
2021-04-20 14:43 ` iains at gcc dot gnu.org
` (55 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: lucier at math dot purdue.edu @ 2021-04-20 14:40 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
2021-04-20 13:48 [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
` (4 preceding siblings ...)
2021-04-20 14:40 ` lucier at math dot purdue.edu
@ 2021-04-20 14:43 ` iains at gcc dot gnu.org
2021-04-20 14:58 ` lucier at math dot purdue.edu
` (54 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-04-20 14:43 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
2021-04-20 13:48 [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
` (5 preceding siblings ...)
2021-04-20 14:43 ` iains at gcc dot gnu.org
@ 2021-04-20 14:58 ` lucier at math dot purdue.edu
2021-04-20 15:02 ` iains at gcc dot gnu.org
` (53 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: lucier at math dot purdue.edu @ 2021-04-20 14:58 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
2021-04-20 13:48 [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
` (6 preceding siblings ...)
2021-04-20 14:58 ` lucier at math dot purdue.edu
@ 2021-04-20 15:02 ` iains at gcc dot gnu.org
2021-04-20 15:09 ` lucier at math dot purdue.edu
` (52 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-04-20 15:02 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
2021-04-20 13:48 [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
` (7 preceding siblings ...)
2021-04-20 15:02 ` iains at gcc dot gnu.org
@ 2021-04-20 15:09 ` lucier at math dot purdue.edu
2021-04-20 15:13 ` lucier at math dot purdue.edu
` (51 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: lucier at math dot purdue.edu @ 2021-04-20 15:09 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
2021-04-20 13:48 [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
` (8 preceding siblings ...)
2021-04-20 15:09 ` lucier at math dot purdue.edu
@ 2021-04-20 15:13 ` lucier at math dot purdue.edu
2021-04-20 15:17 ` iains at gcc dot gnu.org
` (50 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: lucier at math dot purdue.edu @ 2021-04-20 15:13 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
2021-04-20 13:48 [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
` (9 preceding siblings ...)
2021-04-20 15:13 ` lucier at math dot purdue.edu
@ 2021-04-20 15:17 ` iains at gcc dot gnu.org
2021-04-20 15:24 ` lucier at math dot purdue.edu
` (49 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-04-20 15:17 UTC (permalink / raw)
To: gcc-bugs
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)?
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
2021-04-20 13:48 [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
` (10 preceding siblings ...)
2021-04-20 15:17 ` iains at gcc dot gnu.org
@ 2021-04-20 15:24 ` lucier at math dot purdue.edu
2021-04-20 17:22 ` lucier at math dot purdue.edu
` (48 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: lucier at math dot purdue.edu @ 2021-04-20 15:24 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
2021-04-20 13:48 [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
` (11 preceding siblings ...)
2021-04-20 15:24 ` lucier at math dot purdue.edu
@ 2021-04-20 17:22 ` lucier at math dot purdue.edu
2021-04-21 4:27 ` gabravier at gmail dot com
` (47 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: lucier at math dot purdue.edu @ 2021-04-20 17:22 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
2021-04-20 13:48 [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
` (12 preceding siblings ...)
2021-04-20 17:22 ` lucier at math dot purdue.edu
@ 2021-04-21 4:27 ` gabravier at gmail dot com
2021-04-21 8:52 ` iains at gcc dot gnu.org
` (46 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: gabravier at gmail dot com @ 2021-04-21 4:27 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
2021-04-20 13:48 [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
` (13 preceding siblings ...)
2021-04-21 4:27 ` gabravier at gmail dot com
@ 2021-04-21 8:52 ` iains at gcc dot gnu.org
2021-04-21 13:17 ` lucier at math dot purdue.edu
` (45 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-04-21 8:52 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
2021-04-20 13:48 [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
` (14 preceding siblings ...)
2021-04-21 8:52 ` iains at gcc dot gnu.org
@ 2021-04-21 13:17 ` lucier at math dot purdue.edu
2021-04-21 15:32 ` iains at gcc dot gnu.org
` (44 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: lucier at math dot purdue.edu @ 2021-04-21 13:17 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
2021-04-20 13:48 [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
` (15 preceding siblings ...)
2021-04-21 13:17 ` lucier at math dot purdue.edu
@ 2021-04-21 15:32 ` iains at gcc dot gnu.org
2021-04-21 18:12 ` lucier at math dot purdue.edu
` (43 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-04-21 15:32 UTC (permalink / raw)
To: gcc-bugs
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,
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
2021-04-20 13:48 [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
` (16 preceding siblings ...)
2021-04-21 15:32 ` iains at gcc dot gnu.org
@ 2021-04-21 18:12 ` lucier at math dot purdue.edu
2021-04-21 18:18 ` iains at gcc dot gnu.org
` (42 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: lucier at math dot purdue.edu @ 2021-04-21 18:12 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
2021-04-20 13:48 [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
` (17 preceding siblings ...)
2021-04-21 18:12 ` lucier at math dot purdue.edu
@ 2021-04-21 18:18 ` iains at gcc dot gnu.org
2021-04-21 18:29 ` iains at gcc dot gnu.org
` (41 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-04-21 18:18 UTC (permalink / raw)
To: gcc-bugs
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 :(
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
2021-04-20 13:48 [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
` (18 preceding siblings ...)
2021-04-21 18:18 ` iains at gcc dot gnu.org
@ 2021-04-21 18:29 ` iains at gcc dot gnu.org
2021-04-21 20:00 ` iains at gcc dot gnu.org
` (40 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-04-21 18:29 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
2021-04-20 13:48 [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
` (19 preceding siblings ...)
2021-04-21 18:29 ` iains at gcc dot gnu.org
@ 2021-04-21 20:00 ` iains at gcc dot gnu.org
2021-04-21 20:38 ` iains at gcc dot gnu.org
` (39 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-04-21 20:00 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
2021-04-20 13:48 [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
` (20 preceding siblings ...)
2021-04-21 20:00 ` iains at gcc dot gnu.org
@ 2021-04-21 20:38 ` iains at gcc dot gnu.org
2021-04-21 23:24 ` lucier at math dot purdue.edu
` (38 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-04-21 20:38 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
2021-04-20 13:48 [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
` (21 preceding siblings ...)
2021-04-21 20:38 ` iains at gcc dot gnu.org
@ 2021-04-21 23:24 ` lucier at math dot purdue.edu
2021-04-22 10:28 ` [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
` (37 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: lucier at math dot purdue.edu @ 2021-04-21 23:24 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10.3, 11, 12 Regression] [Darwin, X86] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (22 preceding siblings ...)
2021-04-21 23:24 ` lucier at math dot purdue.edu
@ 2021-04-22 10:28 ` iains at gcc dot gnu.org
2021-04-22 12:54 ` lucier at math dot purdue.edu
` (36 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-04-22 10:28 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10.3, 11, 12 Regression] [Darwin, X86] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (23 preceding siblings ...)
2021-04-22 10:28 ` [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
@ 2021-04-22 12:54 ` lucier at math dot purdue.edu
2021-04-22 14:35 ` feeley at iro dot umontreal.ca
` (35 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: lucier at math dot purdue.edu @ 2021-04-22 12:54 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10.3, 11, 12 Regression] [Darwin, X86] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (24 preceding siblings ...)
2021-04-22 12:54 ` lucier at math dot purdue.edu
@ 2021-04-22 14:35 ` feeley at iro dot umontreal.ca
2021-04-22 23:13 ` [Bug target/100152] [10.3, 11, 12 Regression] " iains at gcc dot gnu.org
` (34 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: feeley at iro dot umontreal.ca @ 2021-04-22 14:35 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10.3, 11, 12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (25 preceding siblings ...)
2021-04-22 14:35 ` feeley at iro dot umontreal.ca
@ 2021-04-22 23:13 ` iains at gcc dot gnu.org
2021-04-23 0:32 ` iains at gcc dot gnu.org
` (33 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-04-22 23:13 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10.3, 11, 12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (26 preceding siblings ...)
2021-04-22 23:13 ` [Bug target/100152] [10.3, 11, 12 Regression] " iains at gcc dot gnu.org
@ 2021-04-23 0:32 ` iains at gcc dot gnu.org
2021-04-23 6:51 ` iains at gcc dot gnu.org
` (32 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-04-23 0:32 UTC (permalink / raw)
To: gcc-bugs
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);
}
}
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10.3, 11, 12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (27 preceding siblings ...)
2021-04-23 0:32 ` iains at gcc dot gnu.org
@ 2021-04-23 6:51 ` iains at gcc dot gnu.org
2021-04-23 8:13 ` [Bug target/100152] [10/11/12 " rguenth at gcc dot gnu.org
` (31 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-04-23 6:51 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (28 preceding siblings ...)
2021-04-23 6:51 ` iains at gcc dot gnu.org
@ 2021-04-23 8:13 ` rguenth at gcc dot gnu.org
2021-04-23 8:32 ` iains at gcc dot gnu.org
` (30 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-04-23 8:13 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (29 preceding siblings ...)
2021-04-23 8:13 ` [Bug target/100152] [10/11/12 " rguenth at gcc dot gnu.org
@ 2021-04-23 8:32 ` iains at gcc dot gnu.org
2021-04-23 8:48 ` iains at gcc dot gnu.org
` (29 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-04-23 8:32 UTC (permalink / raw)
To: gcc-bugs
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".
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (30 preceding siblings ...)
2021-04-23 8:32 ` iains at gcc dot gnu.org
@ 2021-04-23 8:48 ` iains at gcc dot gnu.org
2021-04-23 8:54 ` rguenth at gcc dot gnu.org
` (28 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-04-23 8:48 UTC (permalink / raw)
To: gcc-bugs
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 ?
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (31 preceding siblings ...)
2021-04-23 8:48 ` iains at gcc dot gnu.org
@ 2021-04-23 8:54 ` rguenth at gcc dot gnu.org
2021-04-23 8:58 ` rguenth at gcc dot gnu.org
` (27 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-04-23 8:54 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (32 preceding siblings ...)
2021-04-23 8:54 ` rguenth at gcc dot gnu.org
@ 2021-04-23 8:58 ` rguenth at gcc dot gnu.org
2021-04-23 9:05 ` rguenth at gcc dot gnu.org
` (26 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-04-23 8:58 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (33 preceding siblings ...)
2021-04-23 8:58 ` rguenth at gcc dot gnu.org
@ 2021-04-23 9:05 ` rguenth at gcc dot gnu.org
2021-04-23 9:09 ` iains at gcc dot gnu.org
` (25 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-04-23 9:05 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (34 preceding siblings ...)
2021-04-23 9:05 ` rguenth at gcc dot gnu.org
@ 2021-04-23 9:09 ` iains at gcc dot gnu.org
2021-04-23 11:02 ` rguenth at gcc dot gnu.org
` (24 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-04-23 9:09 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (35 preceding siblings ...)
2021-04-23 9:09 ` iains at gcc dot gnu.org
@ 2021-04-23 11:02 ` rguenth at gcc dot gnu.org
2021-04-23 12:34 ` iains at gcc dot gnu.org
` (23 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-04-23 11:02 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (36 preceding siblings ...)
2021-04-23 11:02 ` rguenth at gcc dot gnu.org
@ 2021-04-23 12:34 ` iains at gcc dot gnu.org
2021-04-23 12:57 ` rguenth at gcc dot gnu.org
` (22 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-04-23 12:34 UTC (permalink / raw)
To: gcc-bugs
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 ).
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (37 preceding siblings ...)
2021-04-23 12:34 ` iains at gcc dot gnu.org
@ 2021-04-23 12:57 ` rguenth at gcc dot gnu.org
2021-04-23 12:58 ` rguenth at gcc dot gnu.org
` (21 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-04-23 12:57 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (38 preceding siblings ...)
2021-04-23 12:57 ` rguenth at gcc dot gnu.org
@ 2021-04-23 12:58 ` rguenth at gcc dot gnu.org
2021-04-23 13:13 ` iains at gcc dot gnu.org
` (20 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-04-23 12:58 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (39 preceding siblings ...)
2021-04-23 12:58 ` rguenth at gcc dot gnu.org
@ 2021-04-23 13:13 ` iains at gcc dot gnu.org
2021-04-24 12:41 ` iains at gcc dot gnu.org
` (19 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-04-23 13:13 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (40 preceding siblings ...)
2021-04-23 13:13 ` iains at gcc dot gnu.org
@ 2021-04-24 12:41 ` iains at gcc dot gnu.org
2021-04-24 12:45 ` cvs-commit at gcc dot gnu.org
` (18 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-04-24 12:41 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (41 preceding siblings ...)
2021-04-24 12:41 ` iains at gcc dot gnu.org
@ 2021-04-24 12:45 ` cvs-commit at gcc dot gnu.org
2021-04-24 18:45 ` iains at gcc dot gnu.org
` (17 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-04-24 12:45 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (42 preceding siblings ...)
2021-04-24 12:45 ` cvs-commit at gcc dot gnu.org
@ 2021-04-24 18:45 ` iains at gcc dot gnu.org
2021-05-02 15:36 ` iains at gcc dot gnu.org
` (16 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-04-24 18:45 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (43 preceding siblings ...)
2021-04-24 18:45 ` iains at gcc dot gnu.org
@ 2021-05-02 15:36 ` iains at gcc dot gnu.org
2021-05-03 7:54 ` iains at gcc dot gnu.org
` (15 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-05-02 15:36 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (44 preceding siblings ...)
2021-05-02 15:36 ` iains at gcc dot gnu.org
@ 2021-05-03 7:54 ` iains at gcc dot gnu.org
2021-05-09 1:57 ` lucier at math dot purdue.edu
` (14 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-05-03 7:54 UTC (permalink / raw)
To: gcc-bugs
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 ..
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (45 preceding siblings ...)
2021-05-03 7:54 ` iains at gcc dot gnu.org
@ 2021-05-09 1:57 ` lucier at math dot purdue.edu
2021-05-09 7:25 ` iains at gcc dot gnu.org
` (13 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: lucier at math dot purdue.edu @ 2021-05-09 1:57 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (46 preceding siblings ...)
2021-05-09 1:57 ` lucier at math dot purdue.edu
@ 2021-05-09 7:25 ` iains at gcc dot gnu.org
2021-05-09 15:43 ` lucier at math dot purdue.edu
` (12 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-05-09 7:25 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (47 preceding siblings ...)
2021-05-09 7:25 ` iains at gcc dot gnu.org
@ 2021-05-09 15:43 ` lucier at math dot purdue.edu
2021-05-09 19:22 ` iains at gcc dot gnu.org
` (11 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: lucier at math dot purdue.edu @ 2021-05-09 15:43 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (48 preceding siblings ...)
2021-05-09 15:43 ` lucier at math dot purdue.edu
@ 2021-05-09 19:22 ` iains at gcc dot gnu.org
2021-05-09 20:00 ` lucier at math dot purdue.edu
` (10 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-05-09 19:22 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (49 preceding siblings ...)
2021-05-09 19:22 ` iains at gcc dot gnu.org
@ 2021-05-09 20:00 ` lucier at math dot purdue.edu
2021-05-09 22:36 ` iains at gcc dot gnu.org
` (9 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: lucier at math dot purdue.edu @ 2021-05-09 20:00 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (50 preceding siblings ...)
2021-05-09 20:00 ` lucier at math dot purdue.edu
@ 2021-05-09 22:36 ` iains at gcc dot gnu.org
2021-05-11 7:48 ` iains at gcc dot gnu.org
` (8 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-05-09 22:36 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (51 preceding siblings ...)
2021-05-09 22:36 ` iains at gcc dot gnu.org
@ 2021-05-11 7:48 ` iains at gcc dot gnu.org
2021-05-13 3:35 ` lucier at math dot purdue.edu
` (7 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-05-11 7:48 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (52 preceding siblings ...)
2021-05-11 7:48 ` iains at gcc dot gnu.org
@ 2021-05-13 3:35 ` lucier at math dot purdue.edu
2021-05-14 14:04 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: lucier at math dot purdue.edu @ 2021-05-13 3:35 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (53 preceding siblings ...)
2021-05-13 3:35 ` lucier at math dot purdue.edu
@ 2021-05-14 14:04 ` jakub at gcc dot gnu.org
2021-07-09 16:42 ` cvs-commit at gcc dot gnu.org
` (5 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-05-14 14:04 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (54 preceding siblings ...)
2021-05-14 14:04 ` jakub at gcc dot gnu.org
@ 2021-07-09 16:42 ` cvs-commit at gcc dot gnu.org
2021-07-20 6:52 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-07-09 16:42 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (55 preceding siblings ...)
2021-07-09 16:42 ` cvs-commit at gcc dot gnu.org
@ 2021-07-20 6:52 ` cvs-commit at gcc dot gnu.org
2021-07-20 7:00 ` [Bug target/100152] [10 " iains at gcc dot gnu.org
` (3 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-07-20 6:52 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (56 preceding siblings ...)
2021-07-20 6:52 ` cvs-commit at gcc dot gnu.org
@ 2021-07-20 7:00 ` iains at gcc dot gnu.org
2021-07-22 15:21 ` lucier at math dot purdue.edu
` (2 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2021-07-20 7:00 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (57 preceding siblings ...)
2021-07-20 7:00 ` [Bug target/100152] [10 " iains at gcc dot gnu.org
@ 2021-07-22 15:21 ` lucier at math dot purdue.edu
2022-05-29 19:13 ` cvs-commit at gcc dot gnu.org
2022-05-29 19:25 ` iains at gcc dot gnu.org
60 siblings, 0 replies; 62+ messages in thread
From: lucier at math dot purdue.edu @ 2021-07-22 15:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #58 from lucier at math dot purdue.edu ---
Thanks. Brad
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (58 preceding siblings ...)
2021-07-22 15:21 ` lucier at math dot purdue.edu
@ 2022-05-29 19:13 ` cvs-commit at gcc dot gnu.org
2022-05-29 19:25 ` iains at gcc dot gnu.org
60 siblings, 0 replies; 62+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-05-29 19:13 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 62+ messages in thread
* [Bug target/100152] [10 Regression] used caller-saved register not preserved across a call.
2021-04-20 13:48 [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
` (59 preceding siblings ...)
2022-05-29 19:13 ` cvs-commit at gcc dot gnu.org
@ 2022-05-29 19:25 ` iains at gcc dot gnu.org
60 siblings, 0 replies; 62+ messages in thread
From: iains at gcc dot gnu.org @ 2022-05-29 19:25 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 62+ messages in thread
end of thread, other threads:[~2022-05-29 19:25 UTC | newest]
Thread overview: 62+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-20 13:48 [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
2021-04-20 13:48 ` [Bug target/100152] " lucier at math dot purdue.edu
2021-04-20 13:50 ` lucier at math dot purdue.edu
2021-04-20 14:33 ` iains at gcc dot gnu.org
2021-04-20 14:36 ` iains at gcc dot gnu.org
2021-04-20 14:40 ` lucier at math dot purdue.edu
2021-04-20 14:43 ` iains at gcc dot gnu.org
2021-04-20 14:58 ` lucier at math dot purdue.edu
2021-04-20 15:02 ` iains at gcc dot gnu.org
2021-04-20 15:09 ` lucier at math dot purdue.edu
2021-04-20 15:13 ` lucier at math dot purdue.edu
2021-04-20 15:17 ` iains at gcc dot gnu.org
2021-04-20 15:24 ` lucier at math dot purdue.edu
2021-04-20 17:22 ` lucier at math dot purdue.edu
2021-04-21 4:27 ` gabravier at gmail dot com
2021-04-21 8:52 ` iains at gcc dot gnu.org
2021-04-21 13:17 ` lucier at math dot purdue.edu
2021-04-21 15:32 ` iains at gcc dot gnu.org
2021-04-21 18:12 ` lucier at math dot purdue.edu
2021-04-21 18:18 ` iains at gcc dot gnu.org
2021-04-21 18:29 ` iains at gcc dot gnu.org
2021-04-21 20:00 ` iains at gcc dot gnu.org
2021-04-21 20:38 ` iains at gcc dot gnu.org
2021-04-21 23:24 ` lucier at math dot purdue.edu
2021-04-22 10:28 ` [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
2021-04-22 12:54 ` lucier at math dot purdue.edu
2021-04-22 14:35 ` feeley at iro dot umontreal.ca
2021-04-22 23:13 ` [Bug target/100152] [10.3, 11, 12 Regression] " iains at gcc dot gnu.org
2021-04-23 0:32 ` iains at gcc dot gnu.org
2021-04-23 6:51 ` iains at gcc dot gnu.org
2021-04-23 8:13 ` [Bug target/100152] [10/11/12 " rguenth at gcc dot gnu.org
2021-04-23 8:32 ` iains at gcc dot gnu.org
2021-04-23 8:48 ` iains at gcc dot gnu.org
2021-04-23 8:54 ` rguenth at gcc dot gnu.org
2021-04-23 8:58 ` rguenth at gcc dot gnu.org
2021-04-23 9:05 ` rguenth at gcc dot gnu.org
2021-04-23 9:09 ` iains at gcc dot gnu.org
2021-04-23 11:02 ` rguenth at gcc dot gnu.org
2021-04-23 12:34 ` iains at gcc dot gnu.org
2021-04-23 12:57 ` rguenth at gcc dot gnu.org
2021-04-23 12:58 ` rguenth at gcc dot gnu.org
2021-04-23 13:13 ` iains at gcc dot gnu.org
2021-04-24 12:41 ` iains at gcc dot gnu.org
2021-04-24 12:45 ` cvs-commit at gcc dot gnu.org
2021-04-24 18:45 ` iains at gcc dot gnu.org
2021-05-02 15:36 ` iains at gcc dot gnu.org
2021-05-03 7:54 ` iains at gcc dot gnu.org
2021-05-09 1:57 ` lucier at math dot purdue.edu
2021-05-09 7:25 ` iains at gcc dot gnu.org
2021-05-09 15:43 ` lucier at math dot purdue.edu
2021-05-09 19:22 ` iains at gcc dot gnu.org
2021-05-09 20:00 ` lucier at math dot purdue.edu
2021-05-09 22:36 ` iains at gcc dot gnu.org
2021-05-11 7:48 ` iains at gcc dot gnu.org
2021-05-13 3:35 ` lucier at math dot purdue.edu
2021-05-14 14:04 ` jakub at gcc dot gnu.org
2021-07-09 16:42 ` cvs-commit at gcc dot gnu.org
2021-07-20 6:52 ` cvs-commit at gcc dot gnu.org
2021-07-20 7:00 ` [Bug target/100152] [10 " iains at gcc dot gnu.org
2021-07-22 15:21 ` lucier at math dot purdue.edu
2022-05-29 19:13 ` cvs-commit at gcc dot gnu.org
2022-05-29 19:25 ` iains at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).