[Xenomai] Boost thread macro confilct

[Xenomai] Boost thread macro confilct

[Antoine Hoarau]

Hi again,

I'm having some issues with boost threads macros. If I compile the
following code :

#include <alchemy/task.h>
#include <boost/thread.hpp>
int main() { return 0; }

g++ b.cc $(xeno-config --alchemy --cflags)  $(xeno-config --alchemy
--ldflags) -lboost_system -lboost_thread

It gives me a lot of errors regarding "barrier", a macro present in both
librairies. Copperplate's debug macro also created similar issues with
log4cpp lib.

It compiles only if :
1) Unsetting barrier from alchemy

#include <alchemy/task.h>
#unset barrier
#include <boost/thread.hpp>
int main() { return 0; }

2) Changing the order of the includes (easy here, but hard on a big library)

#include <boost/thread.hpp>
#include <alchemy/task.h>
int main() { return 0; }

I guess it's not a redefinition, but an overloading :

/usr/include/boost/thread/barrier.hpp:138:22: error: too many arguments
provided to function-like macro invocation
    explicit barrier(unsigned int count) :
                     ^
/usr/xenomai/include/boilerplate/atomic.h:83:9: note: macro 'barrier'
defined here
#define barrier()       __asm__ __volatile__("": : :"memory")

Thanks for your insights !

-- 
Antoine Hoarau
Robotics Engineer

Re: [Xenomai] Boost thread macro confilct

[Philippe Gerum]

On 09/24/2017 04:52 PM, Antoine Hoarau wrote:
> Hi again,
> 
> I'm having some issues with boost threads macros. If I compile the
> following code :
> 
> #include <alchemy/task.h>
> #include <boost/thread.hpp>
> int main() { return 0; }
> 
> g++ b.cc $(xeno-config --alchemy --cflags)  $(xeno-config --alchemy
> --ldflags) -lboost_system -lboost_thread
> 
> It gives me a lot of errors regarding "barrier", a macro present in both
> librairies. Copperplate's debug macro also created similar issues with
> log4cpp lib.
> 
> It compiles only if :
> 1) Unsetting barrier from alchemy
> 
> #include <alchemy/task.h>
> #unset barrier
> #include <boost/thread.hpp>
> int main() { return 0; }
> 
> 2) Changing the order of the includes (easy here, but hard on a big library)
> 
> #include <boost/thread.hpp>
> #include <alchemy/task.h>
> int main() { return 0; }
> 
> I guess it's not a redefinition, but an overloading :
> 
> /usr/include/boost/thread/barrier.hpp:138:22: error: too many arguments
> provided to function-like macro invocation
>     explicit barrier(unsigned int count) :
>                      ^
> /usr/xenomai/include/boilerplate/atomic.h:83:9: note: macro 'barrier'
> defined here
> #define barrier()       __asm__ __volatile__("": : :"memory")
> 

We want to define a compiler barrier that represents a strong sequence
point in the instruction flow, this has nothing to do with a thread
synchronization method. We only have a very few instances of such
barriers, so the best fix is to rename our macro.

Please pull this change:
http://git.xenomai.org/xenomai-3.git/commit/?id=cd8815510e4ea53218a36518be09276bab21750d

-- 
Philippe.

Re: [Xenomai] Boost thread macro confilct

[Antoine Hoarau]

2017-09-24 17:17 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
> On 09/24/2017 04:52 PM, Antoine Hoarau wrote:
>> Hi again,
>>
>> I'm having some issues with boost threads macros. If I compile the
>> following code :
>>
>> #include <alchemy/task.h>
>> #include <boost/thread.hpp>
>> int main() { return 0; }
>>
>> g++ b.cc $(xeno-config --alchemy --cflags)  $(xeno-config --alchemy
>> --ldflags) -lboost_system -lboost_thread
>>
>> It gives me a lot of errors regarding "barrier", a macro present in both
>> librairies. Copperplate's debug macro also created similar issues with
>> log4cpp lib.
>>
>> It compiles only if :
>> 1) Unsetting barrier from alchemy
>>
>> #include <alchemy/task.h>
>> #unset barrier
>> #include <boost/thread.hpp>
>> int main() { return 0; }
>>
>> 2) Changing the order of the includes (easy here, but hard on a big library)
>>
>> #include <boost/thread.hpp>
>> #include <alchemy/task.h>
>> int main() { return 0; }
>>
>> I guess it's not a redefinition, but an overloading :
>>
>> /usr/include/boost/thread/barrier.hpp:138:22: error: too many arguments
>> provided to function-like macro invocation
>>     explicit barrier(unsigned int count) :
>>                      ^
>> /usr/xenomai/include/boilerplate/atomic.h:83:9: note: macro 'barrier'
>> defined here
>> #define barrier()       __asm__ __volatile__("": : :"memory")
>>
>
> We want to define a compiler barrier that represents a strong sequence
> point in the instruction flow, this has nothing to do with a thread
> synchronization method. We only have a very few instances of such
> barriers, so the best fix is to rename our macro.
>
> Please pull this change:
> http://git.xenomai.org/xenomai-3.git/commit/?id=cd8815510e4ea53218a36518be09276bab21750d
>
> --
> Philippe.

Excellent, that fixes the barrier problem.
There's now also clz and cls in boilerplate/compiler.h, that conflicts
with libtbb, and debug() in copperplate/debug.h, that conflicts with a
lot of libs I use.


I really don't know why the compiler gets so confused, here's an example :

#include <alchemy/task.h>

struct A
{
A():debug(0){}
bool debug;
};

int main() { return 0; }

The build returns :

/usr/xenomai/include/copperplate/debug.h:38:30: error: expected
identifier before ‘do’
 #define debug(fmt, args...)  do { } while (0)
                              ^
/home/hoarau/dev/boost-xeno3/b.cc:6:6: note: in expansion of macro ‘debug’
  A():debug(0){}
      ^

hack-fix using #define _COPPERPLATE_DEBUG_H before including xeno3 headers.

Re: [Xenomai] Boost thread macro confilct

[Philippe Gerum]

On 09/24/2017 08:19 PM, Antoine Hoarau wrote:
> 2017-09-24 17:17 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>> On 09/24/2017 04:52 PM, Antoine Hoarau wrote:
>>> Hi again,
>>>
>>> I'm having some issues with boost threads macros. If I compile the
>>> following code :
>>>
>>> #include <alchemy/task.h>
>>> #include <boost/thread.hpp>
>>> int main() { return 0; }
>>>
>>> g++ b.cc $(xeno-config --alchemy --cflags)  $(xeno-config --alchemy
>>> --ldflags) -lboost_system -lboost_thread
>>>
>>> It gives me a lot of errors regarding "barrier", a macro present in both
>>> librairies. Copperplate's debug macro also created similar issues with
>>> log4cpp lib.
>>>
>>> It compiles only if :
>>> 1) Unsetting barrier from alchemy
>>>
>>> #include <alchemy/task.h>
>>> #unset barrier
>>> #include <boost/thread.hpp>
>>> int main() { return 0; }
>>>
>>> 2) Changing the order of the includes (easy here, but hard on a big library)
>>>
>>> #include <boost/thread.hpp>
>>> #include <alchemy/task.h>
>>> int main() { return 0; }
>>>
>>> I guess it's not a redefinition, but an overloading :
>>>
>>> /usr/include/boost/thread/barrier.hpp:138:22: error: too many arguments
>>> provided to function-like macro invocation
>>>     explicit barrier(unsigned int count) :
>>>                      ^
>>> /usr/xenomai/include/boilerplate/atomic.h:83:9: note: macro 'barrier'
>>> defined here
>>> #define barrier()       __asm__ __volatile__("": : :"memory")
>>>
>>
>> We want to define a compiler barrier that represents a strong sequence
>> point in the instruction flow, this has nothing to do with a thread
>> synchronization method. We only have a very few instances of such
>> barriers, so the best fix is to rename our macro.
>>
>> Please pull this change:
>> http://git.xenomai.org/xenomai-3.git/commit/?id=cd8815510e4ea53218a36518be09276bab21750d
>>
>> --
>> Philippe.
> 
> Excellent, that fixes the barrier problem.
> There's now also clz and cls in boilerplate/compiler.h, that conflicts
> with libtbb, and debug() in copperplate/debug.h, that conflicts with a
> lot of libs I use.
> 
> 
> I really don't know why the compiler gets so confused, here's an example :
> 
> #include <alchemy/task.h>
> 
> struct A
> {
> A():debug(0){}
> bool debug;
> };
> 

Because it ends up compiling this in the !debug case, once the
preprocessor tokens have been substituted:

struct A
{
A():do { } while (0)(0){}
bool do { } while (0);
};

> int main() { return 0; }
> 
> The build returns :
> 
> /usr/xenomai/include/copperplate/debug.h:38:30: error: expected
> identifier before ‘do’
>  #define debug(fmt, args...)  do { } while (0)
>                               ^
> /home/hoarau/dev/boost-xeno3/b.cc:6:6: note: in expansion of macro ‘debug’
>   A():debug(0){}
>       ^
> 
> hack-fix using #define _COPPERPLATE_DEBUG_H before including xeno3 headers.
> 

This would be abusing the inclusion guards, I would not recommend this.
The tiny debug API is an internal feature of the Xenomai stack, no need
to expose this to client C++ code. I would suggest the following change
instead:

diff --git a/include/copperplate/debug.h b/include/copperplate/debug.h
index 027f12c..494f0f2 100644
--- a/include/copperplate/debug.h
+++ b/include/copperplate/debug.h
@@ -21,6 +21,8 @@

 #include <boilerplate/debug.h>

+#ifndef __cplusplus
+
 #ifdef CONFIG_XENO_DEBUG

 struct threadobj;
