public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Daniel Berlin <dan@dberlin.org>
To: Joe Buck <jbuck@synopsys.COM>
Cc: Mark Mitchell <mark@codesourcery.com>,
	David Edelsohn <dje@watson.ibm.com>,
	Paolo Carlini <pcarlini@unitus.it>,
	"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: g++ and aliasing bools
Date: Fri, 25 Jan 2002 15:43:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.44.0201251734560.1893-100000@dberlin.org> (raw)
In-Reply-To: <200201252002.MAA21171@atrus.synopsys.com>

On Fri, 25 Jan 2002, Joe Buck wrote:

> I wrote:
> 
> [ attempt at a proof that Daniel's right ]
> 
> Mark writes:
> > Your proof has at least one bug.  A type that has no baseclasses or
> > virtuals can contain (as a data member) a type that does; such a type
> > is at least as complex as the contained type.  (Similarly, an array
> > of classes with virtual bases, etc.)  You need to recurse through the
> > type structure.
> 
> Good catch.  OK, Daniel, Mark has demonstrated that he was correct in
> asking you for a proof: your proposal was wrong.
Not quite, Mark has caught a case that is already handled properly.
It is impossible for the type involved as a member to have been given an 
alias set other than 0, by the same test.  So we would never improperly 
generate code because of it.
If you want to me to show both it, and the current type, would be placed 
in set 0:
The C machinery in question records component aliases of structs.
In recording component aliases of structs, it recursively walks the 
members, and gets alias sets for their types, recording them as subsets of 
the struct's alias set:
From record_component_aliases:
"
   for (field = TYPE_FIELDS (type); field != 0; field = TREE_CHAIN 
(field))
        if (TREE_CODE (field) == FIELD_DECL && ! DECL_NONADDRESSABLE_P 
(field))
          record_alias_subset (superset, get_alias_set (TREE_TYPE 
(field)));
"
Once we hit the tree type of the field in question, we'll record it as 
having alias set 0 (it will fail the test, or the same process above 
will repeat, if it has a member that is itself too complex), and then 
record our type as having alias set 0 as a subset.
That will cause record_alias_subset to mark the alias set as a child of 
zero (there's a flag to do this), which is commented as:

"
  /* Nonzero if would have a child of zero: this effectively makes 
this
     alias set the same as alias set zero.  */
"
Thus, no accesses to the type in question will be treated as not aliasing 
anything else.

--Dan

  reply	other threads:[~2002-01-25 22:49 UTC|newest]

Thread overview: 97+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-25  8:55 Robert Dewar
2002-01-25  9:21 ` Daniel Berlin
2002-01-25 10:00   ` Daniel Berlin
2002-01-25 10:54     ` Paolo Carlini
2002-01-25 11:37       ` Daniel Berlin
2002-01-25 11:45       ` David Edelsohn
2002-01-25 11:53         ` Joe Buck
2002-01-25 12:09           ` Mark Mitchell
2002-01-25 12:28             ` Paolo Carlini
2002-01-25 13:49               ` Mark Mitchell
2002-01-25 14:19                 ` Joe Buck
2002-01-25 14:21                   ` Mark Mitchell
2002-01-25 15:41                     ` Neil Booth
2002-01-25 16:04                       ` Joe Buck
2002-01-25 17:37                         ` Paolo Carlini
2002-01-25 18:10                         ` Daniel Berlin
2002-01-27  5:11                         ` Mark Mitchell
2002-01-27  5:34                           ` Daniel Berlin
2002-01-28 10:39                             ` Joe Buck
2002-01-28 10:51                               ` Joe Buck
2002-01-28 15:59                               ` Mark Mitchell
2002-01-28 17:11                                 ` Daniel Berlin
2002-01-28 17:28                                   ` Joe Buck
2002-01-28 18:14                                     ` Daniel Berlin
2002-01-28 17:18                                 ` Joe Buck
2002-01-28 18:05                                   ` Mark Mitchell
2002-01-28 18:50                                     ` Joe Buck
2002-01-28 19:33                                       ` Mark Mitchell
2002-01-28 17:40                                         ` Daniel Berlin
2002-01-28 21:55                                           ` Daniel Berlin
2002-01-28 22:02                                         ` Alexandre Oliva
2002-01-28 22:12                                           ` Mark Mitchell
2002-01-25 13:07             ` Joe Buck
2002-01-25 15:43               ` Daniel Berlin [this message]
2002-01-25 16:03                 ` Joe Buck
2002-01-25 15:13             ` Daniel Berlin
2002-01-25 12:10           ` Paolo Carlini
2002-01-25 13:16             ` Joe Buck
2002-01-25 15:23             ` Daniel Berlin
2002-01-25 12:05         ` Mark Mitchell
2002-01-25 22:14           ` Daniel Berlin
2002-01-26  3:46             ` Mark Mitchell
  -- strict thread matches above, loose matches on Subject: below --
2002-01-25 14:49 mike stump
2002-01-25 12:23 Robert Dewar
2002-01-25 13:29 ` Joe Buck
2002-01-25 12:06 mike stump
2002-01-25  9:13 Robert Dewar
2002-01-25  8:35 Robert Dewar
2002-01-25  8:54 ` Daniel Berlin
2002-01-25  8:33 Richard Kenner
2002-01-25  8:32 Robert Dewar
2002-01-25  8:53 ` Daniel Berlin
2002-01-25  9:39 ` Joe Buck
2002-01-25  8:28 Robert Dewar
2002-01-25  8:49 ` Daniel Berlin
2002-01-25  7:51 Robert Dewar
2002-01-25  8:18 ` Daniel Berlin
2002-01-25  8:20   ` Daniel Berlin
2002-01-25  7:38 Robert Dewar
2002-01-25  8:11 ` Daniel Berlin
2002-01-25 14:09   ` Gabriel Dos Reis
2002-01-25  7:30 Richard Kenner
2002-01-25  7:30 Richard Kenner
2002-01-25  7:33 ` Daniel Berlin
2002-01-25 15:43   ` Daniel Berlin
2002-01-25  7:23 Richard Kenner
2002-01-25  7:24 ` Daniel Berlin
2002-01-25  7:05 Richard Kenner
2002-01-25  8:59 ` Paolo Carlini
2002-01-24 16:09 Richard Kenner
2002-01-24 15:30 Richard Kenner
2002-01-25  2:16 ` Gabriel Dos Reis
2002-01-25  3:04   ` Paolo Carlini
2002-01-25  4:17     ` Gabriel Dos Reis
2002-01-25  4:35       ` Paolo Carlini
2002-01-25  6:34         ` Daniel Berlin
2002-01-25  7:17   ` Daniel Berlin
2002-01-25 13:57     ` Gabriel Dos Reis
2002-01-25 14:47       ` Tim Hollebeek
2002-01-23 17:56 Dan Nicolaescu
2002-01-23 18:27 ` Daniel Berlin
2002-01-23 18:48   ` Dan Nicolaescu
2002-01-23 19:16     ` Daniel Berlin
2002-01-24 14:15     ` Mark Mitchell
2002-01-24 14:16       ` Daniel Berlin
2002-01-24 14:27         ` Mark Mitchell
2002-01-24 14:35           ` Daniel Berlin
2002-01-24 15:06             ` Mark Mitchell
2002-01-24 15:08             ` Paolo Carlini
2002-01-24 15:18       ` Dan Nicolaescu
2002-01-24 15:36         ` Mark Mitchell
2002-01-25  2:25           ` Daniel Berlin
2002-01-25 15:48           ` Dan Nicolaescu
2002-01-25 20:22             ` Joe Buck
2002-01-25 23:59               ` Daniel Berlin
2002-01-27 17:04               ` Dan Nicolaescu
2002-01-27 17:59                 ` Paolo Carlini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44.0201251734560.1893-100000@dberlin.org \
    --to=dan@dberlin.org \
    --cc=dje@watson.ibm.com \
    --cc=gcc@gcc.gnu.org \
    --cc=jbuck@synopsys.COM \
    --cc=mark@codesourcery.com \
    --cc=pcarlini@unitus.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).