[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0705080931460.10409@frodo.shire>
Date: Tue, 8 May 2007 09:34:49 +0200 (CEST)
From: Esben Nielsen <nielsen.esben@...glemail.com>
To: Johannes Stezenbach <js@...uxtv.org>
cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Esben Nielsen <nielsen.esben@...glemail.com>,
Ingo Molnar <mingo@...e.hu>,
Balbir Singh <balbir@...ux.vnet.ibm.com>,
linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Con Kolivas <kernel@...ivas.org>,
Nick Piggin <npiggin@...e.de>, Mike Galbraith <efault@....de>,
Arjan van de Ven <arjan@...radead.org>,
Peter Williams <pwil3058@...pond.net.au>,
Thomas Gleixner <tglx@...utronix.de>, caglar@...dus.org.tr,
Willy Tarreau <w@....eu>,
Gene Heskett <gene.heskett@...il.com>, Mark Lord <lkml@....ca>,
Zach Carter <linux@...hcarter.com>,
buddabrod <buddabrod@...il.com>
Subject: Re: [patch] CFS scheduler, -v8
On Mon, 7 May 2007, Johannes Stezenbach wrote:
> On Mon, May 07, 2007, Linus Torvalds wrote:
>> On Mon, 7 May 2007, Esben Nielsen wrote:
>>>
>>> What is (long)(a-b) ? I have tried to look it up in the C99 standeard but I
>>> can't find it. Maybe it is in the referred LIA-1 standeard, which I can't find
>>> with google.
>
> C99 defines unsigned overflow semantics, but it doesn't say anything
> about signed overflow, thus it's undefined -- and you have a hard
> time finding it out.
>
> However, I have no clue *why* it's undefined and not
> implementation defined. Does someone know?
>
>> I don't worry about non-2's-complement machines (they don't exist, and
>> likely won't exist in the future either).
>
> I think DSPs can do saturated arithmetics (clamp to min/max
> values instead of wrap around). Not that it matters for Linux...
>
>> So I worry about compilers rewriting my code.
>
> gcc has -fwrapv and -ftrapv to change signed integer overflow
> behaviour.
>
> One baffling example where gcc rewrites code is when
> conditionals depend on signed integer overflow:
>
> $ cat xx.c
> #include <assert.h>
>
> int foo(int a)
> {
> assert(a + 100 > a);
> return a;
> }
>
> int bar(int a)
> {
> if (a + 100 > a)
> a += 100;
> return a;
> }
> $ gcc -Wall -Wextra -fomit-frame-pointer -c xx.c
> $ objdump -dr xx.o
>
> xx.o: file format elf32-i386
>
> Disassembly of section .text:
>
> 00000000 <foo>:
> 0: 8b 44 24 04 mov 0x4(%esp),%eax
> 4: c3 ret
>
> 00000005 <bar>:
> 5: 83 44 24 04 64 addl $0x64,0x4(%esp)
> a: 8b 44 24 04 mov 0x4(%esp),%eax
> e: c3 ret
>
>
> The assert and the condition were just dropped
> by gcc -- without any warning.
>
> gcc-4.2 will add -fstrict-overflow and -Wstrict-overflow.
> http://gcc.gnu.org/gcc-4.2/changes.html
>
>
> Johannes
>
This is contrary to C99 standeard annex H2.2
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf):
"An implementation that defines signed integer types as also being modulo need
not detect integer overflow, in which case, only integer divide-by-zero need
be detected."
So if it doesn't properly defines wrapping it has to detect integer
overflow, right?
gcc does niether with that optimization :-(
Esben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists