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: Fri, 09 Mar 2007 11:35:00 -0000	[thread overview]
Message-ID: <20070309113457.18845.qmail@sourceware.org> (raw)
In-Reply-To: <bug-26797-7210@http.gcc.gnu.org/bugzilla/>



------- Comment #32 from baldrick at free dot fr  2007-03-09 11:34 -------
Subject: Re:  [4.3 regression] ACATS cxh1001 fails

> Well, the only problem with V_C_E is that if you assert on the range of the
> base type like
> 
>   if (V_C_E <X'Base> (y) > 5)
>     abort();
> 
> that you still want VRP to infer that V_C_E <X'Base> (y) is <= 5 after this
> check (to eliminate further checks).

I don't think this is a very serious problem.  My understanding is that the
checks
can be divided into two classes: normal checks and validity checks.  A normal
check,
such as when you do a type conversion, does not use a V_C_E, it just does:

if (y < new_type_lb || y > new_type_ub)
        abort;
new_var = (new_type) y;

A validity check does:

if (V_C_E <X'Base> (y) < x_lb || V_C_E <X'Base> (y) > x_ub)
  abort();

Note how it checks that x is in the range of x's type, so this does not
give any new information about x.

It is true that multiple validity checks will not be eliminated (multiple
normal
checks will be eliminated), but validity checks are not that common.  One place
that might hurt is in array accesses: IIRC the front-end does a validity check
on the index before accessing an array, rather than a normal check, because it
considers it too dangerous to do otherwise (eg: they want to catch the case
when the index has an out-of-range value because it is uninitialized).

My suggested use of a builtin would allow multiple redundant validity checks
to be safely eliminated, because the builtin would be a "pure" function.  The
validity check becomes:

y2 = __builtin_nop(y);
if (y2 < x_lb || y2 > x_ub)
  abort();

Now suppose you do another one:

y22 = __builtin_nop(y);
if (y22 < x_lb || y22 > x_ub)
  abort();

The compiler can deduce that y2 and y22 are the same, and eliminate the
second check.

> I believe this will not automatically 
> happen at the moment because V_C_E <X'Base> (y) will not have the same
> ssa name assigned for evey occurance.  But of course we will never know until
> the Ada FE people finally fix their frontend.
> 
> All the mess would be way easier if the FE would not expose the subtypes to
> the middle-end...

I agree.  The LLVM model seems more sensible in this regard.

D.


-- 


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


  parent reply	other threads:[~2007-03-09 11:35 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 [this message]
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
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=20070309113457.18845.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).