cuitao2046 / gperftools

Automatically exported from code.google.com/p/gperftools
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

cannot convert 'base::subtle::Atomic64*' to 'const volatile Atomic32*' #442

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. use Blue Gene/P architecture
2. ./configure --disable-shared --enable-static CXX=powerpc-bgp-linux-g++ 
CC=powerpc-bgp-linux-gcc --host=powerpc-bgp-linux
3. make

What is the expected output? What do you see instead?

This is the error I see:

> make
if /bin/sh ./libtool --tag=CXX --mode=compile powerpc-bgp-linux-g++ 
-DHAVE_CONFIG_H -I. -I. -I./src  -I./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      -g -O2 -MT spinlock_internal.lo -MD -MP -MF 
".deps/spinlock_internal.Tpo" -c -o spinlock_internal.lo `test -f 
'src/base/spinlock_internal.cc' || echo './'`src/base/spinlock_internal.cc; \
then mv -f ".deps/spinlock_internal.Tpo" ".deps/spinlock_internal.Plo"; else rm 
-f ".deps/spinlock_internal.Tpo"; exit 1; fi
libtool: compile:  powerpc-bgp-linux-g++ -DHAVE_CONFIG_H -I. -I. -I./src 
-I./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 -g -O2 -MT spinlock_internal.lo -MD 
-MP -MF .deps/spinlock_internal.Tpo -c src/base/spinlock_internal.cc -o 
spinlock_internal.o
./src/base/spinlock_linux-inl.h: In function 'void 
base::internal::SpinLockDelay(volatile Atomic32*, int32, int)':
./src/base/spinlock_linux-inl.h:87: warning: dereferencing type-punned pointer 
will break strict-aliasing rules
src/base/spinlock_internal.cc: In function 'int 
base::internal::SuggestedDelayNS(int)':
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*)'
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

Is this because 32-bit systems are no longer supported?  I am curious what is 
the reasoning for casting a 64-bit atomic type to a 32-bit atomic type.

What version of the product are you using? On what operating system?

I am using Blue Gene/P, which is a variant of 32-bit PowerPC.  I am compiling 
with GCC 4.1.2.

Thanks,

Jeff

Original issue reported on code.google.com by jeff.science@gmail.com on 2 Jul 2012 at 3:43

GoogleCodeExporter commented 9 years ago
I get the same error when compiling for 32-bit PowerPC. The problem is that 
spinlock_internal.cc assumes there will be an Atomic64 overload of 
NoBarrier_Load and NoBarrier_Store available, but atomicops-internal-linuxppc.h 
only declares the Atomic32 overloads if __PPC64__ is not defined.

It would appear that base::subtle::NoBarrier_Load(volatile const Atomic64 *) 
and base::subtle::NoBarrier_Store(volatile Atomic64 *, Atomic64) don't really 
need a PPC64 CPU, so they should not be inside an #ifdef __PPC64__ section. 
Indeed, simply commenting out the #ifdef __PPC64__ and #endif directives allows 
gperftools to compile for this architecture.

Original comment by mwhitl...@gmail.com on 24 Jul 2012 at 4:25

GoogleCodeExporter commented 9 years ago
> but atomicops-internal-linuxppc.h only declares the Atomic32 overloads if 
__PPC64__ is not defined.

Rather, I meant, atomicops-internal-linuxppc.h only declares the Atomic64 
overloads (in addition to the Atomic32 overloads) if __PPC64__ is defined. If 
__PPC64__ is not defined, then only the Atomic32 overloads are declared and not 
the Atomic64 overloads.

(I hate human languages.)

Original comment by mwhitl...@gmail.com on 24 Jul 2012 at 4:27

GoogleCodeExporter commented 9 years ago
On second thought, I am not sure that 32-bit PowerPC has a 64-bit memory access 
mode; it may need two instructions to load and store 64-bit memory locations, 
in which case there is no way to perform a lock-free, atomic, 64-bit 
load/store, so the Atomic64 overloads should remain #ifdef'd out on that 
platform.

As an alternative on platforms that lack BASE_HAS_ATOMIC64, the 
linear-congruential pseudo-random number generator in 
base::internal::SuggestedDelayNS(int) can be re-implemented as a 32-bit LCG. 
See the attached patch.

Original comment by mwhitl...@gmail.com on 24 Jul 2012 at 5:27

Attachments:

GoogleCodeExporter commented 9 years ago
Correct, one cannot do 64b atomics on PPC32.  I'll try the patch shortly.  
Thanks!

Original comment by jeff.science@gmail.com on 24 Jul 2012 at 3:59

GoogleCodeExporter commented 9 years ago
Issue 431 has been merged into this issue.

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

GoogleCodeExporter commented 9 years ago
------------------------------------------------------------------------
r160 | chappedm@gmail.com | 2012-09-17 22:47:24 -0400 (Mon, 17 Sep 2012) | 1 
line

issue-442: Fixes an issue encountered on PPC with undefined conversions from 
'base::subtle::Atomic64*' to 'const volatile Atomic32*'
------------------------------------------------------------------------

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