Pre-DR: enum type compatibility
===============================

Type compatibility of enum and integer types is not transitive.  For
example:

enum e1 { A };
enum e2 { B };
// Suppose that enum e1 and enum e2 are both compatible with int.
// (6.7.2.2#4: an enum is compatible with an implementation-defined
// one of char, a signed integer type or an unsigned integer type.)
// Then they are nevertheless not compatible with each other.
enum e1 a;
enum e2 *b = &a; // Constraint violation.

I think this is clear from the text of the standard, but some
implementations reportedly do not implement this and it isn't clear
whether this is intended.

Question: Are enum e1 and enum e2 above indeed incompatible types?

(Experience with making them incompatible in GCC, following a user bug
report that they should be incompatible, is that there isn't much
existing code expecting the types to be compatible; there wasn't a
problem with user complaints wanting the types to be made compatible
again.)

Despite such incompatibility, type-based alias analysis (6.5#7) must
allow for these types to alias.  For example,

int f(enum e1 *a, enum e2 *b) { int x = *a; *b = x + 2; return *a; }

must allow for the write to *b changing *a, since f could have been
called as

  int x;
  f((enum e1 *)&x, (enum e2 *)&x);

where the object has declared type (and so effective type) int, so the
accesses through both types enum e1 and enum e2 are permitted.