Что же делать, что же делать… А, мы «обманем» компилятор… Вот что можно найти по запросу “prevent memset optimization”:

1. замена локальной переменной на переменную в динамической памяти со всеми вытекающими накладными расходами и риском утечки (сообщение в архиве рассылки linux-kernel)
2. макрос с ассемблерной магией (сообщение в архиве рассылки linux-kernel)
3. предложение использовать специальный символ препроцессора, который запрещает встраивание memset() по месту и затрудняет компилятору оптимизацию (естественно, такая возможность должна быть поддержана в используемой версии библиотеки, плюс Visual C++ 10 умеет оптимизировать даже код функций, помеченных как не подлежащие встраиванию)
4. всевозможные последовательности чтения-записи с использованием глобальных переменных (кода становится заметно больше и такой код не потокобезопасен)
5. последующее чтение с сообщением об ошибке в случае, если считаны не те данные, что были записаны (компилятор имеет право заметить, что «не тех» данных оказаться не может, и удалить этот код)

У всех этих способов много общих черт – они плохо переносимы и их сложно проверить. Например, вы «обманули» какую-то версию компилятора, а более новая будет иметь более умный анализатор, который догадается, что код не имеет смысла, и удалит его, и сделает так не везде, а только в некоторых местах.

Вы можете скомпилировать функцию перезаписи в отдельную единицу трансляции, чтобы компилятор «не увидел», что она делает. После очередной смены компилятора в игру вступит генерация кода линкером (LTCG в Visual C++, LTO в gcc или как это называется в используемом вами компилятором) – и компилятор прозреет и увидит, что перезапись памяти «не имеет смысла», и удалит ее.

Не зря появилась поговорка you can’t lie to a compiler.