Paul Eggert wrote:
Matthew Woehlke <[EMAIL PROTECTED]> writes:
Nope, no luck, '0' in both cases, and adding a printf confirms the
correct values.
Can you strip down intparam1.c to relatively small test case that
illustrates the problem?
Sorry for taking so long, I am just now looking at thi
Matthew Woehlke <[EMAIL PROTECTED]> writes:
> This simple test is OK on my Linux box and on NSK without -O. It does
> not work /AT ALL/ (100% failure rate) on NSK with -O.
OK, but the C standard does not require that it has to work, because
it doesn't say what happens when you shift a negative in
Paul Eggert wrote:
Matthew Woehlke <[EMAIL PROTECTED]> writes:
This simple test is OK on my Linux box and on NSK without -O. It does
not work /AT ALL/ (100% failure rate) on NSK with -O.
OK, but the C standard does not require that it has to work, because
it doesn't say what happens when you s
Matthew Woehlke <[EMAIL PROTECTED]> writes:
> Eh? How is testing if ((1<<1)>>1) == 1 "too strict"?
It's not. But it wasn't clear from your earlier posting whether the
failure was 1LL<<1>>1 or 1LL<<63>>63. The latter is not required to
yield 1 (assuming long long is 64 bits), because C doesn't d
I installed the following into Autoconf to propagate the gnulib fix
into Autoconf.
2006-11-07 Paul Eggert <[EMAIL PROTECTED]>
* lib/autoconf/types.m4 (AC_TYPE_LONG_LONG_INT): Detect bug in
Tandem NonStop Kernel (OSS) cc -O circa 2004, reported by
Matthew Woehlke.
--- li
