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.
