Re: [patch] Fix pr23046

[Roger Sayle <roger at eyesopen dot com>]

Hi Richard,

On Sun, 18 Sep 2005, Richard Henderson wrote:
> Roger's cop-out in the c++ front end is unfortunate, especially since
> the middle-end does handle zero or sign extending values to fill the
> mode -- it does exactly that for C.

I only wish this were true!

For a recent review of the topic see
http://gcc.gnu.org/ml/gcc/2005-08/msg00176.html

Especially, the earlier discussions cited in that post:
http://gcc.gnu.org/ml/gcc-patches/2004-05/msg02002.html
http://gcc.gnu.org/ml/gcc/2004-08/msg01129.html


In my mind, you over simplify the problem with your three options,
(1), (2) and (3), but miss the key issue, which is that given a partial
mode type with TYPE_MIN_VALUE and TYPE_MAX_VALUE what can the
optimizers assume (at run-time) about a value from such a type held
in a register/pseudo.  Ada may well be able to describe a type with
bounds between 2 and 10, but where/who is responsible for ensuring
variables of that type are always in the prescribed range and
correctly sign or zero extended.  In C++, if we generate no additional
RTL for the assignment of an integer to an enumerated type, then as
far as the optimizers are concerned variables can potentially hold
any value in the specified mode.

c.f. one of the examples in the discussions cited above:

enum E { e = 0x0f };

void test(int n)
{
  enum E x, y;

  x = (E)0x10;
  y = (E)n;

  if (x != y)
    abort ();
}

int main()
{
  test(0x10);
  return 0;
}



I think we both agree that the ability of the middle-end to support
partial-mode integral types would be beneficial to the compiler.
Where we perhaps disagree is the amount of work still required to
adequately support them.  For example, PR11264 shows that we fail
to generate suitable RTL for rotations of these types.

My role has purely been to fix/avoid the numerous bugs caused by the
lack of a model (semantics) for partial-mode integral types.  Despite
repeated claims to the contrary, the middle-end currently doesn't handle
these bitfield types well (as demonstrated by the numerous PRs), so the
less than ideal "cop-out" has been to avoid generating them in the
front-ends.  It should be easy enough to demonstrate these problems by
reverting the "cop-out" patch to the C++ front-end, to re-expose the
latent bugs, such as PR16372.

Perhaps to make some progress on this issue, you could comment
on where in the RTL expanders the assignment of a 3-bit unsigned
field to a 3-bit signed field, we (should) generate the necessary
manual sign extension using XORs and subtractions, if we believe
that the stored representations should always be suitably extended?

Roger
--