Re: [PATCH] support: user more portable atomic wrappers

[Florian Weimer]

* Vineet Gupta:

> I agree that gcc atomics should be baseline. I would still propose to
> carry this patch as it makes code less verbose if nothing else and the
> wrappers are part of glibc already.

The advantage of the GCC built-ins is that they have easy-to-find
documentation.  Our wrapper macros are in the same file as the legacy
atomics that no longer should be used.  They are also not easy to use
correctly (e.g., there is no support for access to single bytes, but the
code will still compile on some architectures).

The GCC built-ins have other problems, of course.  For example, one
might accidentally introduce a dependency on libatomic (leading to a
link failure later).  But I think these issues are less severe.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v2] binutils/ARC: cleanup

[Vineet Gupta]

Hi Thomas,

On 12/22/19 1:41 PM, Thomas Petazzoni wrote:
> Hello Vineet,
> 
> On Tue, 17 Dec 2019 13:32:53 -0800
> Vineet Gupta  wrote:
> 
>> Remove special handling for ARC - as it is not needed for cksy etc.
>>
>> A nice side benefit is that the ARC specific version now only needs to
>> be specified in single place (vs 3 currently) in binutils/Config.in.host
>>
>> Signed-off-by: Vineet Gupta 
>> 
>> ---
>>  package/binutils/binutils.mk | 6 +-
>>  1 file changed, 1 insertion(+), 5 deletions(-)
>>
>> diff --git a/package/binutils/binutils.mk b/package/binutils/binutils.mk
>> index a19d6940f7c1..3ae5561d67d3 100644
>> --- a/package/binutils/binutils.mk
>> +++ b/package/binutils/binutils.mk
>> @@ -8,14 +8,10 @@
>>  # If not, we do like other packages
>>  BINUTILS_VERSION = $(call qstrip,$(BR2_BINUTILS_VERSION))
>>  ifeq ($(BINUTILS_VERSION),)
>> -ifeq ($(BR2_arc),y)
>> -BINUTILS_VERSION = arc-2019.09-rc1
>> -else
>>  BINUTILS_VERSION = 2.32
>>  endif
>> -endif # BINUTILS_VERSION
>>  
>> -ifeq ($(BINUTILS_VERSION),arc-2019.09-rc1)
>> +ifeq ($(BR2_BINUTILS_VERSION_ARC),y)

Looks like we need this specific thunk anyways. When I select pristine upstream
binutils (not ARC fork @ github), the above forces it to download from github
which it should not and will not if the tag/branch has not been mirrored there.

>>  BINUTILS_SITE = $(call 
>> github,foss-for-synopsys-dwc-arc-processors,binutils-gdb,$(BINUTILS_VERSION))
>>  BINUTILS_SOURCE = binutils-gdb-$(BINUTILS_VERSION).tar.gz
>>  BINUTILS_FROM_GIT = y
> 
> In fact, I was wrong, this also does not work, in the following
> situation:
> 
>  - You're using a pre-compiled external toolchain, so host-binutils is
>not selected/enabled, so the version selection in
>package/binutils/Config.in.host is not used, and therefore
>BR2_BINUTILS_VERSION_ARC cannot be set to 'y'.
> 
>  - You have binutils enabled for the target.
> 
> Then, with your patch, we will no longer select the ARC-specific fork
> of binutils.
> 
> Basically, for the target binutils (just like for target gdb), we don't
> have any version selection, so we force using one specific version
> depending on the architecture.
> 
> Best regards,
> 
> Thomas
> 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc