gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64

Alexander Best arundel at freebsd.org
Sun Nov 20 01:57:57 UTC 2011


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).

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.


More information about the freebsd-hackers mailing list