И при этом выдачу предупреждения при компиляции компилятором из этой-же линейки для другой платформы ??? И выдачу предупреждения undefined bihavior этим-же компилятром для другого выражения? И все это с грубыми, по Вашему мнению нарушениями?

Компилятор вполне постижимая - сам писал в свое время со своего-же тестового языка для Z80 target. Проблема здесь в толковании правил и обеспечении соблюдения неписанных договоренностей.

Я считаю, что все, что касается правил компиляции - изложено в стандарте языка. Там нет ничего непостижимого. Стандарт - это закон. Поэтому доводы "это непостижимо" не приемлю, извините.

Я Вам привел цитаты из стандарта и разъяснил, как именно значение 14 противоречит понятию "правильности" результата этого выражения если даже забыть на время об ограничении по поводу undefined bihavior для выражения в целом. Вы можете привести какие-либо аргументы в поддержку своей позиции (утверждений об "однозначности разбора" и о "правильности" результата 14) кроме того, что некоторые космпиляторы не выдают предупреждение, выдавая в результате 14?

Ну и кроме того, хочу привести последний аргумент. То, что часть компиляторов выдает 13 (имеют полное право), а часть - 14, не означает ли, что компиляторы, не выдающие на такой код предупреждение, просто имеют более слабую диагностику по сравнению с теми, которые выдают такую диагностику?

Закон. Только закон (хоть "компиляторный" хоть "человеческий" ) все не описывает и уж точно не все описывает понятно. Отсюда и профессиональные писатели компиляторов и профессиональные адвокаты. И уж тем более закон не запрещает разбирать компиляторам более сложные случаи. Вот и получаем, те которые разбирают и не жалуются на непонятливость те выдают 14.

Это хорошо-бы а то ходим уже по мамнадцатому кругу

Может и быть, но! Повторяю неудобные вопросы на которые нет ответов:
B при этом, те которые 14 - все как один не выдают warnings, а те которые 13 все напротив - выдают. Случайность?
Компилятор одной линейки для одной платформы без warnings выдает 14 а для другой с warnings и 13.
Случайность?
Поведение с 14 позволяют себе минимум 4 весьма распространенных компилятора. Случайнось?
Не слишком-ли много неумелых толкователей закона среди писателей компиляторов?

P.S.
Пат.

Мне-то в этом законе все совершенно понятно. Это Вы почему-то жалуетесь, что там что-то непонятно написано. А по-моему, все совершенно четко. Логика есть логика.

Кстати, Вы так и не показали, как аккуратно исполняя дерево грамматического разбора обсуждаемого выражения можно получить 14.



arm-alf-gcc с опциями по умолчанию тоже никаких предупреждений не выдает, компилируя в 13. Нужно продолжать опровержения Вашего утверждения про заговор писателей компиляторов?

P.S. Это не пат, это мат.

Меня не интересует работа компиляторов с подавленными warnings, даже если они собраны кем-то по умолчанию.

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

Можете про себя считать, как угодно. Я это переживу .

Я Вам не помешаю ?
Выскажу свое ИМХО:
- Компилятор который не выдет warning в такой ситуации, вне зависимости от уровня оптимизации,
это компилятор который не следует стандарту С.
- соглашусь с Oldring, 12 или 13 еще как-то укладывается в то, как учитывая стандарт С,
компилятор должен был бы разбирать это выражение
- результат 14 для большинства компиляторов говорит только о том,
что "очень хотелось соптимизировать" и компилятор "успешно" справился с этой
задачей...
2zligo
Если Вы имеете в виду такую предсказуемость работы "оптимизаторов" в компиляторах,
то с Вами я тоже полностью согласен

Нет этим однозначно объяснить не получается. Посмотоите результаты реального OpenWatcom, три из многочисленных вариантов (от полной заоптимизированности в банальный возврат 14, до тупого кода при полностью отключенной оптимизации) приводил выше - без разницы. Последовательность действий при этом совершенно не изменялась - решене было приято уже ДО оптимизатора.

А с отсутствующими - интересует



Что-то новенькое?
По поводу "часть компиляторов выдает ворнинги, а часть нет" - отвечать не могу в принципе. Не понимаю логику вопроса. Я почему-то в ходе этого спора вспомнил нумерологию. Я ведь тоже не могу опровергнуть утверждение про несчастливость числа 13.

