Need help debugging possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

Need help debugging possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[Lucier, Bradley J]

I’m seeing an “Illegal Instruction” fault and don’t quite know how to generate a proper bug report yet.

This is the 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) 

This is the crash report from the console:

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)

This is the disassembled code (arrow points to crash point):

(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 don’t know why that particular instruction is “Illegal”.

Can someone suggest a way forward?

Thanks.

Brad

Re: Need help debugging possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[Iain Sandoe]

Lucier, Bradley J via Gcc <gcc@gcc.gnu.org> wrote:

> I’m seeing an “Illegal Instruction” fault and don’t quite know how to  
> generate a proper bug report yet.
>
> This is the 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)

>
> Can someone suggest a way forward?

Please could you raise a PR (Bugzilla) -  
(https://gcc.gnu.org/bugzilla/enter_bug.cgi?product=gcc)
..  the information here is enough to start
   - but it would help to know what you were compiling when this occurred ..
  adding ‘-save-temps’ to the compile line and adding the .i file to the BZ can be helfpul.

.. I think this will take a little analysis (and isn’t something I've seen  
in testing on either i7 or xeon w hardware).

thanks
Iain

Re: Need help debugging possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[Gabriel Paubert]

On Tue, Apr 20, 2021 at 12:20:06PM +0000, Lucier, Bradley J via Gcc wrote:
> I’m seeing an “Illegal Instruction” fault and don’t quite know how to generate a proper bug report yet.
> 
> This is the 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) 
> 
> This is the crash report from the console:
> 
> 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)
> 
> This is the disassembled code (arrow points to crash point):
> 
> (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)

Does GCC ever generate this last instruction (a variable shift of a
byte in memory!)? Even the next to last (register to memory) is only
generated infrequently.

First thing to do would be to start the disassembly earlier, or even at
the beginning of the function, because I believe that the address you
gave is not an instruction boundary, and in this case the output of the
disassembler is nonsense until it resynchronizes on a real boundary.

	Regards,
	Gabriel


>     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 don’t know why that particular instruction is “Illegal”.
> 
> Can someone suggest a way forward?
> 
> Thanks.
> 
> Brad

Re: Need help debugging possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[Lucier, Bradley J]

On Apr 20, 2021, at 9:11 AM, Gabriel Paubert <paubert@iram.es<mailto:paubert@iram.es>> wrote:

(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)

Does GCC ever generate this last instruction (a variable shift of a
byte in memory!)? Even the next to last (register to memory) is only
generated infrequently.

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

You may be correct, but it appears that the “offending" instruction is

->  0x103d60010 <+1520>: movl   (%rbp,%r10,4), %esi

Brad