public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Daniel Berlin <dan@dberlin.org>
To: Robert Dewar <dewar@gnat.com>
Cc: kenner@vlsi1.ultra.nyu.edu, <gcc@gcc.gnu.org>
Subject: Re: g++ and aliasing bools
Date: Fri, 25 Jan 2002 08:18:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.44.0201251039010.31319-100000@dberlin.org> (raw)
In-Reply-To: <20020125151715.6AA02F28AD@nile.gnat.com>

On Fri, 25 Jan 2002, Robert Dewar wrote:

> <<Undecidability is not just based on run-time behavior of the program.
> It's also undecidable in the static case.
> may-alias is undecidable statically, as is must-alias (Unless i'm
> misremembering).
> >>
> 
> This is confused.
No, it's not, it's perfectly true.
> 
> May-alias is a predicate with many possible solutions. One not very useful
> solution is that anything may alias anything else. We are not interested
> in whether something actually IS aliased at run time. We are interested
> just in the subset of cases that we can prove do NOT alias. 
Well, duh.
> 
> The problem before us is to narrow down the may-alias relationship as far
> as possible statically. There is no issue of undecidability here.
Of course there is, which is why you conservatively assume that everything 
aliases everything else until you prove otherwise.
I've been told i need to come up with a formal proof that given certain 
relationships between C++ types, that may-alias is always determinable 
statically correctly, or that we always correctly determine that we can't 
determine it (IE never claim wrong that things may not alias).
I've said before, and i'll say again, that i'm not going to do that.

But claiming that undecidability doesn't enter anyway is simply wrong. 
I'm claiming that undecidability enters the picture in another way as 
well. The C++ language specification does not give you enough information 
in our case to determine that we can determine it or not. We can't always 
say whether or not we can say whether two pieces of two types alias.
Our C++ ABI may or may not allow us to do it, since it gives us some, 
possibly all, of the information  the C++ standard leaves to 
implementations.
I'm not going to spend time trying to formally prove it one way or the 
other.

Which brings us back to the reason i suggested we improve it for a 
restricted subset of C++ classes that we already handle properly for C.

--Dan

  reply	other threads:[~2002-01-25 15:51 UTC|newest]

Thread overview: 97+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-25  7:51 Robert Dewar
2002-01-25  8:18 ` Daniel Berlin [this message]
2002-01-25  8:20   ` Daniel Berlin
  -- 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: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
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
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: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.0201251039010.31319-100000@dberlin.org \
    --to=dan@dberlin.org \
    --cc=dewar@gnat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=kenner@vlsi1.ultra.nyu.edu \
    /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).