здесь происходит четыре вещи:

• gcc -O0 поведение объясняет разницу между двумя версиями. (А clang -O0 случается компилировать их обоих с idiv). И почему вы получаете это даже с операндами константы времени компиляции.
• x86 idiv поведение ошибки против поведения инструкции разделения на ARM

• если целочисленная математика приводит к доставке сигнала, POSIX требует, чтобы он был Сигнала sigfpe: на каких платформах целое число делится на ноль вызывает исключение с плавающей запятой? но POSIX не require trapping для любой конкретной целочисленной операции. (Вот почему разрешено, чтобы x86 и ARM были разными).

  Единственная Спецификация Unix определяет SIGFPE как "ошибочная арифметическая операция". Он путано назван в честь плавающей точки, но в нормальной системе с FPU в состоянии по умолчанию только целое число математика поднимет его. На x86, только целочисленное деление. В MIPS компилятор может использовать add вместо addu для подписанной математики, чтобы вы могли получить ловушки на подписанном add overflow. (gcc использует addu даже для подписанных, но детектор неопределенного поведения может использовать add.)

• C неопределенные правила поведения (подписанное переполнение и разделение в частности), которые позволяют gcc испускать код, который может ловить в этом случай.

gcc без опций-это то же самое, что gcc -O0.

-O0 Сократите время компиляции и сделать отладку производить ожидаемые результаты. Это значение по умолчанию.

это объясняет разницу между двумя версиями:

не только gcc -O0 Не пытайтесь оптимизировать, он активно де-оптимизирует сделать asm, который самостоятельно реализует каждый оператор C внутри функции. Это позволяет gdb ' s jump команда для безопасной работы, позволяя вам перейти к другой линии в функции и действовать так, как будто вы действительно прыгаете в источнике C.

он также не может ничего предполагать о значениях переменных между операторами, потому что вы можете изменять переменные с помощью set b = 4. Это, очевидно, катастрофически плохо для производительности, поэтому -O0 код работает в несколько раз медленнее, чем обычный код, и почему?--116-->оптимизация -O0 конкретно это полная чушь. Это также делает -O0 выход asm очень шумно и трудно для человека, чтобы прочитать, из-за всего хранения/перезагрузки и отсутствия даже самых очевидных оптимизаций.

int a = 0x80000000;
int b = -1;
  // debugger can stop here on a breakpoint and modify b.
int c = a / b;        // a and b have to be treated as runtime variables, not constants.
printf("%d\n", c);

я помещаю ваш код внутри функций на Godbolt компилятор обозреватель чтобы получить ASM для этих заявлений.

оценить a/b, gcc -O0 должен испустите код для перезагрузки a и b по памяти, и не делайте никаких предположений об их ценности.

но с int c = a / -1;, вы не можете изменить -1 С помощью отладчика, поэтому gcc может и реализует этот оператор так же, как он будет реализовывать int c = -a;, С x86 neg eax или AArch64 neg w0, w0 инструкция, окруженная грузом (a) / магазином(c). На ARM32 это rsb r3, r3, #0 (реверс-вычесть: r3 = 0 - r3).

однако, clang5.0 -O0 не оптимизации. Он по-прежнему использует idiv на a / -1, поэтому обе версии будут неисправны на x86 с clang. Почему gcc вообще "оптимизирует"? См.отключить все параметры оптимизации в GCC. gcc всегда преобразуется через внутреннее представление, а-O0 - это минимальный объем работы, необходимый для создания двоичного файла. У него нет "Тупого и буквального" режима, который пытается сделать asm как можно более похожим на источник.

x86 idiv и AArch64 sdiv:

x86-64:

    # int c = a / b  from x86_fault()
    mov     eax, DWORD PTR [rbp-4]
    cdq                                 # dividend sign-extended into edx:eax
    idiv    DWORD PTR [rbp-8]           # divisor from memory
    mov     DWORD PTR [rbp-12], eax     # store quotient

в отличие от imul r32,r32, нет 2-операнд idiv это не имеет дивидендов верхней половины ввода. Во всяком случае, это не имеет значения; gcc использует его только с edx = копии бита знака в eax, поэтому он действительно делает 32B / 32b => 32B фактор + остаток. как описано в руководстве Intel, idiv поднимает #DE на:

