memset and host char requirement

[Paulo J. Matos]

On 26/07/12 15:04, Joseph S. Myers wrote:
> On Thu, 26 Jul 2012, Paulo J. Matos wrote:
>
>> My target has 16bit chars.
>
> As I explained before, support for such targets is extremely limited and
> bitrotten (this applies whether it is BITS_PER_UNIT, CHAR_TYPE_SIZE or
> both that are not 8) and a large amount of work, and global GCC expertise
> and vision for what internal interfaces should look like in the context of
> such bytes, will be required to remove assumptions about target bytes
> being 8 bits before such a port can work.  It would not surprise me if a
> series of more (possibly much more) than 100 large patches to the
> target-independent compiler is needed to make such targets work properly.
>
> http://gcc.gnu.org/ml/gcc/2010-03/msg00445.html
>

I understand we had this discussion before and much of my work in my 
current company is to get GCC to support this exotic architecture.

It is sometimes frustrating that GCC appears to be flexible enough to 
support many different architectures (by allowing you to set 
CHAR_TYPE_SIZE and BITS_PER_UNIT for example) but then making 
assumptions about these same values throughout the code.

> It's not particular useful to raise questions about "why" something is
> broken in such a case, as it's simply generally not been a design
> consideration at all; rather, propose a clear definition of a relevant
> interface that is meaningful for such a case, with a complete patch making
> all the code follow that definition.  And repeat 100 (possibly many more)
> times until all interfaces are properly defined for general target byte
> sizes.  And keep a careful watch on all patches going through gcc-patches
> for anything hardcoding new assumptions about target byte size.
>

Realistically I understand that since it seems I am the only one facing 
these problems there's no reason not to make these assumption but why, 
then not just assume these assumptions publicly and force BITS_PER_UNIT 
== 8 and CHAR_TYPE_SIZE <= HOST_BITS_PER_CHAR for example for GCC?

Also, as much as I would like to help in an effort to remove these 
constraints, again I am the only one interested and the company I work 
for prefers if I spend my time developing optimisations that improve 
code density for client software than removing constraints from GCC just 
so we can memset with a fill variable > 255.

Thanks once again for your comments on this,

-- 
PMatos