From: Bakul Shah <bakul+plan9@bitblocks.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] BUG!!! in Plan9 compiler!
Date: Thu, 22 Apr 2010 10:03:58 -0700 [thread overview]
Message-ID: <20100422170358.80B9D5B73@mail.bitblocks.com> (raw)
In-Reply-To: Your message of "Thu, 22 Apr 2010 17:29:53 +0200." <20100422152953.GA616@polynum.com>
On Thu, 22 Apr 2010 17:29:53 +0200 tlaronde@polynum.com wrote:
> Data:
> Under NetBSD/gcc, I have the following values:
>
> before: x1:=5440, x2:=-5843, x3:=78909
> after: x1:=5440, x2:=-201, x3:=18166, r:=6827 t:=30232
>
> Under Plan9/gcc, I have the following values:
>
> before: x1:=5440, x2:=-5843, x3:=78909
> after: x1:=5440, x2:=2147483447, x3:=1073759990, r:=6827 t:=-1073711592
>
> Uhm... seems to have a `slight' divergence...
>
> In fact, all wrong values depend upon x2, that has the "correct"
> value... with 2^31 complement. A positive when it should be negative,
> since the offending code is the following:
>
> x2 = half ( x1 + x2 + xicorr ) ;
>
> that is :
> x2 = (5440 - 5843 + 1) / 2;
>
> Not exactly pushing things to the limit! And yes, the expected result is
> indeed -201.
You would get 2147483447 if x1 and x2 were treated as
unsigned numbers but -201 if treated as signed. Try this:
cat > x.c <<EOF
#include <stdio.h>
NUM f(NUM x, NUM y) { return (x + y + 1) / 2; }
int main(int c, char**v) { printf("%d\n", f(atoi(v[1]), atoi(v[2]))); }
EOF
cc -DNUM=signed x.c && a.out 5440 -5843
cc -DNUM=unsigned x.c && a.out 5440 -5843
What is the type of x1 and x2? Can you show an actual C code
fragment? Don't worry about it being complete. Just the half()
function (or macro), header of the function where it is
called, declarations for x1 and x2 and a couple of lines of
around call to half. I am still wondering if this is due to a
different interpretation of language semantics by the two
compilers.
> Since the problem arises in this context, but not if you just add
> this isolated in a test program, and call it with these very 3
> values (5440, -5843, 1), it is clear that's the way the computation
> is handled with huge number of parameters and auto variables
> that wreaks havoc.
You *suspect* this but you need to prove it. An isolated
test case that doesn't trigger this problem simply means you
have not created the right condition for the bug. Creating a
simple test can be tricky and may be more work than debugging
your program.
> If I declare all the auto volatile, this does nothing: same result.
>
> If I do the addition, and afterwards take the half, that works:
>
> x2 += x1 + xicorr;
> x2 = half(x2); /* works! */
I wouldn't bother changing anything. You already have a
smoking gun (at least you know in which neighbourhood it has
gone off). You can try a binary search to narrow down the
area but in the end you will have to look at the assembly
output of the relevant code fragment.
next prev parent reply other threads:[~2010-04-22 17:03 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-22 15:29 tlaronde
2010-04-22 17:03 ` Bakul Shah [this message]
2010-04-22 17:36 ` tlaronde
2010-04-22 17:50 ` tlaronde
2010-04-22 19:08 ` geoff
2010-04-22 19:32 ` tlaronde
2010-04-22 20:07 ` Bakul Shah
2010-04-22 21:15 ` tlaronde
2010-04-22 21:26 ` tlaronde
2010-04-22 22:49 ` Bakul Shah
2010-04-23 7:42 ` tlaronde
2010-04-23 18:53 ` C H Forsyth
2010-04-23 18:51 ` tlaronde
2010-04-23 20:08 ` Bakul Shah
2010-04-23 20:46 ` ron minnich
2010-04-23 21:44 ` erik quanstrom
2010-04-23 22:34 ` erik quanstrom
2010-04-24 18:59 ` Bakul Shah
2010-04-24 21:47 ` Charles Forsyth
2010-04-25 0:31 ` erik quanstrom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100422170358.80B9D5B73@mail.bitblocks.com \
--to=bakul+plan9@bitblocks.com \
--cc=9fans@9fans.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).