From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13213 invoked by alias); 2 Aug 2008 02:15:27 -0000 Received: (qmail 13204 invoked by uid 22791); 2 Aug 2008 02:15:27 -0000 X-Spam-Check-By: sourceware.org Received: from gamma.dmkhost.com (HELO gamma.dmkhost.com) (67.19.42.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 02 Aug 2008 02:14:58 +0000 Received: from [195.24.248.244] (port=51573 helo=[192.168.1.100]) by gamma.dmkhost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1KP6dz-0004mZ-Jc for gcc-help@gcc.gnu.org; Sat, 02 Aug 2008 04:14:55 +0200 Message-ID: <4893C31D.3000602@loskot.net> Date: Sat, 02 Aug 2008 02:15:00 -0000 From: Mateusz Loskot User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: gcc-help@gcc.gnu.org Subject: Re: [GCC 4.3] Strange -O2 optimization issue References: <4893866F.9050800@loskot.net> <4893A622.23D87C16@dessent.net> In-Reply-To: <4893A622.23D87C16@dessent.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2008-08/txt/msg00006.txt.bz2 Brian Dessent wrote: > Mateusz Loskot wrote: > >> Why the first value printed is different (136623933) in the 3rd >> test case. > > Your suspicion is correct, as this violates the ISO C aliasing rules: Brian, Good to hear I was close ;-) >> static unsigned long HashDouble(double* pdfVal) >> { >> unsigned int* pnValue = (unsigned int*)pdfVal; > > You're accessing a variable of type double through a pointer of type > unsigned int. For the purposes of optimization the compiler is allowed > to assume that values of type double will only be accessed through > variables of type double, and thus it can assume that pdfVal and pnValue > can't refer to the same thing. It may seem nonsensical in this instance > that it would assume that, but it's still legal for the compiler to do > so. > [...] Thank you very much for in-depth explanation of the problem. It was greatly helpful. > If you want to rewrite your code in a conformant way you can use a union > or memcpy; or you can disable strict aliasing with > -fno-strict-aliasing. I fixed my code with memcpy option. > -Wstrict-aliasing is intended to warn about > things like this, but since it's included in -Wall it obviously failed > to warn in your case. There are several levels of -Wstrict-aliasing > though, so you may need to turn to -Wstrict-aliasing=2 to catch this > case. See the docs for details: > -Wstrict-aliasing=2 does not warn about aliasing rules broken in that line with the case, but -Wstrict-aliasing=1 does. Yes, I've read the manual and understand it why. > As to why only the first value printed differs, or why taking the > address of pnValue changes the outcome, or why older versions of gcc > worked fine: that is the general nature of undefined behavior. It can > take on any form whatsoever, from working perfectly, to failing > spectacularly, or anywhere in between. All rules are out the window. Right, I suspected UB from the beginning of my investigation. > It is best not to try to understand the effects or outcome but rather to > understand how to fix the code so that it is no longer undefined. Very good point :-) >> I'd be also very thankful for references in C/C++ standards >> explaining this behavior of GCC. > > See section 6.5.7 of the C99 standard. > > Brian Thank you very much again! Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org