Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 2 Dec 2011 01:56:52 -0800
From:      Stanislav Sedov <stas@FreeBSD.org>
To:        Gleb Kurtsou <gleb.kurtsou@gmail.com>
Cc:        freebsd-hackers@FreeBSD.org, mdf@freebsd.org
Subject:   Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
Message-ID:  <20111202015652.475ee54e.stas@FreeBSD.org>
In-Reply-To: <20111119100150.GA1560@reks>
References:  <20111119100150.GA1560@reks>

next in thread | previous in thread | raw e-mail | index | archive | help
--Signature=_Fri__2_Dec_2011_01_56_52_-0800_VCl/=6NAmU9YiIfo
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, 19 Nov 2011 12:01:50 +0200
Gleb Kurtsou <gleb.kurtsou@gmail.com> mentioned:

> Hi,
>=20
> 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)
>=20
> -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.
>=20
> 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 do=
wn
> to a simple test I could share but without much success.
>=20
> 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.
>=20
> -O2 -fno-omit-frame-pointer -fno-inline is buggy
> -O2 -fno-omit-frame-pointer -frename-registers is buggy
>=20
> 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=3D679924
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D47893
>=20
> I'll be glad to help debugging it and will be hanging on #bsddev during
> weekend as glk.
>=20

Hi!

I'm not sure this is relevant to your case, but our base gcc used to have
a bug with strict aliasing, which was fixed only in a GPLv3 version of
it.  That's why we have -fno-strict-aliasing in default CFALGS.  So you
might try to build using -fno-strict-aliasing.

--=20
Stanislav Sedov
ST4096-RIPE

()  ascii ribbon campaign - against html e-mail=20
/\  www.asciiribbon.org   - against proprietary attachments

--Signature=_Fri__2_Dec_2011_01_56_52_-0800_VCl/=6NAmU9YiIfo
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----

iQIcBAEBAgAGBQJO2KDpAAoJEL8lojEJL9nw0HIP/38ws0TRzJQEXXiY2oLz/uKd
r7nJ+UZ87kDI6EIMs2zYcb19lZw3vhRDLfmHxX3XTqhhQvfDhTu6fcAuDNl1VVOi
qoYv+aowD7Hl7aLBUi4L28NOc8mz1hZosCfoJGzxetewYm9r1NRPXPPVQFVkR3rw
yJuPF10NFTjnZJS7K/t/NQ6ibcl8Pr54VoaynfNxx6KO725wYoCBKAItpL/Ymrbl
fthkbYOW2ZnFxDrfUdJiVh9ACRUyeGaZMlL3tYDvo/QpsiWnTqsjZUfD9Wa2L+vu
8Tq7oo5wWY/hM76oe+abn0lnM58Jc8iWg0GZpvNBu00LsI0yNMiCc7mbRBY6e691
dhJ3vKdGIJiHGws7mO0RnTEx3/F22rWBLqbta61a5lW5J4Znwipfhxic2B/sXXbR
r3ztDCw5CS1+VJyYvdLLTkHSqgpBnr4pETGP/oil4uY5a3Gq3MsPlYaOJMBRcHFN
0nyLFGzqoMsOvOBn3tbkQZoJGqZx/qgQwbwsEl5smkL+7gsbfCKX6lktCkoY4LrY
+wptXTS1vR5sqqPQuMWuJiOmje0qiFOvXQ7WyfGF6ikdMYmtZIw4945iA3+LtITZ
AknNdgxWM/sjEOyacdNHdIRzPoHy8fg1Nrc69W36G1pQkIHV4q2lhmXv2ZWJKDj4
Rvcvw3KDgDBG4ExEpbfS
=wi30
-----END PGP SIGNATURE-----

--Signature=_Fri__2_Dec_2011_01_56_52_-0800_VCl/=6NAmU9YiIfo--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111202015652.475ee54e.stas>