On Thu, Dec 19, 2013 at 10:16:16AM +0100, Stefan Esser wrote:
> Am 30.11.2013 14:56, schrieb Konstantin Belousov:
> > 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 do
On 12/19/13, Stefan Esser wrote:
> Am 30.11.2013 14:56, schrieb Konstantin Belousov:
>> 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
Am 30.11.2013 14:56, schrieb Konstantin Belousov:
> 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 co
On 01 Dec 2013, at 01:33, Adrian Chadd wrote:
> On 30 November 2013 15:25, Dimitry Andric 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
Konstantin Belousov wrote, On 11/30/2013 13:56:
The compiler authors take the undefined part there as a blanket to perform
optimizations which are assuming that signed overflow cannot happen.
Personally, when I first heard about such assumptions, it was inspiring to
write code in a way that au
On Sat, Nov 30, 2013 at 04:33:17PM -0800, Adrian Chadd wrote:
> On 30 November 2013 15:25, Dimitry Andric wrote:
> > On 30 Nov 2013, at 14:56, Konstantin Belousov wrote:
> >> I propose to unconditionally add the switch -fno-strict-overflow to the
> >> kernel compilation. See the patch at the en
On Sat, Nov 30, 2013 at 8:38 PM, Eitan Adler wrote:
> On Sat, Nov 30, 2013 at 11:26 PM, Peter Wemm wrote:
>> On Sat, Nov 30, 2013 at 4:33 PM, Adrian Chadd wrote:
>> [..]
>>> Are you able to have clang/llvm/gcc tell us where/when code is relying
>>> on undefined behaviour? So we can, like, fix th
On Sat, Nov 30, 2013 at 11:26 PM, Peter Wemm wrote:
> On Sat, Nov 30, 2013 at 4:33 PM, Adrian Chadd wrote:
> [..]
>> Are you able to have clang/llvm/gcc tell us where/when code is relying
>> on undefined behaviour? So we can, like, fix them?
>
> It wasn't all that long ago that we had this wonder
On Sat, Nov 30, 2013 at 4:33 PM, Adrian Chadd wrote:
[..]
> Are you able to have clang/llvm/gcc tell us where/when code is relying
> on undefined behaviour? So we can, like, fix them?
It wasn't all that long ago that we had this wonderful thing called
-Werror and had a clean kernel build.
The pr
Adrian Chadd wrote, On 12/01/2013 01:33:
Are you able to have clang/llvm/gcc tell us where/when code is relying
on undefined behaviour? So we can, like, fix them?
Well, there's -ftrapv.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd
On 30 November 2013 15:25, Dimitry Andric wrote:
> On 30 Nov 2013, at 14:56, Konstantin Belousov 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 d
On 30 Nov 2013, at 14:56, Konstantin Belousov 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
> th
In message
, Adrian Chadd writes:
>> The compiler authors take the undefined part there as a blanket to perform
>> optimizations which are assuming that signed overflow cannot happen.
That's sufficient explanation for me to support your proposal.
--
Poul-Henning Kamp | UNIX since Zilog Z
+1, this caught us out with sendfile testing very recently :(
-a
On 30 November 2013 05:56, Konstantin Belousov 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
14 matches
Mail list logo
