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

[mdf at FreeBSD.org]

On Sun, Nov 20, 2011 at 10:24 AM, Gleb Kurtsou <gleb.kurtsou at gmail.com> wrote:
> On (19/11/2011 09:11), mdf at FreeBSD.org wrote:
>> On Sat, Nov 19, 2011 at 8:19 AM, Gleb Kurtsou <gleb.kurtsou at gmail.com> wrote:
>> > 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.
>>
>> I can't find the thing I'm thinking of.  The only potentially relevant
>> patch I see in our gcc sources is this:
>
> It could be related but doesn't fix bug I observe. I've installed fresh
> 9.0-RC2 virtual machine and reran tests in clean environment.
>
> Do you plan committing it?

We probably should, but I haven't heard that anyone else has had a
problem with this.  I'm sure when I do the next FreeBSD merge at $WORK
I'll re-remember it and probably commit it then.

Thanks,
matthew

>> Index: opts.c
>> ===================================================================
>> --- opts.c    (.../vendor.branches/freebsd/stable/7/src/contrib/gcc/opts.c)   (revision
>> 211574)
>> +++ opts.c    (.../head/src/contrib/gcc/opts.c)       (revision 211574)
>> @@ -457,11 +457,7 @@
>>        flag_tree_dse = 1;
>>        flag_tree_ter = 1;
>>        flag_tree_live_range_split = 1;
>> +      /**
>> +       * 7dot1MERGE: tree-sra in gcc 4.2.x is buggy and
>> +       * breaks bitfield structs.
>> +       */
>> +      flag_tree_sra = 0;
>> -      flag_tree_sra = 1;
>>        flag_tree_copyrename = 1;
>>        flag_tree_fre = 1;
>>        flag_tree_copy_prop = 1;
>>
>> Thanks,
>> matthew
>