Paul Eggert wrote:
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),
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
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
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:
> 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:
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:
> 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?
___
Bug-coreutils mailing lis
Paul Eggert wrote:
Matthew Woehlke <[EMAIL PROTECTED]> writes:
Notice that it looks like the result of 'x>>y' under certain
circumstances is '0x1 | (x & 0x)', regardless of the
value of 'y'... which is of course Just Plain Wrong.
That's what we're looking for. Ideally, I'd li
Matthew Woehlke <[EMAIL PROTECTED]> writes:
> Notice that it looks like the result of 'x>>y' under certain
> circumstances is '0x1 | (x & 0x)', regardless of the
> value of 'y'... which is of course Just Plain Wrong.
That's what we're looking for. Ideally, I'd like a sample progr
Paul Eggert wrote:
Matthew Woehlke <[EMAIL PROTECTED]> writes:
Um, do you want the output from this? There is a LOT... almost 170k
lines according to 'wc -l'. Or is there something I should be looking
for?
That's very strange. There are only 87 lines on my platform.
I'll attach them below.
Matthew Woehlke <[EMAIL PROTECTED]> writes:
> Um, do you want the output from this? There is a LOT... almost 170k
> lines according to 'wc -l'. Or is there something I should be looking
> for?
That's very strange. There are only 87 lines on my platform.
I'll attach them below.
I'm talking about
Paul Eggert wrote:
Have you had a chance to look into the problems with long long shifts
on NSK(OSS)? What happens if you compile and run the following program?
Um, do you want the output from this? There is a LOT... almost 170k
lines according to 'wc -l'. Or is there something I should be lo
Have you had a chance to look into the problems with long long shifts
on NSK(OSS)? What happens if you compile and run the following program?
/*
* Bestimmung einiger Maschinen-Parameter und -Abhängigkeiten
* und Ausgabe in ein Include-File
* Bruno Haible 10.9.1991, 12.10.1992, 6.12.1992, 24.10
I wrote:
> Fundamentally the problem is that sha512 assumes a 64-bit unsigned
> integer type, and you don't have one. I guess the best way to fix
> this is to change coreutils to not build sha512 on hosts that don't
> have uint64_t.
I started to implement that, but it was such a configuration ha
* Matthew Woehlke wrote on Thu, Oct 12, 2006 at 08:20:14PM CEST:
> Paul Eggert wrote:
> >
> >--- m4/extensions.m4 3 Oct 2006 04:12:40 - 1.11
> >+++ m4/extensions.m4 11 Oct 2006 23:10:59 -
> [snip]
> >+#ifndef _TANDEM_SOURCE
> >+# undef _TANDEM_SOURCE
> > #endif])
> [snip]
>
> Um... i
mwoehlke <[EMAIL PROTECTED]> writes:
> If I am seeing correctly, however, aren't you missing
> patches to Makefile.in and configure (or rather sources there-to)
Those files are not installed in CVS, so there's no need to send
patches for them. You can regenerate them. See the file README-cvs.
I
mwoehlke <[EMAIL PROTECTED]> writes:
> I would prefer
> that autoconf know that if it is on NSK/OSS ('#ifdef __TANDEM'), that
> _TANDEM_SOURCE needs to be defined.
OK, I installed this patch into gnulib; this merges the change to
Autoconf that I installed earlier there today for this.
2006-10-11
mwoehlke <[EMAIL PROTECTED]> writes:
> I would prefer that autoconf know that if it is on NSK/OSS ('#ifdef
> __TANDEM'), that _TANDEM_SOURCE needs to be defined.
Makes sense, though I wish this stuff were better-documented on the
web. Might as well do it unconditionally, as that's what we do for
Paul Eggert wrote:
mwoehlke <[EMAIL PROTECTED]> writes:
Ok... Attaching an initial attempt at a patch for stdint_.h. The
configure script (or more appropriately, I suppose, configure.in)
needs to be patched additionally, but alas, I do not speak autotools
:-)
I'm afraid you'll have to get up t
I installed the following into gnulib in an attempt to address part of
the porting problem that you mentioned.
2006-10-10 Paul Eggert <[EMAIL PROTECTED]>
Port to Tandem NSK OSS, which has 64-bit signed int but at most
32-bit unsigned int. Problem reported by Matthew Woehlke in:
mwoehlke <[EMAIL PROTECTED]> writes:
> Ok... Attaching an initial attempt at a patch for stdint_.h. The
> configure script (or more appropriately, I suppose, configure.in)
> needs to be patched additionally, but alas, I do not speak autotools
> :-)
I'm afraid you'll have to get up to speed with t
Paul Eggert wrote:
mwoehlke <[EMAIL PROTECTED]> writes:
So what would be your recommendation? Remove all use of 64-bit
integers? (i.e. make intmax_t also 'long' rather than 'long long'?)
No, I'd make uintmax_t 32-bit and intmax_t 64 bit, if those are
the widest unsigned and signed types. Then
mwoehlke wrote:
I have a problem building on Tandem/NSK OSS; specifically, uintmax_t
(unsigned long long) is not a valid data type. [snip]
Also, I don't remember this problem with 5.97 (but I could be wrong);
[snip]
Ah, hmm, maybe '2006-08-21 Jim Meyering <[EMAIL PROTECTED]>' has
somethin
mwoehlke <[EMAIL PROTECTED]> writes:
> So what would be your recommendation? Remove all use of 64-bit
> integers? (i.e. make intmax_t also 'long' rather than 'long long'?)
No, I'd make uintmax_t 32-bit and intmax_t 64 bit, if those are
the widest unsigned and signed types. Then I'd fix any bugs
Paul Eggert wrote:
mwoehlke <[EMAIL PROTECTED]> writes:
I have a problem building on Tandem/NSK OSS; specifically, uintmax_t
(unsigned long long) is not a valid data type (don't ask me why!).
Sorry, but we've gotta ask why. Why isn't it a valid data type?
Does the compiler reject 'unsigned l
mwoehlke <[EMAIL PROTECTED]> writes:
> I have a problem building on Tandem/NSK OSS; specifically, uintmax_t
> (unsigned long long) is not a valid data type (don't ask me why!).
Sorry, but we've gotta ask why. Why isn't it a valid data type?
Does the compiler reject 'unsigned long long int x;'?
26 matches
Mail list logo
