фича компиляторв, инкремент переменной Опции

[zhevak]

На форуме программистов (здесь http://www.rsdn.ru/Forum/?mid=2481623) с пацанами сейчас подняли интересную тему. Думаю, что си-шникам тоже следует остерегаться подобного кода. В двух словах проблема состоит в том, как компилятор должен понимать оператор инкремента.

int i;
int x;

i = 5;
x = ++i + ++i;

Чему в результате будет равно х ?

Прикол в том, что MS VC++ 6.0 и VC++.NET дают результат, равный 14. Майкрософтовский C# и IAR говорят, что х = 13. А более всего удивил Watcom -- у него результат зависит от того, включена-ли оптимизация или нет...

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

Вечером дома, попробую еще в CodeVision эту фичу покрутить.

[vetal]

Потому и "undefined bihavior", что по моему мнению оператор + складывает 2 ячейки памяти с адресом I, а по вашему он заводит дополнительную переменную. Тут всё и кроется))

[Oldring]

Потому и "undefined bihavior", что по моему мнению оператор + складывает 2 ячейки памяти с адресом I, а по вашему он заводит дополнительную переменную. Тут всё и кроется))

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

Ваше мнение о том, "что оператор + складывает 2 ячейки памяти с адресом i" противоречит утверждению из стандарта, что результат вычисления ++i не есть lvalue. Так что такую интерпретацию принять не могу как "правильную"

Вся эта бодяга действительно отдана на откуп компилятору в зависимости от платформы. Но что интересно - в результате реального эксперимента все компиляторы для x86 платформы выдали тот самый результат, а под ARM и BF выдали warning - не смогли на штатном механизме обеспечить?
Интересный такой нюанс. Надо будет GNU на не на x86 платформе спытать.

arm-elf-gcc версии 4.1.1 выдает 13.

[zltigo]

arm-elf-gcc версии 4.1.1 выдает 13.

Молча?

[Oldring]

Молча?

По умолчанию - да.

В программе, приведенной ниже, с ключем -Wsequence-point выдается предупреждение "warning: operation on 'i' may be undefined" внутри main(), но не внутри f(). В обоих случаях - 13.

Код

int f( int* p1, int* p2 )
{
    return ++(*p1) + ++(*p2);
}

int main( void )
{
    int i;
    int x1, x2;

    i = 5;
    x1 = ++i + ++i;

    i = 5;
    x2 = f( &i, &i );

    return x2;
}

P.S. С включенной оптимизацией -O3 main своится к возврату 13.

[zltigo]

В программе, приведенной ниже, с ключем -Wsequence-point выдается предупреждение "warning: operation on 'i' may be undefined" внутри main(), но не внутри f(). В обоих случаях - 13.

Ну про f() это естественно правильно - по другому было-бы крайне странно. С main() выдал warning расписавшись в непонятках - тоже каой-же после этого спрос.

Зксперименировал для начала с OpenWatcom...

P.S. С включенной оптимизацией -O3 main своится к возврату 13.

Аналогично. C приличными оптимизациями все сводится к

Код

    push      0000000eH
    push      offset FLAT:L$402
    call      near ptr FLAT:printf_
    add       esp,00000008H
    ret

Пришлось извне передавать.

Код

void dummy( int i )
{
int k = ++i + ++i;
    printf( "k=%i\r", k );
}

Это вариант с разнообразными оптимизаторами:

Код

    add       eax,00000002H
    add       eax,eax
    push      eax
    push      offset FLAT:L$402
    call      near ptr FLAT:printf_
    add       esp,00000008H
    ret

и вообще без оптимизации:

Код

    push      00000030H
    call      near ptr FLAT:__CHK
    push      ebx
    push      ecx
    push      edx
    push      esi
    push      edi
    push      ebp
    mov       ebp,esp
    sub       esp,0000000cH
    mov       dword ptr -0cH[ebp],eax
    inc       dword ptr -0cH[ebp]
    inc       dword ptr -0cH[ebp]
    mov       eax,dword ptr -0cH[ebp]
    add       eax,dword ptr -0cH[ebp]
    mov       dword ptr -4H[ebp],eax
    push      dword ptr -4H[ebp]
    mov       eax,offset FLAT:L$450
    push      eax
    call      near ptr FLAT:printf_
    add       esp,00000008H
    mov       esp,ebp
    pop       ebp
    pop       edi
    pop       esi
    pop       edx
    pop       ecx
    pop       ebx
    ret

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

И говорит что так делать нельзя.

В обоих случаях оптимизации говорит нельзя?

[Oldring]

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

В любом случае, это не есть доказательство "правильности" значения 14.

Ну про f() это естественно правильно - по другому было-бы крайне странно. С main() выдал warning расписавшись в непонятках - тоже каой-же после этого спрос.

gcc на x86 неизменно возвращает 14. в том числе, из f()

[zltigo]

В любом случае, это не есть доказательство "правильности" значения 14.

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

gcc на x86 неизменно возвращает 14. в том числе, из f()

Я мельком глянул на f() - естественно ошибся .

[Oldring]

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

Как истолковать? Как невыдачу предупреждения на undefined bihavior код.

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

