Good suggestion Victor. "__atomic_add_fetch(ptr, 1, __ATOMIC_RELAXED);" gives the code I am looking for, no barriers (because a counter increment by itself does not need any barriers).
Now there is no need for the old __sync builtins. They are also described as legacy by GCC documentation. The question is if we really need the current set of ODP atomic functions? (Except for presenting a standard API that works when not using GCC). -- Ola On 10 September 2014 16:46, Victor Kamensky <[email protected]> wrote: > On 10 September 2014 07:01, Ola Liljedahl <[email protected]> > wrote: > > The GCC __sync functions are not ideal anyway, containing unnecessary > > barriers (there isn't really any need for barriers at all in these > > functions, that's just a legacy from the original Itanium definition and > > implementation me thinks). So we ought to re-implement odp_atomic.h, e.g. > > with optimized in-lined assembly code. > > In gcc there are __atomic builtins that are aware about memory > models [1]. They could be used instead of specific custom implementation > without barriers. > > Thanks, > Victor > > [1] > https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html#g_t_005f_005fatomic-Builtins > > > The current implementation may lead > > applications not to use barriers when really needed, instead relying on > the > > gratuitous use of barriers in the current implementation. > > > > -- Ola > > > > > > On 10 September 2014 13:15, Steve McIntyre <[email protected]> > > wrote: > >> > >> On Wed, Sep 10, 2014 at 06:02:53AM +0000, Mrityunjay Kumar wrote: > >> >Hi maxim > >> > > >> >I want to compile odp for AMRMv6j with toolchain having gcc version > >> > 4.3.3,. I > >> >getting the following issue . > >> > > >> >1. Compilation fails for ARMv6j with toolchain having gcc version > 4.3.3: > >> > > >> > a. Undefined reference to > >> > __sync_fetch_and_sub_4/__sync_fetch_and_add_8/ > >> >__sync_lock_test_and_set_4/ __sync_fetch_and_sub_4/ > >> > __sync_fetch_and_sub_8 (all > >> >sync built-in functions). As the sync functions support was provided in > >> > gcc > >> >4.4+ versions > >> > > >> > b. Undefined reference to `__aeabi_read_tp' - This issues comes due > >> > to the > >> >presence of __thread specifier > >> > >> <snip> > >> > >> >We have constraints moving to newer version of gcc so can you provide > >> > guidance > >> >in this respect. > >> > >> It looks like you're out of luck, then. You need a newer compiler to > >> get the basic locking primitives that we're relying on. It's not like > >> gcc 4.4 is *particularly* new, it was released in 2009. > >> > >> Alternatively, you could try implementing the __sync* functions > >> yourself to meet the needs here, but that's not likely to be an easy > >> task either. > >> > >> Cheers, > >> -- > >> Steve McIntyre [email protected] > >> <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs > >> > >> > >> _______________________________________________ > >> lng-odp mailing list > >> [email protected] > >> http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > > > _______________________________________________ > > lng-odp mailing list > > [email protected] > > http://lists.linaro.org/mailman/listinfo/lng-odp > > >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
