Здравствуйте, Erop, Вы писали:
R>>>В windows из-за хорошо подобранного названия всё получается просто: ACCESS_VIOLATION — ошибка зашиты памяти. ДД>>Если быть точным, то "нарушение доступа". Хорошо, что PERMISSION_DENIED не назвали E>Это ты про UNIX-like?
Да про все понемножку
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
говорят, что ничего не падает... очная ставка!
Там говорят отчасти правду, позор на мои седины.
На 2005.sp1 оно работает правильно, это у меня ошибка в коде
Там компилер присутствие alloca воспринимает весьма однозначно.
1. функция не будет заинлайнена
2. функция не будет заинлайнена даже если вызов alloca будет выброшен в процессе оптимизации
3. в функции будет сгенерирован пролог и эпилог проверяющий состояние стека.
про VC6 правду написал — инлайнит и падает.
VC7 под рукой нету
R>Наконец понял R>Правда без собственных тестов не обошлось. Пришлось заменить __inline на __forceinline, т.к. иначе всё работало и под релизом... R>Мой вывод такой:
R>Вот описание функции из MSDN: R>
R>_alloca allocates size bytes from the program stack. The allocated space is automatically freed when the calling function exits (not when the allocation merely passes out of scope)
R>А фактически получается, что работает так: R>
R>_alloca allocates size bytes from the program stack. The allocated space is automatically freed when the first non-inlined calling function exits (not when the calling function exits and not when the allocation merely passes out of scope)
R>Основная проблема в том, что нельзя угадать как компилятор заинлайнит функции.
Имхо, это просто тупая бага компилятора, за которую нужно отрывать руки. Мне лично плевать, что там делает оптимизатор\линкер — инлайнит или нет. Я описал валидную языковую конструкцию, значит, она должна при любой агрессивной оптимизации работать — иначе это уже не оптимизация. Вариантов у компилятора как минимум 2 — либо правильно инлайнить (как делает, по моим воспоминаям, ватком — там это был обычный прием оптимизации — вынести alloca в отдельную функцию), при этом восстанавливая стек фрейм (больших проблем в кодогенерации я тут не вижу — да вообще никаких проблем не вижу, тем более сейчас компилятор пытается это делать, используя для адресации локальных переменных ebp (именно и только в такой функции) и сохраняя и восстанавливая значение esp (правда, немного не в том месте). Либо не инлайнить вообще, как поступает gcс (что чревато, поскольку это один из приемов оптимизации).
Здравствуйте, Andrew S, Вы писали:
AS>Имхо, это просто тупая бага компилятора, за которую нужно отрывать руки. Мне лично плевать, что там делает оптимизатор\линкер — инлайнит или нет. Я описал валидную языковую конструкцию, значит, она должна при любой агрессивной оптимизации работать — иначе это уже не оптимизация. Вариантов у компилятора как минимум 2 — либо правильно инлайнить (как делает, по моим воспоминаям, ватком — там это был обычный прием оптимизации — вынести alloca в отдельную функцию), при этом восстанавливая стек фрейм (больших проблем в кодогенерации я тут не вижу — да вообще никаких проблем не вижу, тем более сейчас компилятор пытается это делать, используя для адресации локальных переменных ebp (именно и только в такой функции) и сохраняя и восстанавливая значение esp (правда, немного не в том месте). Либо не инлайнить вообще, как поступает gcс (что чревато, поскольку это один из приемов оптимизации).
void allo() __attribute__((always_inline));
void allo()
{
alloca(1024 * 500); // 500k
}
int main()
{
for (int x = 0; x < 8; ++x)
allo();
}
gcc4.1.1 — stack overflow
компилирую с -O3 больше никаких опций нет
причём если сделать цикл до 4, то не падает
если он складывает все стеки, то 500k * 4 = 2М
а если не складывает, то почему при 8 падает
R>void allo() __attribute__((always_inline));
R>void allo()
R>{
R> alloca(1024 * 500); // 500k
R>}
R>int main()
R>{
R> for (int x = 0; x < 8; ++x)
R> allo();
R>}
R>
R>gcc4.1.1 — stack overflow
R>компилирую с -O3 больше никаких опций нет R>причём если сделать цикл до 4, то не падает R>если он складывает все стеки, то 500k * 4 = 2М R>а если не складывает, то почему при 8 падает
Может, в данном случае он просто разворачивает цикл? Конечно, это не оправдывает некорректной работы результата.
говорят, что ничего не падает... очная ставка! R>Там говорят отчасти правду, позор на мои седины. R>На 2005.sp1 оно работает правильно, это у меня ошибка в коде R>Там компилер присутствие alloca воспринимает весьма однозначно. R>1. функция не будет заинлайнена R>2. функция не будет заинлайнена даже если вызов alloca будет выброшен в процессе оптимизации R>3. в функции будет сгенерирован пролог и эпилог проверяющий состояние стека.
R>про VC6 правду написал — инлайнит и падает. R>VC7 под рукой нету
под vc71 всё плохо
а ты попробуй на 2005.sp1 включить максимальные оптимизации, у меня тоже не сразу получилось под vc71
В частности:
Optimization — O2
Inline Function Expansion — Any Suitable
void traceIt( void* a )
{
std::cout << "Trace address:" << (int)a << std::endl;
}
void allo() __attribute__((always_inline));
void allo()
{
void * p = alloca(1024 * 500); // 500k
traceIt( p );
}
int main()
{
for (int x = 0; x < 8; ++x)
allo();
}
Чито так пишет?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Andrew S, Вы писали:
R>>gcc4.1.1 — stack overflow
R>>компилирую с -O3 больше никаких опций нет R>>причём если сделать цикл до 4, то не падает R>>если он складывает все стеки, то 500k * 4 = 2М R>>а если не складывает, то почему при 8 падает
AS>Может, в данном случае он просто разворачивает цикл? Конечно, это не оправдывает некорректной работы результата.
Я чо-то не понимаю по асму — там белибирда какая-то...
Но видимо что-то типа того. Тем не менее суть остаётся прежней — у gcc тоже с этим плохо
Ну вот его и заловили с поличным
R>
Взаимно: , хоть мне и нельзя
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, remark, Вы писали:
R>До смерти выдал:
R>
R>Trace address:245504
А если цикл до 4 крутить, то типа пролащит ещё?
Типа повезло с константами?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
говорят, что ничего не падает... очная ставка! R>>Там говорят отчасти правду, позор на мои седины. R>>На 2005.sp1 оно работает правильно, это у меня ошибка в коде R>>Там компилер присутствие alloca воспринимает весьма однозначно. R>>1. функция не будет заинлайнена R>>2. функция не будет заинлайнена даже если вызов alloca будет выброшен в процессе оптимизации R>>3. в функции будет сгенерирован пролог и эпилог проверяющий состояние стека.
R>>про VC6 правду написал — инлайнит и падает. R>>VC7 под рукой нету
R>под vc71 всё плохо
R>а ты попробуй на 2005.sp1 включить максимальные оптимизации, у меня тоже не сразу получилось под vc71 R>В частности: R>Optimization — O2 R>Inline Function Expansion — Any Suitable
Пробовал, не надает.
R>Так же попробуй __forceinline
пробовал -не падает
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
