--- Comment #74 from charlet at gcc dot gnu dot org 2009-11-17 17:03
---
Marking as WONTFIX, as requested
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #73 from baldrick at free dot fr 2009-11-17 16:56 ---
Can someone please close this bug as WONTFIX then (I don't know how to do
this myself).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
--- Comment #72 from charlet at adacore dot com 2009-11-17 15:50 ---
Subject: Re: VRP fails to eliminate range
checks in Ada code
> > Is there anyway for the optimizers to get at this range information still?
> > Or was range information removed because it is essentially imposs
> > Is there anyway for the optimizers to get at this range information still?
> > Or was range information removed because it is essentially impossible to use
> > it correctly (if so this bug report should be closed as unfixable)?
>
> It was removed because it was impossible to use it correctly.
--- Comment #71 from rguenther at suse dot de 2009-11-17 15:07 ---
Subject: Re: VRP fails to eliminate range checks
in Ada code
On Tue, 17 Nov 2009, baldrick at free dot fr wrote:
> --- Comment #69 from baldrick at free dot fr 2009-11-17 11:04 ---
> It seems that variables p
--- Comment #70 from ebotcazou at gcc dot gnu dot org 2009-11-17 11:19
---
> It seems that variables produced by the Ada front-end no longer have any
> non-trivial range information associated with them. Without knowing the
> range information
>type S is range 0 .. 100;
>type T
--- Comment #69 from baldrick at free dot fr 2009-11-17 11:04 ---
It seems that variables produced by the Ada front-end no longer have any
non-trivial range information associated with them. Without knowing the
range information
type S is range 0 .. 100;
type T is range 10 .. 20;
--- Comment #68 from rguenth at gcc dot gnu dot org 2008-04-03 19:52
---
I am no longer working on specifically this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #67 from baldrick at free dot fr 2008-03-30 17:03 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
> Try first to compile it. :-)
I did! I didn't notice the compile error
after the -gnatG output. Indeed, when fixed
thusly
procedure Overflow (X : Positive
--- Comment #66 from ebotcazou at gcc dot gnu dot org 2008-03-30 16:18
---
> Consider the following test case:
>
> procedure Overflow (X : Positive) return Integer is
>A : array (Positive) of Integer;
>pragma Import (Ada, A);
> begin
>A (X) := X;
> end;
>
> (for which no c
--- Comment #65 from ebotcazou at gcc dot gnu dot org 2008-03-30 16:15
---
> So even GNAT assumes parameter values are in-range? Wouldn't that
> cause an bounded error to become an unbounded error if it were
> out-of-range?
GNAT considers that it's an unbounded error in a few specific
--- Comment #64 from baldrick at free dot fr 2008-03-30 16:02 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
> > But there are no checks on the array access. It looks like the f-e
> > doesn't generate them in the first place (as opposed to fold or gigi
> > making a m
--- Comment #63 from rguenther at suse dot de 2008-03-30 15:56 ---
Subject: Re: VRP fails to eliminate range checks
in Ada code
On Sun, 30 Mar 2008, ebotcazou at gcc dot gnu dot org wrote:
> --- Comment #62 from ebotcazou at gcc dot gnu dot org 2008-03-30 15:45
> ---
> > Ye
--- Comment #62 from ebotcazou at gcc dot gnu dot org 2008-03-30 15:45
---
> Yes, even with -gnato. With -gnato it checks that the
> addition doesn't overflow.
Oh, sorry, I thought we were talking about the overflow check...
> But there are no checks on the array access. It looks li
--- Comment #61 from baldrick at free dot fr 2008-03-30 15:16 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
> > And here's a testcase that was supposed to check that
> > VRP is not removing checks that array accesses are in
> > range. Instead it shows that the Ada f
--- Comment #60 from rguenth at gcc dot gnu dot org 2008-03-30 15:09
---
function overflow (x : positive) return integer is
y : positive;
a : static array (1 .. 16#7FFF_#) of integer;
pragma import (ada, a);
begin
R4b : constant long_long_integer := long_long_integer?(a
--- Comment #59 from ebotcazou at gcc dot gnu dot org 2008-03-30 15:03
---
> And here's a testcase that was supposed to check that
> VRP is not removing checks that array accesses are in
> range. Instead it shows that the Ada f-e is failing
> to generate checks at all!
Even with -gnat
--- Comment #58 from rguenth at gcc dot gnu dot org 2008-03-30 14:55
---
Btw, can we have those testcases in gnat.dg/ with a name I can remember
(bounds-N.adb or similar)? Looking for testcases in acats is no fun ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
--- Comment #57 from rguenther at suse dot de 2008-03-30 14:52 ---
Subject: Re: VRP fails to eliminate range checks
in Ada code
On Sun, 30 Mar 2008, baldrick at gcc dot gnu dot org wrote:
> --- Comment #55 from baldrick at gcc dot gnu dot org 2008-03-30 14:18
> ---
> And he
--- Comment #56 from baldrick at free dot fr 2008-03-30 14:26 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
> > What does "must be in the range" mean? Firstly, the program behaviour is
> > undefined if a variable is outside its range.
>
> That's not true. The refe
--- Comment #55 from baldrick at gcc dot gnu dot org 2008-03-30 14:18
---
And here's a testcase that was supposed to check that
VRP is not removing checks that array accesses are in
range. Instead it shows that the Ada f-e is failing
to generate checks at all!
function Overflow (X : P
--- Comment #54 from baldrick at gcc dot gnu dot org 2008-03-30 14:14
---
Here's a test that VRP is not eliminating
validity checks. "abort" should be called
if either X or Y is <= 0. With Richard's
latest patch (from the gcc mailing list)
applied, everything is fine: the tests are
st
--- Comment #53 from ebotcazou at gcc dot gnu dot org 2008-03-30 09:15
---
I should have been more careful, there are wrong premises:
> Yes. Amazing, isn't it ;) The important thing to keep in mind is that
> all "target" variables must be in the range 10..20, and all "source"
> varia
--- Comment #52 from rguenth at gcc dot gnu dot org 2008-03-28 22:58
---
I'm now testing a variant of the patch that fixes fold_sign_changed_comparison
and just initializes incoming parameter value-ranges based on their types.
This seems to do the same range-check removals and looks lik
--- Comment #51 from baldrick at free dot fr 2008-03-28 22:48 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
> This is fold simplifying (js__TtB) target_first == -128 to
> target_first == 128 via fold_sign_changed_comparison.
Right, that was my instant guess. The Ad
--- Comment #50 from baldrick at free dot fr 2008-03-28 22:42 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
> T' sub;
> T x;
>
> x = sub; (1)
> sub = (T')x; (2)
> x = VIEW_CONVERT_EXPR (sub); (3)
>
> where VRP for the simple copy (1) does not rest
--- Comment #49 from rguenth at gcc dot gnu dot org 2008-03-28 22:35
---
As of
"The TYPE_MIN/MAX_VALUEs
are of the type of the base type, so target_first_66s value range is
[10, 20] at the point of this comparison. Is this supposed to be
a comparison with -128 or with 128? That is, i
--- Comment #48 from rguenth at gcc dot gnu dot org 2008-03-28 22:14
---
Created an attachment (id=15394)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15394&action=view)
patch for comment #47
This is what I was playing with.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30
--- Comment #47 from rguenth at gcc dot gnu dot org 2008-03-28 22:12
---
What is interesting is that j__target_type___XDLU_10__20 is a unsigned sub type
with range [10, 20] of a signed base type with range [-128, 127]. So, we
enter compare_values ((js__TtB)20, (j__target_type___XDLU_10
--- Comment #46 from rguenth at gcc dot gnu dot org 2008-03-28 19:18
---
Ok, I didn't really expect that ;)
Some new background information. With the middle-end type-system work we now
omit conversions from sub-types T' to their base-types T. Thus we have
the three cases
T' sub;
--- Comment #45 from baldrick at gcc dot gnu dot org 2008-03-28 14:58
---
The recent VRP improvements made no difference to this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
--- Comment #44 from rguenth at gcc dot gnu dot org 2008-03-28 12:21
---
Subject: Bug 30911
Author: rguenth
Date: Fri Mar 28 12:20:09 2008
New Revision: 133680
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133680
Log:
2008-03-28 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #43 from rguenth at gcc dot gnu dot org 2007-03-02 09:53
---
I agree. Let's create another bug for this issue. PR31023.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #42 from baldrick at free dot fr 2007-03-02 09:16 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
> Thaks for the detective work! I sort of expected the fold patch to be weird
> or
> have no effect - but it was needed only (for the testcase) to get rid of
--- Comment #41 from rguenth at gcc dot gnu dot org 2007-03-02 09:02
---
Thaks for the detective work! I sort of expected the fold patch to be weird or
have no effect - but it was needed only (for the testcase) to get rid of the
target_first == 128 comparison, as that is confusing VRP.
--- Comment #40 from baldrick at free dot fr 2007-03-01 23:07 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
The problem is in this transformation:
/* Fold (X & C) op (Y & C) as (X ^ Y) & C op 0", and symmetries. */
X^Y may not be in the range of the type. I
--- Comment #39 from rguenth at gcc dot gnu dot org 2007-03-01 09:50
---
One key point to notice is that the transformation looks at ARG0 op CST where
arg0 and cst don't necessarily have to have the same type (arg0 is reduced from
op0 by STRIP_SIGN_NOPS), so effectively this folds
(B
--- Comment #38 from baldrick at free dot fr 2007-03-01 08:18 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
> ... The problem
> is that the value of arg1, a constant, is not in the
> range of its own type! ...
It seemed clear to me last night why this is a problem,
--- Comment #37 from baldrick at free dot fr 2007-02-28 23:30 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
> With bootstrapping the compiler and then checking you get
>
> FAIL: c35507j
> FAIL: cd92001
> FAIL: cxh1001
I get a slightly different set (i486-linu
--- Comment #36 from charlet at adacore dot com 2007-02-24 12:47 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
> I was talking about the rts that get's used if I configure with
> --disable-bootstrap, do a make and then run make check-ada from within the
> gcc/ subdir
> I was talking about the rts that get's used if I configure with
> --disable-bootstrap, do a make and then run make check-ada from within the
> gcc/ subdirectory. As far as I understand that rts seems to be built using
> the bootstrap compiler. At least this would explain the difference in the
>
--- Comment #35 from rguenth at gcc dot gnu dot org 2007-02-24 12:38
---
I was talking about the rts that get's used if I configure with
--disable-bootstrap, do a make and then run make check-ada from within the
gcc/ subdirectory. As far as I understand that rts seems to be built using
--- Comment #34 from charlet at adacore dot com 2007-02-24 12:32 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
> > we have a disconnect between the redundant checks in the rts and the
> > testcases. If it happens that the non-bootstrapped rts is built by the
> > hos
> > we have a disconnect between the redundant checks in the rts and the
> > testcases. If it happens that the non-bootstrapped rts is built by the
> > host compiler(?).
>
> No, that never happens. The rts is always built with the latest (stage3)
> compiler. Otherwise it would not even begin to w
--- Comment #33 from charlet at adacore dot com 2007-02-24 10:12 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
> I guess that nearly all range checks are eliminated and without bootstrapping
> we have a disconnect between the redundant checks in the rts and the
> tes
> I guess that nearly all range checks are eliminated and without bootstrapping
> we have a disconnect between the redundant checks in the rts and the
> testcases. If it happens that the non-bootstrapped rts is built by the
> host compiler(?).
No, that never happens. The rts is always built with
--- Comment #32 from rguenth at gcc dot gnu dot org 2007-02-23 22:40
---
Created an attachment (id=13103)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13103&action=view)
patch
Bah - now with the errors fixed. Bootstraps ok, some of acats regresses.
If you disable bootstrap and
--- Comment #31 from rguenth at gcc dot gnu dot org 2007-02-23 20:18
---
Created an attachment (id=13102)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13102&action=view)
patch
updated patch
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #30 from rguenth at gcc dot gnu dot org 2007-02-23 17:32
---
Ok, I have too little Ada skills ;) What is missing in the following?
with test;
package test is
type Count is range 0 .. Natural'Last;
subtype Positive_Count is Count range 1 .. Count'Last;
procedure Set
--- Comment #29 from baldrick at free dot fr 2007-02-23 17:09 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
> BTW, this is not a bug, but a possible enhancement, and a very tricky one at
> that, since removing too many checks will hurt much more Ada programmers than
--- Comment #28 from rguenth at gcc dot gnu dot org 2007-02-23 16:11
---
Got it compiling now with -gnatpg -- my tree was probably too old and messed
up, rebuilding everything helped. Now we indeed fold "not To'Valid" to 1 ;)
Unfolded
it looks like
if (to == 0 || (SIGNED_32) to <
--- Comment #27 from charlet at gcc dot gnu dot org 2007-02-23 16:05
---
BTW, this is not a bug, but a possible enhancement, and a very tricky one at
that, since removing too many checks will hurt much more Ada programmers than
having too many, so let's please be extra careful here.
Ar
--- Comment #26 from baldrick at free dot fr 2007-02-23 16:01 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
> Of course in this case I would have expected VRP or whatever to optimize away
>
> if not To'Valid then
> raise Constraint_Error;
> end if
--- Comment #25 from baldrick at free dot fr 2007-02-23 15:59 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
There seems to be an additional C testsuite failure: loadpre1.c
Also, some of the acats failures look interesting, for example
the first one c34004a is showin
--- Comment #24 from rguenth at gcc dot gnu dot org 2007-02-23 15:55
---
Of course in this case I would have expected VRP or whatever to optimize away
if not To'Valid then
raise Constraint_Error;
end if;
but it looks it is now an unconditional
raise Constraint
--- Comment #23 from baldrick at free dot fr 2007-02-23 15:40 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
> if not To'Valid then
I'm pretty sure that this is an example of PR26797:
the front-end should generate 'Valid by doing a
VIEW_CONVERT_EXPR of To to it
--- Comment #22 from rguenth at gcc dot gnu dot org 2007-02-23 15:15
---
Ok, I get lot's of acats failures with the patch, all of the form
RUN a22006d
raised CONSTRAINT_ERROR : a-textio.adb:1339 explicit raise
FAIL: a22006d
which is from
procedure Set_Col
(File : File_Typ
--- Comment #21 from rguenth at gcc dot gnu dot org 2007-02-23 14:05
---
Yep, INTEGRAL_TYPE_P is better. the u!=0 case might be why I tried to preserve
~[0,0] for unsigneds... maybe we have some failing testcases with ranges for
range_is_nonnull, which only checks
static inline bool
r
--- Comment #20 from baldrick at free dot fr 2007-02-23 13:04 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
> !POINTER_TYPE_P
I'm testing with INTEGRAL_TYPE_P.
By the way, I see a lot a anti-range canonicalization going
on in C code. A lot of code where u is of a
--- Comment #19 from rguenth at gcc dot gnu dot org 2007-02-23 12:41
---
Yeah, the fold-const.c chunk misses
+ /* We can compare x OP cst based on the value range of the type of
+ x. */
+ if (TREE_CODE (arg1) == INTEGER_CST
+ && TREE_CODE (arg0) != INTEGER_CST
+ &
--- Comment #18 from baldrick at free dot fr 2007-02-23 12:36 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
> The attached patch removes all checks (from the first half of the testcase).
Thanks for the patch!
> + Make sure to preserve ~[a, a] (FIXME: why?) an
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-02-23 11:42
---
This also depends on PR30317 as we have for example
:;
source.4_29 = (js__TsB) source_4;
R5b_30 = source.4_29 + 1;
R5b.5_31 = (UNSIGNED_8) R5b_30;
if (R5b.5_31 > 100) goto ; else goto ;
--
rguenth at g
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-02-23 11:37
---
Created an attachment (id=13096)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13096&action=view)
patch fixing the problem
The attached patch removes all checks (from the first half of the testcase).
Not
ye
--- Comment #15 from baldrick at free dot fr 2007-02-23 10:03 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
On Friday 23 February 2007 10:22:15 rguenth at gcc dot gnu dot org wrote:
>
> --- Comment #13 from rguenth at gcc dot gnu dot org 2007-02-23 09:22
> ---
--- Comment #14 from baldrick at free dot fr 2007-02-23 09:39 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
On Friday 23 February 2007 06:50:48 ebotcazou at gcc dot gnu dot org wrote:
>
> --- Comment #12 from ebotcazou at gcc dot gnu dot org 2007-02-23 05:50
>
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-02-23 09:22
---
In reply to comment #8
To understand the issues a little bit more -- are there any requirements on
overflow behavior of the _base_ type? Suppose a type T with range -100..120
has indeed be assigned a signed char
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2007-02-23 05:50
---
> Sorry about that - it wasn't on purpose: your comment
> and mine collided. I actually checked the two bugs
> after getting the message that I'd manage to wipe out
> your change, and the relationship between 26
--- Comment #11 from baldrick at gcc dot gnu dot org 2007-02-22 22:54
---
> Please do not overwrite changes, thanks.
Sorry about that - it wasn't on purpose: your comment
and mine collided. I actually checked the two bugs
after getting the message that I'd manage to wipe out
your chan
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2007-02-22 18:19
---
Please do not overwrite changes, thanks.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from baldrick at gcc dot gnu dot org 2007-02-22 18:18
---
(In reply to comment #7)
> > Do not work too hard on this, there is code in the AdaCore tree to disable
> > VRP in more cases, lest language-mandated checks are erroneously removed.
>
> For example PR ada/26797.
--- Comment #8 from baldrick at gcc dot gnu dot org 2007-02-22 18:14
---
> Can you walk me through some of the checks and why they can be removed? I see
> (.004.gimple dump):
...
> I assume all of the above is gimplified from just
>
>if Source_Last < Source_First then
> if T
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2007-02-22 18:00
---
> Do not work too hard on this, there is code in the AdaCore tree to disable
> VRP in more cases, lest language-mandated checks are erroneously removed.
For example PR ada/26797.
--
ebotcazou at gcc dot gnu d
--- Comment #6 from baldrick at gcc dot gnu dot org 2007-02-22 17:41
---
> Bonus points if you can reduce this to a C test case ;-)
> Starting with the gimple dumps, this is usually not hard to do.
It can't be reduced because it relies on integer types with restricted ranges,
i.e. TYPE
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-02-22 17:33
---
Do not work too hard on this, there is code in the AdaCore tree to disable
VRP in more cases, lest language-mandated checks are erroneously removed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-02-22 17:04 ---
Can you walk me through some of the checks and why they can be removed? I see
(.004.gimple dump):
source = source_first;
target = target_first;
source_last.0 = (js__TsB) source_last;
source_first.1
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-02-21 18:01
---
> Bonus points if you can reduce this to a C test case ;-)
> Starting with the gimple dumps, this is usually not hard to do.
Not everything is in the dumps, in particular you don't have subtypes in C.
--
ebot
--- Comment #2 from steven at gcc dot gnu dot org 2007-02-21 17:55 ---
Bonus points if you can reduce this to a C test case ;-)
Starting with the gimple dumps, this is usually not hard to do.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
--- Comment #1 from baldrick at gcc dot gnu dot org 2007-02-21 15:17
---
I've tried and failed to attach the source code (bugzilla problem), so here it
is inline (you can extract it using gnatchop):
with Join_Equal;
with JS;
procedure J is new Join_Equal (
Source_Type => JS.S,
Equa
78 matches
Mail list logo
