Здравствуйте, Masterspline, Вы писали:

M>А в этом вашем VC++ разве нельзя включить только нужные оптимизации

В VC++ сам оптимизатор хороший, но управляется отвратительно — практически "или все, или ничего".

M>Godbolt говорит, так можно в gcc.

В GCC управление на порядки тоньше.

Здравствуйте, Mr.Delphist, Вы писали:

MD>Либо же там в рантайме остаются какие-то guard scopes, которые выбросят осетра (assert), если будет попытка обращения к уже освобождённому адресу.

Как это могло бы быть сделано технически?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Такое впечатление, что Вы никогда не работали с компиляторами иначе, как через оболочку вроде студии, где режимы включаются/отключаются через менюшки.
"-1".

Здравствуйте, Skorodum, Вы писали:

S>"-1".

Приборы?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Если вдруг кто изучал особенности кодогенерации MS VC++ в этом плане — можно ли его как-то заставить складывать новые автоматические объекты поверх уже вышедших из области видимости без включения оптимизации всей функции?
Отключение всяких секьюрити опций типа /GS- не помогают?

Здравствуйте, AndrewJD, Вы писали:

AJD>Отключение всяких секьюрити опций типа /GS- не помогают?

Увы. Да и не должно это влиять, /GS проверяет только целостность в районе адреса возврата.

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

