This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: transaction_safe exceptions prevent libstdc++ building for some targets
- From: Joe Seymour <joe dot s at somniumtech dot com>
- To: Jonathan Wakely <jwakely at redhat dot com>
- Cc: libstdc++ at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org, Torvald Riegel <triegel at redhat dot com>
- Date: Wed, 17 Aug 2016 12:50:06 +0100
- Subject: Re: transaction_safe exceptions prevent libstdc++ building for some targets
- Authentication-results: sourceware.org; auth=none
- References: <e19b9c0b-c0d8-830d-5ecf-9c6ddf63cced@somniumtech.com> <20160817113043.GC20016@redhat.com>
On 17/08/2016 12:30, Jonathan Wakely wrote:
> On 17/08/16 12:19 +0100, Joe Seymour wrote:
>> Disabling the original changes for targets with unsupported pointer sizes seems
>> like a reasonable solution to me, but I can't see an existing mechanism to do
>> so? Do others agree?
>
> Yes, the intention was that the transaction-safe exceptions would only
> be defined where it is relatively straightforward to support them. If
> they're causing build failures they can be simply disabled for that
> target. Maybe the configure script should check for 32-bit or 64-bit
> pointers and completely disable the TM exceptions otherwise.
>
>> More generally, it might be useful to have a mechanism to disable transactional
>> memory for some targets. I've observed things like register_tm_clones taking up
>> space in ARM Cortex-M binaries. Presumably, this would be achieved by adding an
>> --{enable,disable}-transactional-memory argument to configure? I'm happy to
>> work on a patch, if this is acceptable in principle.
>
> I think that makes sense, for cases where the target can support the
> TM clones but they aren't wanted.
>
> If we add such an option then the checks for 32/64-bit pointers can go
> in there, so that when the option isn't used the default depends on
> the target.
>
I'll start working on a patch.
Thanks,
Joe