This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ 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, 18 Jan 2017 19:08:21 +0000
- 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> <8642f1ba-d728-8d4f-3ab2-6c34f0351c0e@somniumtech.com>
On 17/08/2016 12:19, Joe Seymour wrote:
> fail to build with...
>
>> ../../../../../libstdc++-v3/src/c++11/cow-stdexcept.cc:274:3: error: static assertion failed: Pointers must be 32 bits or 64 bits wide
>> static_assert(sizeof(uint64_t) == sizeof(void*)
>
> The assert fails because msp430 has 16-bit or 20-bit pointers. The same error
> can be reproduced for the rl78-elf target, which has 16-bit pointers.
With current master, the rl78-elf build completes successfully and the
msp430-elf build doesn't seem to trigger the assertion, but does later fail
with a presumably unrelated ICE.
> the msp430 -mlarge multilib failing to build with...
>> configure: error: Unknown underlying type for size_t
>> make[1]: *** [configure-target-libstdc++-v3] Error 1
This is still reproducible.
> Disabling the original changes for targets with unsupported pointer sizes
> seems like a reasonable solution to me [...]
> Presumably, this would be achieved by adding an
> --{enable,disable}-transactional-memory argument to configure
I have an initial/partial patch that adds a new configure argument:
--enable-transactional-memory=yes|no|auto
Having said that, since I now only see issues with msp430-elf, I wonder if the
configure argument might be excessive, and if my original patch to
GLIBCXX_CHECK_SIZE_T_MANGLING might be more appropriate?