bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Bug report: sort.c or AIX compiler


From: Lemley James - jlemle
Subject: RE: Bug report: sort.c or AIX compiler
Date: Thu, 17 Nov 2005 16:05:42 -0600

> From: Paul Eggert [mailto:address@hidden 
> 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_MODE=64 it creates incorrect code for sort.c.  Their
advice is to use -qnoupconv as a compiler option or to use xlc instead
of cc when compiling in 64-bit mode.  Calling it cc instead of xlc just
changes some options like this upconv thing; it's really the same
compiler. 



Here is their analysis: 

--- 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.  Here it is: 

#include <stdio.h>

                                                                      
int main()

{                                                                       
      unsigned int b = -1;

      long b2; 
      char c[] = "0123456789";                                         
      char *d = c + 5;

      printf("b is unsigned -1, which is %x\n", b );             
      printf("d is %p\n", d); 
      printf("&d[b] is %p\n", &d[b]); 
      printf("&d[0x00000000ffffffff] is %p\n", &d[0x00000000ffffffff]);

      return 0;                                                       
}

Here's what happens: 
- b is 0xffffffff using unsigned notation. 
- d is some 64 bit address (let's use 0xfffffffffffee99) 
- b is added to d to get a new address 
- because b is unsigned, it is extended to 0x00000000ffffffff so that it
retains its value. 
- 0x00000000ffffffff + 0x0fffffffffffee99 = 10000000fffff7a8 

--- end IBM note --- 


And then further, when I asked if the code or the compiler is wrong,
they reply:

--- begin IBM note --- 
Hi James, 

In this particular testcase, neither is wrong.  The compiler invocation
that you are using (cc) uses langlvl=extended.  This langlvl uses the
compiler option -qupconv by default.  This compiler option ensures that
unsigned presevartion is in effect.  This means that when -1 is
represented as an unsigned int and promoted to 64 bits, it becomes
0x00000000ffffffff instead of 0xffffffffffffffff.   

When using -qnoupconv, the default for xlc, value preservation is used
instead.  This means that addressing works as you might expect. 

In order to solve this problem, either use xlc or use the -qupconv
compiler option. 

--- end IBM note --- 
(note: in that last line I am almost sure he means -qnoupconv) 

***************************************************************************
The information contained in this communication is confidential, is
intended only for the use of the recipient named above, and may be legally
privileged.

If the reader of this message is not the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited.

If you have received this communication in error, please resend this
communication to the sender and delete the original message or any copy
of it from your computer system.

Thank You.
****************************************************************************




reply via email to

[Prev in Thread] Current Thread [Next in Thread]