[Bug c++/35836] New: Wrong instruction generated for comparison with zero on PPC 64 bit

[Bug c++/35836] New: Wrong instruction generated for comparison with zero on PPC 64 bit

[oder at eleks dot lviv dot ua]

MacOS 10.5

============= begin of test.cpp =================
#include <stdio.h>

#include <libkern/OSAtomic.h>

typedef int32_t atomicord32;

static inline atomicord32 __attribute__((always_inline))
/*atomicord32 */AtomicIncrement(volatile atomicord32 *paoDestination)
{
        return OSAtomicIncrement32Barrier(paoDestination);
}

bool TestAtomic_Increment()
{
        bool bResult = false;

        do
        {
                volatile atomicord32 aoStorage = (atomicord32)(-1);

                if (AtomicIncrement(&aoStorage) != (atomicord32)0 || aoStorage
!= (atomicord32)0)
                {
                        break;
                }

                if (AtomicIncrement(&aoStorage) != (atomicord32)1 || aoStorage
!= (atomicord32)1)
                {
                        break;
                }

                bResult = true;
        }
        while (false);

        return bResult;
}

int main()
{
  bool bTestResult = TestAtomic_Increment();
  printf("%d\n", (int)(bTestResult ? 1 : 0));

  return 0;
}
============= end of test.cpp =================

with "-m64" TestAtomic_Increment compiles to
================
0x00000001000026e0 <_Z20TestAtomic_Incrementv+0>:       mflr    r0
0x00000001000026e4 <_Z20TestAtomic_Incrementv+4>:       std     r30,-16(r1)
0x00000001000026e8 <_Z20TestAtomic_Incrementv+8>:       std     r0,16(r1)
0x00000001000026ec <_Z20TestAtomic_Incrementv+12>:      stdu    r1,-160(r1)
0x00000001000026f0 <_Z20TestAtomic_Incrementv+16>:      mr      r30,r1
0x00000001000026f4 <_Z20TestAtomic_Incrementv+20>:      li      r0,0
0x00000001000026f8 <_Z20TestAtomic_Incrementv+24>:      stb     r0,112(r30)
0x00000001000026fc <_Z20TestAtomic_Incrementv+28>:      li      r0,-1
0x0000000100002700 <_Z20TestAtomic_Incrementv+32>:      stw     r0,116(r30)
0x0000000100002704 <_Z20TestAtomic_Incrementv+36>:      addi    r0,r30,116
0x0000000100002708 <_Z20TestAtomic_Incrementv+40>:      mr      r3,r0
0x000000010000270c <_Z20TestAtomic_Incrementv+44>:      bl      0x1000017c4
<AtomicIncrement>
0x0000000100002710 <_Z20TestAtomic_Incrementv+48>:      mr      r0,r3
0x0000000100002714 <_Z20TestAtomic_Incrementv+52>:      cmpdi   cr7,r0,0
0x0000000100002718 <_Z20TestAtomic_Incrementv+56>:      bne-    cr7,0x10000272c
<_Z20TestAtomic_Incrementv+76>
0x000000010000271c <_Z20TestAtomic_Incrementv+60>:      lwz     r0,116(r30)
0x0000000100002720 <_Z20TestAtomic_Incrementv+64>:      extsw   r0,r0
0x0000000100002724 <_Z20TestAtomic_Incrementv+68>:      cmpdi   cr7,r0,0
0x0000000100002728 <_Z20TestAtomic_Incrementv+72>:      beq-    cr7,0x100002738
<_Z20TestAtomic_Incrementv+88>
0x000000010000272c <_Z20TestAtomic_Incrementv+76>:      li      r0,1
0x0000000100002730 <_Z20TestAtomic_Incrementv+80>:      std     r0,136(r30)
0x0000000100002734 <_Z20TestAtomic_Incrementv+84>:      b       0x100002740
<_Z20TestAtomic_Incrementv+96>
0x0000000100002738 <_Z20TestAtomic_Incrementv+88>:      li      r0,0
0x000000010000273c <_Z20TestAtomic_Incrementv+92>:      std     r0,136(r30)
0x0000000100002740 <_Z20TestAtomic_Incrementv+96>:      ld      r0,136(r30)
0x0000000100002744 <_Z20TestAtomic_Incrementv+100>:     cmpdi   cr7,r0,0
0x0000000100002748 <_Z20TestAtomic_Incrementv+104>:     bne-    cr7,0x10000279c
<_Z20TestAtomic_Incrementv+188>
0x000000010000274c <_Z20TestAtomic_Incrementv+108>:     addi    r0,r30,116
0x0000000100002750 <_Z20TestAtomic_Incrementv+112>:     mr      r3,r0
0x0000000100002754 <_Z20TestAtomic_Incrementv+116>:     bl      0x1000017c4
<AtomicIncrement>
0x0000000100002758 <_Z20TestAtomic_Incrementv+120>:     mr      r0,r3
0x000000010000275c <_Z20TestAtomic_Incrementv+124>:     cmpwi   cr7,r0,1
0x0000000100002760 <_Z20TestAtomic_Incrementv+128>:     bne-    cr7,0x100002774
<_Z20TestAtomic_Incrementv+148>
0x0000000100002764 <_Z20TestAtomic_Incrementv+132>:     lwz     r0,116(r30)
0x0000000100002768 <_Z20TestAtomic_Incrementv+136>:     extsw   r0,r0
0x000000010000276c <_Z20TestAtomic_Incrementv+140>:     cmpwi   cr7,r0,1
0x0000000100002770 <_Z20TestAtomic_Incrementv+144>:     beq-    cr7,0x100002780
<_Z20TestAtomic_Incrementv+160>
0x0000000100002774 <_Z20TestAtomic_Incrementv+148>:     li      r0,1
0x0000000100002778 <_Z20TestAtomic_Incrementv+152>:     std     r0,128(r30)
0x000000010000277c <_Z20TestAtomic_Incrementv+156>:     b       0x100002788
<_Z20TestAtomic_Incrementv+168>
0x0000000100002780 <_Z20TestAtomic_Incrementv+160>:     li      r0,0
0x0000000100002784 <_Z20TestAtomic_Incrementv+164>:     std     r0,128(r30)
0x0000000100002788 <_Z20TestAtomic_Incrementv+168>:     ld      r0,128(r30)
0x000000010000278c <_Z20TestAtomic_Incrementv+172>:     cmpdi   cr7,r0,0
0x0000000100002790 <_Z20TestAtomic_Incrementv+176>:     bne-    cr7,0x10000279c
<_Z20TestAtomic_Incrementv+188>
0x0000000100002794 <_Z20TestAtomic_Incrementv+180>:     li      r0,1
0x0000000100002798 <_Z20TestAtomic_Incrementv+184>:     stb     r0,112(r30)
0x000000010000279c <_Z20TestAtomic_Incrementv+188>:     lbz     r0,112(r30)
0x00000001000027a0 <_Z20TestAtomic_Incrementv+192>:     clrldi  r0,r0,56
0x00000001000027a4 <_Z20TestAtomic_Incrementv+196>:     mr      r3,r0
0x00000001000027a8 <_Z20TestAtomic_Incrementv+200>:     ld      r1,0(r1)
0x00000001000027ac <_Z20TestAtomic_Incrementv+204>:     ld      r0,16(r1)
0x00000001000027b0 <_Z20TestAtomic_Incrementv+208>:     mtlr    r0
0x00000001000027b4 <_Z20TestAtomic_Incrementv+212>:     ld      r30,-16(r1)
0x00000001000027b8 <_Z20TestAtomic_Incrementv+216>:     blr
================

