Date: Sat, 30 Nov 2013 16:33:17 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Dimitry Andric <dim@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: <CAJ-VmonQip5Q%2BDfSd_dba_=g8bZYM9uyhYw8XmhU4wGydnJJtg@mail.gmail.com> In-Reply-To: <E3E2524B-4423-4962-BFD7-9A81424296F7@FreeBSD.org> References: <20131130135616.GA59496@kib.kiev.ua> <E3E2524B-4423-4962-BFD7-9A81424296F7@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 30 November 2013 15:25, Dimitry Andric <dim@freebsd.org> wrote: > On 30 Nov 2013, at 14:56, Konstantin Belousov <kostikbel@gmail.com> wrote: >> I propose to unconditionally add the switch -fno-strict-overflow to the >> kernel compilation. See the patch at the end of message for exact change >> proposed. >> >> What does it do. It disallows useless and counter-intuitive behaviour of >> the compiler(s) for the signed overflow. Basically, the issue is that >> the C standard left signed overflow as undefined to allow for different >> hardware implementation of signess to be used for signed arithmetic. >> De-facto, all architectures where FreeBSD works or have a chance to be >> ported, use two-complement signed integer representation, and developers >> intuition is right about it. > > I think this is quite a misrepresentation. Any C compiler is free to do > whatever it wants whenever it encounters undefined behavior. Some > behavior is undefined in the C standards, so compilers can do a better > job at optimization. > > If the optimized code fails to do what the programmer thinks it does, it > is almost always the programmer's fault, excluding actual compiler bugs > (which are unavoidable, as all software has bugs). > > 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? 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..) -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonQip5Q%2BDfSd_dba_=g8bZYM9uyhYw8XmhU4wGydnJJtg>