That's probably because the code in the article uses compile-time constants as operands. Try this one and pass "-1" as the command-line parameter:

  int main(int argc, char *argv[]) { return (1LL << 63) / atoi(argv[1]); }

Note that this issue has been written about before by Tavis Ormandy: http://my.opera.com/taviso/blog/show.dml/639454

Floating point exception: 8

Similarly, I tried the pgsql example on 8.4.13, although on FreeBSD rather than Windows like they suggest, and all I got was: ERROR: floating-point exception DETAIL: An invalid floating-point operation was signaled. This probably means an out-of-range result or an invalid operation, such as division by zero.

The example the article gives isn't a general C problem, it's a common bug in some (mostly older) C/C++ compilers. As you point out GCC does not have this bug.

It's not a bug, it's intended to be undefined behavior; see http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html... (issue 1450)

Regardless of undefined behavior, it should not crash the compiler.

Ah, I missed that it can crash the tcc compiler. Yeah, that's a bug.

Probably easy to miss. One really does not expect the compiler to crash on code like that.

Would you mind posting the output of gcc -S ?

Also, what optimization level did you run with?

No optimisation.

http://pastebin.com/NpUExgA2

Here's the LLVM code that clang-3.0-6ubuntu3 emits:

    define i64 @crash() nounwind uwtable readnone optsize {
      ret i64 undef
    }

In machine code terms, on x86-64 this turns into a function composed entirely of the ret opcode. gcc-4.6 adds an xor eax, eax before the ret.