@@ -39,4 +41,6 @@ struct threadobj;

 #endif /* !CONFIG_XENO_DEBUG */

+#endif /* !__cplusplus */
+
 #endif /* _COPPERPLATE_DEBUG_H */

Feedback welcome.

-- 
Philippe.

Re: [Xenomai] Boost thread macro confilct

[Philippe Gerum]

On 09/25/2017 07:35 PM, Philippe Gerum wrote:
> On 09/24/2017 08:19 PM, Antoine Hoarau wrote:
>> 2017-09-24 17:17 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>>> On 09/24/2017 04:52 PM, Antoine Hoarau wrote:
>>>> Hi again,
>>>>
>>>> I'm having some issues with boost threads macros. If I compile the
>>>> following code :
>>>>
>>>> #include <alchemy/task.h>
>>>> #include <boost/thread.hpp>
>>>> int main() { return 0; }
>>>>
>>>> g++ b.cc $(xeno-config --alchemy --cflags)  $(xeno-config --alchemy
>>>> --ldflags) -lboost_system -lboost_thread
>>>>
>>>> It gives me a lot of errors regarding "barrier", a macro present in both
>>>> librairies. Copperplate's debug macro also created similar issues with
>>>> log4cpp lib.
>>>>
>>>> It compiles only if :
>>>> 1) Unsetting barrier from alchemy
>>>>
>>>> #include <alchemy/task.h>
>>>> #unset barrier
>>>> #include <boost/thread.hpp>
>>>> int main() { return 0; }
>>>>
>>>> 2) Changing the order of the includes (easy here, but hard on a big library)
>>>>
>>>> #include <boost/thread.hpp>
>>>> #include <alchemy/task.h>
>>>> int main() { return 0; }
>>>>
>>>> I guess it's not a redefinition, but an overloading :
>>>>
>>>> /usr/include/boost/thread/barrier.hpp:138:22: error: too many arguments
>>>> provided to function-like macro invocation
>>>>     explicit barrier(unsigned int count) :
>>>>                      ^
>>>> /usr/xenomai/include/boilerplate/atomic.h:83:9: note: macro 'barrier'
>>>> defined here
>>>> #define barrier()       __asm__ __volatile__("": : :"memory")
>>>>
>>>
>>> We want to define a compiler barrier that represents a strong sequence
>>> point in the instruction flow, this has nothing to do with a thread
>>> synchronization method. We only have a very few instances of such
>>> barriers, so the best fix is to rename our macro.
>>>
>>> Please pull this change:
>>> http://git.xenomai.org/xenomai-3.git/commit/?id=cd8815510e4ea53218a36518be09276bab21750d
>>>
>>> --
>>> Philippe.
>>
>> Excellent, that fixes the barrier problem.
>> There's now also clz and cls in boilerplate/compiler.h, that conflicts
>> with libtbb, and debug() in copperplate/debug.h, that conflicts with a
>> lot of libs I use.
>>
>>
>> I really don't know why the compiler gets so confused, here's an example :
>>
>> #include <alchemy/task.h>
>>
>> struct A
>> {
>> A():debug(0){}
>> bool debug;
>> };
>>
> 
> Because it ends up compiling this in the !debug case, once the
> preprocessor tokens have been substituted:
> 
> struct A
> {
> A():do { } while (0)(0){}
> bool do { } while (0);
> };
> 

struct A
{
A():do { } while (0)(0){}
bool debug;
};

is more likely.

-- 
Philippe.

Re: [Xenomai] Boost thread macro confilct

[Antoine Hoarau]

2017-09-25 19:40 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
> On 09/25/2017 07:35 PM, Philippe Gerum wrote:
>> On 09/24/2017 08:19 PM, Antoine Hoarau wrote:
>>> 2017-09-24 17:17 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>>>> On 09/24/2017 04:52 PM, Antoine Hoarau wrote:
>>>>> Hi again,
>>>>>
>>>>> I'm having some issues with boost threads macros. If I compile the
>>>>> following code :
>>>>>
>>>>> #include <alchemy/task.h>
>>>>> #include <boost/thread.hpp>
>>>>> int main() { return 0; }
>>>>>
>>>>> g++ b.cc $(xeno-config --alchemy --cflags)  $(xeno-config --alchemy
>>>>> --ldflags) -lboost_system -lboost_thread
>>>>>
>>>>> It gives me a lot of errors regarding "barrier", a macro present in both
>>>>> librairies. Copperplate's debug macro also created similar issues with
>>>>> log4cpp lib.
>>>>>
>>>>> It compiles only if :
>>>>> 1) Unsetting barrier from alchemy
>>>>>
>>>>> #include <alchemy/task.h>
>>>>> #unset barrier
>>>>> #include <boost/thread.hpp>
>>>>> int main() { return 0; }
>>>>>
>>>>> 2) Changing the order of the includes (easy here, but hard on a big library)
>>>>>
>>>>> #include <boost/thread.hpp>
>>>>> #include <alchemy/task.h>
>>>>> int main() { return 0; }
>>>>>
>>>>> I guess it's not a redefinition, but an overloading :
>>>>>
>>>>> /usr/include/boost/thread/barrier.hpp:138:22: error: too many arguments
>>>>> provided to function-like macro invocation
>>>>>     explicit barrier(unsigned int count) :
>>>>>                      ^
>>>>> /usr/xenomai/include/boilerplate/atomic.h:83:9: note: macro 'barrier'
>>>>> defined here
>>>>> #define barrier()       __asm__ __volatile__("": : :"memory")
>>>>>
>>>>
>>>> We want to define a compiler barrier that represents a strong sequence
>>>> point in the instruction flow, this has nothing to do with a thread
>>>> synchronization method. We only have a very few instances of such
>>>> barriers, so the best fix is to rename our macro.
>>>>
>>>> Please pull this change:
>>>> http://git.xenomai.org/xenomai-3.git/commit/?id=cd8815510e4ea53218a36518be09276bab21750d
>>>>
>>>> --
>>>> Philippe.
>>>
>>> Excellent, that fixes the barrier problem.
>>> There's now also clz and cls in boilerplate/compiler.h, that conflicts
>>> with libtbb, and debug() in copperplate/debug.h, that conflicts with a
>>> lot of libs I use.
>>>
>>>
>>> I really don't know why the compiler gets so confused, here's an example :
>>>
>>> #include <alchemy/task.h>
>>>
>>> struct A
>>> {
>>> A():debug(0){}
>>> bool debug;
>>> };
>>>
>>
>> Because it ends up compiling this in the !debug case, once the
>> preprocessor tokens have been substituted:
>>
>> struct A
>> {
>> A():do { } while (0)(0){}
>> bool do { } while (0);
>> };
>>
>
> struct A
> {
> A():do { } while (0)(0){}
> bool debug;
> };
>
> is more likely.
>
> --
> Philippe.

I'm obviously fine with any solution, but why not rename the internal
macros with a "namespace __xeno" , like __xeno_debug(), __xeno_clz() ?

btw the line in question for clz() is here :
https://github.com/jckarter/tbb/blob/master/include/tbb/machine/gcc_generic.h#L77
gcc_generic.h seems to be included in may libs.

-- 
Antoine Hoarau

Re: [Xenomai] Boost thread macro confilct

[Philippe Gerum]

On 09/26/2017 05:51 PM, Antoine Hoarau wrote:
> 2017-09-25 19:40 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>> On 09/25/2017 07:35 PM, Philippe Gerum wrote:
>>> On 09/24/2017 08:19 PM, Antoine Hoarau wrote:
>>>> 2017-09-24 17:17 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>>>>> On 09/24/2017 04:52 PM, Antoine Hoarau wrote:
>>>>>> Hi again,
>>>>>>
>>>>>> I'm having some issues with boost threads macros. If I compile the
>>>>>> following code :
>>>>>>
>>>>>> #include <alchemy/task.h>
>>>>>> #include <boost/thread.hpp>
>>>>>> int main() { return 0; }
>>>>>>
>>>>>> g++ b.cc $(xeno-config --alchemy --cflags)  $(xeno-config --alchemy
>>>>>> --ldflags) -lboost_system -lboost_thread
>>>>>>
>>>>>> It gives me a lot of errors regarding "barrier", a macro present in both
>>>>>> librairies. Copperplate's debug macro also created similar issues with
>>>>>> log4cpp lib.
>>>>>>
>>>>>> It compiles only if :
>>>>>> 1) Unsetting barrier from alchemy
>>>>>>
>>>>>> #include <alchemy/task.h>
>>>>>> #unset barrier
>>>>>> #include <boost/thread.hpp>
>>>>>> int main() { return 0; }
>>>>>>
>>>>>> 2) Changing the order of the includes (easy here, but hard on a big library)
>>>>>>
>>>>>> #include <boost/thread.hpp>
>>>>>> #include <alchemy/task.h>
>>>>>> int main() { return 0; }
>>>>>>
>>>>>> I guess it's not a redefinition, but an overloading :
>>>>>>
>>>>>> /usr/include/boost/thread/barrier.hpp:138:22: error: too many arguments
>>>>>> provided to function-like macro invocation
>>>>>>     explicit barrier(unsigned int count) :
>>>>>>                      ^
>>>>>> /usr/xenomai/include/boilerplate/atomic.h:83:9: note: macro 'barrier'
>>>>>> defined here
>>>>>> #define barrier()       __asm__ __volatile__("": : :"memory")
>>>>>>
>>>>>
>>>>> We want to define a compiler barrier that represents a strong sequence
>>>>> point in the instruction flow, this has nothing to do with a thread
>>>>> synchronization method. We only have a very few instances of such
>>>>> barriers, so the best fix is to rename our macro.
>>>>>
>>>>> Please pull this change:
>>>>> http://git.xenomai.org/xenomai-3.git/commit/?id=cd8815510e4ea53218a36518be09276bab21750d
>>>>>
>>>>> --
>>>>> Philippe.
>>>>
>>>> Excellent, that fixes the barrier problem.
>>>> There's now also clz and cls in boilerplate/compiler.h, that conflicts
>>>> with libtbb, and debug() in copperplate/debug.h, that conflicts with a
>>>> lot of libs I use.
>>>>
>>>>
>>>> I really don't know why the compiler gets so confused, here's an example :
>>>>
>>>> #include <alchemy/task.h>
>>>>
>>>> struct A
>>>> {
>>>> A():debug(0){}
>>>> bool debug;
>>>> };
>>>>
>>>
>>> Because it ends up compiling this in the !debug case, once the
>>> preprocessor tokens have been substituted:
>>>
>>> struct A
>>> {
>>> A():do { } while (0)(0){}
>>> bool do { } while (0);
>>> };
>>>
>>
>> struct A
>> {
>> A():do { } while (0)(0){}
>> bool debug;
>> };
>>
>> is more likely.
>>
>> --
>> Philippe.
> 
> I'm obviously fine with any solution, but why not rename the internal
> macros with a "namespace __xeno" , like __xeno_debug(), __xeno_clz() ?
> 
> btw the line in question for clz() is here :
> https://github.com/jckarter/tbb/blob/master/include/tbb/machine/gcc_generic.h#L77
> gcc_generic.h seems to be included in may libs.
> 

