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
