0/0 in C - gcc-7 or higher - c

Question

Mathematically, 0 / 0 is undefined. But, in C programming (especially gcc compiler gcc-7.3.0 on ubuntu), it produces the answer as 1. I would like to know the reason. Is it working by repeated subtraction? For, the same code, if I use n = 1 / n, I get a floating point exception. However, for gcc-5.3.0, it produces an error.
#include <stdio.h>
int main() {
int n = 5;
n = n - 5;
switch (n) {
case 0:
printf("n= %d", n);
n = n / n;
printf("n calc= %d", n);
break;
case 5:
printf("n=5");
break;
default:
printf("n=1");
break;
}
return 0;
}

Answer 1

Divide by zero is undefined behavior in C programming (C11 6.5.5 §6). Meaning that there is no predictable result, there is no telling what your program might do.
It isn't very meaningful to try reason about why you get one particular outcome of "anything might happen". It might print 1, it might print 42, it might print nothing at all. The program might crash and burn. If you run the program twice, you might get different outcomes. And so on.
As for why you won't get a compiler error, the compiler isn't able or obliged to find or diagnose run-time errors. Most cases of undefined behavior need to be avoided by the programmer.
Some good compilers may be able to give warnings if you use pure integer constant expressions such as int x = 0/0;, but again it is not the job of the compiler to find this bug. It is the programmer's job. Therefore you should make a habit of always checking if the right operand of / or % is zero before applying the operands.

Answer 2

Compilers are allowed to assume that the code does not invoke undefined behavior, and use that assumption while optimizing the code.
For any value, other than n==0 the expression n/n evaluates as 1. Since diving by zero is undefined behavior in C, the compiler can assume that this scenario never happens, i.e., it can assume that n!=0.
Since it may assume that, the compiler can replace the slow n/n with the cheap constant value of 1. This is probably what happens with the code in question.
Of course, the compiler is not required to make any such assumption, and might generate an actual division. Depending on the hardware that executes the code, a specific hardware signal (or exception) might be triggered in such a case of division by zero. I doubt that any reasonable compiler will emit division in this example for optimized code, because division is extremely slow, and according to the standard the constant 1 is good enough. However, it is still likely it will produce an actual division in debug mode.
Similar things happen when optimizing away other undefined behavior, such as int overflow:
void f(int x)
{
if (x > x + 1)
// executed only in case of overflow,
// which is undefined behavior,
// and hence likely optimized out.
overflow_error();
...
Don't rely on undefined behavior - it is not predictable.

Answer 3

As can be seen on Godbolt's compiler explorer, both gcc and clang optimize n / n for n integer to evaluate to 1 without any warning. gcc performs this optimisation even at -O0 whereas clang generates the division opcode for -O0 but the optimized alternative for -O1 and above.
0 / 0 has undefined behavior anyway, therefore any behavior for n / n is OK if n is zero, including evaluating to 1 without an observable side-effect.
If you insist, you could qualify n as volatile and the compiler might generate a division, as both gcc and clang do in this case, but as long as n is read twice, it does not have to.