Howdy.
There's really no reason why the array bounds code should live in
tree-vrp, when all it really needs is a get_value_range() call back.
Particularly painful is that it partially lives inside the vrp_prop class.
This patch moves the array bounds code into its own class, while taking
in
Whoops, I seem to have a discrepancy in my local tree and upstream.
I've reverted this patch.
Aldy
On 5/17/20 1:50 PM, Aldy Hernandez wrote:
There's no reason to export operand_less_p from tree-vrp when its only
use is in vr-values.c. Function moved.
Committed as obvious.
Aldy
Missed this on the previous patch. The method live_on_edge() no
longer needs to be inside the vrp_insert class. I've removed the
prototype.
Committed to mainline.
On Sun, May 17, 2020 at 1:35 PM Aldy Hernandez wrote:
>
> Funny, I had queued up more or less the same changes on my tree, but
>
There's no reason to export operand_less_p from tree-vrp when its only
use is in vr-values.c. Function moved.
Committed as obvious.
Aldy
commit 8bfc81876f9325891a52d036a9c454d0c81b3033
Author: Aldy Hernandez
Date: Fri May 8 13:36:32 2020 +0200
Move operand_less_p to vr-values.c.
diff
Funny, I had queued up more or less the same changes on my tree, but
Giuliano beat me to it.
I am committing the attached patch that has been approved by Jeff.
I moved a couple more functions into the vrp_insert class, as well as
abstract out the liveness bitmap into its own class. I also
As a follow-up to the patch moving array bounds checking into its own
class, this moves the class into its own files. As I've mentioned
previously, having it in tree-vrp just pollutes the file with unrelated
stuff.
Jeff, I know you've mentioned you'd like to move the array bounds
checking
We already moved the value_range class into its own class in the last
release. I think it's time to move the value_range_equiv stuff into its
own class, as it's a distraction from the VRP code.
I've moved it to value-range-equiv.*, and gave it a semblance of order,
by putting the
Howdy.
The main evrp domwalker seems cut and pasted from the
substitute_and_fold_engine (or was it the other way around?). Albeit,
there are a few things that evrp does, like set up ranges, but these can
be set up with virtuals, and thus provide a general repository to do all
things subst
As discussed in the PR, the type of a switch operand may be different
than the type of the individual cases. This is causing us to attempt to
intersect incompatible ranges.
This inconsistent IL seems wrong to me, but it also seems pervasive
throughout GCC. Jason, as one of the original
On 8/31/20 10:33 AM, Richard Biener wrote:
On Mon, Aug 31, 2020 at 10:20 AM Aldy Hernandez wrote:
As discussed in the PR, the type of a switch operand may be different
than the type of the individual cases. This is causing us to attempt to
intersect incompatible ranges.
This inconsistent
This is the same issue as PR96818. It's another intersect that's
missing a cast in the same function. I missed it in the previous PR.
Pushed as obvious.
PR tree-optimization/96967
* tree-vrp.c (find_case_label_range): Cast label range to
type of switch operand.
---
This fixes an ICE when trying to copy a legacy value_range containing a
symbolic to a multi-range:
min = make_ssa_name (type);
max = build_int_cst (type, 55);
value_range vv (min, max);
int_range<2> vr = vv;
This doesn't affect anything currently, as we don't
template
class GTY((user)) int_range : public irange
{
so people can use
int_range x;
and get the max range by default?
Indeed, I had forgotten about default template arguments, the only
problem is
int_range x;
is valid in c++17, but previous to that we have to do
int_range<> x;
Its a
On 8/31/20 2:55 PM, Richard Biener wrote:
On Mon, Aug 31, 2020 at 11:10 AM Aldy Hernandez wrote:
On 8/31/20 10:33 AM, Richard Biener wrote:
On Mon, Aug 31, 2020 at 10:20 AM Aldy Hernandez wrote:
As discussed in the PR, the type of a switch operand may be different
than the type of
This should have been included in the irange_allocator patch, as a
method to see if the current object can hold a passed range without
truncation.
Pushed.
gcc/ChangeLog:
* value-range.h (irange::fits_p): New.
---
gcc/value-range.h | 1 +
1 file changed, 1 insertion(+)
diff --git
On 10/2/20 2:17 AM, David Edelsohn wrote:
On Thu, Oct 1, 2020 at 8:02 PM Andrew MacLeod wrote:
Hi, Andrew
Thanks for investigating. And I definitely am not suggesting that you
delay the great progress on Ranger to flatten and compact tree-vrp.h
and ssa.h immediately.
Inclusion of any
On 10/7/20 8:10 AM, Richard Biener wrote:
> On Tue, Oct 6, 2020 at 7:06 PM Andrew MacLeod via Gcc-patches
> wrote:
>>
>> I have now checked in the hybrid EVRP pass.
>>
>> We have resolved all the issue we are aware of with a full Fedora build,
>> but if any more issues arise, please let us
On 10/8/20 2:49 PM, Jakub Jelinek wrote:
On Thu, Oct 08, 2020 at 11:46:36AM +0200, Aldy Hernandez via Gcc-patches wrote:
This was a pasto by yours truly while porting the __builtin code from
vr_values::extract_range_basic.
I've tested Andrew's patch, and pushed it.
Note for next time, I
On 10/8/20 5:08 PM, Jakub Jelinek wrote:
On Thu, Oct 08, 2020 at 04:55:07PM +0200, Aldy Hernandez via Gcc-patches wrote:
Yes, for max == 0 aka [0, 0] I wanted:
1) if mini == -1, i.e. the DEFINED_VALUE_AT_ZERO == 2 VALUE is -1, return [-1,
-1]
2) if maxi == prec, i.e. DEFINED_VALUE_AT_ZERO
On 10/8/20 3:54 PM, Jakub Jelinek wrote:
On Thu, Oct 08, 2020 at 12:22:11PM +0200, Jakub Jelinek via Gcc-patches wrote:
Perhaps another way out of this would be document and enforce that
__builtin_c[lt]z{,l,ll} etc calls are undefined at zero, but C[TL]Z ifn
calls are defined there based on
On 10/8/20 4:39 PM, Jakub Jelinek wrote:
On Thu, Oct 08, 2020 at 04:28:37PM +0200, Aldy Hernandez wrote:
On 10/8/20 3:54 PM, Jakub Jelinek wrote:
On Thu, Oct 08, 2020 at 12:22:11PM +0200, Jakub Jelinek via Gcc-patches wrote:
Perhaps another way out of this would be document and enforce
Hi Jakub.
As the last known expert in this area, would you review this, please? :)
This sets things up so we can share range handling of builtins between
vr_values and ranger. It is meant to refactor the code so that we can
verify that both implementations yield the same results.
First, we
There's a read of a freed block while accessing the default_slot in
calc_switch_ranges.
default_slot->intersect (def_range);
It seems the default_slot got swiped from under us, and the valgrind
dump indicates the free came from the get_or_insert in the same
function:
irange * =
[Neither Andrew nor I are familiar with the SCEV code. We treat it as a
black box :). So we could use a SCEV expert here.]
In bounds_of_var_in_loop, evolution_part_in_loop_num is returning NULL:
step = evolution_part_in_loop_num (chrec, loop->num);
and we ICE while trying to calculate the
On 10/13/20 6:02 PM, Richard Biener wrote:
On October 13, 2020 5:17:48 PM GMT+02:00, Aldy Hernandez via Gcc-patches
wrote:
[Neither Andrew nor I are familiar with the SCEV code. We treat it as
a
black box :). So we could use a SCEV expert here.]
In bounds_of_var_in_loop
On 10/6/20 9:52 AM, Jakub Jelinek wrote:
On Tue, Oct 06, 2020 at 09:37:21AM +0200, Aldy Hernandez via Gcc-patches wrote:
Pushed as obvious.
gcc/ChangeLog:
* value-range.h (irange_allocator::allocate): Increase
newir storage by one.
---
gcc/value-range.h | 2 +-
1 file
- builtin_memref dstref (dst, dstsize);
- builtin_memref srcref (src, srcsize);
+ builtin_memref dstref (query, call, dst, dstsize);
+ builtin_memref srcref (query, call, src, srcsize);
/* Create a descriptor of the access. This may adjust both DSTREF
and SRCREF based on one
On 10/5/20 7:12 PM, Martin Sebor wrote:
It the future, I would even like to remove the specific range the
ranger was able to compute from the error message itself. As will
become obvious, the ranger can get pretty outrageous ranges that are
entirely non-obvious by looking at the code.
Pushed as obvious.
gcc/ChangeLog:
* value-range.h (irange_allocator::allocate): Increase
newir storage by one.
---
gcc/value-range.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/value-range.h b/gcc/value-range.h
index 94b48e55e77..7031a823138 100644
On 10/6/20 4:51 PM, Martin Sebor wrote:
On 10/6/20 8:42 AM, Andrew MacLeod wrote:
On 10/6/20 10:30 AM, Martin Sebor wrote:
On 10/6/20 3:45 AM, Aldy Hernandez wrote:
- builtin_memref dstref (dst, dstsize);
- builtin_memref srcref (src, srcsize);
+ builtin_memref dstref (query, call, dst,
The walloca pass is a mess. It has all sorts of heuristics to divine
problematic ranges fed into alloca, none of them very good, and all of
them unreadable. The mess therein was actually one of the original
motivators for the ranger project (along with array bounds checking).
The attached
Pushed as obvious.
gcc/ChangeLog:
PR tree-optimization/97371
* range-op.cc (operator_rshift::op1_range): Ignore shifts larger than
or equal to type precision.
gcc/testsuite/ChangeLog:
* gcc.dg/pr97371.c: New test.
---
gcc/range-op.cc| 7 +++
From: Andrew MacLeod
[posting on behalf of Andrew]
We were ignoring the return value if op2 returned false and getting garbage
ranges propagated.
Tested on x86-64 Linux.
Pushed.
gcc/ChangeLog:
PR tree-optimization/97381
* gimple-range-gori.cc
Division by zero should return VARYING, otherwise we propagate undefine all
over the
ranger and cause bad things to happen :). This fixes MOD 0 to also return
VARYING.
This is Andrew's patch. I forgot to use --author for proper patch
attribution.
Tested on x86-64 Linux.
Pushed to trunk.
If the shift amount in operator_lshift::op1_range was zero, an invalid range
of [1, 0] was being created.
Pushed.
gcc/ChangeLog:
PR tree-optimization/97467
* range-op.cc (operator_lshift::op1_range): Handle shifts by 0.
gcc/testsuite/ChangeLog:
* gcc.dg/pr97467.c: New
Forwarded Message
Subject: [PATCH] Refactor range handling of builtins in vr_values and
ranger.
Date: Fri, 9 Oct 2020 14:32:05 +0200
From: Aldy Hernandez
To: GCC patches , Jakub Jelinek
CC: Andrew MacLeod , Aldy Hernandez
Hi Jakub.
As the last known expert in this
On Mon, Oct 19, 2020 at 12:44 PM Jakub Jelinek wrote:
>
> On Mon, Oct 19, 2020 at 12:36:24PM +0200, Aldy Hernandez via Gcc-patches
> wrote:
> > The test is trying to shift by 129, but the underlying type is 128 bits.
> > This causes low_bits to wrap around to -1 and
On 10/19/20 1:01 PM, Jakub Jelinek wrote:
On Mon, Oct 19, 2020 at 12:55:38PM +0200, Aldy Hernandez wrote:
Shifts are undefined already when the shift count is equal to the precision.
And arbitrarily choosing one of the values as the shift count seems risky to
me (and even when used, the most
The test is trying to shift by 129, but the underlying type is 128 bits.
This causes low_bits to wrap around to -1 and things go bad really
quick.
Attached is my proposed solution.
Andrew, do you have a preference on how to fix this?
gcc/ChangeLog:
PR tree-optimization/97488
*
__int128 does not exist on 32-bit targets.
Pushed.
gcc/testsuite/ChangeLog:
* gcc.dg/pr97488.c: Add target int128 predicate.
---
gcc/testsuite/gcc.dg/pr97488.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/pr97488.c
On 10/19/20 4:22 PM, Jakub Jelinek wrote:
On Mon, Oct 19, 2020 at 10:19:48AM -0400, Andrew MacLeod via Gcc-patches wrote:
On 10/19/20 5:38 AM, Aldy Hernandez wrote:
If the shift amount in operator_lshift::op1_range was zero, an invalid range
of [1, 0] was being created.
Should we do the
Rebased on current trunk.
There is one adjustment to a C++ test which now gives a false positive.
After talking with Martin Sebor, we've concluded this is expected. There
is no way to communicate that libstdc++ allocated objects are always
less than PTRDIFF_MAX.
OK?
gcc/ChangeLog:
copy_legacy_range was a small but complex function. It was tricky
to understand, and easy to introduce bugs into it. It also did
unnecessary work on some code paths.
This patch splits the function into two functions that are more
efficient and easier to read (copy_to_legacy and
logical_stmt_cache::cacheable_p() returns true for relops, but
logical_combine (which does the caching) doesn't handle them and ICEs.
This patch fixes the inconsistency by returning false for relops.
This was working before because even though logical_combine doesn't
handle relops, statements
OK for trunk?
gcc/testsuite/ChangeLog:
PR testsuite/97337
* gcc.dg/pr97315-1.c: Moved to...
* g++.dg/opt/pr97315-1.C: ...here.
---
gcc/testsuite/{gcc.dg/pr97315-1.c => g++.dg/opt/pr97315-1.C} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename
As discussed in the PR, this fixes the range-ops cast code to handle
casts where the precision of the RHS is only 1 greater than the precision
of the LHS.
This is actually Andrew's patch.
Tested on x86-64 Linux.
Pushed.
gcc/ChangeLog:
PR tree-optimization/97317
* range-op.cc
[Martin, as the original author of this pass, do you have any concerns?]
This patch converts the -Wrestrict pass to use an on-demand ranger
instead of global ranges.
No effort was made to convert value_range's into multi-ranges.
Basically, the places that were using value_range's, and
This fixes the first testcase in the PR by removing the trap and instead
annotating the listing.
I've tested Andrew's patch and pushed it.
Aldy
Fix PR97315 (part 1 of 2)
gcc/ChangeLog:
PR tree-optimization/97315
* gimple-ssa-evrp.c
This fixes the second testcase in the PR.
I've tested Andrew's patch and pushed it.
Aldy
gcc/ChangeLog:
PR tree-optimization/97315
* range-op.cc (value_range_with_overflow): Change any
non-overflow calculation in which both bounds are
I am quoting my analysis from the PR. Could an aarch64 expert
pontificate here?
This test is checking the final assembly for a specific sequence. I
don't speak aarch64 assembly, but the IL is different coming out of evrp.
The first culprit is this difference in the mergephi1 dump:
_9 =
This was a pasto by yours truly while porting the __builtin code from
vr_values::extract_range_basic.
I've tested Andrew's patch, and pushed it.
Aldy
gcc/ChangeLog:
PR tree-optimization/97325
* gimple-range.cc (gimple_ranger::range_of_builtin_call):
Handle
This patch imports three fixes from the ranger branch:
1. Fold division by zero into varying instead of undefined.
This provides compatibility with existing stuff on trunk.
2. Solver changes for lshift and rshift.
This should not affect anything on trunk, as it only involves
the GORI solver
And now with changelog entry :).
gcc/ChangeLog:
* range-op.cc (operator_div::wi_fold): Return varying for
division by zero.
(class operator_rshift): Move class up.
(operator_abs::wi_fold): Return [-MIN,-MIN] for ABS([-MIN,-MIN]).
(operator_tests): Adjust
More changes from the ranger branch that been tested and retested,
including a full Fedora build.
These are cleanups so that multi-range union/intersect doesn't have to
deal with legacy code. Instead, these should be done in legacy mode.
OK pending new tests against trunk?
gcc/ChangeLog:
On 10/14/20 9:43 AM, Richard Biener wrote:
On Tue, Oct 13, 2020 at 6:12 PM Aldy Hernandez wrote:
On 10/13/20 6:02 PM, Richard Biener wrote:
On October 13, 2020 5:17:48 PM GMT+02:00, Aldy Hernandez via Gcc-patches
wrote:
[Neither Andrew nor I are familiar with the SCEV code. We treat
, Aldy Hernandez via Gcc-patches
wrote:
[Neither Andrew nor I are familiar with the SCEV code. We treat it as
a
black box :). So we could use a SCEV expert here.]
In bounds_of_var_in_loop, evolution_part_in_loop_num is returning NULL:
step = evolution_part_in_loop_num (chrec, loop->
Rebased on current trunk.
FWIW, we finally get rid of the Walloca-6.c XFAIL. This has been a long time
in coming:
-/* { dg-xfail-if "Currently broken but Andrew's work should fix this" { *-*-*
} } */
:-)
OK?
Aldy
gcc/ChangeLog:
* gimple-ssa-warn-alloca.c (enum alloca_type):
Attached is another revision of this patch with the new helper
function you suggested. Is this version okay to commit?
I don't actually have the ability to grant check-in in this area. I
just figured that implementing some of these suggestions might make it
more palatable to reviewers who
And here's the patch without the sanity check.
Aldy
diff --git a/gcc/vr-values.c b/gcc/vr-values.c
index fe51a6faeb8..9b21441dff3 100644
--- a/gcc/vr-values.c
+++ b/gcc/vr-values.c
@@ -1006,7 +1006,7 @@ vr_values::extract_range_from_comparison (value_range_equiv *vr,
overflow. */
static
On 8/17/20 5:59 PM, Andrew MacLeod wrote:
On 8/17/20 6:04 AM, Aldy Hernandez wrote:
On 8/14/20 7:16 PM, Andrew MacLeod wrote:
On 8/14/20 12:05 PM, Aldy Hernandez wrote:
I made some minor changes to the function comments.
gcc/ChangeLog:
* vr-values.c (check_for_binary_op_overflow):
First, didn't Marek say in the PR that the diagnostic code should go in
diagnose_mismatched_attributes?
An overall comment-- could we write a generic validator rather than
having to special case validation on a case by case basis?
Is there way of marking attributes as immutable if specified
PING * 2
On 8/11/20 1:56 PM, Aldy Hernandez wrote:
-- Forwarded message -
From: *Aldy Hernandez* mailto:al...@redhat.com>>
Date: Thu, Aug 6, 2020, 16:54
Subject: [PATCH] Rewrite get_size_range for irange API.
To: mailto:gcc-patches@gcc.gnu.org>>
Cc: mailto:mse...@redhat.com>>,
PING * 2
On 8/11/20 1:55 PM, Aldy Hernandez wrote:
-- Forwarded message -
From: *Aldy Hernandez* mailto:al...@redhat.com>>
Date: Tue, Aug 4, 2020, 13:34
Subject: [PATCH] Adjust tree-ssa-strlen.c for irange API.
To: mailto:gcc-patches@gcc.gnu.org>>
Cc: mailto:l...@redhat.com>>,
On 8/21/20 1:37 AM, Martin Sebor wrote:
On 8/20/20 3:00 PM, Aldy Hernandez wrote:
Regardless, here are some random comments.
Thanks for the careful review!
diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index 37214831538..bc4f409e346 100644
---
On 8/14/20 7:16 PM, Andrew MacLeod wrote:
On 8/14/20 12:05 PM, Aldy Hernandez wrote:
I made some minor changes to the function comments.
gcc/ChangeLog:
* vr-values.c (check_for_binary_op_overflow): Change type of store
to range_query.
(vr_values::adjust_range_with_scev):
On 8/14/20 6:03 PM, Andrew MacLeod wrote:
On 8/11/20 7:53 AM, Aldy Hernandez via Gcc-patches wrote:
-- Forwarded message -
From: Aldy Hernandez
Date: Tue, Aug 4, 2020, 13:55
Subject: [PATCH 1/2] Add statement context to get_value_range.
To:
Cc: , Aldy Hernandez
On 9/25/20 3:17 PM, Andrew MacLeod wrote:
On 9/24/20 5:51 PM, Martin Sebor via Gcc-patches wrote:
On 9/18/20 12:38 PM, Aldy Hernandez via Gcc-patches wrote:
3. Conversion of sprintf/strlen pass to class.
This is a nonfunctional change to the sprintf/strlen passes. That is,
no effort
On 9/24/20 1:53 AM, Martin Sebor wrote:
Finally, unless both a type and function with the same name exist
in the same scope there is no reason to mention the class-id when
referencing a class name. I.e., this
value_range_equiv *allocate_value_range_equiv ();
void
> Thanks for doing all this! There isn't anything I don't understand
> in the sprintf changes so no questions from me (well, almost none).
> Just some comments:
Thanks for your comments on the sprintf/strlen API conversion.
>
> The current call statement is available in all functions that take
On 10/1/20 3:22 PM, Andrew MacLeod wrote:
> On 10/1/20 5:05 AM, Aldy Hernandez via Gcc-patches wrote:
>>> Thanks for doing all this! There isn't anything I don't understand
>>> in the sprintf changes so no questions from me (well, almost none).
>>> Just som
As part of the ranger work, we have been trying to clean up and
generalize interfaces whenever possible. This not only helps in
reducing the maintenance burden going forward, but provides mechanisms
for backwards compatibility between ranger and other providers/users of
ranges throughout the
Forgot to include ChangeLog entries.
Aldy
>From 49246a5aa51aff0e1beb97b8415985ffdbd5d922 Mon Sep 17 00:00:00 2001
From: Aldy Hernandez
Date: Thu, 17 Sep 2020 09:23:12 +0200
Subject: [PATCH 1/3] Initial implementation of value query class.
gcc/ChangeLog:
* Makefile.in: Add
This is the irange storage class. It is used to allocate the minimum
amount of storage needed for a given irange. Storage is automatically
freed at destruction.
It is meant for long term storage, as opposed to int_range_max which is
meant for intermediate temporary results on the stack.
On 9/18/20 3:43 AM, David Malcolm wrote:
On Thu, 2020-09-17 at 12:36 +0200, Aldy Hernandez via Gcc-patches
wrote:
This is the irange storage class. It is used to allocate the
minimum
amount of storage needed for a given irange. Storage is
automatically
freed at destruction.
It is meant
On 9/17/20 8:02 PM, Martin Sebor wrote:
> On 9/17/20 4:36 AM, Aldy Hernandez via Gcc-patches wrote:
>> This is the irange storage class. It is used to allocate the minimum
>> amount of storage needed for a given irange. Storage is automatically
>> freed at destructi
On 9/17/20 10:18 PM, Martin Sebor wrote:
On 9/17/20 12:39 PM, Andrew MacLeod wrote:
On 9/17/20 12:08 PM, Martin Sebor via Gcc-patches wrote:
On 9/16/20 9:23 PM, Jeff Law wrote:
On 9/15/20 1:47 PM, Martin Sebor wrote:
Overflowing the size of a dynamic allocation (e.g., malloc or VLA)
can
PING
-- Forwarded message -
From: Aldy Hernandez
Date: Mon, May 18, 2020 at 7:59 PM
Subject: [patch] substitute_and_fold_engine merge with evrp domwalker
To: Jeff Law
Cc: gcc-patches
Howdy.
The main evrp domwalker seems cut and pasted from the
substitute_and_fold_engine (or
On Sun, May 31, 2020 at 7:31 PM Jeff Law wrote:
>
> On Mon, 2020-05-18 at 20:11 +0200, Aldy Hernandez wrote:
> > As a follow-up to the patch moving array bounds checking into its own
> > class, this moves the class into its own files. As I've mentioned
> > previously, having it in tree-vrp just
On 9/19/20 11:22 PM, Martin Sebor wrote:
On 9/18/20 12:29 AM, Aldy Hernandez wrote:
On 9/17/20 10:18 PM, Martin Sebor wrote:
On 9/17/20 12:39 PM, Andrew MacLeod wrote:
On 9/17/20 12:08 PM, Martin Sebor via Gcc-patches wrote:
On 9/16/20 9:23 PM, Jeff Law wrote:
On 9/15/20 1:47 PM,
On 9/19/20 10:32 PM, Martin Sebor wrote:
On 9/18/20 3:09 PM, Andrew MacLeod wrote:
On 9/18/20 4:35 PM, Martin Sebor wrote:
On 9/18/20 11:36 AM, Andrew MacLeod wrote:
On
it works exactly like one would expect a simple allocator to work..
as long as the allcoator is "live", its allocations
>> // Swap min/max if they are out of order. Return TRUE if further
> these seems OK, but can't there be anti-ranges with symbolics too? ie
> ~[a_12, a_12]
> The code for that just does:
>
> else if (src.kind () == VR_ANTI_RANGE)
> set (src.min (), src.max (), VR_ANTI_RANGE);
>
>
On 9/18/20 6:42 PM, Andrew MacLeod wrote:
On 9/18/20 8:28 AM, David Malcolm wrote:I think of a "pool allocator" as
something that makes a small
number of
large allocation under the covers, and then uses that to serve
large
numbers of fixed sized small allocations and deallocations with
O(1)
On 9/18/20 2:28 PM, David Malcolm wrote:
On Fri, 2020-09-18 at 07:49 +0200, Aldy Hernandez wrote:
On 9/18/20 3:43 AM, David Malcolm wrote:
On Thu, 2020-09-17 at 12:36 +0200, Aldy Hernandez via Gcc-patches
wrote:
This is the irange storage class. It is used to allocate the
minimum
amount
bounds_of_var_in_loop is returning an overflowed int, which is causing
us to create a range for which we can't compare the bounds causing
an ICE in verify_range.
Overflowed bounds cause compare_values() to return -2, which we
don't handle in verify_range.
We don't represent overflowed ranges in
On Tue, Oct 20, 2020 at 6:19 PM Andrew MacLeod wrote:
>
> On 10/19/20 6:03 AM, Aldy Hernandez wrote:
> >
> >
> >
> > Forwarded Message
> > Subject: [PATCH] Refactor range handling of builtins in vr_values and
> > ranger.
> > Date: Fri, 9 Oct 2020 14:32:05 +0200
> > From: Aldy
An undefined range was leaking through to the end of this function,
which leads us to use an uninitialized wide_int.
Pushed.
gcc/ChangeLog:
PR tree-optimization/97538
* calls.c (get_size_range): Handle undefined ranges.
gcc/testsuite/ChangeLog:
* g++.dg/pr97538.C: New
This was already fixed by the patch for PR97520, but it can't hurt to
keep this test around as well :).
Pushed.
gcc/testsuite/ChangeLog:
PR tree-optimization/97560
* g++.dg/pr97560.C: New test.
---
gcc/testsuite/g++.dg/pr97560.C | 44 ++
1 file
On Tue, Oct 27, 2020 at 3:10 PM Jakub Jelinek wrote:
>
> On Tue, Oct 27, 2020 at 07:38:53AM +0100, Aldy Hernandez via Gcc-patches
> wrote:
> > This was already fixed by the patch for PR97520, but it can't hurt to
> > keep this test around as well :).
>
> Small tweak
For the record, this is what I envision the follow-up patch to be (untested).
Aldy
diff --git a/gcc/vr-values.c b/gcc/vr-values.c
index 9f5943a1ab6..3db72a360a6 100644
--- a/gcc/vr-values.c
+++ b/gcc/vr-values.c
@@ -1159,188 +1159,16 @@ check_for_binary_op_overflow (range_query *query,
On Tue, Oct 27, 2020 at 3:29 PM Jakub Jelinek wrote:
>
> On Tue, Oct 27, 2020 at 03:20:55PM +0100, Aldy Hernandez wrote:
> > > g++.dg/opt/, g++.dg/ itself shouldn't really have any tests directly.
> >
> > Wait, what? I've always put them into g++.dg. And it looks like that
>
> Many people
The UBSAN builtins degrade into PLUS/MINUS/MULT and call
extract_range_from_binary_expr, which as the PR shows, can special
case some symbolics which the ranger doesn't currently handle.
Looking at vr_values::extract_range_builtin(), I see that every single
place where we ask for a range, we bail
The problem here is we are trying to add 1 to a -1 in a signed 1-bit
field and coming up with UNDEFINED because of the overflow.
Signed 1-bits are annoying because you can't really add or subtract
one, because the one is unrepresentable. For invert() we have a
special subtract_one() function
Fixes PR.
Pushed.
commit 6c4763fa5b55f6e883ed7077b67c6175c2da63d1
Author: Aldy Hernandez
Date: Mon Aug 3 18:30:30 2020 +0200
Avoid shifting by amounts larger than target int in irange self-tests.
gcc/ChangeLog:
PR tree-optimization/96430
*
It seems to me that we should also check for [0,0] and [1,1] in the
range, but I am leaving things as is to avoid functional changes.
gcc/ChangeLog:
* vr-values.c (simplify_using_ranges::op_with_boolean_value_range_p):
Adjust
for irange API.
---
gcc/vr-values.c | 7 ---
1
gcc/ChangeLog:
* tree-ssanames.c (get_range_info): Use irange instead of value_range.
* tree-ssanames.h (get_range_info): Same.
---
gcc/tree-ssanames.c | 2 +-
gcc/tree-ssanames.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/tree-ssanames.c
gcc/ChangeLog:
* fold-const.c (expr_not_equal_to): Adjust for irange API.
---
gcc/fold-const.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 1324a194995..5d27927f6bf 100644
--- a/gcc/fold-const.c
+++
Anti ranges of ~[MIN,X] are automatically canonicalized to [X+1,MAX],
at creation time. There is no need to handle them specially.
Tested by adding a gcc_unreachable and bootstrapping/testing.
gcc/ChangeLog:
* builtins.c (determine_block_size): Remove ad-hoc range
canonicalization.
The following patchset adjusts various files for adherence to the
irange API. There are no functional changes. The changes are mostly
obvious and will be pushed pending tests.
No effort was made to improve the existing code. That is, I didn't
bend over backwards to convert the code to
gcc/ChangeLog:
* vr-values.c (simplify_using_ranges::two_valued_val_range_p):
Use irange API.
---
gcc/vr-values.c | 31 +--
1 file changed, 9 insertions(+), 22 deletions(-)
diff --git a/gcc/vr-values.c b/gcc/vr-values.c
index 38c9a657dad..2fd4956a2e4
gcc/ChangeLog:
* vr-values.c (test_for_singularity): Use irange API.
(simplify_using_ranges::simplify_cond_using_ranges_1): Do not
special case VR_RANGE.
---
gcc/vr-values.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/gcc/vr-values.c
1 - 100 of 1121 matches
Mail list logo
