Date: Sun, 20 Nov 2011 11:16:08 -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_1pYNcMbicYNtDtoVBEcBntvzUuZcsGZ_4njk7wQ%2B3=Q@mail.gmail.com> In-Reply-To: <20111120182430.GA1672@reks> References: <20111119100150.GA1560@reks> <CAMBSHm8TdZcEJQTVoier8LGA-5j7sjoPCQxKabWVsrdk0p3=ZA@mail.gmail.com> <20111119161958.GA91681@reks> <CAMBSHm-WbYxPvc5p43%2B78kY4mehRCY7r5OwjsCVh_sYaUdbv=A@mail.gmail.com> <20111120182430.GA1672@reks>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Nov 20, 2011 at 10:24 AM, Gleb Kurtsou <gleb.kurtsou@gmail.com> wro= te: > On (19/11/2011 09:11), mdf@FreeBSD.org wrote: >> On Sat, Nov 19, 2011 at 8:19 AM, Gleb Kurtsou <gleb.kurtsou@gmail.com> w= rote: >> > 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= > 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 gc= c >> >> > from base system and last gcc 4.2 snapshot from ports. It works wit= h 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 th= e >> >> > 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, ca= ll a >> >> > function with pointers to those stucts as arguments. A number of in= lined >> >> > assertion functions. gcc fails to correctly optimize struct assignm= ents >> >> > with -fno-omit-frame-pointer, I have a number of small structs assi= gned, >> >> > 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 produ= ces >> >> > correct code, but that's not a solution. >> >> >> >> How small are the structs? =A0gcc has an optimization for structs tha= t >> >> 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 iss= ue >> > for me. >> >> I can't find the thing I'm thinking of. =A0The 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 >> =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 =A0 =A0(.../vendor.branches/freebsd/stable/7/src/contrib/gcc/= opts.c) =A0 (revision >> 211574) >> +++ opts.c =A0 =A0(.../head/src/contrib/gcc/opts.c) =A0 =A0 =A0 (revisio= n 211574) >> @@ -457,11 +457,7 @@ >> =A0 =A0 =A0 =A0flag_tree_dse =3D 1; >> =A0 =A0 =A0 =A0flag_tree_ter =3D 1; >> =A0 =A0 =A0 =A0flag_tree_live_range_split =3D 1; >> + =A0 =A0 =A0/** >> + =A0 =A0 =A0 * 7dot1MERGE: tree-sra in gcc 4.2.x is buggy and >> + =A0 =A0 =A0 * breaks bitfield structs. >> + =A0 =A0 =A0 */ >> + =A0 =A0 =A0flag_tree_sra =3D 0; >> - =A0 =A0 =A0flag_tree_sra =3D 1; >> =A0 =A0 =A0 =A0flag_tree_copyrename =3D 1; >> =A0 =A0 =A0 =A0flag_tree_fre =3D 1; >> =A0 =A0 =A0 =A0flag_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_1pYNcMbicYNtDtoVBEcBntvzUuZcsGZ_4njk7wQ%2B3=Q>