Проблемы со смещением бит (<< >>)

Сообщение было отмечено Segaman как решение

Решение

Давай вкратце объясню, что тут произошло

-----

Как было раньше (несколько лет назад). У gcc есть (были) две опции -march и -mcpu. Опция -march задаёт, какую нужно использовать систему команд, т.е. задаёт набор допустимых инструкций, которыми вправе пользоваться компилятор. Опция -mcpu задаёт конкретную модель процессора, под которую надо подстраиваться, т.е. задаёт набор задержек между операциями, который должен выдерживать компилятор

Логика двух опций примерно такая. Допустим, есть семейство процессоров П, в котором по очереди были выпущены совместимые процессора П1, П2, П3, П4, П5. Каждый новый процессор обладал более широкой системой команд (т.е. более широкими возможностями). Но при этом каждый процессор имел свои точные задержки. Мы можем задать режим -march=П2 -mcpu=П4. Опция -march=П2 означает, что код будет использовать систему команд П2, т.е. итоговый код сможет работать на процессорах П2, П3, П4, П5, но не сможет работать на процессоре П1. Опция -mcpu=П4 означает, что следует использовать задержки, соответствующие процессору П4. В итоге полученный код будет работать на процессорах П2, П3, П4, П5, но при этом на процессоре П4 он будет работать наиболее эффективно, т.к. именно на этом процессоре все реальные задержки в коде и аппаратуре будут совпадать. На остальных процессорах могут возникать лишние холостые такты

Но в реальности в какой-то из ранних версий gcc они переименовали опции. В итоге нынешнее -march совпадает с тем, что написано выше. Но то, что в моём описании описано как -mcpu, в современных версиях теперь называется -mtune. Что теперь означает -mcpu, я не совсем понимаю

-----

Вернёмся в сегодняшний день

В твоём случае, судя по всему, компилятор по умолчанию работает в режиме -march=m68020 -mcpu=m68020 -mtune=m68020 (последнее нам не интересно, я его буду опускать). Когда ты просто подавал опцию -mc68000, то по описанию (ссылка в посте #4) она эквивалентна -march=m68000. Т.е. у тебя как бы включался режим -march=m68000 -mcpu=m68020. Далее там есть тонкий момент

-mcpu=cpu overrides -march=arch if arch is compatible with cpu

Похоже на то, что в твоём случае дефолтный режим -mcpu=68020 перебивает опцию командной строки -march=68000 и в итоге компилятор всё равно работает в системе команд 68020, но не 68000, как предполагалось бы, глядя на командную строку. Это и приводит к проблеме. Компилятор строит код 68020, который ломается при запуске на твоём процессоре 68000

Когда вместо одной опции -m68000 ты начал использовать две опции -march=m68000 -mcpu=m68000, то эфект перебития дефолтным режимом пропал и поведение компилятора начало соответствовать тому, что написано в командной строке

Однако опции -march/-mcpu/-mtune влияют только на процесс компиляции (на процесс построения кода). На процесс линковки они не должны влиять, т.к. во время линковки не рожается никаких кодов. Исключение составляет режим -flto, который приводит к тому, что во время линковки запускается компилятор для повторной перекомпиляции некоторых модулей. И здесь опции -march/-mcpu берутся из командной строки и подсовываются в компилятор. Собственно, поэтому для меня пост #14 является загадкой. Я не понимаю, как это могло исправить ситуацию. А в таких случаях очень часто возникает ситуация, когда сегодня работает, а завтра перестаёт работать, потому что в реальности случилось не исправление проблемы, а затычка

Опция -mno-bitfiled говорит о том, что из системы команд m68020 нельзя использовать какие-то отдельно взятые инструкции. Т.е. использовать кастрированную систему команд m68020. В твоём случае на конкретно твоей программе получилось так, что система команд m68020 за вычетом операций bitfiled привела к тому, что именно в твоём коде остались только операции m68000, а потому код перестал падать. Но если бы компилятор генерировал условную операцию venik, которая есть в m68020, но нет в m68000, то тебе опция -mno-bitfiled не помогла бы. Другими словами, опция -mno-bitfiled выполняла роль затычки в конкретном случае, но не выполняла роль исправления проблемы

1