[sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64

[sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64

[Roman Savochenko]

[-- Attachment #1: Type: text/plain, Size: 769 bytes --]

Приветствую Всех

Имеется некая целевая задачка собрать из двух 16-разрядных целых 
вещественное (float), 32 разряда.
Казалось-бы тривиальная задача, которая решается кодом типа
int w1 = 62915, w2 = 16456;
ui32 vl = ((w2&0xffff)<<16) | w1&0xffff;
//sleep(1);
printf("TEST 00: %f\n",*(float*)&vl);

И как ожидалось на x86_32 он работает корректно при различной нагрузке.
А вот на x86_64 замечается ситуация когда вместо 3.14 получаем ноль.
Причём в тестовой программке с единственным потоком всё работает 
нормально, а на высоконагруженном процессе с десятками потоков, из 
которых около пяти работают с периодом 5мс. устойчиво получатся 0.
Если раскомментирую sleep, то получаю номальный результат 3.14.

Кто нибуть может такое поведение объяснить?

С уважением, Роман

[-- Attachment #2: rom_as.vcf --]
[-- Type: text/x-vcard, Size: 218 bytes --]

begin:vcard
fn:Roman Savochenko
n:Savochenko;Roman
adr;dom:;;;Dneprodzerjinsk
email;internet:rom_as@diyaorg.dp.ua
title:NIP "DIYA"
tel;work:NIP "DIYA"
tel;cell:+380679859815
x-mozilla-html:FALSE
version:2.1
end:vcard

Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64

[Alexey Rusakov]

[-- Attachment #1: Type: text/plain, Size: 1659 bytes --]

В Срд, 05/08/2009 в 20:08 +0300, Roman Savochenko пишет:
> Приветствую Всех
> 
> Имеется некая целевая задачка собрать из двух 16-разрядных целых 
> вещественное (float), 32 разряда.
> Казалось-бы тривиальная задача, которая решается кодом типа
> int w1 = 62915, w2 = 16456;
> ui32 vl = ((w2&0xffff)<<16) | w1&0xffff;
> //sleep(1);
> printf("TEST 00: %f\n",*(float*)&vl);
> 
> И как ожидалось на x86_32 он работает корректно при различной нагрузке.
> А вот на x86_64 замечается ситуация когда вместо 3.14 получаем ноль.
> Причём в тестовой программке с единственным потоком всё работает 
> нормально, а на высоконагруженном процессе с десятками потоков, из 
> которых около пяти работают с периодом 5мс. устойчиво получатся 0.
> Если раскомментирую sleep, то получаю номальный результат 3.14.
> 
> Кто нибуть может такое поведение объяснить?
Объяснить не могу, но поиграйтесь с опциями отладки и оптимизации(-O,
-g) и смотрите объектный код, генерируемый компилятором (-S).

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64

[Roman Savochenko]

[-- Attachment #1: Type: text/plain, Size: 1790 bytes --]

Alexey Rusakov wrote:
>> Имеется некая целевая задачка собрать из двух 16-разрядных целых 
>> вещественное (float), 32 разряда.
>> Казалось-бы тривиальная задача, которая решается кодом типа
>> int w1 = 62915, w2 = 16456;
>> ui32 vl = ((w2&0xffff)<<16) | w1&0xffff;
>> //sleep(1);
>> printf("TEST 00: %f\n",*(float*)&vl);
>>
>> И как ожидалось на x86_32 он работает корректно при различной нагрузке.
>> А вот на x86_64 замечается ситуация когда вместо 3.14 получаем ноль.
>> Причём в тестовой программке с единственным потоком всё работает 
>> нормально, а на высоконагруженном процессе с десятками потоков, из 
>> которых около пяти работают с периодом 5мс. устойчиво получатся 0.
>> Если раскомментирую sleep, то получаю номальный результат 3.14.
>>
>> Кто нибуть может такое поведение объяснить?
>>     
> Объяснить не могу, но поиграйтесь с опциями отладки и оптимизации(-O,
> -g) и смотрите объектный код, генерируемый компилятором (-S).
>   
Да действительно, проблема связана с ключом -O2. Сменил на -O1 всё 
заработало нормально.

Багу на компилятор по этому поводу вешать?

С уважением, Роман

[-- Attachment #2: rom_as.vcf --]
[-- Type: text/x-vcard, Size: 230 bytes --]

begin:vcard
fn:Roman Savochenko
n:Savochenko;Roman
adr;dom:;;;Dneprodzerjinsk
email;internet:rom_as@diyaorg.dp.ua
title:NIP "DIYA"
tel;work:NIP "DIYA"
tel;cell:+380679859815
x-mozilla-html:FALSE
version:2.1
end:vcard

Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64

[Alexey Rusakov]

[-- Attachment #1: Type: text/plain, Size: 2045 bytes --]

В Чтв, 06/08/2009 в 10:17 +0300, Roman Savochenko пишет:
> Alexey Rusakov wrote:
> >> Имеется некая целевая задачка собрать из двух 16-разрядных целых 
> >> вещественное (float), 32 разряда.
> >> Казалось-бы тривиальная задача, которая решается кодом типа
> >> int w1 = 62915, w2 = 16456;
> >> ui32 vl = ((w2&0xffff)<<16) | w1&0xffff;
> >> //sleep(1);
> >> printf("TEST 00: %f\n",*(float*)&vl);
> >>
> >> И как ожидалось на x86_32 он работает корректно при различной нагрузке.
> >> А вот на x86_64 замечается ситуация когда вместо 3.14 получаем ноль.
> >> Причём в тестовой программке с единственным потоком всё работает 
> >> нормально, а на высоконагруженном процессе с десятками потоков, из 
> >> которых около пяти работают с периодом 5мс. устойчиво получатся 0.
> >> Если раскомментирую sleep, то получаю номальный результат 3.14.
> >>
> >> Кто нибуть может такое поведение объяснить?
> >>     
> > Объяснить не могу, но поиграйтесь с опциями отладки и оптимизации(-O,
> > -g) и смотрите объектный код, генерируемый компилятором (-S).
> >   
> Да действительно, проблема связана с ключом -O2. Сменил на -O1 всё 
> заработало нормально.
> 
> Багу на компилятор по этому поводу вешать?
Наверное, имеет смысл, хотя бы для истории.

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64

[Michael Shigorin]

On Thu, Aug 06, 2009 at 10:17:09AM +0300, Roman Savochenko wrote:
> Да действительно, проблема связана с ключом -O2. Сменил на -O1
> всё заработало нормально.  Багу на компилятор по этому поводу
> вешать?

Лучше сюда: http://gcc.gnu.org/bugzilla/

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64

[Kirill A. Shutemov]

2009/8/5 Roman Savochenko <rom_as@diyaorg.dp.ua>:
> Приветствую Всех
>
> Имеется некая целевая задачка собрать из двух 16-разрядных целых
> вещественное (float), 32 разряда.
> Казалось-бы тривиальная задача, которая решается кодом типа
> int w1 = 62915, w2 = 16456;
> ui32 vl = ((w2&0xffff)<<16) | w1&0xffff;
> //sleep(1);
> printf("TEST 00: %f\n",*(float*)&vl);
>
> И как ожидалось на x86_32 он работает корректно при различной нагрузке.
> А вот на x86_64 замечается ситуация когда вместо 3.14 получаем ноль.
> Причём в тестовой программке с единственным потоком всё работает нормально,
> а на высоконагруженном процессе с десятками потоков, из которых около пяти
> работают с периодом 5мс. устойчиво получатся 0.
> Если раскомментирую sleep, то получаю номальный результат 3.14.
>
> Кто нибуть может такое поведение объяснить?

Похоже, вы нарушили strict aliasing. Попробуйте собрать с -Wstrict-aliasing=2.
Если будет ругаться, то это наверно оно(см. оговорку в мане насчёт этой опции).

Нарушение strict aliasing может сломать некоторые оптимизации. Два выхода --
или собрать с -fno-strict-aliasing или переписать код корректней.

Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64

[Michael Shigorin]

On Thu, Aug 06, 2009 at 07:21:21PM +0300, I wrote:
> > Багу на компилятор по этому поводу вешать?
> Лучше сюда: http://gcc.gnu.org/bugzilla/

led@ заметил, что в нашей сборке gcc место для багрепортов
заменяется на bugzilla.altlinux.org, и не зря -- патчи ж есть.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64

[Roman Savochenko]

[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]

Kirill A. Shutemov wrote:
>> Имеется некая целевая задачка собрать из двух 16-разрядных целых
>> вещественное (float), 32 разряда.
>> Казалось-бы тривиальная задача, которая решается кодом типа
>> int w1 = 62915, w2 = 16456;
>> ui32 vl = ((w2&0xffff)<<16) | w1&0xffff;
>> //sleep(1);
>> printf("TEST 00: %f\n",*(float*)&vl);
>>
>> И как ожидалось на x86_32 он работает корректно при различной нагрузке.
>> А вот на x86_64 замечается ситуация когда вместо 3.14 получаем ноль.
>> Причём в тестовой программке с единственным потоком всё работает нормально,
>> а на высоконагруженном процессе с десятками потоков, из которых около пяти
>> работают с периодом 5мс. устойчиво получатся 0.
>> Если раскомментирую sleep, то получаю номальный результат 3.14.
>>
>> Кто нибуть может такое поведение объяснить?
>>     
> Похоже, вы нарушили strict aliasing. Попробуйте собрать с -Wstrict-aliasing=2.
> Если будет ругаться, то это наверно оно(см. оговорку в мане насчёт этой опции).
>
> Нарушение strict aliasing может сломать некоторые оптимизации. Два выхода --
> или собрать с -fno-strict-aliasing или переписать код корректней.
>   
Я его записывал уже тремя различными способами с одинаковым результатом. :)

int w1 = 62915, w2 = 16456;
float vl = 0;
*(ui16*)&vl = w1;
*(((ui16*)&vl)+1) = w2;
printf("TEST 00: %f\n",vl);

и

int w1 = 62915, w2 = 16456;
char vl[4];
*(ui16*)vl = w1;
*(((ui16*)vl)+1) = w2;
printf("TEST 00: %f\n",*(float*)vl);

С уважением, Роман

[-- Attachment #2: rom_as.vcf --]
[-- Type: text/x-vcard, Size: 218 bytes --]

begin:vcard
fn:Roman Savochenko
n:Savochenko;Roman
adr;dom:;;;Dneprodzerjinsk
email;internet:rom_as@diyaorg.dp.ua
title:NIP "DIYA"
tel;work:NIP "DIYA"
tel;cell:+380679859815
x-mozilla-html:FALSE
version:2.1
end:vcard

Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64

[Yuriy Kashirin]

On Пятница 07 августа 2009, Roman Savochenko wrote:
> Kirill A. Shutemov wrote:
> >> Имеется некая целевая задачка собрать из двух 16-разрядных целых
> >> вещественное (float), 32 разряда.
> >> Казалось-бы тривиальная задача, которая решается кодом типа
> >> int w1 = 62915, w2 = 16456;
> >> ui32 vl = ((w2&0xffff)<<16) | w1&0xffff;
> >> //sleep(1);
> >> printf("TEST 00: %f\n",*(float*)&vl);
> >>
> >> И как ожидалось на x86_32 он работает корректно при различной
> >> нагрузке. А вот на x86_64 замечается ситуация когда вместо 3.14
> >> получаем ноль. Причём в тестовой программке с единственным
> >> потоком всё работает нормально, а на высоконагруженном процессе
> >> с десятками потоков, из которых около пяти работают с периодом
> >> 5мс. устойчиво получатся 0.
> >> Если раскомментирую sleep, то получаю номальный результат 3.14.
> >>
> >> Кто нибуть может такое поведение объяснить?
> >
> > Похоже, вы нарушили strict aliasing. Попробуйте собрать с
> > -Wstrict-aliasing=2. Если будет ругаться, то это наверно оно(см.
> > оговорку в мане насчёт этой опции).
> >
> > Нарушение strict aliasing может сломать некоторые оптимизации.
> > Два выхода -- или собрать с -fno-strict-aliasing или переписать
> > код корректней.
>
> Я его записывал уже тремя различными способами с одинаковым
> результатом. :)
>
> int w1 = 62915, w2 = 16456;
> float vl = 0;
> *(ui16*)&vl = w1;
> *(((ui16*)&vl)+1) = w2;
> printf("TEST 00: %f\n",vl);
>
> и
>
> int w1 = 62915, w2 = 16456;
> char vl[4];
> *(ui16*)vl = w1;
> *(((ui16*)vl)+1) = w2;
> printf("TEST 00: %f\n",*(float*)vl);

Попробуйте так:

    int w1 = 62915, w2 = 16456;
    union {
      ui32 wl;
      float f;
    } u;
    u.wl = ((w2&0xffff)<<16) | w1&0xffff;
    printf("TEST 00: %f\n", u.f);


-- 
 Best regards
 Yuriy Kashirin

Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64

[Kirill A. Shutemov]

2009/8/7 Roman Savochenko <rom_as@diyaorg.dp.ua>:
> Kirill A. Shutemov wrote:
>>>
>>> Имеется некая целевая задачка собрать из двух 16-разрядных целых
>>> вещественное (float), 32 разряда.
>>> Казалось-бы тривиальная задача, которая решается кодом типа
>>> int w1 = 62915, w2 = 16456;
>>> ui32 vl = ((w2&0xffff)<<16) | w1&0xffff;
>>> //sleep(1);
>>> printf("TEST 00: %f\n",*(float*)&vl);
>>>
>>> И как ожидалось на x86_32 он работает корректно при различной нагрузке.
>>> А вот на x86_64 замечается ситуация когда вместо 3.14 получаем ноль.
>>> Причём в тестовой программке с единственным потоком всё работает
>>> нормально,
>>> а на высоконагруженном процессе с десятками потоков, из которых около
>>> пяти
>>> работают с периодом 5мс. устойчиво получатся 0.
>>> Если раскомментирую sleep, то получаю номальный результат 3.14.
>>>
>>> Кто нибуть может такое поведение объяснить?
>>>
>>
>> Похоже, вы нарушили strict aliasing. Попробуйте собрать с
>> -Wstrict-aliasing=2.
>> Если будет ругаться, то это наверно оно(см. оговорку в мане насчёт этой
>> опции).
>>
>> Нарушение strict aliasing может сломать некоторые оптимизации. Два выхода
>> --
>> или собрать с -fno-strict-aliasing или переписать код корректней.
>>
>
> Я его записывал уже тремя различными способами с одинаковым результатом. :)

И во всех трёх вариантах нарушили strict aliasing. Используйте union.

>
> int w1 = 62915, w2 = 16456;
> float vl = 0;
> *(ui16*)&vl = w1;
> *(((ui16*)&vl)+1) = w2;
> printf("TEST 00: %f\n",vl);
>
> и
>
> int w1 = 62915, w2 = 16456;
> char vl[4];
> *(ui16*)vl = w1;
> *(((ui16*)vl)+1) = w2;
> printf("TEST 00: %f\n",*(float*)vl);
>
> С уважением, Роман
>
> _______________________________________________
> Sisyphus mailing list
> Sisyphus@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/sisyphus
>

Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64

[Roman Savochenko]

[-- Attachment #1: Type: text/plain, Size: 3339 bytes --]

Kirill A. Shutemov wrote:
> 2009/8/7 Roman Savochenko <rom_as@diyaorg.dp.ua>:
>   
>> Kirill A. Shutemov wrote:
>>     
>>>> Имеется некая целевая задачка собрать из двух 16-разрядных целых
>>>> вещественное (float), 32 разряда.
>>>> Казалось-бы тривиальная задача, которая решается кодом типа
>>>> int w1 = 62915, w2 = 16456;
>>>> ui32 vl = ((w2&0xffff)<<16) | w1&0xffff;
>>>> //sleep(1);
>>>> printf("TEST 00: %f\n",*(float*)&vl);
>>>>
>>>> И как ожидалось на x86_32 он работает корректно при различной нагрузке.
>>>> А вот на x86_64 замечается ситуация когда вместо 3.14 получаем ноль.
>>>> Причём в тестовой программке с единственным потоком всё работает
>>>> нормально,
>>>> а на высоконагруженном процессе с десятками потоков, из которых около
>>>> пяти
>>>> работают с периодом 5мс. устойчиво получатся 0.
>>>> Если раскомментирую sleep, то получаю номальный результат 3.14.
>>>>
>>>> Кто нибуть может такое поведение объяснить?
>>>>
>>>>         
>>> Похоже, вы нарушили strict aliasing. Попробуйте собрать с
>>> -Wstrict-aliasing=2.
>>> Если будет ругаться, то это наверно оно(см. оговорку в мане насчёт этой
>>> опции).
>>>       
In file included from statfunc.cpp:25:
sysfnc.h:401: warning: floating constant exceeds range of ‘double’
sysfnc.h: In member function ‘virtual void 
FLibSYS::floatSplitWord::calc(TValFunc*)’:
sysfnc.h:994: warning: dereferencing type-punned pointer will break 
strict-aliasing rules
sysfnc.h:995: warning: dereferencing type-punned pointer will break 
strict-aliasing rules
sysfnc.h: In member function ‘virtual void 
FLibSYS::floatMergeWord::calc(TValFunc*)’:
sysfnc.h:1021: warning: dereferencing type-punned pointer will break 
strict-aliasing rules
>>> Нарушение strict aliasing может сломать некоторые оптимизации. Два выхода
>>> --
>>> или собрать с -fno-strict-aliasing или переписать код корректней.
>>>       
С -fno-strict-aliasing работает.
>> Я его записывал уже тремя различными способами с одинаковым результатом. :)
>>     
> И во всех трёх вариантах нарушили strict aliasing. Используйте union.
>   
С ним работает, но это не решение, поскольку приведенные мною обороты 
распространены и я не уверен что подобных проблем нет в других частях 
моей, в общем-то не маленькой, программы.

В любом случае спасибо за прояснение ситуации. И думаю багу повесить нужно.

С уважением, Роман

[-- Attachment #2: rom_as.vcf --]
[-- Type: text/x-vcard, Size: 202 bytes --]

begin:vcard
fn:Roman Savochenko
n:Savochenko;Roman
email;internet:rom_as@diyaorg.dp.ua
title:NIP "DIYA"
tel;work:NIP "DIYA"
tel;cell:+380679859815
x-mozilla-html:FALSE
version:2.1
end:vcard

Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64

[Kirill A. Shutemov]

2009/8/7 Roman Savochenko <rom_as@diyaorg.dp.ua>:
> Kirill A. Shutemov wrote:
>> И во всех трёх вариантах нарушили strict aliasing. Используйте union.
>>
>
> С ним работает, но это не решение, поскольку приведенные мною обороты
> распространены и я не уверен что подобных проблем нет в других частях моей,
> в общем-то не маленькой, программы.

Есть повод исправить код.

Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64

[Roman Savochenko]

[-- Attachment #1: Type: text/plain, Size: 378 bytes --]

Kirill A. Shutemov wrote:
>>> И во всех трёх вариантах нарушили strict aliasing. Используйте union.
>>  ним работает, но это не решение, поскольку приведенные мною обороты
>> распространены и я не уверен что подобных проблем нет в других частях моей,
>> в общем-то не маленькой, программы.
>>     
> Есть повод исправить код.
>   
Я не считаю его ошибочным.

С уважением, Роман

[-- Attachment #2: rom_as.vcf --]
[-- Type: text/x-vcard, Size: 218 bytes --]

begin:vcard
fn:Roman Savochenko
n:Savochenko;Roman
adr;dom:;;;Dneprodzerjinsk
email;internet:rom_as@diyaorg.dp.ua
title:NIP "DIYA"
tel;work:NIP "DIYA"
tel;cell:+380679859815
x-mozilla-html:FALSE
version:2.1
end:vcard

Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64

[Kirill A. Shutemov]

2009/8/7 Roman Savochenko <rom_as@diyaorg.dp.ua>:
> Kirill A. Shutemov wrote:
>>>>
>>>> И во всех трёх вариантах нарушили strict aliasing. Используйте union.
>>>
>>>  ним работает, но это не решение, поскольку приведенные мною обороты
>>> распространены и я не уверен что подобных проблем нет в других частях
>>> моей,
>>> в общем-то не маленькой, программы.
>>>
>>
>> Есть повод исправить код.
>>
>
> Я не считаю его ошибочным.

Strict aliasing rule -- часть стандарта C99. Если вы хотите писать
быстрый переносимый
код, то вам стоит следовать этому правилу.

Подробней про strict aliaing можно почитать тут:
http://www.cellperformance.com/mike_acton/2006/06/understanding_strict_aliasing.html

Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64

[Roman Savochenko]

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

Kirill A. Shutemov wrote:
>>>>> И во всех трёх вариантах нарушили strict aliasing. Используйте union.
>>>>>           
>>>>  ним работает, но это не решение, поскольку приведенные мною обороты
>>>> распространены и я не уверен что подобных проблем нет в других частях
>>>> моей,
>>>> в общем-то не маленькой, программы.
>>> сть повод исправить код.
>>  не считаю его ошибочным.
>>     
> Strict aliasing rule -- часть стандарта C99. Если вы хотите писать
> быстрый переносимый
> код, то вам стоит следовать этому правилу.
>
> Подробней про strict aliaing можно почитать тут:
> http://www.cellperformance.com/mike_acton/2006/06/understanding_strict_aliasing.html
>   
Not Found
The requested URL 
/articles/mike_acton/2006/06/understanding_strict_aliasing.html was not 
found on this server.
Apache/2.2.4 (Ubuntu) PHP/5.2.3-1ubuntu6.5 mod_ssl/2.2.4 OpenSSL/0.9.8e 
Server at cellperformance.beyond3d.com Port 80

С уважением, Роман

[-- Attachment #2: rom_as.vcf --]
[-- Type: text/x-vcard, Size: 218 bytes --]

begin:vcard
fn:Roman Savochenko
n:Savochenko;Roman
adr;dom:;;;Dneprodzerjinsk
email;internet:rom_as@diyaorg.dp.ua
title:NIP "DIYA"
tel;work:NIP "DIYA"
tel;cell:+380679859815
x-mozilla-html:FALSE
version:2.1
end:vcard

Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64

[Alexey Rusakov]

[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]

В Птн, 07/08/2009 в 11:54 +0300, Kirill A. Shutemov пишет:
> 2009/8/7 Roman Savochenko <rom_as@diyaorg.dp.ua>:
> > Kirill A. Shutemov wrote:
> >>>>
> >>>> И во всех трёх вариантах нарушили strict aliasing. Используйте union.
> >>>
> >>>  ним работает, но это не решение, поскольку приведенные мною обороты
> >>> распространены и я не уверен что подобных проблем нет в других частях
> >>> моей,
> >>> в общем-то не маленькой, программы.
> >>>
> >>
> >> Есть повод исправить код.
> >>
> >
> > Я не считаю его ошибочным.
> 
> Strict aliasing rule -- часть стандарта C99. Если вы хотите писать
> быстрый переносимый
> код, то вам стоит следовать этому правилу.
> 
> Подробней про strict aliaing можно почитать тут:
> http://www.cellperformance.com/mike_acton/2006/06/understanding_strict_aliasing.html
Подозрительная ссылка. Во-первых, сайт не нравится Гуглу ("...атакует
компьютеры"), во-вторых, сама по себе ссылка битая.

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64

[Roman Savochenko]

[-- Attachment #1: Type: text/plain, Size: 830 bytes --]

Kirill A. Shutemov wrote:
> 2009/8/7 Roman Savochenko <rom_as@diyaorg.dp.ua>:
>   
>> Kirill A. Shutemov wrote:
>>     
>>>>> И во всех трёх вариантах нарушили strict aliasing. Используйте union.
>>>>>           
>>>>  ним работает, но это не решение, поскольку приведенные мною обороты
>>>> распространены и я не уверен что подобных проблем нет в других частях
>>>> моей,
>>>> в общем-то не маленькой, программы.
>>>>
>>>>         
>>> Есть повод исправить код.
>>>
>>>       
>> Я не считаю его ошибочным.
>>     
> Strict aliasing rule -- часть стандарта C99. Если вы хотите писать
> быстрый переносимый
> код, то вам стоит следовать этому правилу.
>   
Ничего про стандартность тут 
http://en.wikipedia.org/wiki/Aliasing_(computing) не увидил. А про то 
что существуют конфликты с оптимизаторами там есть.

С уважением, Роман

[-- Attachment #2: rom_as.vcf --]
[-- Type: text/x-vcard, Size: 218 bytes --]

begin:vcard
fn:Roman Savochenko
n:Savochenko;Roman
adr;dom:;;;Dneprodzerjinsk
email;internet:rom_as@diyaorg.dp.ua
title:NIP "DIYA"
tel;work:NIP "DIYA"
tel;cell:+380679859815
x-mozilla-html:FALSE
version:2.1
end:vcard

Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64

[Kirill A. Shutemov]

2009/8/7 Roman Savochenko <rom_as@diyaorg.dp.ua>:
> Kirill A. Shutemov wrote:
>>>>>>
>>>>>> И во всех трёх вариантах нарушили strict aliasing. Используйте union.
>>>>>>
>>>>>
>>>>>  ним работает, но это не решение, поскольку приведенные мною обороты
>>>>> распространены и я не уверен что подобных проблем нет в других частях
>>>>> моей,
>>>>> в общем-то не маленькой, программы.
>>>>
>>>> сть повод исправить код.
>>>
>>>  не считаю его ошибочным.
>>>
>>
>> Strict aliasing rule -- часть стандарта C99. Если вы хотите писать
>> быстрый переносимый
>> код, то вам стоит следовать этому правилу.
>>
>> Подробней про strict aliaing можно почитать тут:
>>
>> http://www.cellperformance.com/mike_acton/2006/06/understanding_strict_aliasing.html
>>
>
> Not Found
> The requested URL
> /articles/mike_acton/2006/06/understanding_strict_aliasing.html was not
> found on this server.
> Apache/2.2.4 (Ubuntu) PHP/5.2.3-1ubuntu6.5 mod_ssl/2.2.4 OpenSSL/0.9.8e
> Server at cellperformance.beyond3d.com Port 80

Да, похоже оно со вчера успело перехать, а у меня в кэше браузера осталось.

http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html

Must read.

Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64

[Alexey Rusakov]

[-- Attachment #1: Type: text/plain, Size: 1672 bytes --]

В Птн, 07/08/2009 в 12:02 +0300, Roman Savochenko пишет:
> Kirill A. Shutemov wrote:
> > 2009/8/7 Roman Savochenko <rom_as@diyaorg.dp.ua>:
> >   
> >> Kirill A. Shutemov wrote:
> >>     
> >>>>> И во всех трёх вариантах нарушили strict aliasing. Используйте union.
> >>>>>           
> >>>>  ним работает, но это не решение, поскольку приведенные мною обороты
> >>>> распространены и я не уверен что подобных проблем нет в других частях
> >>>> моей,
> >>>> в общем-то не маленькой, программы.
> >>>>
> >>>>         
> >>> Есть повод исправить код.
> >>>
> >>>       
> >> Я не считаю его ошибочным.
> >>     
> > Strict aliasing rule -- часть стандарта C99. Если вы хотите писать
> > быстрый переносимый
> > код, то вам стоит следовать этому правилу.
> >   
> Ничего про стандартность тут 
> http://en.wikipedia.org/wiki/Aliasing_(computing) не увидил. А про то 
> что существуют конфликты с оптимизаторами там есть.
Смотрите внимательнее:
"...the ISO standard for the C programming language (including its newer
C99 edition) specifies that it is illegal (with some exceptions) for
pointers of different types to reference the same memory location."

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64

[Serge Ryabchun]

Это не повод собирать не верный код:

[sr@sr 6]$ gcc-4.3 -Wall -O2 f2.c
f2.c: In function 'main':
f2.c:10: warning: dereferencing type-punned pointer will break
strict-aliasing rules
[sr@sr 6]$ ./a.out
TEST 00: 0.000000
[sr@sr 6]$
[sr@sr 6]$ gcc-4.4 -Wall -O2 f2.c
f2.c: In function 'main':
f2.c:10: warning: dereferencing type-punned pointer will break
strict-aliasing rules
[sr@sr 6]$ ./a.out
TEST 00: 3.140000

2009/8/7 Alexey Rusakov <ktirf@altlinux.org>:
> В Птн, 07/08/2009 в 12:02 +0300, Roman Savochenko пишет:
>> Kirill A. Shutemov wrote:
>> > 2009/8/7 Roman Savochenko <rom_as@diyaorg.dp.ua>:
>> >
>> >> Kirill A. Shutemov wrote:
>> >>
>> >>>>> И во всех трёх вариантах нарушили strict aliasing. Используйте union.
>> >>>>>
>> >>>>  ним работает, но это не решение, поскольку приведенные мною обороты
>> >>>> распространены и я не уверен что подобных проблем нет в других частях
>> >>>> моей,
>> >>>> в общем-то не маленькой, программы.
>> >>>>
>> >>>>
>> >>> Есть повод исправить код.
>> >>>
>> >>>
>> >> Я не считаю его ошибочным.
>> >>
>> > Strict aliasing rule -- часть стандарта C99. Если вы хотите писать
>> > быстрый переносимый
>> > код, то вам стоит следовать этому правилу.
>> >
>> Ничего про стандартность тут
>> http://en.wikipedia.org/wiki/Aliasing_(computing) не увидил. А про то
>> что существуют конфликты с оптимизаторами там есть.
> Смотрите внимательнее:
> "...the ISO standard for the C programming language (including its newer
> C99 edition) specifies that it is illegal (with some exceptions) for
> pointers of different types to reference the same memory location."
>
> --
>  Alexey "Ktirf" Rusakov
>  GNOME Project
>  ALT Linux Team
>
> _______________________________________________
> Sisyphus mailing list
> Sisyphus@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/sisyphus
>



-- 
Рябчун Сергей <serge.ryabchun@gmail.com>

Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64

[Alexey Rusakov]

[-- Attachment #1: Type: text/plain, Size: 3148 bytes --]

В Птн, 07/08/2009 в 15:59 +0300, Serge Ryabchun пишет: 
> Это не повод собирать не верный код:
> 
> [sr@sr 6]$ gcc-4.3 -Wall -O2 f2.c
> f2.c: In function 'main':
> f2.c:10: warning: dereferencing type-punned pointer will break
> strict-aliasing rules
> [sr@sr 6]$ ./a.out
> TEST 00: 0.000000
> [sr@sr 6]$
> [sr@sr 6]$ gcc-4.4 -Wall -O2 f2.c
> f2.c: In function 'main':
> f2.c:10: warning: dereferencing type-punned pointer will break
> strict-aliasing rules
> [sr@sr 6]$ ./a.out
> TEST 00: 3.140000
По-моему, это вопрос из разряда разрешённости к использованию
конструкции reinterpret_cast<> в С++. Некоторые пользуются. На некоторых
архитектурах и в некоторых условиях результат даже работает. В данном
случае не повезло. Это C, в нём можно почти всё, в том числе и
непринуждённым движением прострелить себе ногу.

> 2009/8/7 Alexey Rusakov <ktirf@altlinux.org>:
> > В Птн, 07/08/2009 в 12:02 +0300, Roman Savochenko пишет:
> >> Kirill A. Shutemov wrote:
> >> > 2009/8/7 Roman Savochenko <rom_as@diyaorg.dp.ua>:
> >> >
> >> >> Kirill A. Shutemov wrote:
> >> >>
> >> >>>>> И во всех трёх вариантах нарушили strict aliasing. Используйте union.
> >> >>>>>
> >> >>>>  ним работает, но это не решение, поскольку приведенные мною обороты
> >> >>>> распространены и я не уверен что подобных проблем нет в других частях
> >> >>>> моей,
> >> >>>> в общем-то не маленькой, программы.
> >> >>>>
> >> >>>>
> >> >>> Есть повод исправить код.
> >> >>>
> >> >>>
> >> >> Я не считаю его ошибочным.
> >> >>
> >> > Strict aliasing rule -- часть стандарта C99. Если вы хотите писать
> >> > быстрый переносимый
> >> > код, то вам стоит следовать этому правилу.
> >> >
> >> Ничего про стандартность тут
> >> http://en.wikipedia.org/wiki/Aliasing_(computing) не увидил. А про то
> >> что существуют конфликты с оптимизаторами там есть.
> > Смотрите внимательнее:
> > "...the ISO standard for the C programming language (including its newer
> > C99 edition) specifies that it is illegal (with some exceptions) for
> > pointers of different types to reference the same memory location."
> >
> > --
> >  Alexey "Ktirf" Rusakov
> >  GNOME Project
> >  ALT Linux Team
> >
> > _______________________________________________
> > Sisyphus mailing list
> > Sisyphus@lists.altlinux.org
> > https://lists.altlinux.org/mailman/listinfo/sisyphus

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64

[Kirill A. Shutemov]

2009/8/7 Serge Ryabchun <sr@osdn.org.ua>:
> Это не повод собирать не верный код:
>
> [sr@sr 6]$ gcc-4.3 -Wall -O2 f2.c
> f2.c: In function 'main':
> f2.c:10: warning: dereferencing type-punned pointer will break
> strict-aliasing rules
> [sr@sr 6]$ ./a.out
> TEST 00: 0.000000
> [sr@sr 6]$
> [sr@sr 6]$ gcc-4.4 -Wall -O2 f2.c
> f2.c: In function 'main':
> f2.c:10: warning: dereferencing type-punned pointer will break
> strict-aliasing rules
> [sr@sr 6]$ ./a.out
> TEST 00: 3.140000

Это ничего не значит. Точнее значит лишь то, что работа оптимизатора
различается между версиями компилятора.

То, что криво написаный код иногда работает -- не аргумент. Если вы
желаете отказаться от подбного рода оптимизиций -- используйте
-fno-strict-aliasing.

>
> 2009/8/7 Alexey Rusakov <ktirf@altlinux.org>:
>> В Птн, 07/08/2009 в 12:02 +0300, Roman Savochenko пишет:
>>> Kirill A. Shutemov wrote:
>>> > 2009/8/7 Roman Savochenko <rom_as@diyaorg.dp.ua>:
>>> >
>>> >> Kirill A. Shutemov wrote:
>>> >>
>>> >>>>> И во всех трёх вариантах нарушили strict aliasing. Используйте union.
>>> >>>>>
>>> >>>>  ним работает, но это не решение, поскольку приведенные мною обороты
>>> >>>> распространены и я не уверен что подобных проблем нет в других частях
>>> >>>> моей,
>>> >>>> в общем-то не маленькой, программы.
>>> >>>>
>>> >>>>
>>> >>> Есть повод исправить код.
>>> >>>
>>> >>>
>>> >> Я не считаю его ошибочным.
>>> >>
>>> > Strict aliasing rule -- часть стандарта C99. Если вы хотите писать
>>> > быстрый переносимый
>>> > код, то вам стоит следовать этому правилу.
>>> >
>>> Ничего про стандартность тут
>>> http://en.wikipedia.org/wiki/Aliasing_(computing) не увидил. А про то
>>> что существуют конфликты с оптимизаторами там есть.
>> Смотрите внимательнее:
>> "...the ISO standard for the C programming language (including its newer
>> C99 edition) specifies that it is illegal (with some exceptions) for
>> pointers of different types to reference the same memory location."
>>
>> --
>>  Alexey "Ktirf" Rusakov
>>  GNOME Project
>>  ALT Linux Team
>>
>> _______________________________________________
>> Sisyphus mailing list
>> Sisyphus@lists.altlinux.org
>> https://lists.altlinux.org/mailman/listinfo/sisyphus
>>
>
>
>
> --
> Рябчун Сергей <serge.ryabchun@gmail.com>
> _______________________________________________
> Sisyphus mailing list
> Sisyphus@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/sisyphus

Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64

[Kirill A. Shutemov]

2009/8/13 Victor Forsyuk <force@altlinux.org>:
>
>
> 2009/8/7 Kirill A. Shutemov <kirill@shutemov.name>
>>
>> 2009/8/7 Serge Ryabchun <sr@osdn.org.ua>:
>> > Это не повод собирать не верный код:
>> >
>> > [sr@sr 6]$ gcc-4.3 -Wall -O2 f2.c
>> > f2.c: In function 'main':
>> > f2.c:10: warning: dereferencing type-punned pointer will break
>> > strict-aliasing rules
>> > [sr@sr 6]$ ./a.out
>> > TEST 00: 0.000000
>> > [sr@sr 6]$
>> > [sr@sr 6]$ gcc-4.4 -Wall -O2 f2.c
>> > f2.c: In function 'main':
>> > f2.c:10: warning: dereferencing type-punned pointer will break
>> > strict-aliasing rules
>> > [sr@sr 6]$ ./a.out
>> > TEST 00: 3.140000
>>
>> Это ничего не значит. Точнее значит лишь то, что работа оптимизатора
>> различается между версиями компилятора.
>>
>> То, что криво написаный код иногда работает -- не аргумент. Если вы
>> желаете отказаться от подбного рода оптимизиций -- используйте
>> -fno-strict-aliasing.
>>
>
> Я вот сижу и думаю (нет, это не по поводу этого кода), если даже с полностью
> выключенной оптимизацией компилятор (gcc 4.4) создает код, отказывающийся
> работать, тогда как скомпилированный gcc 4.3 работает - стоит разбираться с
> кодом или это в любом случае регрессия компилятора?

Зависит от.

> Кому-то интересно будет посмотреть?

Давай. Только не два мегабайта кода. Локализуй до 50-100 строк, не больше.

Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64

[Alexander Bokovoy]

2009/8/17 Victor Forsyuk <force@altlinux.org>:
> Проблема обнаружилась в liblensfun. Эту библиотеку сейчас использует ufraw.
> Скомпилированный при помощи gcc 4.3 код отлично работает в ufraw. Для
> компиляции gcc 4.4 пришлось приложить патчик на тему const char, но он тут
> даже теоретически не может быть при чем, поскольку чинит сборку своего
> makedep и ABI посему никак сломать не мог.
>
> Если использовать gcc 4.4, то даже с "-O0" компилируется нерабочий код.
> Симптом: ufraw при открытии любого файла зависает, вероятно где-то
> зацикливаясь(?).
Опс. А я думал, это мое устройство неправильные jpeg-и делает, что
gimp зависает на их открытии именно внутри ufraw.
Оставлю за рамками выбор GIMPа использовать ufraw для открытия jpeg, у
меня этот случай сто процентов воспроизводится.

-- 
/ Alexander Bokovoy

Re: [sisyphus] ufraw/liblensfun/etc vs gcc

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]

On Mon, Aug 17, 2009 at 06:25:39PM +0300, Victor Forsyuk wrote:
> 2009/8/13 Kirill A. Shutemov <kirill@shutemov.name>
[...]
> > > Я вот сижу и думаю (нет, это не по поводу этого кода), если даже с
> > полностью
> > > выключенной оптимизацией компилятор (gcc 4.4) создает код, отказывающийся
> > > работать, тогда как скомпилированный gcc 4.3 работает - стоит разбираться
> > с
> > > кодом или это в любом случае регрессия компилятора?
> >
> > Зависит от.
> >
> > > Кому-то интересно будет посмотреть?
> >
> > Давай. Только не два мегабайта кода. Локализуй до 50-100 строк, не больше.
> >
> Если бы у меня было время всё бросить и сесть с отладчиком локализуя до 100
> строк кода я бы не отказал себе в удовольствии самому покопаться. Но эта
> задача у меня в самом конце TODO, а если это действительно баг в gcc, то его
> стоило бы локализовать пораньше...
> 
> Проблема обнаружилась в liblensfun. Эту библиотеку сейчас использует ufraw.
> Скомпилированный при помощи gcc 4.3 код отлично работает в ufraw. Для
> компиляции gcc 4.4 пришлось приложить патчик на тему const char, но он тут
> даже теоретически не может быть при чем, поскольку чинит сборку своего
> makedep и ABI посему никак сломать не мог.
> 
> Если использовать gcc 4.4, то даже с "-O0" компилируется нерабочий код.
> Симптом: ufraw при открытии любого файла зависает, вероятно где-то
> зацикливаясь(?).

На каких версиях пакетов ufraw+liblensfun+... это воспроизводится?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] ufraw/liblensfun/etc vs gcc

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]

On Mon, Aug 17, 2009 at 11:54:51PM +0300, Victor Forsyuk wrote:
> 2009/8/17 Dmitry V. Levin <ldv@altlinux.org>
> 
> > > Проблема обнаружилась в liblensfun. Эту библиотеку сейчас использует
> > ufraw.
> > > Скомпилированный при помощи gcc 4.3 код отлично работает в ufraw. Для
> > > компиляции gcc 4.4 пришлось приложить патчик на тему const char, но он
> > тут
> > > даже теоретически не может быть при чем, поскольку чинит сборку своего
> > > makedep и ABI посему никак сломать не мог.
> > >
> > > Если использовать gcc 4.4, то даже с "-O0" компилируется нерабочий код.
> > > Симптом: ufraw при открытии любого файла зависает, вероятно где-то
> > > зацикливаясь(?).
> >
> > На каких версиях пакетов ufraw+liblensfun+... это воспроизводится?
> >
> На текущем ufraw и сборке liblensfun 0.2.3-alt3 (в сизифе уже рабочая -alt4
> собранная gcc 4.3).

$ ufraw --help
(ufraw:12345): Gtk-WARNING **: cannot open display: 
$ ldd /usr/bin/ufraw |wc -l
51

Ну и софтинка...  Где бы ей найти "любой файл" поменьше?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] liblensfun

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1487 bytes --]

On Thu, Aug 13, 2009 at 07:04:39PM +0300, Kirill A. Shutemov wrote:
> 2009/8/13 Victor Forsyuk <force@altlinux.org>:
[...]
> > Я вот сижу и думаю (нет, это не по поводу этого кода), если даже с полностью
> > выключенной оптимизацией компилятор (gcc 4.4) создает код, отказывающийся
> > работать, тогда как скомпилированный gcc 4.3 работает - стоит разбираться с
> > кодом или это в любом случае регрессия компилятора?
> 
> Зависит от.
> 
> > Кому-то интересно будет посмотреть?
> 
> Давай. Только не два мегабайта кода. Локализуй до 50-100 строк, не больше.

792	    for (i = 0; ; i++)
793	    {
794	        const char *model_name;
795	        lfTCAModel model = LF_TCA_MODEL_NONE + i;
796	        model_name = lf_get_tca_model_desc (model, NULL, NULL);
797	        if (!model_name)
798	            break;
799	        gtk_combo_box_append_text (GTK_COMBO_BOX (data->LensTCAModel), model_name);
800	        if (model == CFG->lens_tca.Model)
801	            active_index = i;
802	    }

При выполнении ufraw_lens_ui.c:798 происходит stack corruption.
Вызов lf_get_tca_model_desc ведёт в странно собирающуюся cpp'шную библиотеку
liblensfun, про использование которой в ufraw пишут забавные вещи:
http://ufraw.sourceforge.net/lensfun.html

В debian на lensfun есть патчи, добавляющие поддержку современных камер,
однако ufraw они собирают без lensfun.
В FC ufraw с lensfun собирают вот так:
https://bugzilla.redhat.com/show_bug.cgi?id=517558


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] ufraw/liblensfun/etc vs gcc

[Anton V. Boyarshinov]

> Ну и софтинка...  Где бы ей найти "любой файл" поменьше?
Поменьше не обещаю, но см каталог altair:/home/boyarsh/nef

Re: [sisyphus] liblensfun

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]

On Tue, Aug 18, 2009 at 02:39:24AM +0400, Dmitry V. Levin wrote:
> On Thu, Aug 13, 2009 at 07:04:39PM +0300, Kirill A. Shutemov wrote:
> > 2009/8/13 Victor Forsyuk <force@altlinux.org>:
> [...]
> > > Я вот сижу и думаю (нет, это не по поводу этого кода), если даже с полностью
> > > выключенной оптимизацией компилятор (gcc 4.4) создает код, отказывающийся
> > > работать, тогда как скомпилированный gcc 4.3 работает - стоит разбираться с
> > > кодом или это в любом случае регрессия компилятора?
> > 
> > Зависит от.
> > 
> > > Кому-то интересно будет посмотреть?
> > 
> > Давай. Только не два мегабайта кода. Локализуй до 50-100 строк, не больше.
> 
> 792	    for (i = 0; ; i++)
> 793	    {
> 794	        const char *model_name;
> 795	        lfTCAModel model = LF_TCA_MODEL_NONE + i;
> 796	        model_name = lf_get_tca_model_desc (model, NULL, NULL);
> 797	        if (!model_name)
> 798	            break;
> 799	        gtk_combo_box_append_text (GTK_COMBO_BOX (data->LensTCAModel), model_name);
> 800	        if (model == CFG->lens_tca.Model)
> 801	            active_index = i;
> 802	    }
> 
> При выполнении ufraw_lens_ui.c:798 происходит stack corruption.
> Вызов lf_get_tca_model_desc ведёт в странно собирающуюся cpp'шную библиотеку
> liblensfun, про использование которой в ufraw пишут забавные вещи:
> http://ufraw.sourceforge.net/lensfun.html

Попробовал свежий компилятор и посмотрел немного внимательнее.
То, что я сперва принял за stack corruption, таковым не является, но вот
внутри lfLens::GetTCAModelDesc действительно происходят странные вещи,
в результате которых вышепроцитированный цикл не прекращается.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] liblensfun vs g++

[Dmitry V. Levin]

[-- Attachment #1.1: Type: text/plain, Size: 1000 bytes --]

On Mon, Aug 17, 2009 at 06:25:39PM +0300, Victor Forsyuk wrote:
[...]
> Если бы у меня было время всё бросить и сесть с отладчиком локализуя до 100
> строк кода я бы не отказал себе в удовольствии самому покопаться. Но эта
> задача у меня в самом конце TODO, а если это действительно баг в gcc, то его
> стоило бы локализовать пораньше...
> 
> Проблема обнаружилась в liblensfun. Эту библиотеку сейчас использует ufraw.
> Скомпилированный при помощи gcc 4.3 код отлично работает в ufraw. Для
> компиляции gcc 4.4 пришлось приложить патчик на тему const char, но он тут
> даже теоретически не может быть при чем, поскольку чинит сборку своего
> makedep и ABI посему никак сломать не мог.
> 
> Если использовать gcc 4.4, то даже с "-O0" компилируется нерабочий код.
> Симптом: ufraw при открытии любого файла зависает, вероятно где-то
> зацикливаясь(?).

Поведение g++ изменилось между 4.3 и 4.4; если это не regression, то, видимо,
надо патчить liblensfun (см. патч).


-- 
ldv

[-- Attachment #1.2: lensfun-0.2.3-alt-gcc44.diff --]
[-- Type: text/plain, Size: 1060 bytes --]

--- lensfun/libs/lensfun/lens.cpp
+++ lensfun/libs/lensfun/lens.cpp
@@ -301,6 +301,7 @@ const char *lfLens::GetDistortionModelDesc (
             if (params)
                 *params = param_ptlens;
             return "PanoTools lens model";
+        default: break;
     }
 
     if (details)
@@ -335,6 +336,7 @@ const char *lfLens::GetTCAModelDesc (
             if (params)
                 *params = param_linear;
             return "Linear";
+        default: break;
     }
 
     if (details)
@@ -372,6 +374,7 @@ const char *lfLens::GetVignettingModelDesc (
             if (params)
                 *params = param_pa;
             return "6th order polynomial";
+        default: break;
     }
 
     if (details)
@@ -405,6 +408,7 @@ const char *lfLens::GetLensTypeDesc (lfLensType type, const char **details)
             if (details)
                 *details = "Ref: http://wiki.panotools.org/Equirectangular_Projection";
             return "Equirectangular";
+        default: break;
     }
 
     if (details)

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] liblensfun vs g++

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 2288 bytes --]

On Wed, Aug 19, 2009 at 04:41:07AM +0400, Dmitry V. Levin wrote:
> Поведение g++ изменилось между 4.3 и 4.4; если это не regression, то, видимо,
> надо патчить liblensfun (см. патч).

Testcase попроще:

-----------------------------------------------------------------------
#include <stdio.h>

enum TestEnum
{
	TEST_0,
	TEST_1
};

#ifndef __cplusplus
typedef enum TestEnum TestEnum;
#endif

#ifdef __cplusplus
extern "C"
#endif
void print_value(TestEnum x)
{
	switch (x) {

	  case TEST_0:
		printf("TEST_0\n");
		return;

	  case TEST_1:
		printf("TEST_1\n");
		return;
	}
	printf("BAD\n");
}

int main(int argc, char *argv[])
{
	(void)argc; (void)argv;

	print_value(TEST_0);
	print_value(TEST_1);
	print_value((TestEnum)2);
	return 0;
}
-----------------------------------------------------------------------

При компиляции этого кода как C он работает ожидаемым образом:

$ gcc -g -O2 -Wall -W -o enum_test enum_test.c     
$ ./enum_test                                 
TEST_0
TEST_1
BAD

А вот при компиляции как C++ происходит странное:

$ g++ -g -O2 -Wall -W -o enum_test enum_test.c     
$ ./enum_test                                 
TEST_0
TEST_1
TEST_0

(и даже с -O0 этот результат не меняется).

Формально стандартом C++98 подобное поведение не запрещено - результат
преобразования целочисленного значения в enum-тип не определён в
случае, когда значение не входит в диапазон значений этого enum:

  5.2.9/7:
    A value of integral type can be explicitly converted to an
    enumeration type. The value is unchanged if the integral value is
    within the range of the enumeration values (7.2). Otherwise, the
    resulting enumeration value is unspecified.

(причём для "unspecified behavior" не обязательно даже документировать
поведение в таких случаях).

С точки зрения C++98 ошибочный код в данном случае - (TestEnum)2;
в комбинации ufraw+liblensfun ситуация усугубляется тем, что
преобразование в enum выполняется в коде на C, для которого enum
практически не отличается от целочисленного типа.

Что интересно - такое поведение компилятора наблюдается только для
enum с двумя константами; при добавлении третьей константы проверки на
недопустимое для enum значение не исчезают.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] liblensfun vs g++

[Damir]

> Что интересно - такое поведение компилятора наблюдается только для
> enum с двумя константами; при добавлении третьей константы проверки на
> недопустимое для enum значение не исчезают.

Скорее всего, там switch заменяется на просто if else.

Re: [sisyphus] liblensfun vs g++

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

On Wed, Aug 19, 2009 at 12:33:21PM +0400, Damir wrote:
> On Wed, Aug 19, 2009 at 12:27:44PM +0400, Sergey Vlasov wrote:
> > On Wed, Aug 19, 2009 at 04:41:07AM +0400, Dmitry V. Levin wrote:
> > > Поведение g++ изменилось между 4.3 и 4.4; если это не regression, то,
> > > видимо, надо патчить liblensfun (см. патч).
> > 
> > Что интересно - такое поведение компилятора наблюдается только для
> > enum с двумя константами; при добавлении третьей константы проверки на
> > недопустимое для enum значение не исчезают.
> 
> Скорее всего, там switch заменяется на просто if else.

Это всё понятно.  Непонятно, это g++ regression или вольная трактовка
undefined behavior?  В любом случае рекомендую Виктору приложить патч на
liblensfun и отправить его upstream.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]