This is the mail archive of the
mailing list for the GCC project.
Re: [Patch] [Aarch64] PR 86538 - Define __ARM_FEATURE_LSE if LSE is available
- From: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>
- To: sellcey at cavium dot com, James Greenhalgh <james dot greenhalgh at arm dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>, nd at arm dot com
- Date: Wed, 25 Jul 2018 11:04:00 +0100
- Subject: Re: [Patch] [Aarch64] PR 86538 - Define __ARM_FEATURE_LSE if LSE is available
- References: <firstname.lastname@example.org> <20180724210423.GA28802@arm.com> <email@example.com>
On 24/07/18 22:55, Steve Ellcey wrote:
> On Tue, 2018-07-24 at 22:04 +0100, James Greenhalgh wrote:
>> I'd say this patch isn't desirable for trunk. I'd be interested in use cases
>> that need a static decision on presence of LSE that are not better expressed
>> using higher level language features.
> How about when building the higher level features? Right now,
> in sysdeps/aarch64/atomic-machine.h, we
> hardcode ATOMIC_EXCHANGE_USES_CAS to 0. If we had __ARM_FEATURE_LSE we
> could use that to determine if we wanted to set
> ATOMIC_EXCHANGE_USES_CAS to 0 or 1 which would affect the call
> generated in nptl/pthread_spin_lock.c. That would be useful if we
> built a lipthread specifically for a platform that had LSE.
> Steve Ellcey
If there is a case for such a define, it needs to be made with the ACLE
specification maintainers. I don't think GCC should be ploughing a
separate furrow here.
So make your case to the ACLE maintainers. If that adopts a pre-define,
then implementing it in GCC would go through on the nod.