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: [PATCH] Make alias_sets_conflict_p less conservative


On Wed, 5 Mar 2008, Richard Kenner wrote:

> > you are right if for
> > 
> >   char c[4];
> > 
> > c has a declared type of char.  Which would make
> > 
> >   char c[4];
> >   int *p = c;
> >   *p = 0;
> > 
> > undefined.  But the above is commonly used enough to make any
> > declared character array handled the same as allocated storage is.
> 
> So you feel that we need to support it?
> 
> But we're actually creating an object of char * here in that second
> statement.  Perhaps we can use that knowlege somehow.
> 
> But pessimizing "char" with no pointers in sight just to support this
> seems very bad.  There must be some approach that works.

Well, my C-fu is from interpreting the words in the standard and looking
at existing use.

So you agree that your change introducing this handling of alias set zero
was not with the fact in mind that C assigns alias set zero to 'char'?

Note that apart from the bug in RTL dse which is uncovered by the patch
everything still seems to work fine.  The fact that we assign alias set
zero to char should not matter, and I still do not understand the
reasoning behind

struct alias_set_entry GTY(())
{
...
  /* Nonzero if would have a child of zero: this effectively makes this
     alias set the same as alias set zero.  */
  int has_zero_child;

and the purpose and reasoning of

alias_sets_conflict_p (alias_set_type set1, alias_set_type set2)
{
...
  /* See if the first alias set is a subset of the second.  */
  ase = get_alias_set_entry (set1);
  if (ase != 0
      && (ase->has_zero_child
        ^^^^^^^^^^^^^^^^^^^^^^
          || splay_tree_lookup (ase->children,
                                (splay_tree_key) set2)))
    return 1;

Can you explain again why a alias-set zero child of set1 or set2
makes any alias set conflict with such set?  This effectively makes
a set with an alias-set zero child equivalent to alias-set zero itself,
which doesn't make sense.

In which case would the above (alias-set zero member) happen for Ada
(which does not assign alias set zero to char, but to "something else")?

Thanks,
Richard.


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