это все херня по сравнению с тем что мне новомодный компилер сегодня сгенерил то о чем его не просили

    pStr = FullFileName;
    while ( *pStr )
    {
      Length = 0;
      while ( *pStr && *pStr != 92 )
        FileName[Length++] = *pStr++;
      if ( Length >= 0x104 )
        __report_rangecheckfailure();
      FileName[Length] = 0;

в оригинале

while (*pStr)
{
        char FileName[MAX_FN_LEN];
        int Length = 0;
        while (*pStr && *pStr != '\\')
                FileName[Length++] = *pStr++;
        FileName[Length] = 0;
        if (Length)
        {

я конечно все понимаю
но это мои желания делать так и не иначе
лучше он бы варнингами завалил чем такую каку подсовывать в бинарь

Здравствуйте, niXman, Вы писали:

X>сам недавно обратил внимание, что GCC с включенными оптимизациями переупорядочивает стековые переменные чтоб уменьшить "дыры"...

Так это можно было бы делать и при отключенных оптимизациях. Я же говорил, что алгоритм распределения памяти под автоматические переменные на стеке идентичен алгоритму распределения памяти в любом union. А крупных объектов в современных программах используется много, в том числе и чисто временных, неуправляемых, под каждый из которых зачем-то выделяется отдельная область на стеке. В итоге объем стека растет в десятки раз, и от переполнения в большинстве случаев спасает лишь заведомо избыточное резервирование в пользовательском режиме. А в режиме ядра резервирование для произвольного потока невозможно, поэтому возникает дилемма: или оптимизировать код вручную, или включать оптимизацию, теряя возможность трассировки этого кода в отладчике.

Здравствуйте, reversecode, Вы писали:

R>новомодный компилер сегодня сгенерил то о чем его не просили

Это который? Он это сгенерил в режиме без ключей?

R>но это мои желания делать так и не иначе

"Так" — это писать заведомо за пределами массива?

R>лучше он бы варнингами завалил чем такую каку подсовывать в бинарь

Какие предупреждения он мог бы выдать?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, reversecode, Вы писали:

R>>новомодный компилер сегодня сгенерил то о чем его не просили

ЕМ>Это который? Он это сгенерил в режиме без ключей?

а то!

R>>но это мои желания делать так и не иначе

ЕМ>"Так" — это писать заведомо за пределами массива?

это дело программиста

R>>лучше он бы варнингами завалил чем такую каку подсовывать в бинарь

ЕМ>Какие предупреждения он мог бы выдать?

любые о выходе индекса за границы массива

ps вообще это все выключается через /GS-
но в современных версиях msvc он уже включен по умолчанию

тонкий вам намек на туже самую тему

Здравствуйте, reversecode, Вы писали:

R>а то!

Версия компилятора какая?

ЕМ>>"Так" — это писать заведомо за пределами массива?

R>это дело программиста

Ну так ради бога, отключаете проверки, и вперед.

ЕМ>>Какие предупреждения он мог бы выдать?

R>любые о выходе индекса за границы массива

На какие именно операции — на каждую запись в массив по неконстантному индексу? Вы точно этого хотите?

R>ps вообще это все выключается через /GS-

/GS- всегда выключал только проверку защитного значения в верхней части кадра. До недавних пор (у меня последняя версия — 19.10) проверки границ массива вообще не было.

R>тонкий вам намек на туже самую тему

Не понял, можно точнее?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Так это можно было бы делать и при отключенных оптимизациях. Я же говорил, что алгоритм распределения памяти под автоматические переменные на стеке идентичен алгоритму распределения памяти в любом union.
Уверены? Насколько я помню, там надо рассчитать "live range" для каждой переменной и если они не пересекаются, то их можно разместить в одной области памяти, а чтобы рассчитать диапазоны нужно найти все использования, чтобы найти все использования нужно выполнить "alias analysis"... может еще чего забыл.

Здравствуйте, cserg, Вы писали:

C>там надо рассчитать "live range" для каждой переменной и если они не пересекаются

Посмотрите первое сообщение — я имел прежде всего подобные примеры. Ну и временные объекты, которые существуют только вокруг операций с ними — там тоже легко расставить воображаемые скобки. А по всей истории использования переменных, видимых на протяжении всей функции, уже пусть разбирается "взрослый" оптимизатор, это его забота.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, Mr.Delphist, Вы писали:

MD>>Либо же там в рантайме остаются какие-то guard scopes, которые выбросят осетра (assert), если будет попытка обращения к уже освобождённому адресу.

ЕМ>Как это могло бы быть сделано технически?

Заполнение специальной цепочкой байтов: ABABABAB, CCCCCCCC и т.п.
https://stackoverflow.com/questions/127386/in-visual-studio-c-what-are-the-memory-allocation-representations

Далее рантайм проверяет контент в памяти перед использованием. При необходимости бьёт тревогу.

Здравствуйте, Mr.Delphist, Вы писали:

MD>Заполнение специальной цепочкой байтов: ABABABAB, CCCCCCCC и т.п.

Это делается еще с версии 13 или 14 (ключи /RTCs, /RTCu) — однократно при входе в функцию. Память выделяется с полями, которые однократно проверяются при выходе.

MD>Далее рантайм проверяет контент в памяти перед использованием. При необходимости бьёт тревогу.

Явная проверка перед каждым использованием даст слишком большие накладные расходы. И что-то придется делать на случай, когда специальное значение совпадет с допустимым. Хотя я и считаю, что лишних проверок/предупреждений не бывает, лишь бы ими можно было эффективно управлять.

Здравствуйте, Евгений Музыченко, Вы писали:


ЕМ>Если вдруг кто изучал особенности кодогенерации MS VC++ в этом плане — можно ли его как-то заставить складывать новые автоматические объекты поверх уже вышедших из области видимости без включения оптимизации всей функции?

Можно создать тикет у них и попросить такую фичу. Как минимум, в ответ прилетит аргументация об отказе, как максимум — фичу реализуют (а новые версии компилятора сейчас выходят довольно часто).

P.S. Тяжелые штуки в ядре лучше помещать в глобальную область памяти. Если код многопоточный, то делать аналогично TLS (thread local storage) — если рекурсии нет, то всё довольно надёжно получится; а если есть, то и её поддержку можно добавить.

Здравствуйте, flаt, Вы писали:

F>Можно создать тикет у них и попросить такую фичу.

Разве у них есть возможность создать тикет любому желающему? А тратить один-два support case, входящих в комплекст стандартной подписки VS/MSDN, на такую ерунду неразумно. Я вот в прошлом году пытался через тикет у VMware решить проблему с Workstation Pro — в итоге тикет протух, и теперь я не могу до них достучаться.

F>Тяжелые штуки в ядре лучше помещать в глобальную область памяти.

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

Здравствуйте, Евгений Музыченко, Вы писали:


ЕМ>Разве у них есть возможность создать тикет любому желающему? А тратить один-два support case, входящих в комплекст стандартной подписки VS/MSDN, на такую ерунду неразумно. Я вот в прошлом году пытался через тикет у VMware решить проблему с Workstation Pro — в итоге тикет протух, и теперь я не могу до них достучаться.

Есть, были замечены при 2017 студии. Например, release notes для 15.9.14 и сам багрепорт.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>pragma optimize действует только на функцию в целом, поэтому оборачивание ими подобной функции лишает меня возможности нормально смотреть локальные переменные. А выделять память динамически с такой частотой в реальном времени — моветон.
С точки зрения компилятора, либо вы хотите нормально смотреть локальные переменные — и тогда он по честному раскладывает их по разным адресам. Либо вы хотите оптимального использования стека — и тогда он максимально совместит переменные с неперекрывающимися областями видимости, но это повлияет не только на byte[100], но и на все остальные переменные.
Любое другое поведение было бы крайне странным.