erlang: disable for sparc

Required atomic operations not available for sparc.
Fixes autobuild failures:
http://autobuild.buildroot.net/results/688278236e6d5bcd63b7d4413303eb115a38f3a7/
http://autobuild.buildroot.net/results/7875a7425bfe1f43d46c9a1db9f96b54f7a99b19/

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
---
 package/erlang/Config.in |    2 ++
 1 file changed, 2 insertions(+)

Waldemar,

On Sun, 6 Dec 2015 16:10:04 +0100, Waldemar Brodkorb wrote:
> Required atomic operations not available for sparc.
> Fixes autobuild failures:
> http://autobuild.buildroot.net/results/688278236e6d5bcd63b7d4413303eb115a38f3a7/
> http://autobuild.buildroot.net/results/7875a7425bfe1f43d46c9a1db9f96b54f7a99b19/
> 
> Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>

While I agree that this would fix the problem, I am not too happy with
this solution. We have lots of packages that are affected by atomic
operations issues, not only on SPARC, so I'd prefer to have a better
understanding of the handling of those atomic operations and add proper
dependencies.

For example, we have BR2_ARCH_HAS_ATOMICS. What does this Config.in
option means exactly ?

There are some __sync_*() builtins and __atomic_*() builtins. There is
libatomic on some architectures.

This is a rather big mess, and to me adding one more "depends
on !BR2_sparc" is just a band-aid rather than a proper solution.

Gustavo ?

Thomas

Hi Thomas,
Thomas Petazzoni wrote,

> Waldemar,
> 
> On Sun, 6 Dec 2015 16:10:04 +0100, Waldemar Brodkorb wrote:
> > Required atomic operations not available for sparc.
> > Fixes autobuild failures:
> > http://autobuild.buildroot.net/results/688278236e6d5bcd63b7d4413303eb115a38f3a7/
> > http://autobuild.buildroot.net/results/7875a7425bfe1f43d46c9a1db9f96b54f7a99b19/
> > 
> > Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
> 
> While I agree that this would fix the problem, I am not too happy with
> this solution. We have lots of packages that are affected by atomic
> operations issues, not only on SPARC, so I'd prefer to have a better
> understanding of the handling of those atomic operations and add proper
> dependencies.

Sure.
 
> For example, we have BR2_ARCH_HAS_ATOMICS. What does this Config.in
> option means exactly ?

It seems to declare a architecture as having atomic operations.
Should we depend on BR2_ARCH_HAS_ATOMICS instead?

There is another symbol for packages using libatomic_ops:
BR2_PACKAGE_LIBATOMIC_ARCH_SUPPORTS

Interesting is that bdwgc at least is compilable for sparc. I
have not done any runtime testing. But I think erlang does not
only use libatomic_ops, but also they are using sync* builtins from
gcc.
 
> There are some __sync_*() builtins and __atomic_*() builtins. There is
> libatomic on some architectures.

GCC documentation states that _atomic_*() builtins should be used
for new code.
 
> This is a rather big mess, and to me adding one more "depends
> on !BR2_sparc" is just a band-aid rather than a proper solution.

Right. It seems to even get more complicated. I started hacking on
leon3/leon4 support. It seems leon3/leon4 have some sparcv8
extensions, which allow to use atomic operations, so that depending
on !BR2_sparc would be wrong.

best regards
 Waldemar

Waldemar,

On Sun, 6 Dec 2015 16:10:04 +0100, Waldemar Brodkorb wrote:
> Required atomic operations not available for sparc.
> Fixes autobuild failures:
> http://autobuild.buildroot.net/results/688278236e6d5bcd63b7d4413303eb115a38f3a7/
> http://autobuild.buildroot.net/results/7875a7425bfe1f43d46c9a1db9f96b54f7a99b19/
> 
> Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
> ---
>  package/erlang/Config.in |    2 ++
>  1 file changed, 2 insertions(+)

Now that we have proper options to describe atomic intrinsics
dependencies, this patch is no longer the correct solution to solve
this problem. Also, there are some patches from Frank pending around
erlang, touching atomic support. However, I haven't checked if they
fixed the sparc issue specifically.

Frank?

In any case, I've marked this particular patch as Rejected.

Best regards,

Thomas

Hi Thomas, Waldemar, all,

On Sun, Mar 6, 2016 at 6:05 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Waldemar,
>
> On Sun, 6 Dec 2015 16:10:04 +0100, Waldemar Brodkorb wrote:
>> Required atomic operations not available for sparc.
>> Fixes autobuild failures:
>> http://autobuild.buildroot.net/results/688278236e6d5bcd63b7d4413303eb115a38f3a7/
>> http://autobuild.buildroot.net/results/7875a7425bfe1f43d46c9a1db9f96b54f7a99b19/
>>
>> Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
>> ---
>>  package/erlang/Config.in |    2 ++
>>  1 file changed, 2 insertions(+)
>
> Now that we have proper options to describe atomic intrinsics
> dependencies, this patch is no longer the correct solution to solve
> this problem. Also, there are some patches from Frank pending around
> erlang, touching atomic support. However, I haven't checked if they
> fixed the sparc issue specifically.

No, the sparc issue isn't fixed in Erlang 18. Compilation fails with
'architecture mismatch on "cas" and "membar"' errors. Sparc_v9 works,
though. My Erlang patch series had included this. It strikes me, now,
that I probably should have broken the submitted patch into second
commit to address sparc. I'll address that next iteration since the
current submission already is greatly changed (simplified) and likely
due for more comments.

Regards,
Frank