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: must_alias question


> In message <20031120203146.GH11681@kam.mff.cuni.cz>, Jan Hubicka writes:
>  >But for foloowing code:
>  >
>  >char global;
>  >t()
>  >{
>  >  char *a=global;
>  >  char **b=&a;
>  >  return *a;
>  >}
>  >must_alias clears may_point_to_global_mem for variable a based on fact
>  >that it's address is no longer taken.  This looks just wrong.
>  >the fact that we don't take address of pointer has nothing to do about
>  >the fact whehtehr it points to global memory or not.
>  >Or am I missunderstanding semantics of the flag?
> Well, it's entire possible the semantics of the flag do not match its
> name.  I've got a case where we've got a pointer that obviously might
> point to global memory, but may_point_to_global_mem is not set for
> that variable.
This is bug, I hope to commit fix soon (need to update patch once again
per Richard's suggestion in another mail)
> 
> All that code is a freaking mess.  It's far from clear to me what it's
> doing and why.
This is what hit me with tail call code (where I relied on invariant
that variables with address taken do have ADDRESSOF bit set).  I think I
got it back into shape now.

Honza
> 
> jeff


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