Probably for the same reason than TBB does not define tbb_clz() but clz().

-- 
Philippe.

Re: [Xenomai] Boost thread macro confilct

[Antoine Hoarau]

2017-09-26 18:07 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
> On 09/26/2017 05:51 PM, Antoine Hoarau wrote:
>> 2017-09-25 19:40 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>>> On 09/25/2017 07:35 PM, Philippe Gerum wrote:
>>>> On 09/24/2017 08:19 PM, Antoine Hoarau wrote:
>>>>> 2017-09-24 17:17 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>>>>>> On 09/24/2017 04:52 PM, Antoine Hoarau wrote:
>>>>>>> Hi again,
>>>>>>>
>>>>>>> I'm having some issues with boost threads macros. If I compile the
>>>>>>> following code :
>>>>>>>
>>>>>>> #include <alchemy/task.h>
>>>>>>> #include <boost/thread.hpp>
>>>>>>> int main() { return 0; }
>>>>>>>
>>>>>>> g++ b.cc $(xeno-config --alchemy --cflags)  $(xeno-config --alchemy
>>>>>>> --ldflags) -lboost_system -lboost_thread
>>>>>>>
>>>>>>> It gives me a lot of errors regarding "barrier", a macro present in both
>>>>>>> librairies. Copperplate's debug macro also created similar issues with
>>>>>>> log4cpp lib.
>>>>>>>
>>>>>>> It compiles only if :
>>>>>>> 1) Unsetting barrier from alchemy
>>>>>>>
>>>>>>> #include <alchemy/task.h>
>>>>>>> #unset barrier
>>>>>>> #include <boost/thread.hpp>
>>>>>>> int main() { return 0; }
>>>>>>>
>>>>>>> 2) Changing the order of the includes (easy here, but hard on a big library)
>>>>>>>
>>>>>>> #include <boost/thread.hpp>
>>>>>>> #include <alchemy/task.h>
>>>>>>> int main() { return 0; }
>>>>>>>
>>>>>>> I guess it's not a redefinition, but an overloading :
>>>>>>>
>>>>>>> /usr/include/boost/thread/barrier.hpp:138:22: error: too many arguments
>>>>>>> provided to function-like macro invocation
>>>>>>>     explicit barrier(unsigned int count) :
>>>>>>>                      ^
>>>>>>> /usr/xenomai/include/boilerplate/atomic.h:83:9: note: macro 'barrier'
>>>>>>> defined here
>>>>>>> #define barrier()       __asm__ __volatile__("": : :"memory")
>>>>>>>
>>>>>>
>>>>>> We want to define a compiler barrier that represents a strong sequence
>>>>>> point in the instruction flow, this has nothing to do with a thread
>>>>>> synchronization method. We only have a very few instances of such
>>>>>> barriers, so the best fix is to rename our macro.
>>>>>>
>>>>>> Please pull this change:
>>>>>> http://git.xenomai.org/xenomai-3.git/commit/?id=cd8815510e4ea53218a36518be09276bab21750d
>>>>>>
>>>>>> --
>>>>>> Philippe.
>>>>>
>>>>> Excellent, that fixes the barrier problem.
>>>>> There's now also clz and cls in boilerplate/compiler.h, that conflicts
>>>>> with libtbb, and debug() in copperplate/debug.h, that conflicts with a
>>>>> lot of libs I use.
>>>>>
>>>>>
>>>>> I really don't know why the compiler gets so confused, here's an example :
>>>>>
>>>>> #include <alchemy/task.h>
>>>>>
>>>>> struct A
>>>>> {
>>>>> A():debug(0){}
>>>>> bool debug;
>>>>> };
>>>>>
>>>>
>>>> Because it ends up compiling this in the !debug case, once the
>>>> preprocessor tokens have been substituted:
>>>>
>>>> struct A
>>>> {
>>>> A():do { } while (0)(0){}
>>>> bool do { } while (0);
>>>> };
>>>>
>>>
>>> struct A
>>> {
>>> A():do { } while (0)(0){}
>>> bool debug;
>>> };
>>>
>>> is more likely.
>>>
>>> --
>>> Philippe.
>>
>> I'm obviously fine with any solution, but why not rename the internal
>> macros with a "namespace __xeno" , like __xeno_debug(), __xeno_clz() ?
>>
>> btw the line in question for clz() is here :
>> https://github.com/jckarter/tbb/blob/master/include/tbb/machine/gcc_generic.h#L77
>> gcc_generic.h seems to be included in may libs.
>>
>
> Probably for the same reason than TBB does not define tbb_clz() but clz().
>
> --
> Philippe.

In TBB clz() is not a preprocessor macro but an inline function that
is actually defined in tbb::internal::gcc_builtins::clz()
That's why I'm suggesting the __xeno prefix.

-- 
Antoine Hoarau

Re: [Xenomai] Boost thread macro confilct

[Philippe Gerum]

On 09/26/2017 06:14 PM, Antoine Hoarau wrote:
> 2017-09-26 18:07 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>> On 09/26/2017 05:51 PM, Antoine Hoarau wrote:
>>> 2017-09-25 19:40 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>>>> On 09/25/2017 07:35 PM, Philippe Gerum wrote:
>>>>> On 09/24/2017 08:19 PM, Antoine Hoarau wrote:
>>>>>> 2017-09-24 17:17 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>>>>>>> On 09/24/2017 04:52 PM, Antoine Hoarau wrote:
>>>>>>>> Hi again,
>>>>>>>>
>>>>>>>> I'm having some issues with boost threads macros. If I compile the
>>>>>>>> following code :
>>>>>>>>
>>>>>>>> #include <alchemy/task.h>
>>>>>>>> #include <boost/thread.hpp>
>>>>>>>> int main() { return 0; }
>>>>>>>>
>>>>>>>> g++ b.cc $(xeno-config --alchemy --cflags)  $(xeno-config --alchemy
>>>>>>>> --ldflags) -lboost_system -lboost_thread
>>>>>>>>
>>>>>>>> It gives me a lot of errors regarding "barrier", a macro present in both
>>>>>>>> librairies. Copperplate's debug macro also created similar issues with
>>>>>>>> log4cpp lib.
>>>>>>>>
>>>>>>>> It compiles only if :
>>>>>>>> 1) Unsetting barrier from alchemy
>>>>>>>>
>>>>>>>> #include <alchemy/task.h>
>>>>>>>> #unset barrier
>>>>>>>> #include <boost/thread.hpp>
>>>>>>>> int main() { return 0; }
>>>>>>>>
>>>>>>>> 2) Changing the order of the includes (easy here, but hard on a big library)
>>>>>>>>
>>>>>>>> #include <boost/thread.hpp>
>>>>>>>> #include <alchemy/task.h>
>>>>>>>> int main() { return 0; }
>>>>>>>>
>>>>>>>> I guess it's not a redefinition, but an overloading :
>>>>>>>>
>>>>>>>> /usr/include/boost/thread/barrier.hpp:138:22: error: too many arguments
>>>>>>>> provided to function-like macro invocation
>>>>>>>>     explicit barrier(unsigned int count) :
>>>>>>>>                      ^
>>>>>>>> /usr/xenomai/include/boilerplate/atomic.h:83:9: note: macro 'barrier'
>>>>>>>> defined here
>>>>>>>> #define barrier()       __asm__ __volatile__("": : :"memory")
>>>>>>>>
>>>>>>>
>>>>>>> We want to define a compiler barrier that represents a strong sequence
>>>>>>> point in the instruction flow, this has nothing to do with a thread
>>>>>>> synchronization method. We only have a very few instances of such
>>>>>>> barriers, so the best fix is to rename our macro.
>>>>>>>
>>>>>>> Please pull this change:
>>>>>>> http://git.xenomai.org/xenomai-3.git/commit/?id=cd8815510e4ea53218a36518be09276bab21750d
>>>>>>>
>>>>>>> --
>>>>>>> Philippe.
>>>>>>
>>>>>> Excellent, that fixes the barrier problem.
>>>>>> There's now also clz and cls in boilerplate/compiler.h, that conflicts
>>>>>> with libtbb, and debug() in copperplate/debug.h, that conflicts with a
>>>>>> lot of libs I use.
>>>>>>
>>>>>>
>>>>>> I really don't know why the compiler gets so confused, here's an example :
>>>>>>
>>>>>> #include <alchemy/task.h>
>>>>>>
>>>>>> struct A
>>>>>> {
>>>>>> A():debug(0){}
>>>>>> bool debug;
>>>>>> };
>>>>>>
>>>>>
>>>>> Because it ends up compiling this in the !debug case, once the
>>>>> preprocessor tokens have been substituted:
>>>>>
>>>>> struct A
>>>>> {
>>>>> A():do { } while (0)(0){}
>>>>> bool do { } while (0);
>>>>> };
>>>>>
>>>>
>>>> struct A
>>>> {
>>>> A():do { } while (0)(0){}
>>>> bool debug;
>>>> };
>>>>
>>>> is more likely.
>>>>
>>>> --
>>>> Philippe.
>>>
>>> I'm obviously fine with any solution, but why not rename the internal
>>> macros with a "namespace __xeno" , like __xeno_debug(), __xeno_clz() ?
>>>
>>> btw the line in question for clz() is here :
>>> https://github.com/jckarter/tbb/blob/master/include/tbb/machine/gcc_generic.h#L77
>>> gcc_generic.h seems to be included in may libs.
>>>
>>
>> Probably for the same reason than TBB does not define tbb_clz() but clz().
>>
>> --
>> Philippe.
> 
> In TBB clz() is not a preprocessor macro but an inline function that
> is actually defined in tbb::internal::gcc_builtins::clz()
> That's why I'm suggesting the __xeno prefix.
> 

