Victor, Ola, Does gcc 4.3.3 (32-bit) supports _atomic builtin functions? I guess the support was added in gcc 4.7/4.8 releases. Can you please confirm.
Regards, Mukesh ________________________________ From: [email protected] <[email protected]> on behalf of Ola Liljedahl <[email protected]> Sent: Thursday, September 11, 2014 6:44 PM To: Victor Kamensky Cc: Mrityunjay Kumar; [email protected]; [email protected] Subject: Re: [lng-odp] ARM compilation issue for version armv6j (gcc ver 4.3.3) 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]<mailto:[email protected]>> wrote: On 10 September 2014 07:01, Ola Liljedahl <[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]> >> <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs >> >> >> _______________________________________________ >> lng-odp mailing list >> [email protected]<mailto:[email protected]> >> http://lists.linaro.org/mailman/listinfo/lng-odp > > > > _______________________________________________ > lng-odp mailing list > [email protected]<mailto:[email protected]> > http://lists.linaro.org/mailman/listinfo/lng-odp > "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
