Детская ошибка Опции

[amiller]

Недавно столкнулся с одной странностью (по крайней мере для меня). Хотелось бы понять.
Есть фрагмент года (упрощенный до безобразия):

CODE

int16u temp1, temp2;
for (int32u i = 0; i < 10; i++)
{
temp1 = 0x0001;
temp2 = 0xFFFE;
if (~temp1 != temp2) continue;
temp2 = temp1;
}

Так вот, в этом фрагменте условный оператор и код после него никогда не выполняется. В отладчике после выполнения операции "temp2 = 0xFFFE;" происходит сразу переход на начало цикла. Переменные объявлены как int16u (== unsigned short (16 бит беззнаковое))
При этом никаких предупреждений на этапе компиляции.
Если переменные объявить как int32u (== unsigned long (32 бита беззнаковое)), то условный оператор выполняется, но естественно результат всегда true.
И код работает как надо только в таком варианте:

CODE

int16u temp1, temp2;
for (int32u i = 0; i < 10; i++)
{
temp1 = 0x0001;
temp2 = 0xFFFE;
temp1 = ~temp1;
if (temp1 != temp2) continue;
temp2 = temp1;
}

В этом случае выполняются все операторы, входящие в тело цикла.
IAR C/C++ Compiler for ARM 7.40.3.8902 (7.40.3.8902)
Добавлю: Оптимизация отключена. Проект под микроконтроллер STM32F105VCT6

Сообщение отредактировал amiller - May 2 2016, 06:41

[AleksBak]

А если так:

Код

int16u temp1, temp2;
    for (int32u i = 0; i < 10; i++)
    {
        temp1 = 0x0001;
        temp2 = 0xFFFE;
        if ( (int16u)(~temp1) != temp2 ) continue;
        temp2 = temp1;
    }

[amiller]

А если так:

Код

int16u temp1, temp2;
    for (int32u i = 0; i < 10; i++)
    {
        temp1 = 0x0001;
        temp2 = 0xFFFE;
        if ( (int16u)(~temp1) != temp2 ) continue;
        temp2 = temp1;
    }

Так как Вы предлагаете, тоже работает. Хотя в этом меня тоже смущает один момент. После выполнения оператора "~" не должна меняться размерность переменной.
Но больше всего меня беспокоит результат компиляции первого моего примера. В ассемблерном коде вообще отсутствует условный оператор и всё, что после него.
И при этом никаких предупреждений от компилятора.
Как это можно рассматривать? Бага компилятора? Или есть более простое объяснение?

[scifi]

Но больше всего меня беспокоит результат компиляции первого моего примера. В ассемблерном коде вообще отсутствует условный оператор и всё, что после него.

Вы будете смеяться, но компилятор вовсе не обязан на каждый чих в исходнике генерить код. Обычно на минимальном уровне оптимизации генерит, но тоже не всегда и не везде. Компилятор отвечает только за то, что сгенерированный код выдаст тот результат, который следует из исходника. Если исходник никакого результата не подразумевает, то компилятор может не генерировать ничего - и будет в своём праве.

1. Раньше во всех случаях, когда в коде был фрагмент, который никогда не выполняется, я получал от компилятора соответствующее предупреждение. В данном случае - нет.

Это вам показалось. Если припомните, какое именно было предупреждение, то поймёте, что в данном случае оно не применимо. А если не припомните, то это просто испорченный телефон. Короче, показалось.

Но в этом случае компилятор не выбрасывает из кода условный оператор и всё что после него.
Есть вероятность, что ответ на этот простой вопрос, как обычно, лежит в более сложных материях.

Не надо там искать сложных материй. В одном случае выкинул бессмысленный код, в другом - нет. Подумаешь - бывает сплошь и рядом. Компилятор - это просто программа, а не какое-то высшее существо с высшим разумом.

[amiller]

Вы будете смеяться, но компилятор вовсе не обязан на каждый чих в исходнике генерить код. Обычно на минимальном уровне оптимизации генерит, но тоже не всегда и не везде. Компилятор отвечает только за то, что сгенерированный код выдаст тот результат, который следует из исходника. Если исходник никакого результата не подразумевает, то компилятор может не генерировать ничего - и будет в своём праве.