Thanks, I can still read C++ a bit.

But no, I don't want to add xeno* in front of every symbol, not only
because I find this particular prefix ugly, but more to the point,
because the symbols you are referring to are part from the internal
interface, and no C++ client code is supposed to ever use Xenomai's
definition of it. Hence the patch.

Should we still prefix it for C code then? Maybe, but so far no conflict
was ever reported, so I'm going to wait and see for now.

-- 
Philippe.

Re: [Xenomai] Boost thread macro confilct

[Philippe Gerum]

On 09/26/2017 06:37 PM, Philippe Gerum wrote:
> On 09/26/2017 06:14 PM, Antoine Hoarau wrote:
>> 2017-09-26 18:07 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>>> On 09/26/2017 05:51 PM, Antoine Hoarau wrote:
>>>> 2017-09-25 19:40 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>>>>> On 09/25/2017 07:35 PM, Philippe Gerum wrote:
>>>>>> On 09/24/2017 08:19 PM, Antoine Hoarau wrote:
>>>>>>> 2017-09-24 17:17 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>>>>>>>> On 09/24/2017 04:52 PM, Antoine Hoarau wrote:
>>>>>>>>> Hi again,
>>>>>>>>>
>>>>>>>>> I'm having some issues with boost threads macros. If I compile the
>>>>>>>>> following code :
>>>>>>>>>
>>>>>>>>> #include <alchemy/task.h>
>>>>>>>>> #include <boost/thread.hpp>
>>>>>>>>> int main() { return 0; }
>>>>>>>>>
>>>>>>>>> g++ b.cc $(xeno-config --alchemy --cflags)  $(xeno-config --alchemy
>>>>>>>>> --ldflags) -lboost_system -lboost_thread
>>>>>>>>>
>>>>>>>>> It gives me a lot of errors regarding "barrier", a macro present in both
>>>>>>>>> librairies. Copperplate's debug macro also created similar issues with
>>>>>>>>> log4cpp lib.
>>>>>>>>>
>>>>>>>>> It compiles only if :
>>>>>>>>> 1) Unsetting barrier from alchemy
>>>>>>>>>
>>>>>>>>> #include <alchemy/task.h>
>>>>>>>>> #unset barrier
>>>>>>>>> #include <boost/thread.hpp>
>>>>>>>>> int main() { return 0; }
>>>>>>>>>
>>>>>>>>> 2) Changing the order of the includes (easy here, but hard on a big library)
>>>>>>>>>
>>>>>>>>> #include <boost/thread.hpp>
>>>>>>>>> #include <alchemy/task.h>
>>>>>>>>> int main() { return 0; }
>>>>>>>>>
>>>>>>>>> I guess it's not a redefinition, but an overloading :
>>>>>>>>>
>>>>>>>>> /usr/include/boost/thread/barrier.hpp:138:22: error: too many arguments
>>>>>>>>> provided to function-like macro invocation
>>>>>>>>>     explicit barrier(unsigned int count) :
>>>>>>>>>                      ^
>>>>>>>>> /usr/xenomai/include/boilerplate/atomic.h:83:9: note: macro 'barrier'
>>>>>>>>> defined here
>>>>>>>>> #define barrier()       __asm__ __volatile__("": : :"memory")
>>>>>>>>>
>>>>>>>>
>>>>>>>> We want to define a compiler barrier that represents a strong sequence
>>>>>>>> point in the instruction flow, this has nothing to do with a thread
>>>>>>>> synchronization method. We only have a very few instances of such
>>>>>>>> barriers, so the best fix is to rename our macro.
>>>>>>>>
>>>>>>>> Please pull this change:
>>>>>>>> http://git.xenomai.org/xenomai-3.git/commit/?id=cd8815510e4ea53218a36518be09276bab21750d
>>>>>>>>
>>>>>>>> --
>>>>>>>> Philippe.
>>>>>>>
>>>>>>> Excellent, that fixes the barrier problem.
>>>>>>> There's now also clz and cls in boilerplate/compiler.h, that conflicts
>>>>>>> with libtbb, and debug() in copperplate/debug.h, that conflicts with a
>>>>>>> lot of libs I use.
>>>>>>>
>>>>>>>
>>>>>>> I really don't know why the compiler gets so confused, here's an example :
>>>>>>>
>>>>>>> #include <alchemy/task.h>
>>>>>>>
>>>>>>> struct A
>>>>>>> {
>>>>>>> A():debug(0){}
>>>>>>> bool debug;
>>>>>>> };
>>>>>>>
>>>>>>
>>>>>> Because it ends up compiling this in the !debug case, once the
>>>>>> preprocessor tokens have been substituted:
>>>>>>
>>>>>> struct A
>>>>>> {
>>>>>> A():do { } while (0)(0){}
>>>>>> bool do { } while (0);
>>>>>> };
>>>>>>
>>>>>
>>>>> struct A
>>>>> {
>>>>> A():do { } while (0)(0){}
>>>>> bool debug;
>>>>> };
>>>>>
>>>>> is more likely.
>>>>>
>>>>> --
>>>>> Philippe.
>>>>
>>>> I'm obviously fine with any solution, but why not rename the internal
>>>> macros with a "namespace __xeno" , like __xeno_debug(), __xeno_clz() ?
>>>>
>>>> btw the line in question for clz() is here :
>>>> https://github.com/jckarter/tbb/blob/master/include/tbb/machine/gcc_generic.h#L77
>>>> gcc_generic.h seems to be included in may libs.
>>>>
>>>
>>> Probably for the same reason than TBB does not define tbb_clz() but clz().
>>>
>>> --
>>> Philippe.
>>
>> In TBB clz() is not a preprocessor macro but an inline function that
>> is actually defined in tbb::internal::gcc_builtins::clz()
>> That's why I'm suggesting the __xeno prefix.
>>
> 
> Thanks, I can still read C++ a bit.
> 
> But no, I don't want to add xeno* in front of every symbol, not only
> because I find this particular prefix ugly, but more to the point,
> because the symbols you are referring to are part from the internal
> interface, and no C++ client code is supposed to ever use Xenomai's
> definition of it. Hence the patch.
> 
> Should we still prefix it for C code then? Maybe, but so far no conflict
> was ever reported, so I'm going to wait and see for now.
> 

Actually, the best general fix for these issues would be to group
internal stuff into private headers, which should not be included by
public ones.

-- 
Philippe.

Re: [Xenomai] Boost thread macro confilct

[Antoine Hoarau]

