From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30515 invoked by alias); 3 Jul 2006 09:32:34 -0000 Received: (qmail 30499 invoked by uid 22791); 3 Jul 2006 09:32:33 -0000 X-Spam-Check-By: sourceware.org Received: from mta07-winn.ispmail.ntl.com (HELO mtaout01-winn.ispmail.ntl.com) (81.103.221.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 03 Jul 2006 09:32:31 +0000 Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com with ESMTP id <20060703093228.YGYC15018.mtaout01-winn.ispmail.ntl.com@aamtaout04-winn.ispmail.ntl.com> for ; Mon, 3 Jul 2006 10:32:28 +0100 Received: from zebedee.littlepinkcloud.COM ([82.6.109.86]) by aamtaout04-winn.ispmail.ntl.com with ESMTP id <20060703093228.ZGBM17397.aamtaout04-winn.ispmail.ntl.com@zebedee.littlepinkcloud.COM> for ; Mon, 3 Jul 2006 10:32:28 +0100 Received: from zebedee.littlepinkcloud.COM (localhost.localdomain [127.0.0.1]) by zebedee.littlepinkcloud.COM (8.13.6/8.13.5) with ESMTP id k639WMsf018302; Mon, 3 Jul 2006 10:32:22 +0100 Received: (from aph@localhost) by zebedee.littlepinkcloud.COM (8.13.6/8.13.5/Submit) id k639WLST018299; Mon, 3 Jul 2006 10:32:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17576.58405.721906.162120@zebedee.pink> Date: Mon, 03 Jul 2006 09:32:00 -0000 From: Andrew Haley To: Michael P Friedlander Cc: gcc-help@gcc.gnu.org Subject: Re: Flags -g and -O give very different results In-Reply-To: <877E6F4D-F10A-4AE4-BDF4-629DF1C3DB32@cs.ubc.ca> References: <17576.4323.352965.195367@zebedee.pink> <877E6F4D-F10A-4AE4-BDF4-629DF1C3DB32@cs.ubc.ca> X-Mailer: VM 7.19 under Emacs 21.4.1 X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2006-07/txt/msg00015.txt.bz2 Michael P Friedlander writes: > Thanks for pointing out various options, Andrew. > > >> The behavior of a numerical code I'm working on varies > >> drastically depending on whether I've compiled it with > >> the -g or -O flags. > >> > >> The code's behavior under -g is much more stable, and I'm > >> wondering if the -O flag is exposing a bug that I need to > >> fix. Are there some gcc flags that I should try that might > >> guide me in finding the problem? (I've already tried the > >> obvious -Wall which gives no warnings.) > > > > If your code does something different with/without -g, then that's a > > bug in gcc. -g shouldn't make any difference to the behaviour of your > > program. > > -g makes no difference. > > > If your code does somethig different with -O, that's possibly a gcc > > bug but it's probably a bug in your code. > > -OO and -O give different results. > > > If you use -fno-strict-aliasing and that makes a difference with -O, > > then that's definitely a bug in your code. > > I think you nailed it! With -fno-strict-aliasing, -O0 and -O > give identical results. I tried -fstrict-aliasing with -Wstrict- > aliasing=2, but gcc doesn't issue any warnings. > > Any pointers for how to track this sort of thing down? What kind of > things should I look for? Your code probably contains something like int n; *(short*)&n = 5; i.e. you're accessing an object as something other than its underlying type. However, something as blatant as this would probably be caught by gcc, so you should be looking for something more subtle. Like this, maybe: int n; void *p = &n; *(short*)p = 5; Andrew.