public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "baldrick at free dot fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
Date: Tue, 13 Mar 2007 10:30:00 -0000	[thread overview]
Message-ID: <20070313103014.10802.qmail@sourceware.org> (raw)
In-Reply-To: <bug-26797-7210@http.gcc.gnu.org/bugzilla/>



------- Comment #42 from baldrick at free dot fr  2007-03-13 10:30 -------
Subject: Re:  [4.3 regression] ACATS cxh1001 fails

> > It is not possible for a pointer value to be uninitialized.  The language
> > requires all pointers to be default initialized to null.
> 
> I mean the thing that pointer points to!

I think I now understand: I thought the problem we were discussing was
how to obtain correctness (which seems to be easy using local checks)
while in fact you were talking about how to optimize away unnecessary
validity checks (as compared to normal checks).  My current plan for
that in LLVM is to implement validity checks using a builtin_nop
intrinsic.  Multiple successive validity checks will be eliminated
as redundant because builtin_nop is a pure function.  That leaves
the question of how to teach the optimizers that an object is valid
in the various cases where the front-end for some reason knows this.
In such cases I'm thinking that you can issue an assert instruction
saying so, eg if type T has range 10..20 and at some point the front-end
knows that x (of type T) is valid, it can issue:
        assert(builtin_nop(x)>=10 && builtin_nop(x)<=20);
The dataflow and predicate analysis needed to exploit this can hopefully
be left to the optimizers, in particular to IPO (which LLVM is rather
good at).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797


  parent reply	other threads:[~2007-03-13 10:30 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-22  7:29 [Bug ada/26797] New: [4.2 Regression] ACATS c35507m cd2a23e cxh1001 wrong code laurent at guerby dot net
2006-03-22 10:33 ` [Bug ada/26797] " ebotcazou at gcc dot gnu dot org
2006-03-22 18:48 ` [Bug ada/26797] [4.2 Regression] ACATS c35507m cd2a23e cxh1001 failures ebotcazou at gcc dot gnu dot org
2006-03-22 21:08 ` pinskia at gcc dot gnu dot org
2006-03-23 13:19 ` [Bug tree-optimization/26797] " baldrick at free dot fr
2006-03-27 17:09 ` law at redhat dot com
2006-03-27 17:23 ` law at redhat dot com
2006-03-27 20:12 ` laurent at guerby dot net
2006-03-27 20:31 ` law at redhat dot com
2006-03-28  3:56 ` kenner at vlsi1 dot ultra dot nyu dot edu
2006-03-28 15:01 ` law at redhat dot com
2006-03-28 15:33 ` law at redhat dot com
2006-03-30  7:58 ` ebotcazou at gcc dot gnu dot org
2006-03-30  8:25 ` ebotcazou at gcc dot gnu dot org
2006-03-30  8:32 ` ebotcazou at gcc dot gnu dot org
2006-03-30 12:13 ` kenner at vlsi1 dot ultra dot nyu dot edu
2006-04-21 23:40 ` [Bug tree-optimization/26797] [4.2 Regression] ACATS c35507m cd2a23e cxh1001 fail pinskia at gcc dot gnu dot org
2006-04-21 23:41 ` pinskia at gcc dot gnu dot org
2006-04-21 23:41 ` pinskia at gcc dot gnu dot org
2006-06-04  8:27 ` christian dot joensson at gmail dot com
2006-06-04 18:19 ` mmitchel at gcc dot gnu dot org
2006-06-26 23:41 ` laurent at guerby dot net
2006-06-27  3:05 ` kenner at vlsi1 dot ultra dot nyu dot edu
2006-10-29 23:17 ` [Bug ada/26797] [4.2/4.3 regression] " ebotcazou at gcc dot gnu dot org
2006-10-30  9:04 ` law at redhat dot com
2006-10-30  9:21 ` ebotcazou at gcc dot gnu dot org
2007-03-04 10:06 ` ebotcazou at gcc dot gnu dot org
2007-03-04 10:08 ` [Bug ada/26797] [4.3 regression] ACATS " ebotcazou at gcc dot gnu dot org
2007-03-08  9:57 ` [Bug ada/26797] [4.3 regression] ACATS cxh1001 fails baldrick at gcc dot gnu dot org
2007-03-08 12:54 ` kenner at vlsi1 dot ultra dot nyu dot edu
2007-03-08 16:06 ` baldrick at free dot fr
2007-03-08 16:52 ` kenner at vlsi1 dot ultra dot nyu dot edu
2007-03-09 10:41 ` baldrick at free dot fr
2007-03-09 11:11 ` rguenth at gcc dot gnu dot org
2007-03-09 11:19 ` ebotcazou at gcc dot gnu dot org
2007-03-09 11:35 ` baldrick at free dot fr
2007-03-09 11:50 ` baldrick at free dot fr
2007-03-09 13:59 ` kenner at vlsi1 dot ultra dot nyu dot edu
2007-03-09 14:19 ` kenner at vlsi1 dot ultra dot nyu dot edu
2007-03-09 14:29 ` kenner at vlsi1 dot ultra dot nyu dot edu
2007-03-09 22:44 ` baldrick at free dot fr
2007-03-09 23:10 ` baldrick at free dot fr
2007-03-09 23:13 ` kenner at vlsi1 dot ultra dot nyu dot edu
2007-03-09 23:41 ` baldrick at free dot fr
2007-03-10  0:17 ` kenner at vlsi1 dot ultra dot nyu dot edu
2007-03-10 16:52 ` ebotcazou at gcc dot gnu dot org
2007-03-13 10:30 ` baldrick at free dot fr [this message]
2007-03-13 12:34 ` kenner at vlsi1 dot ultra dot nyu dot edu
2007-09-12 15:53 ` ebotcazou at gcc dot gnu dot org
2007-09-12 15:55 ` ebotcazou at gcc dot gnu dot org
2007-09-15  6:35 ` law at redhat dot com

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=20070313103014.10802.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).