2017-09-26 19:34 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
> On 09/26/2017 06:37 PM, Philippe Gerum wrote:
>> On 09/26/2017 06:14 PM, Antoine Hoarau wrote:
>>> 2017-09-26 18:07 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>>>> On 09/26/2017 05:51 PM, Antoine Hoarau wrote:
>>>>> 2017-09-25 19:40 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>>>>>> On 09/25/2017 07:35 PM, Philippe Gerum wrote:
>>>>>>> On 09/24/2017 08:19 PM, Antoine Hoarau wrote:
>>>>>>>> 2017-09-24 17:17 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>>>>>>>>> On 09/24/2017 04:52 PM, Antoine Hoarau wrote:
>>>>>>>>>> Hi again,
>>>>>>>>>>
>>>>>>>>>> I'm having some issues with boost threads macros. If I compile the
>>>>>>>>>> following code :
>>>>>>>>>>
>>>>>>>>>> #include <alchemy/task.h>
>>>>>>>>>> #include <boost/thread.hpp>
>>>>>>>>>> int main() { return 0; }
>>>>>>>>>>
>>>>>>>>>> g++ b.cc $(xeno-config --alchemy --cflags)  $(xeno-config --alchemy
>>>>>>>>>> --ldflags) -lboost_system -lboost_thread
>>>>>>>>>>
>>>>>>>>>> It gives me a lot of errors regarding "barrier", a macro present in both
>>>>>>>>>> librairies. Copperplate's debug macro also created similar issues with
>>>>>>>>>> log4cpp lib.
>>>>>>>>>>
>>>>>>>>>> It compiles only if :
>>>>>>>>>> 1) Unsetting barrier from alchemy
>>>>>>>>>>
>>>>>>>>>> #include <alchemy/task.h>
>>>>>>>>>> #unset barrier
>>>>>>>>>> #include <boost/thread.hpp>
>>>>>>>>>> int main() { return 0; }
>>>>>>>>>>
>>>>>>>>>> 2) Changing the order of the includes (easy here, but hard on a big library)
>>>>>>>>>>
>>>>>>>>>> #include <boost/thread.hpp>
>>>>>>>>>> #include <alchemy/task.h>
>>>>>>>>>> int main() { return 0; }
>>>>>>>>>>
>>>>>>>>>> I guess it's not a redefinition, but an overloading :
>>>>>>>>>>
>>>>>>>>>> /usr/include/boost/thread/barrier.hpp:138:22: error: too many arguments
>>>>>>>>>> provided to function-like macro invocation
>>>>>>>>>>     explicit barrier(unsigned int count) :
>>>>>>>>>>                      ^
>>>>>>>>>> /usr/xenomai/include/boilerplate/atomic.h:83:9: note: macro 'barrier'
>>>>>>>>>> defined here
>>>>>>>>>> #define barrier()       __asm__ __volatile__("": : :"memory")
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We want to define a compiler barrier that represents a strong sequence
>>>>>>>>> point in the instruction flow, this has nothing to do with a thread
>>>>>>>>> synchronization method. We only have a very few instances of such
>>>>>>>>> barriers, so the best fix is to rename our macro.
>>>>>>>>>
>>>>>>>>> Please pull this change:
>>>>>>>>> http://git.xenomai.org/xenomai-3.git/commit/?id=cd8815510e4ea53218a36518be09276bab21750d
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Philippe.
>>>>>>>>
>>>>>>>> Excellent, that fixes the barrier problem.
>>>>>>>> There's now also clz and cls in boilerplate/compiler.h, that conflicts
>>>>>>>> with libtbb, and debug() in copperplate/debug.h, that conflicts with a
>>>>>>>> lot of libs I use.
>>>>>>>>
>>>>>>>>
>>>>>>>> I really don't know why the compiler gets so confused, here's an example :
>>>>>>>>
>>>>>>>> #include <alchemy/task.h>
>>>>>>>>
>>>>>>>> struct A
>>>>>>>> {
>>>>>>>> A():debug(0){}
>>>>>>>> bool debug;
>>>>>>>> };
>>>>>>>>
>>>>>>>
>>>>>>> Because it ends up compiling this in the !debug case, once the
>>>>>>> preprocessor tokens have been substituted:
>>>>>>>
>>>>>>> struct A
>>>>>>> {
>>>>>>> A():do { } while (0)(0){}
>>>>>>> bool do { } while (0);
>>>>>>> };
>>>>>>>
>>>>>>
>>>>>> struct A
>>>>>> {
>>>>>> A():do { } while (0)(0){}
>>>>>> bool debug;
>>>>>> };
>>>>>>
>>>>>> is more likely.
>>>>>>
>>>>>> --
>>>>>> Philippe.
>>>>>
>>>>> I'm obviously fine with any solution, but why not rename the internal
>>>>> macros with a "namespace __xeno" , like __xeno_debug(), __xeno_clz() ?
>>>>>
>>>>> btw the line in question for clz() is here :
>>>>> https://github.com/jckarter/tbb/blob/master/include/tbb/machine/gcc_generic.h#L77
>>>>> gcc_generic.h seems to be included in may libs.
>>>>>
>>>>
>>>> Probably for the same reason than TBB does not define tbb_clz() but clz().
>>>>
>>>> --
>>>> Philippe.
>>>
>>> In TBB clz() is not a preprocessor macro but an inline function that
>>> is actually defined in tbb::internal::gcc_builtins::clz()
>>> That's why I'm suggesting the __xeno prefix.
>>>
>>
>> Thanks, I can still read C++ a bit.
>>
>> But no, I don't want to add xeno* in front of every symbol, not only
>> because I find this particular prefix ugly, but more to the point,
>> because the symbols you are referring to are part from the internal
>> interface, and no C++ client code is supposed to ever use Xenomai's
>> definition of it. Hence the patch.
>>
>> Should we still prefix it for C code then? Maybe, but so far no conflict
>> was ever reported, so I'm going to wait and see for now.
>>

The context is orocos + gazebo (that apparently uses tbb). Limited
audience indeed.

>
> Actually, the best general fix for these issues would be to group
> internal stuff into private headers, which should not be included by
> public ones.
>

That'd be a good solution.
Nevertheless I see clz/ctz are only used in heapobj-pshared.c one time
each, so what about defining the macros in this file ?
For now I'm using this patch, that just renames clz and ctz to __clz and __ctz :

