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

[Alexander Best]

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?

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.