Date: Sat, 19 Nov 2011 15:39:13 +0200 From: Gleb Kurtsou <gleb.kurtsou@gmail.com> To: Alexander Best <arundel@freebsd.org> Cc: freebsd-hackers@FreeBSD.org Subject: Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64 Message-ID: <20111119133913.GA87101@reks> In-Reply-To: <20111119122538.GA47771@freebsd.org> References: <20111119100150.GA1560@reks> <20111119122538.GA47771@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111119133913.GA87101>