RE: Bug report: sort.c or AIX compiler

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 PROT

RE: Bug report: sort.c or AIX compiler

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 kno

Re: Bug report: sort.c or AIX compiler

"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 be

RE: Bug report: sort.c or AIX compiler

> 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

Re: Bug report: sort.c or AIX compiler

"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

> 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 OBJECT_M

Re: Bug report: sort.c or AIX compiler

"Lemley James - jlemle" <[EMAIL PROTECTED]> writes: > 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) It's OK to fail with gcc 2.96, since that

RE: Bug report: sort.c or AIX compiler

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

"Lemley James - jlemle" <[EMAIL PROTECTED]> writes: > this detects it: > > #include > #include > 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 compi

RE: Bug report: sort.c or AIX compiler

> 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

"Lemley James - jlemle" <[EMAIL PROTECTED]> writes: > The problem isn't with bool or _Bool; the problem reproduces with char > and unsigned char as well. I kind of expected that with unsigned char. If char is unsigned on your host (is it?) I would expect it with char as well. > Moreover, the as

Re: Bug report: sort.c or AIX compiler

Jim Meyering <[EMAIL PROTECTED]> writes: > That looks fine. OK, I installed it into coreutils. Also into gnulib. I'm CC:ing this message to bug-gnulib so here is the patch again, relative to gnulib. The original bug report is here:

RE: Bug report: sort.c or AIX compiler

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

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 >#include >int main (void) { > assert (-

Re: Bug report: sort.c or AIX compiler

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 #include int main (void) { assert (-1 - (_Bool) 0 < 0); assert (-1 - (bool) 0 < 0);

Re: Bug report: sort.c or AIX compiler

"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 (&li

Re: Bug report: sort.c or AIX compiler

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 ad

RE: Bug report: sort.c or AIX compiler

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

"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 like the code is doing the righ

Bug report: sort.c or AIX compiler

Hi Coreutils Coders, 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 like the code is doing the right thing. Same thing is present