RE: Bug report: sort.c or AIX compiler

2005-11-21 Thread Lemley James - jlemle
Paul Eggert writes: The basic idea here is that coreutils will attempt to detect the problem, and pass the -qlanglvl=extc89 option to IBM's compiler. (It will pass -qlanglvl=ansi to older versions of IBM's compilers.) I assume this will work around the problem; if not, please let me know.

RE: Bug report: sort.c or AIX compiler

2005-11-21 Thread Lemley James - jlemle
Yes, -qlanglvl=extc89 fixes it so we are good to go. Thanks. -Original Message- From: Paul Eggert [mailto:[EMAIL PROTECTED] Sent: Monday, November 21, 2005 2:49 PM To: Lemley James - jlemle Cc: bug-coreutils@gnu.org Subject: Re: FW: PMR 52061,370,000 Lemley James - jlemle [EMAIL

RE: Bug report: sort.c or AIX compiler

2005-11-18 Thread Lemley James - jlemle
IBM's test case is fine, but it's not related to the bug. The bug, as I understand it, is exhibited when you use bool. IBM's test case does not involve bool. Well, no. I've discovered that bool isn't really involved; it's an unsigned problem when dealing with 64-bit math. The fact that we

Re: Bug report: sort.c or AIX compiler

2005-11-18 Thread Paul Eggert
Lemley James - jlemle [EMAIL PROTECTED] writes: --- begin IBM note --- There is nothing to fix in cc. This compiler invocation is intended to use an older language level, which uses -qupconv. I understand why IBM cc emulates older compilers when promoting unsigned short. That is because

RE: Bug report: sort.c or AIX compiler

2005-11-17 Thread Lemley James - jlemle
From: Paul Eggert [mailto:[EMAIL PROTECTED] Sent: Friday, October 07, 2005 2:00 PM Also, could you please report the xlc bug to IBM? After going back and forth with IBM some, it appears they don't think there is problem with their compiler, even though with the default options and

Re: Bug report: sort.c or AIX compiler

2005-11-17 Thread Paul Eggert
Lemley James - jlemle [EMAIL PROTECTED] writes: --- begin IBM note --- Hi James, This is not a defect. I wrote a new testcase that exhibits the same behaviour as the one that was submitted. IBM's test case is fine, but it's not related to the bug. The bug, as I understand it, is

Re: Bug report: sort.c or AIX compiler

2005-10-06 Thread Paul Eggert
How about if we install the following coreutils patch? It should catch the more-general problem, if I understand it aright. My understanding is that the following little C program: #include stdbool.h #include assert.h int main (void) { assert (-1 - (_Bool) 0 0); assert (-1 -

Re: Bug report: sort.c or AIX compiler

2005-10-06 Thread Jim Meyering
Paul Eggert [EMAIL PROTECTED] wrote: How about if we install the following coreutils patch? It should catch the more-general problem, if I understand it aright. My understanding is that the following little C program: #include stdbool.h #include assert.h int main (void) {

RE: Bug report: sort.c or AIX compiler

2005-10-06 Thread Lemley James - jlemle
Paul, Jim and other interested parties: The problem isn't with bool or _Bool; the problem reproduces with char and unsigned char as well. Moreover, the assert won't catch it. Looks like a rather severe compiler bug to me. Example program output: -2 + b is -1 -2 + b is -1 -2 + b is -1 d[-2

RE: Bug report: sort.c or AIX compiler

2005-10-06 Thread Lemley James - jlemle
So, the problem occurs only in a subscript context? I really would like to catch it if possible. Near as I can tell, that's right. At least printf prints the right thing. Does the following program catch it? I'll looking for a way to detect that compiler bug at compile-time. Just what

Re: Bug report: sort.c or AIX compiler

2005-10-06 Thread Paul Eggert
Lemley James - jlemle [EMAIL PROTECTED] writes: this detects it: #include stdbool.h #include stdio.h char *c = NULL; int main() { return (c + 5)[-2 + (bool) 1] == c[4] ? 0 : 1; } Thanks. We might use that if that's the best we can do, but I want something that works at

RE: Bug report: sort.c or AIX compiler

2005-10-06 Thread Lemley James - jlemle
Oh, I get it. I didn't realize you wanted fail at compile time. Hm... No, that fails to compile in both 64-bit and 32-bit mode, as well as my old development Linux box (gcc 2.96 on Redhat 7.2) AIX says: eggert.c, line 3.12: 1506-221 (S) Initializer must be a valid constant expression. GCC

RE: Bug report: sort.c or AIX compiler

2005-10-05 Thread Lemley James - jlemle
It dumps core as before. -Original Message- ... Would you please see if it works with this syntax? bool swap = !!(0 compare (lines[-1], lines[-2])); ... ** The information contained in this communication is

Re: Bug report: sort.c or AIX compiler

2005-10-05 Thread Jim Meyering
Jim Meyering [EMAIL PROTECTED] wrote: Lemley James - jlemle [EMAIL PROTECTED] wrote: when compiling coreutils 5.90 on AIX 5.3 in 64 bit mode (OBJECT_MODE=64), sort dumps core at line 1724 or 1725 (coreutils 5.90). It works fine in 32-bit mode, and debugging statements I add make it seem

Re: Bug report: sort.c or AIX compiler

2005-10-05 Thread Paul Eggert
Lemley James - jlemle [EMAIL PROTECTED] writes: When this change is made, it runs just fine (well, it works for at least one input) after being compiled in 64-bit mode: 1723c1723 bool swap = (0 compare (lines[-1], lines[-2])); --- int swap = (0 compare (lines[-1],