Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: nginx-0.8.30
Hello!
On Mon, Dec 21, 2009 at 06:48:01PM +0300, Igor Sysoev wrote:
> On Mon, Dec 21, 2009 at 06:32:50PM +0300, Maxim Dounin wrote:
>
> > On Mon, Dec 21, 2009 at 05:41:11PM +0300, Igor Sysoev wrote:
> >
> > > On Mon, Dec 21, 2009 at 04:58:12PM +0300, Maxim Dounin wrote:
> > >
> > > > > > Это второй репорт который я видел про ngx_http_ephemeral(),
> > > > > > предыдущий был тоже gcc 4.1. Если ты знаешь где ещё это вылезает
> > > > > > - свисти, вдруг у меня завалялось. :)
> > > > > >
> > > > > > > Твой вариант с memcpy мне не нравится: оно не мешает при
> > > > > > > переконфигурации,
> > > > > > > но как общее решение не подходит - зачем копировать лишнее в
> > > > > > > run-time.
> > > > > >
> > > > > > Там проблема в том что объект на стеке в той же функции, и
> > > > > > соответственно гарантированно имеет effective type.
> > > > > > Альтернативные варианты решения:
> > > > > >
> > > > > > 1. Аллоцировать динамически. Что кстати приведёт к
> > > > > > гарантированно правильному выравниванию, и сюрпризов при
> > > > > > преобразовании в sockaddr_in на strict alignment платформах
> > > > > > гарантировано не будет.
> > > > >
> > > > > Там проблема не в выравнивании, а вот в этом:
> > > > > http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html
> > > > > http://cellperformance.beyond3d.com/articles/2006/05/demystifying-the-restrict-keyword.html
> > > >
> > > > Там проблема в том, что нарушаются strict aliasing rules
> > > > прописанные в стандарте ISO C, и поэтому gcc ругается.
> > > >
> > > > В данном случае - ругается вполне правильно, ибо насколько я могу
> > > > судить - потенциально это место чревато проблемами в случае
> > > > архитектур со строгим выравниванием.
> > > >
> > > > Ибо выделяется char[] на стеке, требования к выравниванию у
> > > > которого одни, а используется - вполне себе struct sockaddr_in,
> > > > требования к выравниванию элементов коего совсем другие. Если
> > > > повезёт - всё будет хорошо, но может и не повезти.
> > >
> > > Нет, к выравниванию это не имеет никакого отношения, потому что
> > > ругаться начинает только при -O2, -O3 и -Os. По-твоему получается,
> > > что при -O0 и -O1 выравнивание компилятор не волнует.
> > >
> > > Это именно проблемы оптимизации, когда два указателя указывают
> > > на одну и ту же память.
> >
> > Волнует компилятор действительно только проблема оптимизации. Что
> > там случится с выравниванием - он знать не знает, ведать не ведает
> > (тем более - на других архитектурах). Если что - в runtime будет
> > SIGBUS или ругань про unaligned access.
> >
> > Я как бы пытаюсь сказать, что выдав warning по результатам своего
> > анализа о возможности оптимизации - он заодно вполне осмысленно
> > предупредил о возможных проблемах выравнивания. Ибо ноги у обоих
> > проблем растут из одного и того же нарушения strict-aliasing
> > rules.
>
> Нет. У меня нет под рукой машины с подобным компилятором, поэтому
> проверить негде, но можешь проверить - присвоить такой адрес указателю
> на char, у которого никаких проблем с выравниванием нет, и, я уверен,
> ты увидишь то же самое предупреждение.
На char - не увижу, ибо char'у стандартом явно разрешено alias'ить
любые типы данных. А во всех остальных случаях - преобразование в
несовместимый тип - это потенциально проблемы с выравниванием.
Собственно, это одна из причин почему запрещено.
Ещё раз: я не утверждаю, что наличия warning'а про strict-aliasing
это обязательно проблемы с выравниванием. Но потенциально - да, и
хорошо бы про эти warning'и проверять, всё ли хорошо. Или
переделывать так, чтобы warning'ов не было на законных
основаниях - e.g. использовать malloc() который обеспечивает
пригодность для произвольных типов, либо использовать совместимые
типы.
В данном конкретном случае - непосредственно перед lsopt на стеке идёт
указатель, да и сам lsopt непакованный, так что я с трудом себе
представляю архитектуру где бы могли быть проблемы. Но IMHO этот
warning тем не менее имеет смысл, даже если не использовать
-fstrict-aliasing для оптимизации.
Maxim Dounin
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://nginx.org/mailman/listinfo/nginx-ru
|