[Bug middle-end/66110] uint8_t memory access not optimized

["kevin at koconnor dot net" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #10 from Kevin OConnor <kevin at koconnor dot net> ---
I've looked through the C specs (both C99 and C11) and I don't see anything
that requires uint8_t (nor int8_t) to be considered "character types".  I do
see three relevant sections in the spec which I'm including below.

For aliasing there is section 6.5:

  7 An object shall have its stored value accessed only by an lvalue expression
that has one of the following types:
  [...]
      -- a character type.

For "character types" there is section 6.2.5:

  15 The three types char, signed char, and unsigned char are collectively
called the character types. [...]

For uint8_t there is section 7.20.1.1:

     7.20.1.1 Exact-width integer types

  1 The typedef name intN_t designates a signed integer type with width N , no
padding bits, and a two's complement representation. Thus, int8_t denotes such
a signed integer type with a width of exactly 8 bits.

  2 The typedef name uintN_t designates an unsigned integer type with width N
and no padding bits. Thus, uint24_t denotes such an unsigned integer type with
a width of exactly 24 bits.

So, my read is that uint8_t must be considered an integer type, but is not
required to be considered a "character type".

That said, I understand that changing uint8_t may cause problems for some
existing user-code.  I'd think those enabling -fstrict-aliasing would want the
optimization benefit though.

I certainly understand if the cost of introducing another integer type and the
potential cost of causing issues for existing code is considered too high.  It
is unfortunate, though, that there doesn't appear to currently be any way to
declare a pointer to a non-aliasing 8-bit integer (that doesn't involve
'struct' hacks).