Вы никогда не читали учебники по устройству компиляторов? Вот, например, из недавних был издан на русском языке в 2001 году. "Компиляторы. Принципы, технологии, инструменты". Ахо, Сети, Ульман. Авторы, кстати - классики по теории компиляции. Очень рекомендую.

[zltigo]

Как истолковать? Как невыдачу предупреждения на undefined bihavior код.

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

Компилятор - не такая уж непостижимая для понимания программа.

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

[Oldring]

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

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

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

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

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

[zltigo]

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

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

Ну и кроме того, хочу привести последний аргумент.

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

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

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

P.S.
Пат.

[Oldring]

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

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

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

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

P.S.
Пат.

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

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

[zltigo]

arm-alf-gcc с опциями по умолчанию тоже никаких предупреждений не выдает,

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

Нужно продолжать опровержения Вашего утверждения про заговор писателей компиляторов?

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

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

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

[Oldring]

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

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

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

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

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

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

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

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

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

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

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

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

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

[zltigo]

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

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

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

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

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

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

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

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

[Oldring]

Посему на даный момент остается единственный достоверный стойкий оловянный солдатик - OpenWatcom. Всегда (в том числе и с volatile) выдающий 14.

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

[zltigo]

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

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

[Oldring]

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

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

[zltigo]

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

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

[Oldring]

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

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

[zltigo]

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

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

Код

An object may be declared with the keyword  volatile.  Such an object may be freely modified by the program, and its value also may be modified through actions outside the program.

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

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

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

Код

The keyword  volatile indicates to the compiler that care must be taken when optimizing code referring to the object, so that the meaning of the program is not altered.  An object that the compiler might otherwise have been able to keep in a register for an extended period of time will be forced to reside in normal storage so that an external change to it will be reflected in the program's behavior.

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

[Oldring]

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

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

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

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

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

[zltigo]

Не сочтите за труд, прочтите, в конце концов, стандарт языка

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

Главное назначение volatile - работа с аппаратными регистрами. Например, получение данных из аппаратного FIFO

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

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

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

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

Поэтому атрибут volatile налагает очень жесткие ограничения на любой компилятор

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

The standards encourage compilers to refrain from optimizations concerning accesses to volatile objects that it might perform on non-volatile objects. The C standard leaves it implementation defined as to what constitutes a volatile access. The C++ standard omits to specify this, except to say that C++ should behave in a similar manner to C with respect to volatiles, where possible. The minimum either standard specifies is that at a sequence point all previous accesses to volatile objects have stabilized and no subsequent accesses have occurred. Thus an implementation is free to reorder and combine volatile accesses which occur between sequence points, but cannot do so for accesses across a sequence point. The use of volatiles does not allow you to violate the restriction on updating objects multiple times within a sequence point.

Сообщение отредактировал zltigo - May 13 2007, 09:50

[Oldring]

Может я чего пропустил? Тогда пожалуйста сюда ссылочку из стандарта про главню задачу volatile:
Удивительно другое, что Вы полагаете, что для решения описанных проблем достаточно volatile

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

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

An object that has volatile-qualified type may be modified in ways unknown to the
implementation or have other unknown side effects. Therefore any expression referring
to such an object shall be evaluated strictly according to the rules of the abstract machine,
as described in 5.1.2.3.

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

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

volatile No cacheing through this lvalue: each operation in the abstract semantics must be
performed (that is, no cacheing assumptions may be made, since the location is not
guaranteed to contain any previous value). In the absence of this qualifier, the
contents of the designated location may be assumed to be unchanged except for
possible aliasing.

A static volatile object is an appropriate model for a memory-mapped I/O register.
Implementors of C translators should take into account relevant hardware details on the target
systems when implementing accesses to volatile objects. For instance, the hardware logic of a
system may require that a two-byte memory-mapped register not be accessed with byte operations;
and a compiler for such a system would have to assure that no such instructions were generated,
even if the source code only accesses one byte of the register. Whether read-modify-write
instructions can be used on such device registers must also be considered. Whatever decisions are
adopted on such issues must be documented, as volatile access is implementation-defined. A
volatile object is also an appropriate model for a variable shared among multiple processes.

[zltigo]

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

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

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

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

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

Нечего мне приписывать то, что я не писал.

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

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

[Oldring]

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

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

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

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

[zltigo]

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

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

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

[vromanov]

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

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

[zltigo]

Вообще то известно, что авторы компиляторво делают ошибки в полный рост.

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

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

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

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

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

Код

The standards encourage compilers to refrain from optimizations concerning accesses to volatile objects that it might perform on non-volatile objects. The C standard leaves it implementation defined as to what constitutes a volatile access. The C++ standard omits to specify this, except to say that C++ should behave in a similar manner to C with respect to volatiles, where possible. The minimum either standard specifies is that at a sequence point all previous accesses to volatile objects have stabilized and no subsequent accesses have occurred. Thus an implementation is free to reorder and combine volatile accesses which occur between sequence points, but cannot do so for accesses across a sequence point. The use of volatiles does not allow you to violate the restriction on updating objects multiple times within a sequence point.

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