#18576: zeromq-4.0.5 fails to build on Solaris SPARC due to casting issues with
volatite integer.
-------------------------------------------------+-------------------------
Reporter: drkirkby | Owner:
Type: PLEASE CHANGE | Status: new
Priority: major | Milestone: sage-6.8
Component: porting: Solaris | Resolution:
Keywords: | Merged in:
Authors: | Reviewers:
Report Upstream: Reported upstream. Developers | Work issues:
deny it's a bug. | Commit:
Branch: | Stopgaps:
Dependencies: |
-------------------------------------------------+-------------------------
Changes (by jdemeyer):
* upstream: Reported upstream. No feedback yet. => Reported upstream.
Developers deny it's a bug.
Old description:
> Using
>
> * Sage 6.7
> * Sun Blade 2000 with a 1200 MHz UltraSPARC III+ CPU
> * gcc 4.9.2
>
> I get a build failure on Solaris SPARC when building zeromq 4.0.5.
>
> {{{
>
> make[6]: Entering directory
> `/export/home/drkirkby/sage-6.7/local/var/tmp/sage/build/zeromq-4.0.5/src'
> make[6]: Leaving directory
> `/export/home/drkirkby/sage-6.7/local/var/tmp/sage/build/zeromq-4.0.5/src'
> CXX libzmq_la-address.lo
> CXX libzmq_la-clock.lo
> CXX libzmq_la-ctx.lo
> In file included from ctx.hpp:34:0,
> from ctx.cpp:30:
> atomic_counter.hpp: In member function 'zmq::atomic_counter_t::integer_t
> zmq::atomic_counter_t::add(zmq::atomic_counter_t::integer_t)':
> atomic_counter.hpp:87:71: error: invalid conversion from 'volatile
> integer_t* {aka volatile unsigned int*}' to 'uint32_t* {aka unsigned
> int*}' [-fpermissive]
> integer_t new_value = atomic_add_32_nv (&value, increment_);
> ^
> atomic_counter.hpp: In member function 'bool
> zmq::atomic_counter_t::sub(zmq::atomic_counter_t::integer_t)':
> atomic_counter.hpp:130:59: error: invalid conversion from 'volatile
> integer_t* {aka volatile unsigned int*}' to 'uint32_t* {aka unsigned
> int*}' [-fpermissive]
> integer_t nv = atomic_add_32_nv (&value, delta);
> ^
> make[5]: *** [libzmq_la-ctx.lo] Error 1
> make[5]: Leaving directory
> `/export/home/drkirkby/sage-6.7/local/var/tmp/sage/build/zeromq-4.0.5/src/src'
> make[4]: *** [all] Error 2
> }}}
>
> The following code, which is line 87 in atomic_counter.hpp
>
> {{{
> integer_t new_value = atomic_add_32_nv (&value, increment_);
> }}}
>
> fails to compile on the SPARC processor with gcc 4.9.2. A larger section
> of the code (lines 79 to 100), showing the problem is below.
>
> {{{
>
> // Atomic addition. Returns the old value.
>
> inline integer_t add (integer_t increment_){
> integer_t old_value;
>
> #if defined ZMQ_ATOMIC_COUNTER_WINDOWS
>
> old_value = InterlockedExchangeAdd ((LONG*) &value, increment_);
>
> #elif defined ZMQ_ATOMIC_COUNTER_ATOMIC_H
>
> integer_t new_value = atomic_add_32_nv (&value, increment_); // BREAKS
> ON SOLARIS
> old_value = new_value - increment_;
>
> #elif defined ZMQ_ATOMIC_COUNTER_TILE
>
> old_value = arch_atomic_add (&value, increment_);
>
> #elif defined ZMQ_ATOMIC_COUNTER_X86
>
> __asm__ volatile (
> "lock; xadd %0, %1 \n\t": "=r" (old_value), "=m" (value): "0"
> (increment_), "m" (value): "cc", "memory");
>
> #elif defined ZMQ_ATOMIC_COUNTER_ARM
>
> integer_t flag, tmp;__asm__ volatile (
> " dmb sy\n\t"
> }}}
>
> I am not a C++ programmer, but it looks like there is assembly code that
> is assembled on x86 and ARM processors, but that C++ line is compiled
> only on other processors, which might explain why this error has not been
> noticed before. Perhaps it was tested, but on an older gcc which did not
> indicate any error. Temporarily defining ZMQ_ATOMIC_COUNTER_ATOMIC_H on
> an x86 CPU should cause the compiler to attempt to compile the code.
>
> I '''think''' the problem is that "value" is declared on line 176 as
> volatile
>
> {{{
> volatile integer_t value;
> }}}
>
> but the definition for the function atomic_add_32_nv() on Solaris 10 in
> the header file /usr/include/atomic.h has no "volatile" there. This is
> the prototype for atomic_add_32_nv().
>
> {{{
> extern uint32_t atomic_add_32_nv(uint32_t *target, int32_t delta);
> }}}
>
> As I wrote, I am not a C++ programmer, but I'm slightly confused that
> "value" appears to be defined later in the code than where the error is
> occurring, but this might be a C++ feature I am not familiar with.
>
> GCC is also reporting a similar error on line 130, which is.
>
> {{{
> integer_t nv = atomic_add_32_nv (&value, delta);
> }}}
>
> I have reported this upstream to Martin Sustrik, who is listed in the
> "MAINTAINERS" file as maintaining virtually everything. He asked me to
> report it to zeromq-dev list, so I had to join that at
> http://zeromq.org/docs:mailing-lists then I reported to zeromq-
> [email protected]. I'm waiting a response.
New description:
Using
* Sage 6.7
* Sun Blade 2000 with a 1200 MHz UltraSPARC III+ CPU
* gcc 4.9.2
I get a build failure on Solaris SPARC when building zeromq 4.0.5.
{{{
make[6]: Entering directory
`/export/home/drkirkby/sage-6.7/local/var/tmp/sage/build/zeromq-4.0.5/src'
make[6]: Leaving directory
`/export/home/drkirkby/sage-6.7/local/var/tmp/sage/build/zeromq-4.0.5/src'
CXX libzmq_la-address.lo
CXX libzmq_la-clock.lo
CXX libzmq_la-ctx.lo
In file included from ctx.hpp:34:0,
from ctx.cpp:30:
atomic_counter.hpp: In member function 'zmq::atomic_counter_t::integer_t
zmq::atomic_counter_t::add(zmq::atomic_counter_t::integer_t)':
atomic_counter.hpp:87:71: error: invalid conversion from 'volatile
integer_t* {aka volatile unsigned int*}' to 'uint32_t* {aka unsigned
int*}' [-fpermissive]
integer_t new_value = atomic_add_32_nv (&value, increment_);
^
atomic_counter.hpp: In member function 'bool
zmq::atomic_counter_t::sub(zmq::atomic_counter_t::integer_t)':
atomic_counter.hpp:130:59: error: invalid conversion from 'volatile
integer_t* {aka volatile unsigned int*}' to 'uint32_t* {aka unsigned
int*}' [-fpermissive]
integer_t nv = atomic_add_32_nv (&value, delta);
^
make[5]: *** [libzmq_la-ctx.lo] Error 1
make[5]: Leaving directory
`/export/home/drkirkby/sage-6.7/local/var/tmp/sage/build/zeromq-4.0.5/src/src'
make[4]: *** [all] Error 2
}}}
The following code, which is line 87 in atomic_counter.hpp
{{{
integer_t new_value = atomic_add_32_nv (&value, increment_);
}}}
fails to compile on the SPARC processor with gcc 4.9.2. A larger section
of the code (lines 79 to 100), showing the problem is below.
{{{
// Atomic addition. Returns the old value.
inline integer_t add (integer_t increment_){
integer_t old_value;
#if defined ZMQ_ATOMIC_COUNTER_WINDOWS
old_value = InterlockedExchangeAdd ((LONG*) &value, increment_);
#elif defined ZMQ_ATOMIC_COUNTER_ATOMIC_H
integer_t new_value = atomic_add_32_nv (&value, increment_); // BREAKS
ON SOLARIS
old_value = new_value - increment_;
#elif defined ZMQ_ATOMIC_COUNTER_TILE
old_value = arch_atomic_add (&value, increment_);
#elif defined ZMQ_ATOMIC_COUNTER_X86
__asm__ volatile (
"lock; xadd %0, %1 \n\t": "=r" (old_value), "=m" (value): "0"
(increment_), "m" (value): "cc", "memory");
#elif defined ZMQ_ATOMIC_COUNTER_ARM
integer_t flag, tmp;__asm__ volatile (
" dmb sy\n\t"
}}}
I am not a C++ programmer, but it looks like there is assembly code that
is assembled on x86 and ARM processors, but that C++ line is compiled only
on other processors, which might explain why this error has not been
noticed before. Perhaps it was tested, but on an older gcc which did not
indicate any error. Temporarily defining ZMQ_ATOMIC_COUNTER_ATOMIC_H on an
x86 CPU should cause the compiler to attempt to compile the code.
I '''think''' the problem is that "value" is declared on line 176 as
volatile
{{{
volatile integer_t value;
}}}
but the definition for the function atomic_add_32_nv() on Solaris 10 in
the header file /usr/include/atomic.h has no "volatile" there. This is the
prototype for atomic_add_32_nv().
{{{
extern uint32_t atomic_add_32_nv(uint32_t *target, int32_t delta);
}}}
As I wrote, I am not a C++ programmer, but I'm slightly confused that
"value" appears to be defined later in the code than where the error is
occurring, but this might be a C++ feature I am not familiar with.
GCC is also reporting a similar error on line 130, which is.
{{{
integer_t nv = atomic_add_32_nv (&value, delta);
}}}
Reported upstream: [http://lists.zeromq.org/pipermail/zeromq-
dev/2015-June/028997.html]
--
--
Ticket URL: <http://trac.sagemath.org/ticket/18576#comment:6>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
