compile ok yet ud2 op emitted in x64 assembly and codegen stopped

[Quuxplusone]

Bugzilla Link	PR33017
Status	NEW
Importance	P normal
Reported by	Joris Wu (joriswu@gmail.com)
Reported on	2017-05-12 00:52:26 -0700
Last modified on	2017-05-12 15:34:07 -0700
Version	4.0
Hardware	PC Linux
CC	dimitry@andric.com, llvm-bugs@lists.llvm.org
Fixed by commit(s)
Attachments	compound.s (724194 bytes, text/plain) compound.c (57007 bytes, text/plain)
Blocks
Blocked by
See also

Created attachment 18433
asm output

c11 source compiles without diags, yet executable halts at sigill. Asembly
output reveals an 'ud2' opcode halfway the code, and further code generation is
omitted.

This source file compiled ok with a previous 'trunk' version from 10 March 2017.
After changing the source, this error appeared.

Installed clang release 4.0, and the same error appears.

compiled as :
clang -S -O2 -march=native -Weverything -g -pthread -std=c11 compound.c

offending ud2 is at attached compound.s line 7362, corresponding to compound.c
line 757. From next line compound.c:758 onwards until end of loop is absent in
generated code.

[Quuxplusone]

Attached compound.s (724194 bytes, text/plain): asm output

[Quuxplusone]

Attached compound.c (57007 bytes, text/plain): c source

[Quuxplusone]

build machine :

Linux joris-Latitude-E6420 3.19.0-32-generic #37~14.04.1-Ubuntu SMP Thu Oct 22
09:41:40 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

cpu
vendor_id   : GenuineIntel
cpu family  : 6
model       : 42
model name  : Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
stepping    : 7
microcode   : 0x29

[Quuxplusone]

It's not possible to diagnose this without preprocessed source code, since many
definitions are missing from your test case.

If I would have to guess though, the code on line 758 and everything after it
might be optimized away because accessing hp->rid is undefined, or something
like that:

   752      for (hop = lohop; hop <= rp->hihop; hop++) {
   753        infocc(dbg,0,"hop %u",hop);
   754        infocc(dbg,0,"hop %u",hop);
   755        hp = hops + hop;
   756        chp1 = chops + hop;
   757        infocc(dbg,0,"hop %u",hop);
   758        if (hp->rid != rid) {
   759          infocc(dbg,0,"hop %u",hop);
   760        }

Note that the assembly does contain the code for line 757, which calls infofln
(probably a macro expansion of infocc):

.Ltmp736:
        .loc    2 757 7 discriminator 1 # compound.c:757:7
        movl    msgfile(%rip), %edi
        orl     $757, %edi              # imm = 0x2F5
        xorl    %esi, %esi
        movl    $.L.str.152, %edx
        xorl    %eax, %eax
        movl    %ebx, %ecx
        callq   infofln
.Ltmp737:
.LBB2_347:
        .loc    2 0 7 is_stmt 0 discriminator 1 # compound.c:0:7
        ud2

[Quuxplusone]

hp is indeed set to NULL explicitely earlier at line 659.

So not a compiler bug per se. However, the current behaviour without diagnostic makes troubleshooting harder, as a 'sigill' exception and 'ud2' opcode is hard to correlate to a nil ptr dereference.