[patch] Build issue on Linux/PPC32

[GoogleCodeExporter]

The 'thunk' (tested with revision 149) fails to build for Linux/PPC32 (Using 
SLES11.1 with GCC 4.3.4). The build fails with:

/bin/sh ./libtool --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
-I../gperftools -I./src  -I../gperftools/src   -Wall -Wwrite-strings 
-Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc -fno-builtin-free 
-fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree 
-fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc 
-fno-builtin-pvalloc     -O3 -DTCMALLOC_LARGE_PAGES -m32 -MT 
spinlock_internal.lo -MD -MP -MF .deps/spinlock_internal.Tpo -c -o 
spinlock_internal.lo `test -f 'src/base/spinlock_internal.cc' || echo 
'../gperftools/'`src/base/spinlock_internal.cc
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../gperftools -I./src 
-I../gperftools/src -Wall -Wwrite-strings -Woverloaded-virtual 
-Wno-sign-compare -fno-builtin-malloc -fno-builtin-free -fno-builtin-realloc 
-fno-builtin-calloc -fno-builtin-cfree -fno-builtin-memalign 
-fno-builtin-posix_memalign -fno-builtin-valloc -fno-builtin-pvalloc -O3 
-DTCMALLOC_LARGE_PAGES -m32 -MT spinlock_internal.lo -MD -MP -MF 
.deps/spinlock_internal.Tpo -c ../gperftools/src/base/spinlock_internal.cc  
-fPIC -DPIC -o .libs/spinlock_internal.o
../gperftools/src/base/spinlock_internal.cc: In function ‘int 
base::internal::SuggestedDelayNS(int)’:
../gperftools/src/base/spinlock_internal.cc:84: error: cannot convert 
‘base::subtle::Atomic64*’ to ‘const volatile Atomic32*’ for argument 
‘1’ to ‘Atomic32 base::subtle::NoBarrier_Load(const volatile Atomic32*)’
../gperftools/src/base/spinlock_internal.cc:86: error: cannot convert 
‘base::subtle::Atomic64*’ to ‘volatile Atomic32*’ for argument ‘1’ 
to ‘void base::subtle::NoBarrier_Store(volatile Atomic32*, Atomic32)’
make: *** [spinlock_internal.lo] Error 1

Currently the 'SuggestedDelayNS' relies on an implementation 
'base::subtle::NoBarrier_Load' and 'base::subtle::NoBarrier_Store' with 
'base::subtle::Atomic64' as argument and for Linux/PPC32 they are not defined.

However, since both functions acts just as load/store without any 
synchronization mechanism, I am proposing a patch that enable them even for 
PPC32 ans thus fixing the building (file gperftools-2.0-ppc32.patch).

Original issue reported on code.google.com by zatr...@gmail.com on 14 May 2012 at 12:24

• Merged into: #442

Attachments:

• gperftools-2.0-ppc32.patch

[GoogleCodeExporter]

Original comment by chapp...@gmail.com on 15 May 2012 at 5:32

• Changed state: Accepted

[GoogleCodeExporter]

Any update on this?

Original comment by zatr...@gmail.com on 21 Jun 2012 at 2:58

[GoogleCodeExporter]

I am bundling up patch work for next week. This should make it in then. We have 
been a bit side tracked trying to fix a bunch of issues introduced with the 
current glibc release :)

Original comment by chapp...@gmail.com on 21 Jun 2012 at 3:05

[GoogleCodeExporter]

I wasn't attentive although the function does not require synchronization 
mechanisms, it is still intended to be atomic. And since 64-bits load/store 
will be split in two store in PPC32, my patch is incorrect. Issue 442 
(http://code.google.com/p/gperftools/issues/detail?id=442) provides a better 
approach.

Original comment by zatr...@gmail.com on 26 Jul 2012 at 2:44

[GoogleCodeExporter]

Original comment by chapp...@gmail.com on 18 Sep 2012 at 2:40

• Changed state: Duplicate