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

[Gleb Kurtsou]

On (19/11/2011 07:26), mdf at FreeBSD.org wrote:
> On Sat, Nov 19, 2011 at 2:01 AM, Gleb Kurtsou <gleb.kurtsou at gmail.com> 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.
> 
> How small are the structs?  gcc has an optimization for structs that
> are no larger than a register, but it's buggy in 4.2 and we disabled
> it at $WORK.  I can dig up the patch if this is the problem.
struct sockaddr_in in this particular test. 16 bytes.

Register size structs are rather common, e.g. struct in_addr.

I could test the patch. Adding -finline-functions seems to fix the issue
for me.

Thanks,
Gleb.

> 
> Thanks,
> matthew