Других встречных вопросов не видел.

Ключевой метод для признания "правильности" вычисления выражения - вычисление выражения по грамматическому дереву в соответствии с семантическими правилами. Операция за операцией. Чтобы получить 14 нужно обязательно рассматривать результат ++i как lvalue. По крайней мере, в ANSI C-99 он не lvalue, следовательно, число 14 не может претендовать на правильность. Вы почему-то это ключевое логическое утверждение проигнорировали.



Это здорово. Не обижайтесь - мне само выражение понравилось. Ничего личного.



Я совершенноуже запутался в версиях компиляторов, на которые Вы ссылались.

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

Ключевое отличие x86 от ARM - именно в системе команд. в ARM нет операций АЛУ с аргументами в памяти. В системе команд x86 таких операций море, причем, они широко используются для обхода затычки с регистрами. Поэтому на x86 выгоднее рассматривать результат ++i как находящийся в самой ячейке памяти переменной i, хоть он и не lvalue, потому что ошибка может возникнуть только в выражениях с undefined bihavior.

Кстати, если определить i как volatile - в gcc для x86 результат становится 13.

Ну вы даёте... Эту бы энергию - да в мирных целях :-)
Кстати, тут ссылки на стандарт языка Си. А где его взять можно? Причём и C90, и C99? Посмотрел в закромах - не нашёл...

Да ТОЛЬКО с отсутствующими и интересует. К тем которые предупредили - претензий и спроса нет.

Пост номер 53. Это не вопросы, на которые я "требую" ответа. Это вопросы, которые я прежде всего задал себе и сам не знаю (не знал на тот момент) на них ответа. Но отсутствия ответа на них не позволяет мне прятать голову в песок и обвинять компиляторы не выдавшие warning в кривости.

Странно. 4 компилятора не выдающие warning? но выдающие 14 были перечислены рядышком в одной cтроке.

Хороший эксперимент!
Кроме того, когда я экспериментировал с GNU, я по ленности запихнул эти строчки в готовый поюсовый проект . Теперь повторив c сишным компилятором удалось получить warning. GCC x86 покинул ряды защитников "14":). С плюсовыи GNU странности, ну да бог с ним - уже не до этого. Нашел время спытать и Borland - он покидает арену с позором - выдает произвольные значения и никаких warning.
Microsoft-а у меня не стоит и лично не пытал. Посему на даный момент остается единственный достоверный стойкий оловянный солдатик - OpenWatcom. Всегда (в том числе и с volatile) выдающий 14.
Что уже явно может быть исключительно личным мнением разработчиков одного компилятора.

А вот это явный глюк компилятор. Посмотрите в ассемблере - cколько он раз считывает значение переменной i.

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

Один раз, а не два? В случае volatile int i?
А если просто написать x = i + i?

Не два. Зачем два? Один раз в РЕГИСТР. Затем операции с регистром или тот-же регистр в промежуточную память и операции с промежуточной памятью. Какие проблемы?

Проблемы с volatile. Чтение volatile переменной может обладать побочными эффектами, неизвестными компилятору, как и запись. Поэтому компилятор не может по своей воле оптимизировать чтение volatile переменных.

Ну с этим все очень просто. Берем Help к компилятору и читаем, что нам обещано:

Про побочные эффекты, при чтениии это не забота volatile. Характеристика обьекта с модификатором volatile описана четко. Все остальное фантазии и пустые надежды на решение всех проблем одним махом.

Может, с осторожностью:

Если вдруг существуют компиляторы налагающие более суровые ограниченя, не сочтите за труд назвать их. Очень полезно для общего развития.

Компилятор - GCC.

Не сочтите за труд, прочтите, в конце концов, стандарт языка, или хотя-бы нормальный учебник по языку программирования. Главное назначение volatile - работа с аппаратными регистрами. Например, получение данных из аппаратного FIFO. Изменение количества чтений из такой ячейки памяти приведет к некорректной работе программы. Поэтому атрибут volatile налагает очень жесткие ограничения на любой компилятор: каждое чтение volatile объекта является внешним эффектом программы, поэтому никакая оптимизация не имеет права изменить количество таких чтений.

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