diff --git a/include/boilerplate/compiler.h b/include/boilerplate/compiler.h
index 0509e33..bcef7d4 100644
--- a/include/boilerplate/compiler.h
+++ b/include/boilerplate/compiler.h
@@ -64,7 +64,7 @@ extern "C" {

 void __invalid_operand_size(void);

-#define ctz(__v) \
+#define __ctz(__v) \
  ({ \
  int __ret; \
  if (!__v) \
@@ -83,7 +83,7 @@ void __invalid_operand_size(void);
  __ret; \
  })

-#define clz(__v) \
+#define __clz(__v) \
  ({ \
  int __ret; \
  if (!__v) \
diff --git a/lib/copperplate/heapobj-pshared.c
b/lib/copperplate/heapobj-pshared.c
index 578f442..03d6eaa 100644
--- a/lib/copperplate/heapobj-pshared.c
+++ b/lib/copperplate/heapobj-pshared.c
@@ -291,7 +291,7 @@ static int reserve_page_range(uint32_t *bitmap,
int bitwords, int nrpages)
  v = bitmap[n];
  b = 0;
  while (v != -1U) {
- r = ctz(v);
+ r = __ctz(v);
  if (r) {
  seq += r;
  if (seq >= nrpages) {
@@ -432,7 +432,7 @@ static void *alloc_block(struct shared_heap *heap,
size_t size)
  */
  if (size <= HOBJ_PAGE_SIZE * 2) {
  /* Find log2(size). */
- log2size = sizeof(size) * 8 - 1 - clz(size);
+ log2size = sizeof(size) * 8 - 1 - __clz(size);
  if (size & (size - 1))
  log2size++;
  /* That is the actual block size we need. */



> --
> Philippe.


-- 
Antoine Hoarau

Re: [Xenomai] Boost thread macro confilct

[Philippe Gerum]

On 09/28/2017 03:19 PM, Antoine Hoarau wrote:
> 2017-09-26 19:34 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>> On 09/26/2017 06:37 PM, Philippe Gerum wrote:
>>> On 09/26/2017 06:14 PM, Antoine Hoarau wrote:
>>>> 2017-09-26 18:07 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>>>>> On 09/26/2017 05:51 PM, Antoine Hoarau wrote:
>>>>>> 2017-09-25 19:40 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>>>>>>> On 09/25/2017 07:35 PM, Philippe Gerum wrote:
>>>>>>>> On 09/24/2017 08:19 PM, Antoine Hoarau wrote:
>>>>>>>>> 2017-09-24 17:17 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>>>>>>>>>> On 09/24/2017 04:52 PM, Antoine Hoarau wrote:
>>>>>>>>>>> Hi again,
>>>>>>>>>>>
>>>>>>>>>>> I'm having some issues with boost threads macros. If I compile the
>>>>>>>>>>> following code :
>>>>>>>>>>>
>>>>>>>>>>> #include <alchemy/task.h>
>>>>>>>>>>> #include <boost/thread.hpp>
>>>>>>>>>>> int main() { return 0; }
>>>>>>>>>>>
>>>>>>>>>>> g++ b.cc $(xeno-config --alchemy --cflags)  $(xeno-config --alchemy
>>>>>>>>>>> --ldflags) -lboost_system -lboost_thread
>>>>>>>>>>>
>>>>>>>>>>> It gives me a lot of errors regarding "barrier", a macro present in both
>>>>>>>>>>> librairies. Copperplate's debug macro also created similar issues with
>>>>>>>>>>> log4cpp lib.
>>>>>>>>>>>
>>>>>>>>>>> It compiles only if :
>>>>>>>>>>> 1) Unsetting barrier from alchemy
>>>>>>>>>>>
>>>>>>>>>>> #include <alchemy/task.h>
>>>>>>>>>>> #unset barrier
>>>>>>>>>>> #include <boost/thread.hpp>
>>>>>>>>>>> int main() { return 0; }
>>>>>>>>>>>
>>>>>>>>>>> 2) Changing the order of the includes (easy here, but hard on a big library)
>>>>>>>>>>>
>>>>>>>>>>> #include <boost/thread.hpp>
>>>>>>>>>>> #include <alchemy/task.h>
>>>>>>>>>>> int main() { return 0; }
>>>>>>>>>>>
>>>>>>>>>>> I guess it's not a redefinition, but an overloading :
>>>>>>>>>>>
>>>>>>>>>>> /usr/include/boost/thread/barrier.hpp:138:22: error: too many arguments
>>>>>>>>>>> provided to function-like macro invocation
>>>>>>>>>>>     explicit barrier(unsigned int count) :
>>>>>>>>>>>                      ^
>>>>>>>>>>> /usr/xenomai/include/boilerplate/atomic.h:83:9: note: macro 'barrier'
>>>>>>>>>>> defined here
>>>>>>>>>>> #define barrier()       __asm__ __volatile__("": : :"memory")
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> We want to define a compiler barrier that represents a strong sequence
>>>>>>>>>> point in the instruction flow, this has nothing to do with a thread
>>>>>>>>>> synchronization method. We only have a very few instances of such
>>>>>>>>>> barriers, so the best fix is to rename our macro.
>>>>>>>>>>
>>>>>>>>>> Please pull this change:
>>>>>>>>>> http://git.xenomai.org/xenomai-3.git/commit/?id=cd8815510e4ea53218a36518be09276bab21750d
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Philippe.
>>>>>>>>>
>>>>>>>>> Excellent, that fixes the barrier problem.
>>>>>>>>> There's now also clz and cls in boilerplate/compiler.h, that conflicts
>>>>>>>>> with libtbb, and debug() in copperplate/debug.h, that conflicts with a
>>>>>>>>> lot of libs I use.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I really don't know why the compiler gets so confused, here's an example :
>>>>>>>>>
>>>>>>>>> #include <alchemy/task.h>
>>>>>>>>>
>>>>>>>>> struct A
>>>>>>>>> {
>>>>>>>>> A():debug(0){}
>>>>>>>>> bool debug;
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>
>>>>>>>> Because it ends up compiling this in the !debug case, once the
>>>>>>>> preprocessor tokens have been substituted:
>>>>>>>>
>>>>>>>> struct A
>>>>>>>> {
>>>>>>>> A():do { } while (0)(0){}
>>>>>>>> bool do { } while (0);
>>>>>>>> };
>>>>>>>>
>>>>>>>
>>>>>>> struct A
>>>>>>> {
>>>>>>> A():do { } while (0)(0){}
>>>>>>> bool debug;
>>>>>>> };
>>>>>>>
>>>>>>> is more likely.
>>>>>>>
>>>>>>> --
>>>>>>> Philippe.
>>>>>>
>>>>>> I'm obviously fine with any solution, but why not rename the internal
>>>>>> macros with a "namespace __xeno" , like __xeno_debug(), __xeno_clz() ?
>>>>>>
>>>>>> btw the line in question for clz() is here :
>>>>>> https://github.com/jckarter/tbb/blob/master/include/tbb/machine/gcc_generic.h#L77
>>>>>> gcc_generic.h seems to be included in may libs.
>>>>>>
>>>>>
>>>>> Probably for the same reason than TBB does not define tbb_clz() but clz().
>>>>>
>>>>> --
>>>>> Philippe.
>>>>
>>>> In TBB clz() is not a preprocessor macro but an inline function that
>>>> is actually defined in tbb::internal::gcc_builtins::clz()
>>>> That's why I'm suggesting the __xeno prefix.
>>>>
>>>
>>> Thanks, I can still read C++ a bit.
>>>
>>> But no, I don't want to add xeno* in front of every symbol, not only
>>> because I find this particular prefix ugly, but more to the point,
>>> because the symbols you are referring to are part from the internal
>>> interface, and no C++ client code is supposed to ever use Xenomai's
>>> definition of it. Hence the patch.
>>>
>>> Should we still prefix it for C code then? Maybe, but so far no conflict
>>> was ever reported, so I'm going to wait and see for now.
>>>
> 
> The context is orocos + gazebo (that apparently uses tbb). Limited
> audience indeed.
> 
>>
>> Actually, the best general fix for these issues would be to group
>> internal stuff into private headers, which should not be included by
>> public ones.
>>
> 
> That'd be a good solution.
> Nevertheless I see clz/ctz are only used in heapobj-pshared.c one time
> each, so what about defining the macros in this file ?
> For now I'm using this patch, that just renames clz and ctz to __clz and __ctz :
> 
> diff --git a/include/boilerplate/compiler.h b/include/boilerplate/compiler.h
> index 0509e33..bcef7d4 100644
> --- a/include/boilerplate/compiler.h
> +++ b/include/boilerplate/compiler.h
> @@ -64,7 +64,7 @@ extern "C" {
> 
>  void __invalid_operand_size(void);
> 
> -#define ctz(__v) \
> +#define __ctz(__v) \
>   ({ \
>   int __ret; \
>   if (!__v) \
> @@ -83,7 +83,7 @@ void __invalid_operand_size(void);
>   __ret; \
>   })
> 
> -#define clz(__v) \
> +#define __clz(__v) \
>   ({ \
>   int __ret; \
>   if (!__v) \
> diff --git a/lib/copperplate/heapobj-pshared.c
> b/lib/copperplate/heapobj-pshared.c
> index 578f442..03d6eaa 100644
> --- a/lib/copperplate/heapobj-pshared.c
> +++ b/lib/copperplate/heapobj-pshared.c
> @@ -291,7 +291,7 @@ static int reserve_page_range(uint32_t *bitmap,
> int bitwords, int nrpages)
>   v = bitmap[n];
>   b = 0;
>   while (v != -1U) {
> - r = ctz(v);
> + r = __ctz(v);
>   if (r) {
>   seq += r;
>   if (seq >= nrpages) {
> @@ -432,7 +432,7 @@ static void *alloc_block(struct shared_heap *heap,
> size_t size)
>   */
>   if (size <= HOBJ_PAGE_SIZE * 2) {
>   /* Find log2(size). */
> - log2size = sizeof(size) * 8 - 1 - clz(size);
> + log2size = sizeof(size) * 8 - 1 - __clz(size);
>   if (size & (size - 1))
>   log2size++;
>   /* That is the actual block size we need. */
> 
> 

Ok, I'll pick that one to ease the burden until we manage to move the
internal code out of the public headers entirely. Could you provide a
patch conforming to the git format I can merge (with autorship, subject,
etc., as obtained by git format-patch or git log?).

TIA.

-- 
Philippe.

Re: [Xenomai] Boost thread macro confilct

[Antoine Hoarau]

2017-09-28 15:31 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
> On 09/28/2017 03:19 PM, Antoine Hoarau wrote:
>> 2017-09-26 19:34 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>>> On 09/26/2017 06:37 PM, Philippe Gerum wrote:
>>>> On 09/26/2017 06:14 PM, Antoine Hoarau wrote:
>>>>> 2017-09-26 18:07 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>>>>>> On 09/26/2017 05:51 PM, Antoine Hoarau wrote:
>>>>>>> 2017-09-25 19:40 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>>>>>>>> On 09/25/2017 07:35 PM, Philippe Gerum wrote:
>>>>>>>>> On 09/24/2017 08:19 PM, Antoine Hoarau wrote:
>>>>>>>>>> 2017-09-24 17:17 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>>>>>>>>>>> On 09/24/2017 04:52 PM, Antoine Hoarau wrote:
>>>>>>>>>>>> Hi again,
>>>>>>>>>>>>
>>>>>>>>>>>> I'm having some issues with boost threads macros. If I compile the
>>>>>>>>>>>> following code :
>>>>>>>>>>>>
>>>>>>>>>>>> #include <alchemy/task.h>
>>>>>>>>>>>> #include <boost/thread.hpp>
>>>>>>>>>>>> int main() { return 0; }
>>>>>>>>>>>>
>>>>>>>>>>>> g++ b.cc $(xeno-config --alchemy --cflags)  $(xeno-config --alchemy
>>>>>>>>>>>> --ldflags) -lboost_system -lboost_thread
>>>>>>>>>>>>
>>>>>>>>>>>> It gives me a lot of errors regarding "barrier", a macro present in both
>>>>>>>>>>>> librairies. Copperplate's debug macro also created similar issues with
>>>>>>>>>>>> log4cpp lib.
>>>>>>>>>>>>
>>>>>>>>>>>> It compiles only if :
>>>>>>>>>>>> 1) Unsetting barrier from alchemy
>>>>>>>>>>>>
>>>>>>>>>>>> #include <alchemy/task.h>
>>>>>>>>>>>> #unset barrier
>>>>>>>>>>>> #include <boost/thread.hpp>
>>>>>>>>>>>> int main() { return 0; }
>>>>>>>>>>>>
>>>>>>>>>>>> 2) Changing the order of the includes (easy here, but hard on a big library)
>>>>>>>>>>>>
>>>>>>>>>>>> #include <boost/thread.hpp>
>>>>>>>>>>>> #include <alchemy/task.h>
>>>>>>>>>>>> int main() { return 0; }
>>>>>>>>>>>>
>>>>>>>>>>>> I guess it's not a redefinition, but an overloading :
>>>>>>>>>>>>
>>>>>>>>>>>> /usr/include/boost/thread/barrier.hpp:138:22: error: too many arguments
>>>>>>>>>>>> provided to function-like macro invocation
>>>>>>>>>>>>     explicit barrier(unsigned int count) :
>>>>>>>>>>>>                      ^
>>>>>>>>>>>> /usr/xenomai/include/boilerplate/atomic.h:83:9: note: macro 'barrier'
>>>>>>>>>>>> defined here
>>>>>>>>>>>> #define barrier()       __asm__ __volatile__("": : :"memory")
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> We want to define a compiler barrier that represents a strong sequence
>>>>>>>>>>> point in the instruction flow, this has nothing to do with a thread
>>>>>>>>>>> synchronization method. We only have a very few instances of such
>>>>>>>>>>> barriers, so the best fix is to rename our macro.
>>>>>>>>>>>
>>>>>>>>>>> Please pull this change:
>>>>>>>>>>> http://git.xenomai.org/xenomai-3.git/commit/?id=cd8815510e4ea53218a36518be09276bab21750d
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Philippe.
>>>>>>>>>>
>>>>>>>>>> Excellent, that fixes the barrier problem.
>>>>>>>>>> There's now also clz and cls in boilerplate/compiler.h, that conflicts
>>>>>>>>>> with libtbb, and debug() in copperplate/debug.h, that conflicts with a
>>>>>>>>>> lot of libs I use.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I really don't know why the compiler gets so confused, here's an example :
>>>>>>>>>>
>>>>>>>>>> #include <alchemy/task.h>
>>>>>>>>>>
>>>>>>>>>> struct A
>>>>>>>>>> {
>>>>>>>>>> A():debug(0){}
>>>>>>>>>> bool debug;
>>>>>>>>>> };
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Because it ends up compiling this in the !debug case, once the
>>>>>>>>> preprocessor tokens have been substituted:
>>>>>>>>>
>>>>>>>>> struct A
>>>>>>>>> {
>>>>>>>>> A():do { } while (0)(0){}
>>>>>>>>> bool do { } while (0);
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>
>>>>>>>> struct A
>>>>>>>> {
>>>>>>>> A():do { } while (0)(0){}
>>>>>>>> bool debug;
>>>>>>>> };
>>>>>>>>
>>>>>>>> is more likely.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Philippe.
>>>>>>>
>>>>>>> I'm obviously fine with any solution, but why not rename the internal
>>>>>>> macros with a "namespace __xeno" , like __xeno_debug(), __xeno_clz() ?
>>>>>>>
>>>>>>> btw the line in question for clz() is here :
>>>>>>> https://github.com/jckarter/tbb/blob/master/include/tbb/machine/gcc_generic.h#L77
>>>>>>> gcc_generic.h seems to be included in may libs.
>>>>>>>
>>>>>>
>>>>>> Probably for the same reason than TBB does not define tbb_clz() but clz().
>>>>>>
>>>>>> --
>>>>>> Philippe.
>>>>>
>>>>> In TBB clz() is not a preprocessor macro but an inline function that
>>>>> is actually defined in tbb::internal::gcc_builtins::clz()
>>>>> That's why I'm suggesting the __xeno prefix.
>>>>>
>>>>
>>>> Thanks, I can still read C++ a bit.
>>>>
>>>> But no, I don't want to add xeno* in front of every symbol, not only
>>>> because I find this particular prefix ugly, but more to the point,
>>>> because the symbols you are referring to are part from the internal
>>>> interface, and no C++ client code is supposed to ever use Xenomai's
>>>> definition of it. Hence the patch.
>>>>
>>>> Should we still prefix it for C code then? Maybe, but so far no conflict
>>>> was ever reported, so I'm going to wait and see for now.
>>>>
>>
>> The context is orocos + gazebo (that apparently uses tbb). Limited
>> audience indeed.
>>
>>>
>>> Actually, the best general fix for these issues would be to group
>>> internal stuff into private headers, which should not be included by
>>> public ones.
>>>
>>
>> That'd be a good solution.
>> Nevertheless I see clz/ctz are only used in heapobj-pshared.c one time
>> each, so what about defining the macros in this file ?
>> For now I'm using this patch, that just renames clz and ctz to __clz and __ctz :
>>
>> diff --git a/include/boilerplate/compiler.h b/include/boilerplate/compiler.h
>> index 0509e33..bcef7d4 100644
>> --- a/include/boilerplate/compiler.h
>> +++ b/include/boilerplate/compiler.h
>> @@ -64,7 +64,7 @@ extern "C" {
>>
>>  void __invalid_operand_size(void);
>>
>> -#define ctz(__v) \
>> +#define __ctz(__v) \
>>   ({ \
>>   int __ret; \
>>   if (!__v) \
>> @@ -83,7 +83,7 @@ void __invalid_operand_size(void);
>>   __ret; \
>>   })
>>
>> -#define clz(__v) \
>> +#define __clz(__v) \
>>   ({ \
>>   int __ret; \
>>   if (!__v) \
>> diff --git a/lib/copperplate/heapobj-pshared.c
>> b/lib/copperplate/heapobj-pshared.c
>> index 578f442..03d6eaa 100644
>> --- a/lib/copperplate/heapobj-pshared.c
>> +++ b/lib/copperplate/heapobj-pshared.c
>> @@ -291,7 +291,7 @@ static int reserve_page_range(uint32_t *bitmap,
>> int bitwords, int nrpages)
>>   v = bitmap[n];
>>   b = 0;
>>   while (v != -1U) {
>> - r = ctz(v);
>> + r = __ctz(v);
>>   if (r) {
>>   seq += r;
>>   if (seq >= nrpages) {
>> @@ -432,7 +432,7 @@ static void *alloc_block(struct shared_heap *heap,
>> size_t size)
>>   */
>>   if (size <= HOBJ_PAGE_SIZE * 2) {
>>   /* Find log2(size). */
>> - log2size = sizeof(size) * 8 - 1 - clz(size);
>> + log2size = sizeof(size) * 8 - 1 - __clz(size);
>>   if (size & (size - 1))
>>   log2size++;
>>   /* That is the actual block size we need. */
>>
>>
>
> Ok, I'll pick that one to ease the burden until we manage to move the
> internal code out of the public headers entirely. Could you provide a
> patch conforming to the git format I can merge (with autorship, subject,
> etc., as obtained by git format-patch or git log?).
>
> TIA.
>
> --
> Philippe.

Don't know if I can attach files on this mailing list, so i'm posting
it here also:

From dc99eb1872e02469c2d516b56b6562c78dbd2df0 Mon Sep 17 00:00:00 2001
From: Antoine Hoarau <hoarau.robotics@gmail.com>
Date: Thu, 28 Sep 2017 16:19:09 +0200
Subject: [PATCH] rename clz()/ctz() -> __clz()/__ctz()

Prevents conflicts with libtbb that defines clz as an inline function and gets
replaced by those macros. Temporary fix waiting to move this code in
private headers.
---
 include/boilerplate/compiler.h    | 4 ++--
 lib/copperplate/heapobj-pshared.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/boilerplate/compiler.h b/include/boilerplate/compiler.h
index 0509e33..bcef7d4 100644
--- a/include/boilerplate/compiler.h
+++ b/include/boilerplate/compiler.h
@@ -64,7 +64,7 @@ extern "C" {

 void __invalid_operand_size(void);

-#define ctz(__v) \
+#define __ctz(__v) \
  ({ \
  int __ret; \
  if (!__v) \
@@ -83,7 +83,7 @@ void __invalid_operand_size(void);
  __ret; \
  })

-#define clz(__v) \
+#define __clz(__v) \
  ({ \
  int __ret; \
  if (!__v) \
diff --git a/lib/copperplate/heapobj-pshared.c
b/lib/copperplate/heapobj-pshared.c
index 578f442..03d6eaa 100644
--- a/lib/copperplate/heapobj-pshared.c
+++ b/lib/copperplate/heapobj-pshared.c
@@ -291,7 +291,7 @@ static int reserve_page_range(uint32_t *bitmap,
int bitwords, int nrpages)
  v = bitmap[n];
  b = 0;
  while (v != -1U) {
- r = ctz(v);
+ r = __ctz(v);
  if (r) {
  seq += r;
  if (seq >= nrpages) {
@@ -432,7 +432,7 @@ static void *alloc_block(struct shared_heap *heap,
size_t size)
  */
  if (size <= HOBJ_PAGE_SIZE * 2) {
  /* Find log2(size). */
- log2size = sizeof(size) * 8 - 1 - clz(size);
+ log2size = sizeof(size) * 8 - 1 - __clz(size);
  if (size & (size - 1))
  log2size++;
  /* That is the actual block size we need. */
-- 
2.7.4


Thank you again for your help
-- 
Antoine Hoarau
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-rename-clz-ctz-__clz-__ctz.patch
Type: text/x-patch
Size: 1849 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20170928/76947174/attachment.bin>

Re: [Xenomai] Boost thread macro confilct

[Philippe Gerum]

On 09/28/2017 04:36 PM, Antoine Hoarau wrote:
> 2017-09-28 15:31 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>> On 09/28/2017 03:19 PM, Antoine Hoarau wrote:
>>> 2017-09-26 19:34 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>>>> On 09/26/2017 06:37 PM, Philippe Gerum wrote:
>>>>> On 09/26/2017 06:14 PM, Antoine Hoarau wrote:
>>>>>> 2017-09-26 18:07 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>>>>>>> On 09/26/2017 05:51 PM, Antoine Hoarau wrote:
>>>>>>>> 2017-09-25 19:40 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>>>>>>>>> On 09/25/2017 07:35 PM, Philippe Gerum wrote:
>>>>>>>>>> On 09/24/2017 08:19 PM, Antoine Hoarau wrote:
>>>>>>>>>>> 2017-09-24 17:17 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>>>>>>>>>>>> On 09/24/2017 04:52 PM, Antoine Hoarau wrote:
>>>>>>>>>>>>> Hi again,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm having some issues with boost threads macros. If I compile the
>>>>>>>>>>>>> following code :
>>>>>>>>>>>>>
>>>>>>>>>>>>> #include <alchemy/task.h>
>>>>>>>>>>>>> #include <boost/thread.hpp>
>>>>>>>>>>>>> int main() { return 0; }
>>>>>>>>>>>>>
>>>>>>>>>>>>> g++ b.cc $(xeno-config --alchemy --cflags)  $(xeno-config --alchemy
>>>>>>>>>>>>> --ldflags) -lboost_system -lboost_thread
>>>>>>>>>>>>>
>>>>>>>>>>>>> It gives me a lot of errors regarding "barrier", a macro present in both
>>>>>>>>>>>>> librairies. Copperplate's debug macro also created similar issues with
>>>>>>>>>>>>> log4cpp lib.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It compiles only if :
>>>>>>>>>>>>> 1) Unsetting barrier from alchemy
>>>>>>>>>>>>>
>>>>>>>>>>>>> #include <alchemy/task.h>
>>>>>>>>>>>>> #unset barrier
>>>>>>>>>>>>> #include <boost/thread.hpp>
>>>>>>>>>>>>> int main() { return 0; }
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2) Changing the order of the includes (easy here, but hard on a big library)
>>>>>>>>>>>>>
>>>>>>>>>>>>> #include <boost/thread.hpp>
>>>>>>>>>>>>> #include <alchemy/task.h>
>>>>>>>>>>>>> int main() { return 0; }
>>>>>>>>>>>>>
>>>>>>>>>>>>> I guess it's not a redefinition, but an overloading :
>>>>>>>>>>>>>
>>>>>>>>>>>>> /usr/include/boost/thread/barrier.hpp:138:22: error: too many arguments
>>>>>>>>>>>>> provided to function-like macro invocation
>>>>>>>>>>>>>     explicit barrier(unsigned int count) :
>>>>>>>>>>>>>                      ^
>>>>>>>>>>>>> /usr/xenomai/include/boilerplate/atomic.h:83:9: note: macro 'barrier'
>>>>>>>>>>>>> defined here
>>>>>>>>>>>>> #define barrier()       __asm__ __volatile__("": : :"memory")
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> We want to define a compiler barrier that represents a strong sequence
>>>>>>>>>>>> point in the instruction flow, this has nothing to do with a thread
>>>>>>>>>>>> synchronization method. We only have a very few instances of such
>>>>>>>>>>>> barriers, so the best fix is to rename our macro.
>>>>>>>>>>>>
>>>>>>>>>>>> Please pull this change:
>>>>>>>>>>>> http://git.xenomai.org/xenomai-3.git/commit/?id=cd8815510e4ea53218a36518be09276bab21750d
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Philippe.
>>>>>>>>>>>
>>>>>>>>>>> Excellent, that fixes the barrier problem.
>>>>>>>>>>> There's now also clz and cls in boilerplate/compiler.h, that conflicts
>>>>>>>>>>> with libtbb, and debug() in copperplate/debug.h, that conflicts with a
>>>>>>>>>>> lot of libs I use.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I really don't know why the compiler gets so confused, here's an example :
>>>>>>>>>>>
>>>>>>>>>>> #include <alchemy/task.h>
>>>>>>>>>>>
>>>>>>>>>>> struct A
>>>>>>>>>>> {
>>>>>>>>>>> A():debug(0){}
>>>>>>>>>>> bool debug;
>>>>>>>>>>> };
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Because it ends up compiling this in the !debug case, once the
>>>>>>>>>> preprocessor tokens have been substituted:
>>>>>>>>>>
>>>>>>>>>> struct A
>>>>>>>>>> {
>>>>>>>>>> A():do { } while (0)(0){}
>>>>>>>>>> bool do { } while (0);
>>>>>>>>>> };
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> struct A
>>>>>>>>> {
>>>>>>>>> A():do { } while (0)(0){}
>>>>>>>>> bool debug;
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>> is more likely.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Philippe.
>>>>>>>>
>>>>>>>> I'm obviously fine with any solution, but why not rename the internal
>>>>>>>> macros with a "namespace __xeno" , like __xeno_debug(), __xeno_clz() ?
>>>>>>>>
>>>>>>>> btw the line in question for clz() is here :
>>>>>>>> https://github.com/jckarter/tbb/blob/master/include/tbb/machine/gcc_generic.h#L77
>>>>>>>> gcc_generic.h seems to be included in may libs.
>>>>>>>>
>>>>>>>
>>>>>>> Probably for the same reason than TBB does not define tbb_clz() but clz().
>>>>>>>
>>>>>>> --
>>>>>>> Philippe.
>>>>>>
>>>>>> In TBB clz() is not a preprocessor macro but an inline function that
>>>>>> is actually defined in tbb::internal::gcc_builtins::clz()
>>>>>> That's why I'm suggesting the __xeno prefix.
>>>>>>
>>>>>
>>>>> Thanks, I can still read C++ a bit.
>>>>>
>>>>> But no, I don't want to add xeno* in front of every symbol, not only
>>>>> because I find this particular prefix ugly, but more to the point,
>>>>> because the symbols you are referring to are part from the internal
>>>>> interface, and no C++ client code is supposed to ever use Xenomai's
>>>>> definition of it. Hence the patch.
>>>>>
>>>>> Should we still prefix it for C code then? Maybe, but so far no conflict
>>>>> was ever reported, so I'm going to wait and see for now.
>>>>>
>>>
>>> The context is orocos + gazebo (that apparently uses tbb). Limited
>>> audience indeed.
>>>
>>>>
>>>> Actually, the best general fix for these issues would be to group
>>>> internal stuff into private headers, which should not be included by
>>>> public ones.
>>>>
>>>
>>> That'd be a good solution.
>>> Nevertheless I see clz/ctz are only used in heapobj-pshared.c one time
>>> each, so what about defining the macros in this file ?
>>> For now I'm using this patch, that just renames clz and ctz to __clz and __ctz :
>>>
>>> diff --git a/include/boilerplate/compiler.h b/include/boilerplate/compiler.h
>>> index 0509e33..bcef7d4 100644
>>> --- a/include/boilerplate/compiler.h
>>> +++ b/include/boilerplate/compiler.h
>>> @@ -64,7 +64,7 @@ extern "C" {
>>>
>>>  void __invalid_operand_size(void);
>>>
>>> -#define ctz(__v) \
>>> +#define __ctz(__v) \
>>>   ({ \
>>>   int __ret; \
>>>   if (!__v) \
>>> @@ -83,7 +83,7 @@ void __invalid_operand_size(void);
>>>   __ret; \
>>>   })
>>>
>>> -#define clz(__v) \
>>> +#define __clz(__v) \
>>>   ({ \
>>>   int __ret; \
>>>   if (!__v) \
>>> diff --git a/lib/copperplate/heapobj-pshared.c
>>> b/lib/copperplate/heapobj-pshared.c
>>> index 578f442..03d6eaa 100644
>>> --- a/lib/copperplate/heapobj-pshared.c
>>> +++ b/lib/copperplate/heapobj-pshared.c
>>> @@ -291,7 +291,7 @@ static int reserve_page_range(uint32_t *bitmap,
>>> int bitwords, int nrpages)
>>>   v = bitmap[n];
>>>   b = 0;
>>>   while (v != -1U) {
>>> - r = ctz(v);
>>> + r = __ctz(v);
>>>   if (r) {
>>>   seq += r;
>>>   if (seq >= nrpages) {
>>> @@ -432,7 +432,7 @@ static void *alloc_block(struct shared_heap *heap,
>>> size_t size)
>>>   */
>>>   if (size <= HOBJ_PAGE_SIZE * 2) {
>>>   /* Find log2(size). */
>>> - log2size = sizeof(size) * 8 - 1 - clz(size);
>>> + log2size = sizeof(size) * 8 - 1 - __clz(size);
>>>   if (size & (size - 1))
>>>   log2size++;
>>>   /* That is the actual block size we need. */
>>>
>>>
>>
>> Ok, I'll pick that one to ease the burden until we manage to move the
>> internal code out of the public headers entirely. Could you provide a
>> patch conforming to the git format I can merge (with autorship, subject,
>> etc., as obtained by git format-patch or git log?).
>>
>> TIA.
>>
>> --
>> Philippe.
> 
> Don't know if I can attach files on this mailing list, so i'm posting
> it here also:
> 
>>From dc99eb1872e02469c2d516b56b6562c78dbd2df0 Mon Sep 17 00:00:00 2001
> From: Antoine Hoarau <hoarau.robotics@gmail.com>
> Date: Thu, 28 Sep 2017 16:19:09 +0200
> Subject: [PATCH] rename clz()/ctz() -> __clz()/__ctz()
> 
> Prevents conflicts with libtbb that defines clz as an inline function and gets
> replaced by those macros. Temporary fix waiting to move this code in
> private headers.
> ---
>  include/boilerplate/compiler.h    | 4 ++--
>  lib/copperplate/heapobj-pshared.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/include/boilerplate/compiler.h b/include/boilerplate/compiler.h
> index 0509e33..bcef7d4 100644
> --- a/include/boilerplate/compiler.h
> +++ b/include/boilerplate/compiler.h
> @@ -64,7 +64,7 @@ extern "C" {
> 
>  void __invalid_operand_size(void);
> 
> -#define ctz(__v) \
> +#define __ctz(__v) \
>   ({ \
>   int __ret; \
>   if (!__v) \
> @@ -83,7 +83,7 @@ void __invalid_operand_size(void);
>   __ret; \
>   })
> 
> -#define clz(__v) \
> +#define __clz(__v) \
>   ({ \
>   int __ret; \
>   if (!__v) \
> diff --git a/lib/copperplate/heapobj-pshared.c
> b/lib/copperplate/heapobj-pshared.c
> index 578f442..03d6eaa 100644
> --- a/lib/copperplate/heapobj-pshared.c
> +++ b/lib/copperplate/heapobj-pshared.c
> @@ -291,7 +291,7 @@ static int reserve_page_range(uint32_t *bitmap,
> int bitwords, int nrpages)
>   v = bitmap[n];
>   b = 0;
>   while (v != -1U) {
> - r = ctz(v);
> + r = __ctz(v);
>   if (r) {
>   seq += r;
>   if (seq >= nrpages) {
> @@ -432,7 +432,7 @@ static void *alloc_block(struct shared_heap *heap,
> size_t size)
>   */
>   if (size <= HOBJ_PAGE_SIZE * 2) {
>   /* Find log2(size). */
> - log2size = sizeof(size) * 8 - 1 - clz(size);
> + log2size = sizeof(size) * 8 - 1 - __clz(size);
>   if (size & (size - 1))
>   log2size++;
>   /* That is the actual block size we need. */
> 

Merged, thanks.

-- 
Philippe.