This is the mail archive of the
mailing list for the GCC project.
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
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
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.