• делитель = 0
• в подписанный результат (фактор) слишком велик для назначения.

переполнение может легко произойти, если вы используете полный диапазон делителей, например,int result = long long / int с одиночным разделением 64b / 32b => 32b. Но gcc не может сделать эту оптимизацию, потому что не разрешено делать код, который будет неисправен, вместо того, чтобы следовать правилам продвижения c integer и делать 64-битное деление и затем усек к int. Это тоже не оптимизирует даже в случаях, когда известно, что делитель достаточно велик, чтобы он не мог #DE

при выполнении 32B / 32b деления (с cdq), единственный вход, который может переполниться, -INT_MIN / -1. "Правильным" фактором является 33-разрядное целое число со знаком, т. е. положительное 0x80000000 с битом знака ведущего нуля, чтобы сделать его положительным целым числом со знаком дополнения 2. Так как это не вписывается eax, idiv поднимает #DE исключения. Затем ядро доставляет SIGFPE.

AArch64:

    # int c = a / b  from x86_fault()  (which doesn't fault on AArch64)
    ldr     w1, [sp, 12]
    ldr     w0, [sp, 8]          # 32-bit loads into 32-bit registers
    sdiv    w0, w1, w0           # 32 / 32 => 32 bit signed division
    str     w0, [sp, 4]

AFAICT, инструкции аппаратного разделения ARM не вызывают исключений для деления на ноль или для INT_MIN/-1. Или, по крайней мере, некоторые процессоры ARM не делают. разделить на ноль исключение в ARM OMAP3515 процессор

AArch64 sdiv документация не упоминает никаких исключений.

однако программные реализации целочисленного деления могут поднять:http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka4061.html. (gcc использует вызов библиотеки для разделения на ARM32 по умолчанию, если вы не установите-mcpu, который имеет разделение HW.)

C Неопределенное Поведение.

As PSkocik объясняет, INT_MIN / -1 - неопределенное поведение в C, как и все переполнение целого числа со знаком. это позволяет компиляторам использовать инструкции аппаратного разделения на таких машинах, как x86 не проверяя на этот особый случай. если не ошибка, неизвестные входы потребуют сравнения времени выполнения и проверки ветвей, и никто не хочет, чтобы C требовал этого.

подробнее о последствиях UB:

с включенной оптимизацией, компилятор может предположить, что a и b все еще имеют свои установленные значения, когда a/b работает. Затем он может видеть, что программа имеет неопределенное поведение, и, таким образом, может сделать все, что он захочет. gcc выбирает производить INT_MIN хотелось бы от -INT_MIN.

в системе дополнения 2 самое отрицательное число является его собственным отрицательным. Это неприятный угловой случай для дополнения 2, потому что это означает abs(x) все еще может быть отрицательным. https://en.wikipedia.org/wiki/Two%27s_complement#Most_negative_number

int x86_fault() {
    int a = 0x80000000;
    int b = -1;
    int c = a / b;
    return c;
}

компилировать с gcc6.3 -O3 для x86-64

x86_fault:
    mov     eax, -2147483648
    ret

но clang5.0 -O3 компилируется (с без предупреждения, даже с-Wall -Wextra`):

x86_fault:
    ret

неопределенное поведение действительно совершенно неопределенно. Компиляторы могут делать все, что им нравится, включая возврат любого мусора в eax при вводе функции или загрузке нулевого указателя и незаконной инструкции. например, с gcc6.3-O3 для x86-64:

int *local_address(int a) {
    return &a;
}

local_address:
    xor     eax, eax     # return 0
    ret

void foo() {
    int *p = local_address(4);
    *p = 2;
}

 foo:
   mov     DWORD PTR ds:0, 0     # store immediate 0 into absolute address 0
   ud2                           # illegal instruction

ваш случай с -O0 не позволял компиляторам видеть UB во время компиляции, поэтому вы получили "ожидаемый" вывод asm.

Смотрите также Что Каждый Программист C Должен Знать О Неопределенном Поведении (то же сообщение в блоге LLVM, что и Basile).