P.S. Убедитесь, пожалуйста, что Watcom поддерживает ANSI C, а не остановился в своем развитии на K&R C.

Может я чего пропустил? Тогда пожалуйста сюда ссылочку из стандарта про главню задачу volatile:



Удивительно другое, что Вы полагаете, что для решения описанных проблем достаточно volatile

OpenWatcom поддерживает С99. А что в K&R упоминается volatile?

Накладываемые ограничения:

"Главная задача volatile" описана, безусловно, не в стандарте, а в учебниках по языку. Признаюсь, учебники по языку С я не читал с начала 90-х - но уже в то время все было подробно описано.

В стандарте же написано следующее:



volatile решает часть задачи работы с аппаратурой, которая касается компилятора. Остальное (например, настройка кеша) касается самой аппаратуры, а не компилятора. Нечего мне приписывать то, что я не писал.

P.S. Есть еще такой документ - "Rationale for International Standard—Programming Languages—C"

Отлично. К первоисточникам припали . Ну теперь будучи вооруженным, попробуйте обьяснить, в чем это компилятор провинился:


Ну и Ваши слова:



Да??? Были перечислены проблемы ображения к "железу" и сказано про volatile. При этом никакие другие средства не упоминались а в реальной жизни для решения этих проблем использования только volatile (без, например, разбиения на sequence points )недостаточно.
Так-что как тогда надо было понимать?

P.S.
Да, и с "удивлением", пожалуйста поокуратнее.

Да я Вам с самого начала постоянно кидал ссылки на первоисточники - а в ответ получал лишь "жираф большой - ему видней."

Провинился Watcom тем, что абстрактная C машина считывает volatile объект два раза - а код, порождаемый компилятором, содержит одно чтение из объекта. Такая оптимизация нарушает требование стандарта, которое я процитировал в предыдущем посте.

Кстати. Вы дописали в конце цитату утверждения, что компилятор имеет право комбинировать volatile обращения между соседними sequence point. Так вот, это явный бред. Вы не привели ссылку на источник цитаты - гугл в качестве источника дает документацию на GCC. Это утверждение - явная самодеятельсность авторов GCC. Потому что она противоречит приведенной ранее мною цитате из стандарта. Переупорядочивание обращений к этому не относится. А вот комбинирование может привести к тому, что побочные эффекты от обращения будут потеряны, вместо того, чтобы быть завершены к следующей sequence point.

Ну как-бы я все понял и осознал - существует только одно правильное толкование "стандарта" и оно принадлежит Oldring.
Aвторы компиляторов дружно "отдыхают", ну а остальные фоне этого вообще никто и звать их никак.

Я и говорю: "жираф большой - ему видней".
Ладно. Продолжать мне скушно.
Адью.

Вообще то известно, что авторы компиляторво делают ошибки в полный рост. Для этого достаточно почитать этот форум.
Ну а то что в этом случае i не надо читать два раза очень удивительно слышать от человека, который занимается разработкой для микропроцессоров. Тут таких случаев навалом.
То что это не так в ваткоме говорит о том, что этот компилятор практически не используется для написания совты связанного с работой с железом и такие ошибки не ВЫЛЕЗЛИ у пользователей.

Удивительно другое, что volatile-"правильный" компилятор пока найти не удалось .

Человек, "который занимается" умеет четко выражать свои мысли посредством vоlatile и разбиения инструкций на sequence point. При этом меня абсолютно устраивает минимально-необходимо-достаточная трактовка volatile присутствующая во всех известных мне компиляторах и процитированная ранее по Watcom-овскому хелпу и документации к GCC. При этом такая трактовка volatile не отметает оптимизацию на корню.

Ну то, что я использую под 186 и не только, и то, что IBM-PC это тоже железо - забудем? Но что делать с GCC там ведь вообще "явный бред":

Так вот, я с этим "бредом" полностью согласен. Нормальная, сбалансированная реализация. Не вырубающая оптимизацию полностью при обращении к Random Access (RAM в том числе) обьектам. "Проблемы" c, например, FIFO должны решаться явным образом разбиением обращений на sequence point. Обращение к FIFO (кстати, как там дела c существованием FIFO в "абстрактной С машине" поминаемй с стандарте дела обстоят? ) не должно висеть тяжким грузом на всем остальном.

