Date: Sat, 19 Nov 2011 09:11:03 -0800 From: mdf@FreeBSD.org To: Gleb Kurtsou <gleb.kurtsou@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64 Message-ID: <CAMBSHm-WbYxPvc5p43%2B78kY4mehRCY7r5OwjsCVh_sYaUdbv=A@mail.gmail.com> In-Reply-To: <20111119161958.GA91681@reks> References: <20111119100150.GA1560@reks> <CAMBSHm8TdZcEJQTVoier8LGA-5j7sjoPCQxKabWVsrdk0p3=ZA@mail.gmail.com> <20111119161958.GA91681@reks>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Nov 19, 2011 at 8:19 AM, Gleb Kurtsou <gleb.kurtsou@gmail.com> wrot=
e:
> On (19/11/2011 07:26), mdf@FreeBSD.org wrote:
>> On Sat, Nov 19, 2011 at 2:01 AM, Gleb Kurtsou <gleb.kurtsou@gmail.com> w=
rote:
>> > 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 g=
cc
>> > 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. -O an=
d
>> > -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 inlin=
ed
>> > assertion functions. gcc fails to correctly optimize struct assignment=
s
>> > with -fno-omit-frame-pointer, I have a number of small structs assigne=
d,
>> > 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? =A0gcc 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. =A0I 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:
Index: opts.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- opts.c (.../vendor.branches/freebsd/stable/7/src/contrib/gcc/opts.c) (r=
evision
211574)
+++ opts.c (.../head/src/contrib/gcc/opts.c) (revision 211574)
@@ -457,11 +457,7 @@
flag_tree_dse =3D 1;
flag_tree_ter =3D 1;
flag_tree_live_range_split =3D 1;
+ /**
+ * 7dot1MERGE: tree-sra in gcc 4.2.x is buggy and
+ * breaks bitfield structs.
+ */
+ flag_tree_sra =3D 0;
- flag_tree_sra =3D 1;
flag_tree_copyrename =3D 1;
flag_tree_fre =3D 1;
flag_tree_copy_prop =3D 1;
Thanks,
matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMBSHm-WbYxPvc5p43%2B78kY4mehRCY7r5OwjsCVh_sYaUdbv=A>