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
next prev 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: linkBe 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).