Date: Sun, 1 Dec 2013 15:10:45 +0100 From: Dimitry Andric <dim@FreeBSD.org> To: Adrian Chadd <adrian@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, "current@freebsd.org" <current@freebsd.org> Subject: Re: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds Message-ID: <AE103F97-2C84-4778-8D36-BC344339C5F9@FreeBSD.org> In-Reply-To: <CAJ-VmonQip5Q%2BDfSd_dba_=g8bZYM9uyhYw8XmhU4wGydnJJtg@mail.gmail.com> References: <20131130135616.GA59496@kib.kiev.ua> <E3E2524B-4423-4962-BFD7-9A81424296F7@FreeBSD.org> <CAJ-VmonQip5Q%2BDfSd_dba_=g8bZYM9uyhYw8XmhU4wGydnJJtg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_159D4490-6D58-409D-9F58-776BB4665676 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 On 01 Dec 2013, at 01:33, Adrian Chadd <adrian@freebsd.org> wrote: > On 30 November 2013 15:25, Dimitry Andric <dim@freebsd.org> wrote: ... >> Basically, if you rely on undefined behavior, you are inventing your own >> de facto language, which is *not* C. That is fine with me, but let's >> not pretend the FreeBSD kernel is written in C then. :-) > > Are you able to have clang/llvm/gcc tell us where/when code is relying > on undefined behaviour? So we can, like, fix them? Not in the most general sense, since that would amount to solving the halting problem. But there are some tools that can help quite a lot. I guess Coverity can already cover quite a lot of cases, and there is also the STACK tool from MIT: http://css.csail.mit.edu/stack/ It would be really nice to have this in ports. Another mechanism is run-time detection, e.g. the undefined behavior sanitizer and other sanitizers: http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation some of which have also been ported to gcc, see: http://gcc.gnu.org/gcc-4.9/changes.html However, these have not been completely ported to FreeBSD yet, and come at a (sometimes large) run-time cost. Still a lot less than valgrind, though. :-) Also, for use in the kernel, the run-time support would have to be ported separately to the kernel environment. > If there was a way to lint this stuff then yes, please lint it. > > Otherwise we don't have the tools to know whether we're doing sane > things or not. > > (Same with things like strict aliasing..) Yes, the comparison with strict aliasing is spot-on. A lot of code has been written that is not aliasing safe, and if it is too much effort to fix it, using -fno-strict-aliasing is a reasonable workaround. Note this option can prevent a lot of very useful optimizations, but if you do not particularly care (for example if you are waiting for slow hardware anyway), it is fine to use it. -Dimitry --Apple-Mail=_159D4490-6D58-409D-9F58-776BB4665676 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlKbQ2kACgkQsF6jCi4glqOmawCaAhMUbWSkuCS5aEowsaXbsk1D vigAn1PjUXbAXJUl5ay3I05V9PmPbCL6 =rKnu -----END PGP SIGNATURE----- --Apple-Mail=_159D4490-6D58-409D-9F58-776BB4665676--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AE103F97-2C84-4778-8D36-BC344339C5F9>