Re: proposed patch to allocsa, vasnprintf for Tandem NSK (OSS)

[Matthew Woehlke]

Paul Eggert wrote:
> Matthew Woehlke <address@hidden> 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?