Во-первых, нужно еще обстоятельно проверить, что с -Wframe-larger-than gcc вычисляет расход стека верно. Например, в Visual C++ есть /analyze:stacksize, который в общем работает, но во многих случаях вычисляет расход неверно. Может быть, в gcc это отлажено лучше и аналогичных проблем нет.
Во-вторых, не всегда же большой расход от того, что объявили массив большого размера на стеке явно. Мог быть большой массив в качестве поля класса, а временный объект этого класса мог быть создан автоматически при вызове функции.
В общем, действительно нужно по возможности пользоваться статическим анализом компилятора и проверять на тестовых пакетах, хватает ли стека уменьшенного размера.
В том и дело, что это считается оптимизацией в смысле «сделаем как-нибудь, а потом оптимизируем», в то время как стек является дефицитным ресурсом.
Будет зависеть от компилятора, это надо проверять. На Visual C++ 10 так сразу не сломалось.
Расскажите, пожалуйста, как заставить компилятор использовать выделенный в куче блок памяти для локальных и временных переменных?
Во-первых, нужно еще обстоятельно проверить, что с -Wframe-larger-than gcc вычисляет расход стека верно. Например, в Visual C++ есть /analyze:stacksize, который в общем работает, но во многих случаях вычисляет расход неверно. Может быть, в gcc это отлажено лучше и аналогичных проблем нет.
Во-вторых, не всегда же большой расход от того, что объявили массив большого размера на стеке явно. Мог быть большой массив в качестве поля класса, а временный объект этого класса мог быть создан автоматически при вызове функции.
В общем, действительно нужно по возможности пользоваться статическим анализом компилятора и проверять на тестовых пакетах, хватает ли стека уменьшенного размера.