From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 2 11:48:22 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 D30D6106564A; Fri, 2 Dec 2011 11:48:22 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id D375F8FC16; Fri, 2 Dec 2011 11:48:21 +0000 (UTC) Received: by lahv2 with SMTP id v2so1686189lah.13 for ; Fri, 02 Dec 2011 03:48:20 -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=hNf7MTv9dOlftqE3GftkUmYgMAaXTJlpTxtYS/ExuZY=; b=mpf1knwNikuEL8nAQ6Grj2yQWWRqoM5eHFh2aEBnWhFcRtBXHENUAyCQCt5soag/U3 l451/YPfrdjvcWJ76CNydGVgfKRvWx142ZC6+bUINKdqoV2YARkhxNu4ms8/N7DaOWp+ 2J85oF0COCaBeg9OUlIyxx7oAEeKpYSDQQ+0I= Received: by 10.152.103.165 with SMTP id fx5mr6974230lab.38.1322826500786; Fri, 02 Dec 2011 03:48:20 -0800 (PST) Received: from localhost ([78.157.92.5]) by mx.google.com with ESMTPS id pw12sm8198079lab.13.2011.12.02.03.48.19 (version=SSLv3 cipher=OTHER); Fri, 02 Dec 2011 03:48:19 -0800 (PST) Date: Fri, 2 Dec 2011 13:48:22 +0200 From: Gleb Kurtsou To: Stanislav Sedov Message-ID: <20111202114822.GA1511@reks> References: <20111119100150.GA1560@reks> <20111202015652.475ee54e.stas@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20111202015652.475ee54e.stas@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@FreeBSD.org, mdf@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: Fri, 02 Dec 2011 11:48:23 -0000 On (02/12/2011 01:56), Stanislav Sedov wrote: > On Sat, 19 Nov 2011 12:01:50 +0200 > Gleb Kurtsou mentioned: > > > 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 > > > > 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. > > > > Hi! > > I'm not sure this is relevant to your case, but our base gcc used to have > a bug with strict aliasing, which was fixed only in a GPLv3 version of > it. That's why we have -fno-strict-aliasing in default CFALGS. So you > might try to build using -fno-strict-aliasing. I always have -fno-strict-aliasing, the whole idea of misusing undefined behaviour to perform optimization is crazy. I guess it seemed evident to me so I've skipped the flag above. Besides gcc was barking with aliasing warnings on 3rd party party code in my case, I had to change warnings flags to run tests without -fno-strict-aliasing. I've dropped -fno-omit-frame-pointer, async unwind tables are ok for userland. Another work around was adding -finline-functions. Kernel and modules won't build with -finline-functions. So we are just lucky not to catch it. Thanks, Gleb. > -- > Stanislav Sedov > ST4096-RIPE > > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachments