ALT Linux Sisyphus discussions
 help / color / mirror / Atom feed
* [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64
@ 2009-08-05 17:08 Roman Savochenko
  2009-08-05 21:34 ` Alexey Rusakov
  2009-08-06 18:12 ` Kirill A. Shutemov
  0 siblings, 2 replies; 33+ messages in thread
From: Roman Savochenko @ 2009-08-05 17:08 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

[-- 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


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64
  2009-08-05 17:08 [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64 Roman Savochenko
@ 2009-08-05 21:34 ` Alexey Rusakov
  2009-08-06  7:17   ` Roman Savochenko
  2009-08-06 18:12 ` Kirill A. Shutemov
  1 sibling, 1 reply; 33+ messages in thread
From: Alexey Rusakov @ 2009-08-05 21:34 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

[-- 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 --]

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64
  2009-08-05 21:34 ` Alexey Rusakov
@ 2009-08-06  7:17   ` Roman Savochenko
  2009-08-06  7:59     ` Alexey Rusakov
  2009-08-06 16:21     ` Michael Shigorin
  0 siblings, 2 replies; 33+ messages in thread
From: Roman Savochenko @ 2009-08-06  7:17 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

[-- 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


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64
  2009-08-06  7:17   ` Roman Savochenko
@ 2009-08-06  7:59     ` Alexey Rusakov
  2009-08-06 16:21     ` Michael Shigorin
  1 sibling, 0 replies; 33+ messages in thread
From: Alexey Rusakov @ 2009-08-06  7:59 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

[-- 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 --]

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64
  2009-08-06  7:17   ` Roman Savochenko
  2009-08-06  7:59     ` Alexey Rusakov
@ 2009-08-06 16:21     ` Michael Shigorin
  2009-08-06 21:10       ` Michael Shigorin
  1 sibling, 1 reply; 33+ messages in thread
From: Michael Shigorin @ 2009-08-06 16:21 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

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/


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64
  2009-08-05 17:08 [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64 Roman Savochenko
  2009-08-05 21:34 ` Alexey Rusakov
@ 2009-08-06 18:12 ` Kirill A. Shutemov
  2009-08-07  5:49   ` Roman Savochenko
  1 sibling, 1 reply; 33+ messages in thread
From: Kirill A. Shutemov @ 2009-08-06 18:12 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

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 или переписать код корректней.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64
  2009-08-06 16:21     ` Michael Shigorin
@ 2009-08-06 21:10       ` Michael Shigorin
  0 siblings, 0 replies; 33+ messages in thread
From: Michael Shigorin @ 2009-08-06 21:10 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

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/


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64
  2009-08-06 18:12 ` Kirill A. Shutemov
@ 2009-08-07  5:49   ` Roman Savochenko
  2009-08-07  6:28     ` Yuriy Kashirin
  2009-08-07  6:31     ` Kirill A. Shutemov
  0 siblings, 2 replies; 33+ messages in thread
From: Roman Savochenko @ 2009-08-07  5:49 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

[-- 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


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64
  2009-08-07  5:49   ` Roman Savochenko
@ 2009-08-07  6:28     ` Yuriy Kashirin
  2009-08-07  6:31     ` Kirill A. Shutemov
  1 sibling, 0 replies; 33+ messages in thread
From: Yuriy Kashirin @ 2009-08-07  6:28 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

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



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64
  2009-08-07  5:49   ` Roman Savochenko
  2009-08-07  6:28     ` Yuriy Kashirin
@ 2009-08-07  6:31     ` Kirill A. Shutemov
  2009-08-07  7:14       ` Roman Savochenko
  1 sibling, 1 reply; 33+ messages in thread
From: Kirill A. Shutemov @ 2009-08-07  6:31 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

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
>

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64
  2009-08-07  6:31     ` Kirill A. Shutemov
@ 2009-08-07  7:14       ` Roman Savochenko
  2009-08-07  7:35         ` Kirill A. Shutemov
  0 siblings, 1 reply; 33+ messages in thread
From: Roman Savochenko @ 2009-08-07  7:14 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

[-- 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


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64
  2009-08-07  7:14       ` Roman Savochenko
@ 2009-08-07  7:35         ` Kirill A. Shutemov
  2009-08-07  8:14           ` Roman Savochenko
  0 siblings, 1 reply; 33+ messages in thread
From: Kirill A. Shutemov @ 2009-08-07  7:35 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

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

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64
  2009-08-07  7:35         ` Kirill A. Shutemov
@ 2009-08-07  8:14           ` Roman Savochenko
  2009-08-07  8:54             ` Kirill A. Shutemov
  0 siblings, 1 reply; 33+ messages in thread
From: Roman Savochenko @ 2009-08-07  8:14 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

[-- 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


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64
  2009-08-07  8:14           ` Roman Savochenko
@ 2009-08-07  8:54             ` Kirill A. Shutemov
  2009-08-07  8:57               ` Roman Savochenko
                                 ` (2 more replies)
  0 siblings, 3 replies; 33+ messages in thread
From: Kirill A. Shutemov @ 2009-08-07  8:54 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64
  2009-08-07  8:54             ` Kirill A. Shutemov
@ 2009-08-07  8:57               ` Roman Savochenko
  2009-08-07  9:14                 ` Kirill A. Shutemov
  2009-08-07  8:58               ` Alexey Rusakov
  2009-08-07  9:02               ` Roman Savochenko
  2 siblings, 1 reply; 33+ messages in thread
From: Roman Savochenko @ 2009-08-07  8:57 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

[-- 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


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64
  2009-08-07  8:54             ` Kirill A. Shutemov
  2009-08-07  8:57               ` Roman Savochenko
@ 2009-08-07  8:58               ` Alexey Rusakov
  2009-08-07  9:02               ` Roman Savochenko
  2 siblings, 0 replies; 33+ messages in thread
From: Alexey Rusakov @ 2009-08-07  8:58 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

[-- 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 --]

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64
  2009-08-07  8:54             ` Kirill A. Shutemov
  2009-08-07  8:57               ` Roman Savochenko
  2009-08-07  8:58               ` Alexey Rusakov
@ 2009-08-07  9:02               ` Roman Savochenko
  2009-08-07  9:17                 ` Alexey Rusakov
  2 siblings, 1 reply; 33+ messages in thread
From: Roman Savochenko @ 2009-08-07  9:02 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

[-- 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


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64
  2009-08-07  8:57               ` Roman Savochenko
@ 2009-08-07  9:14                 ` Kirill A. Shutemov
  0 siblings, 0 replies; 33+ messages in thread
From: Kirill A. Shutemov @ 2009-08-07  9:14 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

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.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64
  2009-08-07  9:02               ` Roman Savochenko
@ 2009-08-07  9:17                 ` Alexey Rusakov
  2009-08-07 12:59                   ` Serge Ryabchun
  0 siblings, 1 reply; 33+ messages in thread
From: Alexey Rusakov @ 2009-08-07  9:17 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

[-- 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 --]

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64
  2009-08-07  9:17                 ` Alexey Rusakov
@ 2009-08-07 12:59                   ` Serge Ryabchun
  2009-08-07 13:15                     ` Alexey Rusakov
  2009-08-07 15:43                     ` Kirill A. Shutemov
  0 siblings, 2 replies; 33+ messages in thread
From: Serge Ryabchun @ 2009-08-07 12:59 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

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

[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>

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64
  2009-08-07 12:59                   ` Serge Ryabchun
@ 2009-08-07 13:15                     ` Alexey Rusakov
  2009-08-07 15:43                     ` Kirill A. Shutemov
  1 sibling, 0 replies; 33+ messages in thread
From: Alexey Rusakov @ 2009-08-07 13:15 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions; +Cc: Serge Ryabchun

[-- 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 --]

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64
  2009-08-07 12:59                   ` Serge Ryabchun
  2009-08-07 13:15                     ` Alexey Rusakov
@ 2009-08-07 15:43                     ` Kirill A. Shutemov
    1 sibling, 1 reply; 33+ messages in thread
From: Kirill A. Shutemov @ 2009-08-07 15:43 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64
  @ 2009-08-13 16:04                         ` Kirill A. Shutemov
    2009-08-17 22:39                           ` [sisyphus] liblensfun Dmitry V. Levin
  0 siblings, 2 replies; 33+ messages in thread
From: Kirill A. Shutemov @ 2009-08-13 16:04 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

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 строк, не больше.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64
  @ 2009-08-17 15:48                             ` Alexander Bokovoy
  2009-08-17 20:47                             ` [sisyphus] ufraw/liblensfun/etc vs gcc Dmitry V. Levin
  2009-08-19  0:41                             ` [sisyphus] liblensfun vs g++ Dmitry V. Levin
  2 siblings, 0 replies; 33+ messages in thread
From: Alexander Bokovoy @ 2009-08-17 15:48 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] ufraw/liblensfun/etc vs gcc
    2009-08-17 15:48                             ` Alexander Bokovoy
@ 2009-08-17 20:47                             ` Dmitry V. Levin
    2009-08-19  0:41                             ` [sisyphus] liblensfun vs g++ Dmitry V. Levin
  2 siblings, 1 reply; 33+ messages in thread
From: Dmitry V. Levin @ 2009-08-17 20:47 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

[-- 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 --]

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] ufraw/liblensfun/etc vs gcc
  @ 2009-08-17 21:25                                 ` Dmitry V. Levin
  2009-08-18  8:40                                   ` Anton V. Boyarshinov
  0 siblings, 1 reply; 33+ messages in thread
From: Dmitry V. Levin @ 2009-08-17 21:25 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

[-- 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 --]

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] liblensfun
  2009-08-13 16:04                         ` Kirill A. Shutemov
  @ 2009-08-17 22:39                           ` Dmitry V. Levin
  2009-08-18 23:18                             ` Dmitry V. Levin
  1 sibling, 1 reply; 33+ messages in thread
From: Dmitry V. Levin @ 2009-08-17 22:39 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

[-- 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 --]

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] ufraw/liblensfun/etc vs gcc
  2009-08-17 21:25                                 ` Dmitry V. Levin
@ 2009-08-18  8:40                                   ` Anton V. Boyarshinov
  0 siblings, 0 replies; 33+ messages in thread
From: Anton V. Boyarshinov @ 2009-08-18  8:40 UTC (permalink / raw)
  To: sisyphus



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


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] liblensfun
  2009-08-17 22:39                           ` [sisyphus] liblensfun Dmitry V. Levin
@ 2009-08-18 23:18                             ` Dmitry V. Levin
  0 siblings, 0 replies; 33+ messages in thread
From: Dmitry V. Levin @ 2009-08-18 23:18 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

[-- 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 --]

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] liblensfun vs g++
    2009-08-17 15:48                             ` Alexander Bokovoy
  2009-08-17 20:47                             ` [sisyphus] ufraw/liblensfun/etc vs gcc Dmitry V. Levin
@ 2009-08-19  0:41                             ` Dmitry V. Levin
  2009-08-19  8:27                               ` Sergey Vlasov
  2 siblings, 1 reply; 33+ messages in thread
From: Dmitry V. Levin @ 2009-08-19  0:41 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions


[-- 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 --]

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] liblensfun vs g++
  2009-08-19  0:41                             ` [sisyphus] liblensfun vs g++ Dmitry V. Levin
@ 2009-08-19  8:27                               ` Sergey Vlasov
  2009-08-19  8:33                                 ` Damir
  0 siblings, 1 reply; 33+ messages in thread
From: Sergey Vlasov @ 2009-08-19  8:27 UTC (permalink / raw)
  To: sisyphus

[-- 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 --]

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] liblensfun vs g++
  2009-08-19  8:27                               ` Sergey Vlasov
@ 2009-08-19  8:33                                 ` Damir
  2009-08-19 23:10                                   ` Dmitry V. Levin
  0 siblings, 1 reply; 33+ messages in thread
From: Damir @ 2009-08-19  8:33 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

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

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [sisyphus] liblensfun vs g++
  2009-08-19  8:33                                 ` Damir
@ 2009-08-19 23:10                                   ` Dmitry V. Levin
  0 siblings, 0 replies; 33+ messages in thread
From: Dmitry V. Levin @ 2009-08-19 23:10 UTC (permalink / raw)
  To: ALT Linux Sisyphus discussions

[-- 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 --]

^ permalink raw reply	[flat|nested] 33+ messages in thread

end of thread, other threads:[~2009-08-19 23:10 UTC | newest]

Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-05 17:08 [sisyphus] Странности при переходе объединении двух целых в вещественное на x86_64 Roman Savochenko
2009-08-05 21:34 ` Alexey Rusakov
2009-08-06  7:17   ` Roman Savochenko
2009-08-06  7:59     ` Alexey Rusakov
2009-08-06 16:21     ` Michael Shigorin
2009-08-06 21:10       ` Michael Shigorin
2009-08-06 18:12 ` Kirill A. Shutemov
2009-08-07  5:49   ` Roman Savochenko
2009-08-07  6:28     ` Yuriy Kashirin
2009-08-07  6:31     ` Kirill A. Shutemov
2009-08-07  7:14       ` Roman Savochenko
2009-08-07  7:35         ` Kirill A. Shutemov
2009-08-07  8:14           ` Roman Savochenko
2009-08-07  8:54             ` Kirill A. Shutemov
2009-08-07  8:57               ` Roman Savochenko
2009-08-07  9:14                 ` Kirill A. Shutemov
2009-08-07  8:58               ` Alexey Rusakov
2009-08-07  9:02               ` Roman Savochenko
2009-08-07  9:17                 ` Alexey Rusakov
2009-08-07 12:59                   ` Serge Ryabchun
2009-08-07 13:15                     ` Alexey Rusakov
2009-08-07 15:43                     ` Kirill A. Shutemov
2009-08-13 16:04                         ` Kirill A. Shutemov
2009-08-17 15:48                             ` Alexander Bokovoy
2009-08-17 20:47                             ` [sisyphus] ufraw/liblensfun/etc vs gcc Dmitry V. Levin
2009-08-17 21:25                                 ` Dmitry V. Levin
2009-08-18  8:40                                   ` Anton V. Boyarshinov
2009-08-19  0:41                             ` [sisyphus] liblensfun vs g++ Dmitry V. Levin
2009-08-19  8:27                               ` Sergey Vlasov
2009-08-19  8:33                                 ` Damir
2009-08-19 23:10                                   ` Dmitry V. Levin
2009-08-17 22:39                           ` [sisyphus] liblensfun Dmitry V. Levin
2009-08-18 23:18                             ` Dmitry V. Levin

ALT Linux Sisyphus discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/sisyphus/0 sisyphus/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 sisyphus sisyphus/ http://lore.altlinux.org/sisyphus \
		sisyphus@altlinux.ru sisyphus@altlinux.org sisyphus@lists.altlinux.org sisyphus@lists.altlinux.ru sisyphus@lists.altlinux.com sisyphus@linuxteam.iplabs.ru sisyphus@list.linux-os.ru
	public-inbox-index sisyphus

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.sisyphus


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git