transaction_safe exceptions prevent libstdc++ building for some targets

Joe Seymour joe.s@somniumtech.com
Wed Jan 18 19:24:00 GMT 2017


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?



More information about the Gcc-patches mailing list