В этом с Вами я согласен, но предупредить то надо. Например если поставить внутри функции безусловный return, генерится предупреждение. А в данном случае всё происходит молча. Ну и не совсем понятен алгоритм. В одном случае молча выбрасывает код, а в другом очень похожем случае всё же генерит код, который тем не менее также не выполняется.

Например, если в том же примере заменить строку с условным оператором "if (true) continue;" то получаем предупреждение:
Warning[Pe111]: statement is unreachable - что логично. А в моем примере это происходило "молча".

Тем не менее всем спасибо!
Ошибка локализована. И с утверждением, что компилятор "не обязан", я согласен. Остальное в общем то уже нюансы функционирования программы, которой также является и компилятор.

Сообщение отредактировал amiller - May 2 2016, 11:44

[Tahoe]

Ошибка локализована. И с утверждением, что компилятор "не обязан", я согласен. Остальное в общем то уже нюансы функционирования программы, которой также является и компилятор.

1. Странно, что локализована. Лично мне резануло глаз присваивание константы в цикле, при том что константа объявлена не volatile. Стало быть, весь цикл вообще теряет смысл. И никакие неявные приведения типов тут вообще ни причем.

2. Упрощения, это хорошо. Но приводить упрощенный Си-код вне функции, дело бесполезное. Хотя бы потому, что не понятно, переменные temp1 и temp2 локальные или глобальные.

3. Насчет обязан или не обязан компилер. Конечно не обязан, его дело компилировать. Зато статический анализатор кода сразу завопил бы, с негодованием. Благо в последних IAR встроен C-Stat. Настоятельно рекомендую натравить его на код. Гарантирую(с), он еще много "чудес" выявит в коде.

[amiller]

1. Странно, что локализована. Лично мне резануло глаз присваивание константы в цикле, при том что константа объявлена не volatile. Стало быть, весь цикл вообще теряет смысл. И никакие неявные приведения типов тут вообще ни причем.
2. Упрощения, это хорошо. Но приводить упрощенный Си-код вне функции, дело бесполезное. Хотя бы потому, что не понятно, переменные temp1 и temp2 локальные или глобальные.

Если ошибка воспроизводится в такой простой конструкции, то зачем присылать страницы кода?
Переменные temp1 и temp2 локальные, объявление на строчку выше. В исходном коде переменным присваиваются не константы, а результат, возвращаемый функцией. А после условного оператора ещё сотня строк в цикле.
Меня лично смутило, что компилятор без предупреждений выбросил из программы большой фрагмент кода. Это было главное, на что я обратил внимание.
Но раз общественность не забилась в праведном гневе, значит все считают это нормальным. А тогда вопрос и не стоит обсуждать.
Тем более в коде был грешок с приведением типов, на который мне правильно указали.

[Tahoe]

Если ошибка воспроизводится в такой простой конструкции, то зачем присылать страницы кода?

Еще раз. Нет никакой конструкции. Тот огрызок, что приведен, не позволяет нормально определить источник проблемы.

Переменные temp1 и temp2 локальные, объявление на строчку выше. В исходном коде переменным присваиваются не константы, а результат, возвращаемый функцией.

"Не в преферанс, а в лотерею. Не миллион, а пять тыщ. И не выиграл, а проиграл." (с)

Я только не понял, это вот "в исходном коде не константы", это просто поприкалываться захотелось или на полном серьезе?

Но раз общественность не забилась в праведном гневе, значит все считают это нормальным. А тогда вопрос и не стоит обсуждать.Тем более в коде был грешок с приведением типов, на который мне правильно указали.

А, общественность... Все считают... Тогда другое дело. Это заявка на успех. Желаю удачи.

[amiller]

Еще раз. Нет никакой конструкции. Тот огрызок, что приведен, не позволяет нормально определить источник проблемы.


"Не в преферанс, а в лотерею. Не миллион, а пять тыщ. И не выиграл, а проиграл." (с)

Я только не понял, это вот "в исходном коде не константы", это просто поприкалываться захотелось или на полном серьезе?


А, общественность... Все считают... Тогда другое дело. Это заявка на успех. Желаю удачи.

