Paul Eggert wrote:
Matthew Woehlke <[EMAIL PROTECTED]> writes:
Are you not catching the discussion on the coreutils list?
Quite possibly he's not. To summarize what I have observed so far:
We have observed no bugs when compiling without -O, so that seems to
be a viable platform.
We haven't observed any bug with left shift of long long int, even
with -O.
We haven't? I thought I'd said both had problems; in a previous message
I'd explicitly listed the right-shift errors because the actual values
that failed were relatively small in number. The left-shifts seemed to
have *more* failures, but for some reason they don't come out "in order"
the way the right-shift failures did, so it was harder to assess the
number of actual values that failed.
We have observed some bugs with right shift of long long int with -O;
e.g., (long long int) 0x27a1ad6e467a7e63 >> 1 evaluates to (long long
int) 0x1467a7e63 in some cases. (I'm guessing about the "1" here; I
don't know the specific value yet.)
I want to say '1' failed, although obviously in the bigger test program
and not the trivial case program I tried most recently.
Again, I'd be happy to *send* the actual results; filtered through '|
uniq | sort | uniq', it is about 3000 lines, 9kb bzip2'd... Assuming I
can still attach a binary file. :-)
We don't yet have a small test
case that illustrates the problem, but I hope Matthew Woehlke can
write and test one for us.
So do I. :-)
I should get to it eventually, but I have a lot of *ahem* things I'm
supposed to be doing that get priority. ;-)
Unfortunately it'll most likely be a
run-time test, but we can arrange for it to be invoked only on hosts
that have long long int but not unsigned long long int, which should
be a pretty small sample.
--
Matthew
Don't use a hippo to... what was I saying?
