[Bug c++/110437] New: SIGILL when return missing in a C++ function with a condition

[jan.zizka at nokia dot com via Gcc-bugs]

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

            Bug ID: 110437
           Summary: SIGILL when return missing in a C++ function with a
                    condition
           Product: gcc
           Version: 13.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jan.zizka at nokia dot com
  Target Milestone: ---

Created attachment 55404
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55404&action=edit
Reproducer fails with g++

With gcc 13 following code triggers SIGILL:

#include<iostream>

int func1() {
        int value = 1;
        if (value == 1) {
                std::cout << "ONE" << std::endl;
        } else {
                std::cout << "ZERO" << std::endl;
        }
}

int main() {
        func1();
}

To reproduce:

g++ -o reproduce reproduce.cpp
./reproduce

Resulting with:

ONE
[1]    19714 illegal hardware instruction (core dumped)  ./reproduce

Warning is generated by compiler:

reproduce.cpp: In function ‘int func1()’:
reproduce.cpp:10:1: warning: no return statement in function returning non-void
[-Wreturn-type]
   10 | }
      | ^

With similar C code the SIGILL is not triggered:

#include<stdio.h>

int func1() {
        int value = 1;
        if (value == 1) {
                printf("ONE\n");
        } else {
                printf("ZERO\n");
        }
}

int main() {
        func1();
}

Warning is still generated with -Wall.

Is there some reason this behaves differently in C and C++? And shouldn't
rather compiler throw error instead of warning if this will crash in runtime?
We have caught this on some very old legacy code which just had missing return
statement and with upgrade to gcc 13.1.1 we have started to see SIGILL in
runtime.

Based on disassembled code the compiler emits ud2 instruction triggering
SIGILL.

With gcc 12.2 at least the same code doesn't trigger SIGILL. I didn't check the
disassembly.

I have run this on Fedora 38 and I didn't try to bisect which exact commit
triggers this. If it would be useful I can run bisect.