From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 20 18:40:49 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3DBE1065672; Sun, 20 Nov 2011 18:40:49 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 47FED8FC0C; Sun, 20 Nov 2011 18:40:48 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so7571273bkb.13 for ; Sun, 20 Nov 2011 10:40:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=U+BbxSyqS+zQtshUV2zJgcpQiesxbwnh0TjQS+FhlQU=; b=iiPsA86ptfciUHPv86heoeJQs1l1CNaSbDRNvMvmSWwzQTEQqflM/PN/+MTyQH3kAM TriJkzpzDsJwrypz0cWZIRKgOaEJQmWB+TNiFiuAXA6Z5jdHwLJZHWysoLKv7EopKIkM Lga/QoSKxPL5uWsj+7pt8P/JePdBGZPkPdwUs= Received: by 10.204.154.25 with SMTP id m25mr11114366bkw.140.1321814447353; Sun, 20 Nov 2011 10:40:47 -0800 (PST) Received: from localhost ([78.157.92.5]) by mx.google.com with ESMTPS id d19sm5436116bkq.5.2011.11.20.10.40.45 (version=SSLv3 cipher=OTHER); Sun, 20 Nov 2011 10:40:46 -0800 (PST) Date: Sun, 20 Nov 2011 20:40:47 +0200 From: Gleb Kurtsou To: Alexander Best Message-ID: <20111120182824.GB1672@reks> References: <20111119100150.GA1560@reks> <20111119122538.GA47771@freebsd.org> <20111119133913.GA87101@reks> <20111120015757.GA71026@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20111120015757.GA71026@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@FreeBSD.org Subject: Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 18:40:50 -0000 On (20/11/2011 01:57), Alexander Best wrote: > On Sat Nov 19 11, Gleb Kurtsou wrote: > > On (19/11/2011 12:25), Alexander Best wrote: > > > On Sat Nov 19 11, Gleb Kurtsou wrote: > > > > Hi, > > > > > > > > I was lucky to write a bit of code which gcc 4.2 fails to compile > > > > correctly with -O2. Too keep long story short the code fails for gcc > > > > from base system and last gcc 4.2 snapshot from ports. It works with gcc > > > > 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. -O and > > > > -Os optimization levels are fine (I've tried with all -f* flags > > > > mentioned in documentation) > > > > > > > > -O2 -fno-omit-frame-pointer combination is troublesome on amd64. I > > > > presume i386 should be fine. These options are also used for > > > > compilation of kernel (with debugging enabled) and modules. > > > > > > > > I'm not able to share the code, but have a test case reproducing the > > > > bug. I've encountered the issue over a week ago and tried narrowing it down > > > > to a simple test I could share but without much success. > > > > > > > > The code itself is very common: initialize two structs on stack, call a > > > > function with pointers to those stucts as arguments. A number of inlined > > > > assertion functions. gcc fails to correctly optimize struct assignments > > > > with -fno-omit-frame-pointer, I have a number of small structs assigned, > > > > gcc decides not to use data coping but to assign fields directly. I've > > > > tried disabling sra, tweaking sra parameters -- no luck in forcing it > > > > to copy data. Replacing one particular assignment with memcpy produces > > > > correct code, but that's not a solution. > > > > > > > > -O2 -fno-omit-frame-pointer -fno-inline is buggy > > > > -O2 -fno-omit-frame-pointer -frename-registers is buggy > > > > > > does the issue also come up with '-fno-builtin' in addition to those flags? > > > is '-O2 -fno-omit-frame-pointer' alone also buggy? does the issue also exist > > > when using -O1 and -O3? > > > > -O0 -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- OK > > > > -Os -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- OK > > > > -O -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- BAD > > > > -O1 -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- BAD > > > > -O2 -g -std=gnu99 -pipe -fno-omit-frame-pointer -- BAD > > > > -O2 -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-builtin -fno-strict-aliasing -- BAD > > > > -O3 -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- OK!! > > > > -O3 -fno-inline-functions -fno-unswitch-loops -fno-gcse-after-reload -g > > -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- BAD > > > > -O3 -fno-inline-functions -g -std=gnu99 -pipe -fno-omit-frame-pointer > > -fno-strict-aliasing -- BAD > > > > -O2 -finline-functions -g -std=gnu99 -pipe -fno-omit-frame-pointer > > -fno-strict-aliasing -- OK > > btw: for any optimisation > -O1, -fno-strict-aliasing isn't needed, since it > gets added automatically (see sys/conf/kern.pre.mk). For kernel builds. I'm building 3rd party software with base system compiler. On the other hand kernel and modules are built with -O2 -fno-omit-frame-pointer.. > > cheers. > alex > > > > > So, it's -finline-functions that makes it work. But I'm afraid it just > > masks the real problem. > > > > The rest of CFLAGS is warnings and includes: > > -D_GNU_SOURCE -Wsystem-headers -Werror -Wall -Wno-format-y2k -W > > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type > > -Wcast-qual -Wno-write-strings -Wswitch -Wshadow -Wunused-parameter > > -Wcast-align -Wno-pointer-sign -Wstrict-aliasing=2 > > -Wno-error=strict-aliasing > > > > > > > > cheers. > > > alex > > > > > > > > > > > I found similar issue with gcc 4.6, but I'm not able to reproduce it > > > > with gcc test case: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=679924 > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893 > > > > > > > > I'll be glad to help debugging it and will be hanging on #bsddev during > > > > weekend as glk. > > > > > > > > > > > > Thanks, > > > > Gleb.