This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] ignoring type alias conflicts between structures and scalars


Diego Novillo wrote:
Jeff noticed that TBAA was creating some alias relations that don't seem
to make much sense.  For instance, given

Jeff's argument is that it's not really possible for a pointer to a
structure to point to a scalar variable.  If the structure is not type
compatible with the scalar, then they can't alias.  That makes some
sense to me.

If the program isn't well defined, why is alias_sets_conflict_p() saying
that 'struct int_float_s' and 'int' have conflicting alias sets?

these conflict because the following program is well formed (typos excepting :)


struct int_s {int i;};

struct int_s thing = {5};

void foo (int *i_ptr, struct int_s *s_ptr)
{
  if (*i_ptr) ...
  *s_ptr = thing;  // could clobber *i_ptr
  if (*i_ptr) ...
}

void baz ()
{
  struct int_s s = {0};
  foo (&s.i, &s);
}

your example is different, in that the int lvalue is not some arbitrary
pointer dereference, but a known variable.

Your example looks to me like the rule about structs with identical initial
field sequences conflict up to the point where the fields diverge, coupled
with the rule that the address of a struct is the address of its first
element (and vice versa).

Thus I think int_float_s conflicts with an int variable, but not a float
variable.

I don't think Joseph's example of
	struct float_int_s {float f; int i;};
        int i;
        ((float_int_s *)&((&i)[1]))[-1].i

being possibly valid is actually valid.  Notice this is forming the address
just past the int variable (valid), casting that to 'float_int_s *' (valid),
indexing -1 struct elements into that (INVALID due to address of start of
struct being outside of i), and then obtaining the i field (valid), which is
where the int is.  If the final two operations are folded together, no
ill-formed address is created, so the construct could be valid. I think that
reasoning is wrong, because it is presuming an optimization that might not
be implemented.

But Joseph has thought about this more than me.

nathan
--
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]