For comparison of first AtomicIncrement() invocation result with zero "cmpdi  
cr7,r0,0" instruction has been generated at 0x0000000100002714, which is
incorrect.
For comparison of second AtomicIncrement() invocation result with one "cmpwi  
cr7,r0,1" instruction has been generated at 0x000000010000275c, which is
correct.

On exit from first call to AtomicIncrement() cr3 equals to 0x100000000
(naturally, 0x0FFFFFFFF + 1) and 8 byte comparison with zero yields incorrect
result.

osx-leopard:build oder$ g++ -m64 -o test test.cpp
osx-leopard:build oder$ ./test
0


-- 
           Summary: Wrong instruction generated for comparison with zero on
                    PPC 64 bit
           Product: gcc
           Version: 4.0.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: oder at eleks dot lviv dot ua
 GCC build triplet: ppc
  GCC host triplet: ppc
GCC target triplet: ppc


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35836

[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2008-04-05 21:13 -------
You need to report this with apple or at least try a still maintained gcc
version and provide a testcase without Mac specific headers.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35836

[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit

[oder at eleks dot lviv dot ua]

------- Comment #2 from oder at eleks dot lviv dot ua  2008-04-06 13:21 -------
(In reply to comment #1)
> You need to report this with apple or at least try a still maintained gcc
> version and provide a testcase without Mac specific headers.

Well, it's not so easy. ./configure for GCC 4.3.0 fails with "Building GCC
requires GMP 4.1+ and MPFR 2.3.0+". I don't know what these are and I'm not too
eager spending time to search for all the necessary stuff needed to build a new
version and find out that there is some problem with building I can't resolve
after all. If there are no prebuilt binaries publicly available that means
there must be some reason for it. 
I have already tried to build latest GCC once for QNX. Well, after few days and
lots of corrections to headers I succeeded. But then I found that there are
some system related settings I don't know how to specify for new compiler and
startup stubs in objs, I don't have sources for. So, even though compiler
worked I did not take a risk to use it for production binaries compilation.
As for getting rid of system-specific headers, I tried replacing
OSAtomicIncrement32Barrier(paoDestination) with increment for volatile int64_t,
but the problem can't be reproduced that way. 
This seems to be PowerPC architecture related problem and I don't have other
operating systems/machines based on PowerPC.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35836

[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2008-04-06 13:57 -------
Please attach preprocessed source then, it is likely that apples
OSAtomicIncrement32Barrier implementation is simply bogus (which is why I
suggested reporting this bug to apple).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35836

[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit

[brian at dessent dot net]

------- Comment #4 from brian at dessent dot net  2008-04-06 19:49 -------
Subject: Re:  Wrong instruction generated for comparison with zero 
 on PPC 64 bit

> after all. If there are no prebuilt binaries publicly available that means
> there must be some reason for it.

Where in the world do you get that idea?  Both Fink and Macports have
gcc 4.1, 4.2, and 4.3 packages, and Macports even has a 4.4 snapshot.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35836

[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit

[oder at eleks dot lviv dot ua]

------- Comment #5 from oder at eleks dot lviv dot ua  2008-04-06 20:14 -------
(In reply to comment #4)
> Both Fink and Macports have
> gcc 4.1, 4.2, and 4.3 packages, and Macports even has a 4.4 snapshot.

Could you please provide a link to gcc archive?
On gcc.gnu.org there is no MacOS in Download->Binaries
Fink webpage offers binary installer for download. But I don't like it, since,
as I already mentioned, I don't have root access and would not like to install
anything outside my home folder on a computer I've been let in just to have a
try if my sources could be compiled on MacOS.
As for Macports, I can't browse that site with IE7. It attempts to download
some XML file all the time instead of browsing the pages.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35836

[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit

[brian at dessent dot net]

------- Comment #6 from brian at dessent dot net  2008-04-06 20:44 -------
Subject: Re:  Wrong instruction generated for comparison with zero 
 on PPC 64 bit

> Could you please provide a link to gcc archive?
> On gcc.gnu.org there is no MacOS in Download->Binaries

gcc.gnu.org doesn't supply any binaries, only source.  If you want
binaries you get them from a third party like Debian, SuSE, Fedora,
Fink, MinGW, whatever.  gcc supports something like three dozen
architectures, each with numerous variants/configurations -- there's no
way that any one organization could maintain binaries for those hundreds
of resulting target combinations.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35836

[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2008-04-07 01:22 -------
Can you provide the .ii file which is generated when you add the -save-temps
option.  I want to say this is a bug in Apple's header's inline-asm.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35836

[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit

[oder at eleks dot lviv dot ua]

------- Comment #8 from oder at eleks dot lviv dot ua  2008-04-07 08:58 -------
Created an attachment (id=15438)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15438&action=view)
Preprocessed source


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35836

[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit

[oder at eleks dot lviv dot ua]

------- Comment #9 from oder at eleks dot lviv dot ua  2008-05-21 15:39 -------
Created an attachment (id=15666)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15666&action=view)
Sources without Mac headers

So, I had some free time an enthusiasm to modify the example and remove Apple
headers from it. Now it is OS independent. Please remember that the bug seems
to be ppc64-specific (or at least *64-specific) at first glance though.

Note: It is OK that function returns int64 while its caller expects int32. It
should not affect the result of the test but helps to demonstrate the bug.


-- 

oder at eleks dot lviv dot ua changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #15438|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35836

[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit

[oder at eleks dot lviv dot ua]

-- 

oder at eleks dot lviv dot ua changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |UNCONFIRMED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35836

[Bug target/35836] Wrong instruction generated for comparison with zero on PPC 64 bit

[pinskia at gcc dot gnu dot org]

------- Comment #10 from pinskia at gcc dot gnu dot org  2008-05-21 15:45 -------
OSAtomicIncrement32Barrier will return a 32bit signed extended value to a 64bit
so using a 64bit compare is fine and ok according to the ABI.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |target


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35836

[Bug target/35836] Wrong instruction generated for comparison with zero on PPC 64 bit

[oder at eleks dot lviv dot ua]

------- Comment #11 from oder at eleks dot lviv dot ua  2008-05-21 16:27 -------
(In reply to comment #10)
> OSAtomicIncrement32Barrier will return a 32bit signed extended value to a 64bit
> so using a 64bit compare is fine and ok according to the ABI.

Yes, but it returns value in 64-bit register with lower 32 bit being correct
and higher 32 bit being nonzero (the garbage) and using 64bit comparison for
equality with zero yields incorrect result.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35836

[Bug target/35836] Wrong instruction generated for comparison with zero on PPC 64 bit

[pinskia at gcc dot gnu dot org]

------- Comment #12 from pinskia at gcc dot gnu dot org  2008-05-21 16:31 -------
Your testcase here is invalid as you have two different return types for the
same function.  


If Apple's libc does not fully implement the ABI correctly, that is their bug,
please report it to them.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35836