Извините, но я не понял к чему это всё, что Вы написали.
Или Вы считаете, что если я скопирую сюда полный код функции, Вы точно укажете на источник проблемы? Или Вы считаете, что я школьник, и то, что я прислал к делу не имеет отношения, а ошибка в другом месте?
Смею Вас заверить, что это не так.
И проблема воспроизводится именно в том "огрызке", который я разместил, я специально проверял. Для этого больше ничего не нужно, достаточно этот фрагмент разместить в пустом main(). Ну разве что скорректировать названия типов.
И в отзывах была информация, что это характерно не только для компилятора IAR. В gcc тоже проблема воспроизводится.

[zltigo]

И в отзывах была информация, что это характерно не только для компилятора IAR. В gcc тоже проблема воспроизводится.

Опять . Да не проблема это компилятора, ЛЮБОЙ компилятор ОБЯЗАН поступить аналогично. Это АБСОЛЮТНО Ваша проблема связанная с незнаним языка.

[amiller]

Опять . Да не проблема это компилятора, ЛЮБОЙ компилятор ОБЯЗАН поступить аналогично. Это АБСОЛЮТНО Ваша проблема связанная с незнаним языка.

Я нигде не писал, что претендую на звание "гуру". Более того, на ошибках учусь с удовольствием, как на своих, так и на чужих.
Но никто не дал на мой вопрос чёткий ответ.
1. Если переменные int16u, то компилятор код выбрасывает. У меня нет вопросов к самому факту этого события. У меня вопрос к тому, почему это происходит без предупреждения (молча). Я не считаю, что это нормальное поведение компилятора.
2. Однако если переменные int32u, то с точки зрения выполнения кода ничего не меняется. Но тем не менее в этом случае, код компилируется (не выбрасывается). Хотя результат также предопределен и известен заранее.
Я уже вроде успокоился по этому поводу, но находятся всё новые люди, которые утверждают, что я не знаю язык, но не дают чёткого ответа, почему компилятор поступает именно так.
Может Вы попробуете?

[Tahoe]

1. Если переменные int16u, то компилятор код выбрасывает.

Последний раз, больше даже пытаться не стану. Если десять раз присвоить константу temp1=0x1, хоть что-то изменится, хоть на одном проходе из 10? Если не изменится, то бишь даже без всякой оптимизации, temp1 и temp2 _всегда_ будут иметь одно и то же значение. Результат if (~0x0001!= 0xFFFE) будет отличаться хоть на одном из проходов? И плевать какие там типы, все 10 раз будет одно и то же. А строчка temp2 = temp1; будет вообще игнорироваться.

В итоге, имеем несколько строчек бессмысленного кода, который вырождается в пару присваиваний. И никакого цикла здесь нет. Другой вопрос, когда вместо констант будет присваиваться результат функции. В этом случае, может и дойдет до кривых типов. Но в приведенном куске, с константами, до этого дело даже не доходит.

[amiller]

Последний раз, больше даже пытаться не стану. Если десять раз присвоить константу temp1=0x1, хоть что-то изменится, хоть на одном проходе из 10? Если не изменится, то бишь даже без всякой оптимизации, temp1 и temp2 _всегда_ будут иметь одно и то же значение. Результат if (~0x0001!= 0xFFFE) будет отличаться хоть на одном из проходов? И плевать какие там типы, все 10 раз будет одно и то же. А строчка temp2 = temp1; будет вообще игнорироваться.

В итоге, имеем несколько строчек бессмысленного кода, который вырождается в пару присваиваний. И никакого цикла здесь нет. Другой вопрос, когда вместо констант будет присваиваться результат функции. В этом случае, может и дойдет до кривых типов. Но в приведенном куске, с константами, до этого дело даже не доходит.

Уважаемый, не рассказывайте мне пожалуйста, о бессмысленных присвоениях и сравнениях констант.
Вы невнимательно читали предыдущую переписку. Представленный фрагмент кода имеет только один смысл - продемонстрировать наличие проблемы в действиях компилятора.
Вместо того, чтобы доказывать, что автор сообщения не умеет писать программы, постарались бы понять, что он хотел донести своим сообщением.

Меняется. При приведении int16_t -> int32_t происходит расширение знака.

Уточнение: мои типы int16u и int32u соответствуют uint16_t u uint32_t. Не уверен, что в этом случае можно говорить о расширении знака.
Когда я говорил "ничего не меняется", я имел в виду, что условие в условном операторе по прежнему всегда true (не зависит от типа переменных), но в одном случае код компилируется, а в другом выбрасывается.