[Bug libstdc++/88111] libstdc++-v3 FTB for 16-bit int: memory_resource.cc pool_sizes expects >16-bit int/size_t

[jozef.l at mittosystems dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88111

--- Comment #3 from Jozef Lawrynowicz <jozef.l at mittosystems dot com> ---
(In reply to Jonathan Wakely from comment #2)
> Does it even make sense to have pools for objects of 1024 bytes on a 16-bit
> target? Is anybody really going to dynamically-allocate lots of 1kb objects?
> 
> It certainly seems unnecessary to support objects of size 1<<14 bytes.

I would agree, your change to limit the object size below the theoretical max
object size makes sense.

For the largest 20-bit address space MSP430 devices, RAM can be almost 2^18,
but that would still only allow space for 64 2^12 objects, so the limitation
for "__SIZE_WIDTH__ > 16" also seems to be at a good number.

> I'd prefer to fix this for any 16-bit targets, not just msp430, so I don't
> want the fix to check __MSP430X_LARGE__. 
> 
> So taking all the above into account, and assuming __SIZE_WIDTH__ is set
> correctly, something like this seems preferable:

Ah, I wasn't aware of the __SIZE_WIDTH__ builtin, that's a much better way to
handle it.

Your patch fixes the build, thanks.