From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Virus-Scanned: amavisd-new at localhost Message-ID: <4A7BD461.9060601@diyaorg.dp.ua> Date: Fri, 07 Aug 2009 10:14:41 +0300 From: Roman Savochenko User-Agent: Thunderbird 2.0.0.21 (X11/20090430) MIME-Version: 1.0 To: ALT Linux Sisyphus discussions References: <4A79BC9B.20207@diyaorg.dp.ua> <4A7BC066.8050607@diyaorg.dp.ua> In-Reply-To: Content-Type: multipart/mixed; boundary="------------000400060601000506030701" Subject: Re: [sisyphus] =?utf-8?b?0KHRgtGA0LDQvdC90L7RgdGC0Lgg0L/RgNC4INC/0LU=?= =?utf-8?b?0YDQtdGF0L7QtNC1INC+0LHRitC10LTQuNC90LXQvdC40Lgg0LTQstGD0YUg?= =?utf-8?b?0YbQtdC70YvRhSDQsiDQstC10YnQtdGB0YLQstC10L3QvdC+0LUg0L3QsCB4?= =?utf-8?q?86=5F64?= X-BeenThere: sisyphus@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Sisyphus discussions List-Id: ALT Linux Sisyphus discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 07:15:00 -0000 Archived-At: List-Archive: List-Post: This is a multi-part message in MIME format. --------------000400060601000506030701 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Kirill A. Shutemov wrote: > 2009/8/7 Roman Savochenko : > >> 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. > С ним работает, но это не решение, поскольку приведенные мною обороты распространены и я не уверен что подобных проблем нет в других частях моей, в общем-то не маленькой, программы. В любом случае спасибо за прояснение ситуации. И думаю багу повесить нужно. С уважением, Роман --------------000400060601000506030701 Content-Type: text/x-vcard; charset=utf-8; name="rom_as.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="rom_as.vcf" YmVnaW46dmNhcmQNCmZuOlJvbWFuIFNhdm9jaGVua28NCm46U2F2b2NoZW5rbztSb21hbg0K ZW1haWw7aW50ZXJuZXQ6cm9tX2FzQGRpeWFvcmcuZHAudWENCnRpdGxlOk5JUCAiRElZQSIN CnRlbDt3b3JrOk5JUCAiRElZQSINCnRlbDtjZWxsOiszODA2Nzk4NTk4MTUNCngtbW96aWxs YS1odG1sOkZBTFNFDQp2ZXJzaW9uOjIuMQ0KZW5kOnZjYXJkDQoNCg== --------------000400060601000506030701--