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

[Gleb Kurtsou]

On (02/12/2011 01:56), Stanislav Sedov wrote:
> On Sat, 19 Nov 2011 12:01:50 +0200
> Gleb Kurtsou <gleb.kurtsou at gmail.com> 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