On February 21, 2018 4:25:14 AM GMT+01:00, Jeff Law wrote:
>On 02/20/2018 04:59 PM, Martin Sebor wrote:
>>> It would help if you explained why you think it is a good idea
>>> ignoring the other phi arguments if you have one (or more) where you
>can
>>> determine length.
>>
>> It's a heuristic tha
On 02/20/2018 08:25 PM, Jeff Law wrote:
On 02/20/2018 04:59 PM, Martin Sebor wrote:
It would help if you explained why you think it is a good idea
ignoring the other phi arguments if you have one (or more) where you can
determine length.
It's a heuristic that was meant just for the -Wformat-ov
On Tue, Feb 20, 2018 at 08:56:11PM -0700, Jeff Law wrote:
> On 02/20/2018 02:34 PM, Jakub Jelinek wrote:
> > On Tue, Feb 20, 2018 at 01:13:13PM -0700, Martin Sebor wrote:
> >> A safer and even more conservative alternative that should be
> >> equivalent to your approach while avoiding the sprintf r
On Tue, Feb 20, 2018 at 08:31:06PM -0700, Jeff Law wrote:
> On 02/20/2018 05:14 PM, Jakub Jelinek wrote:
> > On Tue, Feb 20, 2018 at 04:59:12PM -0700, Martin Sebor wrote:
> >>> It would help if you explained why you think it is a good idea
> >>> ignoring the other phi arguments if you have one (or
On Tue, Feb 20, 2018 at 04:59:12PM -0700, Martin Sebor wrote:
> > It would help if you explained why you think it is a good idea
> > ignoring the other phi arguments if you have one (or more) where you can
> > determine length.
>
> It's a heuristic that was meant just for the -Wformat-overflow
> w
On 02/20/2018 02:34 PM, Jakub Jelinek wrote:
> On Tue, Feb 20, 2018 at 01:13:13PM -0700, Martin Sebor wrote:
>> A safer and even more conservative alternative that should be
>> equivalent to your approach while avoiding the sprintf regressions
>> is to add another mode to the function and have it c
On 02/20/2018 02:34 PM, Jakub Jelinek wrote:
> On Tue, Feb 20, 2018 at 01:13:13PM -0700, Martin Sebor wrote:
>> A safer and even more conservative alternative that should be
>> equivalent to your approach while avoiding the sprintf regressions
>> is to add another mode to the function and have it c
On 02/20/2018 12:03 PM, Martin Sebor wrote:
>> The thing that isn't handled conservatively is PHIs and COND_EXPR.
>> The current code, if we can't figure one of the args out, for PHIs in
>> fuzzy mode increases the *maxval value to +INF, but doesn't touch
>> *minval, for COND_EXPR doesn't adjust th
On 02/20/2018 01:13 PM, Martin Sebor wrote:
> On 02/20/2018 12:03 PM, Martin Sebor wrote:
>> On 02/20/2018 10:17 AM, Jakub Jelinek wrote:
>>> Hi!
>>>
>>> The following testcase distilled from pdftex is miscompiled on i?86,
>>> because gimple_fold_builtin_strlen sets incorrect value range on
>>> str
On 02/20/2018 05:14 PM, Jakub Jelinek wrote:
> On Tue, Feb 20, 2018 at 04:59:12PM -0700, Martin Sebor wrote:
>>> It would help if you explained why you think it is a good idea
>>> ignoring the other phi arguments if you have one (or more) where you can
>>> determine length.
>>
>> It's a heuristic t
On 02/20/2018 04:59 PM, Martin Sebor wrote:
>> It would help if you explained why you think it is a good idea
>> ignoring the other phi arguments if you have one (or more) where you can
>> determine length.
>
> It's a heuristic that was meant just for the -Wformat-overflow
> warning. When making
On 02/20/2018 05:14 PM, Jakub Jelinek wrote:
On Tue, Feb 20, 2018 at 04:59:12PM -0700, Martin Sebor wrote:
It would help if you explained why you think it is a good idea
ignoring the other phi arguments if you have one (or more) where you can
determine length.
It's a heuristic that was meant j
On Tue, Feb 20, 2018 at 01:13:13PM -0700, Martin Sebor wrote:
> A safer and even more conservative alternative that should be
> equivalent to your approach while avoiding the sprintf regressions
> is to add another mode to the function and have it clear *minlen
> as an option. This lets the strlen
It would help if you explained why you think it is a good idea
ignoring the other phi arguments if you have one (or more) where you can
determine length.
It's a heuristic that was meant just for the -Wformat-overflow
warning. When making decisions that affect code generation it's
obviously not
On 02/20/2018 02:34 PM, Jakub Jelinek wrote:
On Tue, Feb 20, 2018 at 01:13:13PM -0700, Martin Sebor wrote:
A safer and even more conservative alternative that should be
equivalent to your approach while avoiding the sprintf regressions
is to add another mode to the function and have it clear *mi
On Tue, Feb 20, 2018 at 12:03:26PM -0700, Martin Sebor wrote:
> PR tree-optimization/84478 - [8 Regression] pdftex miscompilation on i386
>
> gcc/ChangeLog:
>
> PR tree-optimization/84478
> * gimple-fold.c (get_range_strlen): Set *MINLEN to zero.
> (get_range_strlen): Reset rang
On 02/20/2018 12:03 PM, Martin Sebor wrote:
On 02/20/2018 10:17 AM, Jakub Jelinek wrote:
Hi!
The following testcase distilled from pdftex is miscompiled on i?86,
because gimple_fold_builtin_strlen sets incorrect value range on
strlen call on SSA_NAME with def_stmt of PHI <"mu", something> where
On 02/20/2018 10:17 AM, Jakub Jelinek wrote:
Hi!
The following testcase distilled from pdftex is miscompiled on i?86,
because gimple_fold_builtin_strlen sets incorrect value range on
strlen call on SSA_NAME with def_stmt of PHI <"mu", something> where
we can't determine anything about string len
Hi!
The following testcase distilled from pdftex is miscompiled on i?86,
because gimple_fold_builtin_strlen sets incorrect value range on
strlen call on SSA_NAME with def_stmt of PHI <"mu", something> where
we can't determine anything about string length of something, so the
right value range is [
19 matches
Mail list logo
