On 03/07/2018 03:52 PM, Martin Sebor wrote:
> On 03/07/2018 12:37 PM, Jeff Law wrote:
>> On 02/26/2018 10:32 AM, Martin Sebor wrote:
>>>
>>> PR tree-optimization/84526 - ICE in generic_overlap at
>>> gcc/gimple-ssa-warn-restrict.c:927 since r257860
>>>
>>>
>>> gcc/ChangeLog:
>>>
>>> PR tree-op
On 03/07/2018 04:04 PM, Richard Sandiford wrote:
Martin Sebor writes:
@@ -409,23 +412,33 @@ builtin_memref::set_base_and_offset (tree expr)
base = get_inner_reference (expr, &bitsize, &bitpos, &var_off,
&mode, &sign, &reverse, &vol);
+ /* get_inner_reference i
Martin Sebor writes:
> @@ -409,23 +412,33 @@ builtin_memref::set_base_and_offset (tree expr)
>base = get_inner_reference (expr, &bitsize, &bitpos, &var_off,
> &mode, &sign, &reverse, &vol);
>
> + /* get_inner_reference is not expected to return null. */
> + gcc
On 03/07/2018 12:37 PM, Jeff Law wrote:
On 02/26/2018 10:32 AM, Martin Sebor wrote:
PR tree-optimization/84526 - ICE in generic_overlap at
gcc/gimple-ssa-warn-restrict.c:927 since r257860
gcc/ChangeLog:
PR tree-optimization/84526
* gimple-ssa-warn-restrict.c (builtin_memref::
On 02/26/2018 10:32 AM, Martin Sebor wrote:
>
> PR tree-optimization/84526 - ICE in generic_overlap at
> gcc/gimple-ssa-warn-restrict.c:927 since r257860
>
> gcc/ChangeLog:
>
> PR tree-optimization/84526
> * gimple-ssa-warn-restrict.c (builtin_memref::set_base_and_offset):
> R
On 02/23/2018 02:46 PM, Martin Sebor wrote:
>> This doesn't address any of my concerns that it is completely random
>> what {dst,src}ref->base is, apples and oranges; sometimes it is a pointer
>> (e.g. the argument of the function), sometimes the ADDR_EXPR operand,
>> sometimes the base of the refe
On 02/23/2018 01:13 PM, Jakub Jelinek wrote:
> On Fri, Feb 23, 2018 at 12:57:14PM -0700, Martin Sebor wrote:
>> + /* get_inner_reference is not expected to return null. */
>> + gcc_assert (base != NULL);
>> +
>>poly_int64 bytepos = exact_div (bitpos, BITS_PER_UNIT);
>>
>> - HOST_WIDE_INT
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01441.html
Jeff, I know this is in your queue. I ping it because a bug
with the same root cause was reported in RHBZ #1552639.
On 02/26/2018 11:13 AM, Martin Sebor wrote:
On 02/26/2018 10:39 AM, Jakub Jelinek wrote:
On Mon, Feb 26, 2018 at 1
Martin Sebor writes:
> + /* Convert the poly_int64 offset to to offset_int. The offset
> + should be constant but be prepared for it not to be just in
> + case. */
This comment seems redundant and could easily get out of date once
ACLE support is added.
> + offset_int cstoff;
> + if
On Mon, Feb 26, 2018 at 10:32:27AM -0700, Martin Sebor wrote:
> That attached revision updates the pass to directly convert
> the poly64_int into offset_int using the API suggested by
> Richard (thanks again). As discussed below, I've made no
> other changes.
>
> Jakub, if you still have concerns
On 02/26/2018 10:39 AM, Jakub Jelinek wrote:
On Mon, Feb 26, 2018 at 10:32:27AM -0700, Martin Sebor wrote:
That attached revision updates the pass to directly convert
the poly64_int into offset_int using the API suggested by
Richard (thanks again). As discussed below, I've made no
other changes
That attached revision updates the pass to directly convert
the poly64_int into offset_int using the API suggested by
Richard (thanks again). As discussed below, I've made no
other changes.
Jakub, if you still have concerns that the false positive
suppression logic isn't sufficiently effective p
Martin Sebor writes:
> On 02/24/2018 02:32 AM, Richard Sandiford wrote:
>> Martin Sebor writes:
>>> On 02/23/2018 01:13 PM, Jakub Jelinek wrote:
On Fri, Feb 23, 2018 at 12:57:14PM -0700, Martin Sebor wrote:
> + /* get_inner_reference is not expected to return null. */
> + gcc_asse
On 02/24/2018 02:32 AM, Richard Sandiford wrote:
Martin Sebor writes:
On 02/23/2018 01:13 PM, Jakub Jelinek wrote:
On Fri, Feb 23, 2018 at 12:57:14PM -0700, Martin Sebor wrote:
+ /* get_inner_reference is not expected to return null. */
+ gcc_assert (base != NULL);
+
poly_int64 bytepos
On Fri, Feb 23, 2018 at 02:46:28PM -0700, Martin Sebor wrote:
> > This doesn't address any of my concerns that it is completely random
> > what {dst,src}ref->base is, apples and oranges; sometimes it is a pointer
> > (e.g. the argument of the function), sometimes the ADDR_EXPR operand,
> > sometime
Martin Sebor writes:
> On 02/23/2018 01:13 PM, Jakub Jelinek wrote:
>> On Fri, Feb 23, 2018 at 12:57:14PM -0700, Martin Sebor wrote:
>>> + /* get_inner_reference is not expected to return null. */
>>> + gcc_assert (base != NULL);
>>> +
>>>poly_int64 bytepos = exact_div (bitpos, BITS_PER_UNI
On 02/23/2018 02:54 PM, Jakub Jelinek wrote:
On Fri, Feb 23, 2018 at 02:46:28PM -0700, Martin Sebor wrote:
This doesn't address any of my concerns that it is completely random
what {dst,src}ref->base is, apples and oranges; sometimes it is a pointer
(e.g. the argument of the function), sometimes
On 02/23/2018 01:13 PM, Jakub Jelinek wrote:
On Fri, Feb 23, 2018 at 12:57:14PM -0700, Martin Sebor wrote:
+ /* get_inner_reference is not expected to return null. */
+ gcc_assert (base != NULL);
+
poly_int64 bytepos = exact_div (bitpos, BITS_PER_UNIT);
- HOST_WIDE_INT const_off;
- if (
On Fri, Feb 23, 2018 at 12:57:14PM -0700, Martin Sebor wrote:
> + /* get_inner_reference is not expected to return null. */
> + gcc_assert (base != NULL);
> +
>poly_int64 bytepos = exact_div (bitpos, BITS_PER_UNIT);
>
> - HOST_WIDE_INT const_off;
> - if (!base || !bytepos.is_constant (&c
r257860 introduced an unsafe assumption under some conditions
that the base object referenced by a memcpy strcpy necessarily
has a pointer or array type. The attached patch removes this
assumption.
In addition, as discussed in the bug and in IRC, the patch
also removes a test for the result of g
20 matches
Mail list logo
