This is the mail archive of the gcc-patches@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: Aliasing brokenness (Was: Re: [patch RFC] SH: UseFRAME_GROWS_DOWNWARD)


> The stdarg machinery
> (TARGET_BUILD_BUILTIN_VA_LIST: sh_build_builtin_va_list,
> EXPAND_BUILTIN_VA_START: sh_va_start,
> TARGET_GIMPLIFY_VA_ARG_EXPR: sh_gimplify_va_arg_expr)
> fabricates the trees for the valist manipulation independent of the C
> frontend, so they might not look like the new alias.c expects them
> to look.

This machinery will cause failures when you illegally play "hide the
ball" from the compiler. 

In particular, if you have accesses to component_refs that you *know*
overlap, but they don't actually have a union somewhere that makes them
overlap, or some other actual type structure that contains them
overlapping.


IE if you had

int foo(struct a *foo, struct b *bar)
{
	bar->d = 5;
	return foo->c;   /* Somehow the same memory as bar->d, but there
is no union of them */
}

it would get this "wrong".

It's not really wrong because you've not told the compiler that they can
overlap in some sane way (unions, casting, etc), in a way that we can
know.

If you cast the accesses, we give up and let you do whatever you want.

(This is a very simplified overview, for all those language lawyers
about to pounce :P)

I imagine something like this is going on with the varray accesses.

--Dan


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