I can find test programs for __atomic_load in GCC 4.6 and at least documented for GCC 4.7. The legacy __sync builtins seems to have been added in GCC 4.4.
You will have to write your own inline assembler functions. You could use a later compiler version, write some wrapper functions that use e.g. __atomic builtins, compile, disassemble and translate into GCC inline assembler. -- Ola On 11 September 2014 17:16, Mukesh Dua <[email protected]> wrote: > 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]> > 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 >> > >> > > "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
