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: gcc3 vs 176.gcc



> <<Having thought about it more, I now think gcc3's behavior in this
> case is clearly wrong, at least as a quality-of-implementation issue.
> The aliasing rules are there to permit compilers to make aggressive
> assumptions when they can't tell whether two memrefs alias or not.
> They are not there to permit compilers to do stupid things when they
> can easily tell that two memrefs do alias.  The examples in the
> Rationale make this clear.
> >>
> 
> Sounds resaonable, but we can we have a bit more detail on the meaning
> of "stupid things" and "easily tel that two memrefs do alias".

We could implement one very specific case where the compiler can
tell, based only on local information without the need for any dataflow
analysis, that the user has violated the rules.  In this case we know
about the violation by looking only at the types of the variables and
a single lvalue expression.

The idea: we have a pointer of type T1, and there is a dereference
based on a casted-to-T2 form of that pointer, where T1 and T2 aren't
compatible types for the purpose of the aliasing rule.  For example
	T1 * p;
	...
	*((T2 *)p = value;
or
	((T2 *)p)[expression] = value;
(or alternatively a read).  The key is that the pointer is converted
to an incompatible type, and then dereferenced, possibly after adding
an offset.

The compiler would issue a warning that this access violates the rules
of C (we should not provide any support for disabling this warning),
and we would then note that accesses through the cast pointer can collide
with accesses through the original pointer.  This might force us to
just merge alias sets for accesses of type T1 and accesses of type T2
(dereferencing p could collide with other accesses of both types).

In the past, people have objected that if we only warn about some aliasing
violations but not all, users will get a false sense of confidence, so
since finding all violations is impossible, we should give up.  But I
think that in this one case, the user's instinct about what is "obvious"
is reasonable, and we can clearly describe the limitations.


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