c - Different results for idiv instruction -

take @ piece of code

int main(int argc) {     int = 1u << 31; // assume yields int_min     volatile int x;     x = -1;     x = / x; //dividing int_min -1 ub     return 0; } 

it invokes undefined behavior on typical platform, "behavior" quite different expect -- acts if infinite loop. can think of scene bites.

of course undefined undefined, have checked output assembly, using plain idiv -- why not trap? sake of comparison, divide 0 causes immediate abort.

using windows 7 64 bit , mingw64

can explain me?

edit

i found signature of main wrong, doesn't matter.

i tried few options, , results same.

here assembly:

    .file   "a.c"     .def    __main; .scl    2;  .type   32; .endef     .section    .text.startup,"x"     .p2align 4,,15     .globl  main     .def    main;   .scl    2;  .type   32; .endef     .seh_proc   main main:     subq    $56, %rsp     .seh_stackalloc 56     .seh_endprologue     call    __main     movl    $-1, 44(%rsp)     movl    $-2147483648, %eax     movl    44(%rsp), %ecx     cltd     idivl   %ecx     movl    %eax, 44(%rsp)     xorl    %eax, %eax     addq    $56, %rsp     ret     .seh_endproc     .ident  "gcc: (x86_64-posix-sjlj, built strawberryperl.com project) 4.8.2" 

the infinite loop observe arguably bug in mingw-w64.

mingw-w64 partially supports seh, , if run code in debugger, see exception handler (function named "_gnu_exception_handler") called result of invalid idiv. (for instance run program in gdb , set breakpoint on _gnu_exception_handler)

said simply, exception handler in case of integer overflow dismissing exception , continuing execution @ point exception occurred (idiv). idiv operation executed again, resulting in same overflow trigger same error handler, , cpu goes , forth between idiv , exception handler. (this behavior of mingw-w64 can seen bug.)

you can see directly in source here if want go deep.

the value "exception_continue_execution" returned _gnu_exception_handler when deals exception_int_overflow (integer overflow) fuels behavior (when system sees handler returned exception_continue_execution, jumps instruction generated exception , tries execute again.)

if interested in more details, here resources understand how seh works on windows.