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?