аналогично!
почему 14 ???
13 и баста...
вариант с 12 - доспустим,но это добжен быть невероятно глупый компилятор, причем с патароченными критериями и правилами оптимизации...

но а 14 откуда берется?
и почему у gcc тоже 14???

я прошу, нет, ... требую... объясните плз...

я конечно не виликий гуру - но тут то заблудиться трудно!
13 и ничего иного...
x = ++i+ ++i

разбиваем как это делает компилятор
temp1 = ++i (стало 6)
temp2 = ++i (стало 7)
x=temp1+temp2 (стало 13)

от куда 14???

...и вообще! что это у людей за безгранично глупая привычка все писать без скобок !?
что за мода надеяться на безграничный интелект компилятора?
...истинну глаголю - индусы писали это эйфелеву конструкцию!
не иначе ...или [CENSORED]!

а глупость то видать явно в компиляторах и это напоминает подвох с x=2+2*2, чему равен x?

.

Пора рассматривать известную шутку Ричи и Кернигана

for(;P('\n'),R-;P('|'))for(e=C;e-;P('_'+(*u++/8)%2))P('| '+(*u/4)%2);

Вдруг и это вызовет полемику?

1. Да простит меня великий All, что я поднял эту волну... Просто мною овладело любопытство.

2. Я про явное отличие компиляторов С/С++ и С# скажу. Точнее скажу свои доводы, как эти компиляторы понимают код
x = ++i + ++i;

Компиляторы С/С++ складывают (последняя операция -- сложение) переменную i c переменной i, в то время как C# складывае результат выражения ++i с результатом выражения ++i.

Таким образом, для С/С++ на момент сложения переменных, они будут равны 7 (даром, что это одна и та же переменная!), результат получаем -- 14. C# складывает результаты выражений: первый результат на момент сложения равен 6, второй -- 7, что в итоге дает 13.

Отсюда вопрос -- что должны складывать компиляторы: результаты выражений или значения переменных?

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

И еще, наверно стоит зайти на РСДН, посмотреть что там говорят гуру. (Сылку я приводил в первом посте.)

А то, что значение переменной может поменяться в результате прерывания? Или в начале каждой sequence point прерывание запрещать, а потом разрешать?

не-е, ну... предполагается, что переменная i -- это обычная переменная, не volatile. Определена внутри какой-нибудь функции, т.е. размещается либо на стеке, либо в регистрах МП. Иначе говоря, никто из вне ее торкнуть не может.

Про исходный пример все ясно. Так просто нельзя писать, т.к. результат по стандарту не определен. Мы уже про другое.

Если следовать строго правилам стандарта, отличие может возникнуть только в том случае, если переменная i объявлена как volatile. В этом случае можно сказать однозначно: так как результат ++i по стандарту не является lvalue, компилятор не имеет права считывать i второй раз и должен использовать результат вычисления выражения.

Если же i не volatile - то в корректно написанных выражениях нет никакой разницы, что использует компилятор. Но исходное выражение нарушает требования к корректным выражениям с однозначным результатом. Таких неоднозначностей в языке С довольно много, они неизбежны в столь низкоуровневом языке и переречислены в стандарте языка. Если компилятор достуточно наворочен - он в части таких случаев может выдать предупреждение.

В пост #4 при компилляции добавляем -Wall и получаем warning и значение 14.
Напомню, это в GCC 3.4.5 x86

все операции детерминированы . в выражении ++i + ++i во втором "отделении спектакля"
производиться только сложение двух подвыражений - а подвыражения эти - равны текущему значению i (вариант а), либо вычисленному значению подвыражения (вариант б). нигде не написано в стандарте про то какой вариант является правильным - именно поэтому это и называется undefined behavior. неправ тот компилятор который не показал ворнинг - а число при этом можно выдавать где то от 12-ти до 14-ти

Еще раз.

Результат всего выражения компилятор имеет право выдать любой - хоть -666, потому что undefined behavior.

Но интерпретация значения выражения ++i прописана в стандарте совершенно четко. Результат не является lvalue. Следовательно, это не есть значение переменной i, а именно вычисленное значение подвыражения. В корректных выражениях различие можно обнаружить только если i - volatile.