Just a reminder:
those are the two parts of this patch, which have been posted already
a while ago when we were still in stage 1:
https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00805.html
https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01237.html
Bernd.
On 10/20/18 11:16 AM, Bernd Edlinger
Hi Maxim,
short after the initial commit there came two more fix-ups in the same function:
$ svn log -r263896
r263896 | law | 2018-08-27 22:31:14 +0200 (Mon, 27 Aug 2018) | 4 lines
* tree-ssa-dse.c (compute_trims):
Hi Jeff,
Hi Bernd,
This change (git commit d0eb64b248a9e40dfa633c4e4baebc3b238fd6eb / svn rev.
263793) causes a segfault when build Linux kernel for AArch64. The exact
configuration is
===
git_repo[linux]=https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
On 10/17/18 11:56 PM, Jeff Law wrote:
> On 10/12/18 9:34 PM, Bernd Edlinger wrote:
>> On 10/12/18 16:55, Jeff Law wrote:
>>> On 9/15/18 2:43 AM, Bernd Edlinger wrote:
Hi,
this is an update on my strlen range patch (V7). Again re-based and
retested to current trunk.
I
On 10/12/18 9:34 PM, Bernd Edlinger wrote:
> On 10/12/18 16:55, Jeff Law wrote:
>> On 9/15/18 2:43 AM, Bernd Edlinger wrote:
>>> Hi,
>>>
>>> this is an update on my strlen range patch (V7). Again re-based and
>>> retested to current trunk.
>>>
>>> I am aware that Martin wants to re-factor the
On 10/12/18 16:55, Jeff Law wrote:
> On 9/15/18 2:43 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> this is an update on my strlen range patch (V7). Again re-based and
>> retested to current trunk.
>>
>> I am aware that Martin wants to re-factor the interface of get_range_strlen
>> and have no objections
On 9/15/18 2:43 AM, Bernd Edlinger wrote:
> Hi,
>
> this is an update on my strlen range patch (V7). Again re-based and
> retested to current trunk.
>
> I am aware that Martin wants to re-factor the interface of get_range_strlen
> and have no objections against, but I'd suggest that to be a
On 9/15/18 2:43 AM, Bernd Edlinger wrote:
> Hi,
>
> this is an update on my strlen range patch (V7). Again re-based and
> retested to current trunk.
>
> I am aware that Martin wants to re-factor the interface of get_range_strlen
> and have no objections against, but I'd suggest that to be a
Hi,
this is an update on my strlen range patch (V7). Again re-based and
retested to current trunk.
I am aware that Martin wants to re-factor the interface of get_range_strlen
and have no objections against, but I'd suggest that to be a follow-up patch.
I might suggest to rename one of the two
Hi,
this is an update on my strlen range patch (V6). Again re-based and
retested to current trunk.
It finally removes the -ffassume-zero-terminated-char-arrays flag.
And is more careful to preserve existing strlen optimization tests.
I did not see the need to change the interface of
On 08/21/2018 10:15 PM, Bernd Edlinger wrote:
> On 08/22/18 00:43, Jeff Law wrote:
>> [ I'm still digesting, but saw something in this that ought to be broken
>> out... ]
>>
>> On 08/19/2018 09:55 AM, Bernd Edlinger wrote:
>>> diff -Npur gcc/tree-ssa-dse.c gcc/tree-ssa-dse.c
>>> ---
On 08/23/18 00:57, Martin Sebor wrote:
> On 08/22/2018 04:34 PM, Jeff Law wrote:
>> On 08/22/2018 11:22 AM, Bernd Edlinger wrote:
>>> On 08/22/18 18:05, Martin Sebor wrote:
On 08/21/2018 10:05 PM, Bernd Edlinger wrote:
> On 08/22/18 00:25, Jeff Law wrote:
>> On 08/21/2018 02:43 AM,
On 08/23/18 00:34, Jeff Law wrote:
> On 08/22/2018 11:22 AM, Bernd Edlinger wrote:
>> On 08/22/18 18:05, Martin Sebor wrote:
>>> On 08/21/2018 10:05 PM, Bernd Edlinger wrote:
On 08/22/18 00:25, Jeff Law wrote:
> On 08/21/2018 02:43 AM, Richard Biener wrote:
>> On Mon, 20 Aug 2018,
On 08/22/2018 04:34 PM, Jeff Law wrote:
On 08/22/2018 11:22 AM, Bernd Edlinger wrote:
On 08/22/18 18:05, Martin Sebor wrote:
On 08/21/2018 10:05 PM, Bernd Edlinger wrote:
On 08/22/18 00:25, Jeff Law wrote:
On 08/21/2018 02:43 AM, Richard Biener wrote:
On Mon, 20 Aug 2018, Bernd Edlinger
On 08/22/2018 11:22 AM, Bernd Edlinger wrote:
> On 08/22/18 18:05, Martin Sebor wrote:
>> On 08/21/2018 10:05 PM, Bernd Edlinger wrote:
>>> On 08/22/18 00:25, Jeff Law wrote:
On 08/21/2018 02:43 AM, Richard Biener wrote:
> On Mon, 20 Aug 2018, Bernd Edlinger wrote:
[ snip. ]
On 08/22/18 18:05, Martin Sebor wrote:
> On 08/21/2018 10:05 PM, Bernd Edlinger wrote:
>> On 08/22/18 00:25, Jeff Law wrote:
>>> On 08/21/2018 02:43 AM, Richard Biener wrote:
On Mon, 20 Aug 2018, Bernd Edlinger wrote:
>>> [ snip. ]
>>>
> Yes, I found some peanuts on my way.
>
>
On 08/21/2018 10:05 PM, Bernd Edlinger wrote:
On 08/22/18 00:25, Jeff Law wrote:
On 08/21/2018 02:43 AM, Richard Biener wrote:
On Mon, 20 Aug 2018, Bernd Edlinger wrote:
[ snip. ]
Yes, I found some peanuts on my way.
For instance this fix for PR middle-end/86121 survives bootstrap on
it's
Hi,
this is an update (v5) of my patch:
As discussed earlier, this version does no longer enable
-fassume-zero-terminated-char-arrays with -Ofast.
I am ready to remove the -fassume-zero-terminated-char-arrays altogether if we
decide what
to do with the code-gen test cases that still use it
On 08/22/18 00:43, Jeff Law wrote:
> [ I'm still digesting, but saw something in this that ought to be broken
> out... ]
>
> On 08/19/2018 09:55 AM, Bernd Edlinger wrote:
>> diff -Npur gcc/tree-ssa-dse.c gcc/tree-ssa-dse.c
>> --- gcc/tree-ssa-dse.c 2018-07-18 21:21:34.0 +0200
>> +++
On 08/22/18 00:25, Jeff Law wrote:
> On 08/21/2018 02:43 AM, Richard Biener wrote:
>> On Mon, 20 Aug 2018, Bernd Edlinger wrote:
> [ snip. ]
>
>>> Yes, I found some peanuts on my way.
>>>
>>> For instance this fix for PR middle-end/86121 survives bootstrap on
>>> it's own, and fixes one xfail.
[ I'm still digesting, but saw something in this that ought to be broken
out... ]
On 08/19/2018 09:55 AM, Bernd Edlinger wrote:
> diff -Npur gcc/tree-ssa-dse.c gcc/tree-ssa-dse.c
> --- gcc/tree-ssa-dse.c2018-07-18 21:21:34.0 +0200
> +++ gcc/tree-ssa-dse.c2018-08-19
On 08/21/2018 02:43 AM, Richard Biener wrote:
> On Mon, 20 Aug 2018, Bernd Edlinger wrote:
[ snip. ]
>> Yes, I found some peanuts on my way.
>>
>> For instance this fix for PR middle-end/86121 survives bootstrap on
>> it's own, and fixes one xfail.
>>
>> Is it OK for trunk?
>
> Yes, that's OK
On 08/20/2018 09:15 AM, Bernd Edlinger wrote:
> On 08/20/18 16:26, Jeff Law wrote:
>> On 08/20/2018 04:23 AM, Bernd Edlinger wrote:
>>> On 08/20/18 12:12, Richard Biener wrote:
On Wed, Aug 15, 2018 at 6:39 AM Jeff Law wrote:
>
> On 08/10/2018 10:56 AM, Martin Sebor wrote:
>> On
On Mon, 20 Aug 2018, Bernd Edlinger wrote:
>
>
> On 08/20/18 12:23, Richard Biener wrote:
> > On Sun, 19 Aug 2018, Bernd Edlinger wrote:
> >
> >> Hi,
> >>
> >>
> >> I rebased my range computation patch to current trunk,
> >> and updated it according to what was discussed here.
> >>
> >> That
On 08/21/18 04:43, Martin Sebor wrote:
>> I must say that I don't like the return value optimization
>> on the sprintf pass, because it uses knowledge of the glibc implementation
>> of sprintf to do it's job (mind the 4K buffer limit).
>
> Yet again, you don't know what you're talking about. The
On 08/20/2018 03:31 PM, Bernd Edlinger wrote:
On 08/20/18 22:42, Martin Sebor wrote:
On 08/20/2018 09:15 AM, Bernd Edlinger wrote:
On 08/20/18 16:26, Jeff Law wrote:
On 08/20/2018 04:23 AM, Bernd Edlinger wrote:
On 08/20/18 12:12, Richard Biener wrote:
On Wed, Aug 15, 2018 at 6:39 AM Jeff
On 08/20/18 22:42, Martin Sebor wrote:
> On 08/20/2018 09:15 AM, Bernd Edlinger wrote:
>> On 08/20/18 16:26, Jeff Law wrote:
>>> On 08/20/2018 04:23 AM, Bernd Edlinger wrote:
On 08/20/18 12:12, Richard Biener wrote:
> On Wed, Aug 15, 2018 at 6:39 AM Jeff Law wrote:
>>
>> On
On 08/20/2018 09:15 AM, Bernd Edlinger wrote:
On 08/20/18 16:26, Jeff Law wrote:
On 08/20/2018 04:23 AM, Bernd Edlinger wrote:
On 08/20/18 12:12, Richard Biener wrote:
On Wed, Aug 15, 2018 at 6:39 AM Jeff Law wrote:
On 08/10/2018 10:56 AM, Martin Sebor wrote:
On 08/08/2018 11:36 PM, Jeff
On 08/20/18 12:23, Richard Biener wrote:
> On Sun, 19 Aug 2018, Bernd Edlinger wrote:
>
>> Hi,
>>
>>
>> I rebased my range computation patch to current trunk,
>> and updated it according to what was discussed here.
>>
>> That means get_range_strlen has already a parameter
>> that is used to
On 08/20/18 16:26, Jeff Law wrote:
> On 08/20/2018 04:23 AM, Bernd Edlinger wrote:
>> On 08/20/18 12:12, Richard Biener wrote:
>>> On Wed, Aug 15, 2018 at 6:39 AM Jeff Law wrote:
On 08/10/2018 10:56 AM, Martin Sebor wrote:
> On 08/08/2018 11:36 PM, Jeff Law wrote:
>> On
On 08/20/2018 04:23 AM, Bernd Edlinger wrote:
> On 08/20/18 12:12, Richard Biener wrote:
>> On Wed, Aug 15, 2018 at 6:39 AM Jeff Law wrote:
>>>
>>> On 08/10/2018 10:56 AM, Martin Sebor wrote:
On 08/08/2018 11:36 PM, Jeff Law wrote:
> On 08/02/2018 09:42 AM, Martin Sebor wrote:
>
On Sun, 19 Aug 2018, Bernd Edlinger wrote:
> Hi,
>
>
> I rebased my range computation patch to current trunk,
> and updated it according to what was discussed here.
>
> That means get_range_strlen has already a parameter
> that is used to differentiate between ranges for warnings
> and ranges
On 08/20/18 12:12, Richard Biener wrote:
> On Wed, Aug 15, 2018 at 6:39 AM Jeff Law wrote:
>>
>> On 08/10/2018 10:56 AM, Martin Sebor wrote:
>>> On 08/08/2018 11:36 PM, Jeff Law wrote:
On 08/02/2018 09:42 AM, Martin Sebor wrote:
> The warning bits are definitely not okay by me. The
On Wed, Aug 15, 2018 at 6:39 AM Jeff Law wrote:
>
> On 08/10/2018 10:56 AM, Martin Sebor wrote:
> > On 08/08/2018 11:36 PM, Jeff Law wrote:
> >> On 08/02/2018 09:42 AM, Martin Sebor wrote:
> >>
> >>> The warning bits are definitely not okay by me. The purpose
> >>> of the warnings
On Fri, Aug 3, 2018 at 9:19 AM Jeff Law wrote:
>
> On 07/25/2018 01:23 AM, Richard Biener wrote:
> > On Tue, 24 Jul 2018, Bernd Edlinger wrote:
> >
> >> On 07/24/18 23:46, Jeff Law wrote:
> >>> On 07/24/2018 01:59 AM, Bernd Edlinger wrote:
> Hi!
>
> This patch makes strlen range
Hi,
I rebased my range computation patch to current trunk,
and updated it according to what was discussed here.
That means get_range_strlen has already a parameter
that is used to differentiate between ranges for warnings
and ranges for code-gen.
That is called "strict", in the 4-parameter
On 08/17/2018 04:31 AM, Richard Biener wrote:
On Tue, 7 Aug 2018, Martin Sebor wrote:
On 08/07/2018 11:44 AM, Richard Biener wrote:
On August 7, 2018 4:37:00 PM GMT+02:00, Martin Sebor
wrote:
On 08/07/2018 02:51 AM, Richard Biener wrote:
On August 7, 2018 4:24:42 AM GMT+02:00, Martin Sebor
On Tue, 7 Aug 2018, Martin Sebor wrote:
> On 08/07/2018 11:44 AM, Richard Biener wrote:
> > On August 7, 2018 4:37:00 PM GMT+02:00, Martin Sebor
> > wrote:
> > > On 08/07/2018 02:51 AM, Richard Biener wrote:
> > > > On August 7, 2018 4:24:42 AM GMT+02:00, Martin Sebor
> > > wrote:
> > > > > On
On 08/09/2018 12:27 AM, Richard Biener wrote:
> On August 9, 2018 7:26:19 AM GMT+02:00, Jeff Law wrote:
>> On 07/24/2018 05:18 PM, Bernd Edlinger wrote:
>>> On 07/24/18 23:46, Jeff Law wrote:
On 07/24/2018 01:59 AM, Bernd Edlinger wrote:
> Hi!
>
> This patch makes strlen range
On 08/10/2018 10:56 AM, Martin Sebor wrote:
> On 08/08/2018 11:36 PM, Jeff Law wrote:
>> On 08/02/2018 09:42 AM, Martin Sebor wrote:
>>
>>> The warning bits are definitely not okay by me. The purpose
>>> of the warnings (-W{format,sprintf}-{overflow,truncation} is
>>> to detect buffer overflows.
On 08/08/2018 11:36 PM, Jeff Law wrote:
On 08/02/2018 09:42 AM, Martin Sebor wrote:
The warning bits are definitely not okay by me. The purpose
of the warnings (-W{format,sprintf}-{overflow,truncation} is
to detect buffer overflows. When a warning doesn't have access
to string length
On August 9, 2018 7:26:19 AM GMT+02:00, Jeff Law wrote:
>On 07/24/2018 05:18 PM, Bernd Edlinger wrote:
>> On 07/24/18 23:46, Jeff Law wrote:
>>> On 07/24/2018 01:59 AM, Bernd Edlinger wrote:
Hi!
This patch makes strlen range computations more conservative.
Firstly if
On 08/02/2018 09:42 AM, Martin Sebor wrote:
> The warning bits are definitely not okay by me. The purpose
> of the warnings (-W{format,sprintf}-{overflow,truncation} is
> to detect buffer overflows. When a warning doesn't have access
> to string length information for dynamically created
On 07/24/2018 05:18 PM, Bernd Edlinger wrote:
> On 07/24/18 23:46, Jeff Law wrote:
>> On 07/24/2018 01:59 AM, Bernd Edlinger wrote:
>>> Hi!
>>>
>>> This patch makes strlen range computations more conservative.
>>>
>>> Firstly if there is a visible type cast from type A to B before passing
>>> then
On August 8, 2018 5:51:16 PM GMT+02:00, Martin Sebor wrote:
>On 08/07/2018 11:46 AM, Richard Biener wrote:
>> On August 7, 2018 6:31:36 PM GMT+02:00, Martin Sebor
> wrote:
>>> On 08/07/2018 09:33 AM, Bernd Edlinger wrote:
On 08/07/18 17:02, Martin Sebor wrote:
> On 08/06/2018 11:45 PM,
On 08/08/18 17:51, Martin Sebor wrote:
> On 08/07/2018 11:46 AM, Richard Biener wrote:
>>
>> Pointer types carry no information in GIMPLE.
>
> So what do you suggest as a solution?
>
> The strlen optimization can be decoupled from warnings and
> disabled, and the aggressive loop optimization can
On 08/07/2018 11:46 AM, Richard Biener wrote:
On August 7, 2018 6:31:36 PM GMT+02:00, Martin Sebor wrote:
On 08/07/2018 09:33 AM, Bernd Edlinger wrote:
On 08/07/18 17:02, Martin Sebor wrote:
On 08/06/2018 11:45 PM, Richard Biener wrote:
On August 7, 2018 5:38:59 AM GMT+02:00, Martin Sebor
On 08/07/2018 11:44 AM, Richard Biener wrote:
On August 7, 2018 4:37:00 PM GMT+02:00, Martin Sebor wrote:
On 08/07/2018 02:51 AM, Richard Biener wrote:
On August 7, 2018 4:24:42 AM GMT+02:00, Martin Sebor
wrote:
On 07/26/2018 02:55 AM, Richard Biener wrote:
On Wed, 25 Jul 2018, Martin
On August 7, 2018 6:31:36 PM GMT+02:00, Martin Sebor wrote:
>On 08/07/2018 09:33 AM, Bernd Edlinger wrote:
>> On 08/07/18 17:02, Martin Sebor wrote:
>>> On 08/06/2018 11:45 PM, Richard Biener wrote:
On August 7, 2018 5:38:59 AM GMT+02:00, Martin Sebor
> wrote:
> On 08/06/2018 11:40 AM,
On August 7, 2018 4:37:00 PM GMT+02:00, Martin Sebor wrote:
>On 08/07/2018 02:51 AM, Richard Biener wrote:
>> On August 7, 2018 4:24:42 AM GMT+02:00, Martin Sebor
> wrote:
>>> On 07/26/2018 02:55 AM, Richard Biener wrote:
On Wed, 25 Jul 2018, Martin Sebor wrote:
>> BUT - for the
On 08/07/2018 09:33 AM, Bernd Edlinger wrote:
On 08/07/18 17:02, Martin Sebor wrote:
On 08/06/2018 11:45 PM, Richard Biener wrote:
On August 7, 2018 5:38:59 AM GMT+02:00, Martin Sebor wrote:
On 08/06/2018 11:40 AM, Jeff Law wrote:
On 08/06/2018 11:15 AM, Martin Sebor wrote:
These examples
On 08/06/2018 05:59 PM, Martin Sebor wrote:
>>> But as I said, far more essential than the optimization is
>>> the ability to detect these invalid access (both reads and
>>> writes), such as in:
>>
>> The essential thing is to not introduce latent wrong code issues
>> because you exploit C
On 08/07/18 17:02, Martin Sebor wrote:
> On 08/06/2018 11:45 PM, Richard Biener wrote:
>> On August 7, 2018 5:38:59 AM GMT+02:00, Martin Sebor
>> wrote:
>>> On 08/06/2018 11:40 AM, Jeff Law wrote:
On 08/06/2018 11:15 AM, Martin Sebor wrote:
>>> These examples do not aim to be valid C,
On 08/06/2018 09:38 PM, Martin Sebor wrote:
> On 08/06/2018 11:40 AM, Jeff Law wrote:
>> On 08/06/2018 11:15 AM, Martin Sebor wrote:
> These examples do not aim to be valid C, they just point out
> limitations
> of the middle-end design, and a good deal of the problems are due
> to
On 08/06/2018 11:45 PM, Richard Biener wrote:
On August 7, 2018 5:38:59 AM GMT+02:00, Martin Sebor wrote:
On 08/06/2018 11:40 AM, Jeff Law wrote:
On 08/06/2018 11:15 AM, Martin Sebor wrote:
These examples do not aim to be valid C, they just point out
limitations
of the middle-end design,
On 08/07/2018 02:51 AM, Richard Biener wrote:
On August 7, 2018 4:24:42 AM GMT+02:00, Martin Sebor wrote:
On 07/26/2018 02:55 AM, Richard Biener wrote:
On Wed, 25 Jul 2018, Martin Sebor wrote:
BUT - for the string_constant and c_strlen functions we are,
in all cases we return something
On August 7, 2018 4:24:42 AM GMT+02:00, Martin Sebor wrote:
>On 07/26/2018 02:55 AM, Richard Biener wrote:
>> On Wed, 25 Jul 2018, Martin Sebor wrote:
>>
BUT - for the string_constant and c_strlen functions we are,
in all cases we return something interesting, able to look
at an
On August 7, 2018 5:38:59 AM GMT+02:00, Martin Sebor wrote:
>On 08/06/2018 11:40 AM, Jeff Law wrote:
>> On 08/06/2018 11:15 AM, Martin Sebor wrote:
> These examples do not aim to be valid C, they just point out
>limitations
> of the middle-end design, and a good deal of the problems are
On 08/06/2018 11:40 AM, Jeff Law wrote:
On 08/06/2018 11:15 AM, Martin Sebor wrote:
These examples do not aim to be valid C, they just point out limitations
of the middle-end design, and a good deal of the problems are due
to trying to do things that are not safe within the boundaries given
by
On 07/26/2018 02:55 AM, Richard Biener wrote:
On Wed, 25 Jul 2018, Martin Sebor wrote:
BUT - for the string_constant and c_strlen functions we are,
in all cases we return something interesting, able to look
at an initializer which then determines that type. Hopefully.
I think the strlen()
But as I said, far more essential than the optimization is
the ability to detect these invalid access (both reads and
writes), such as in:
The essential thing is to not introduce latent wrong code issues because you
exploit C language constraints that are not preserved by GIMPLE transforms
On 08/06/2018 10:32 AM, Martin Sebor wrote:
> On 08/06/2018 09:12 AM, Jeff Law wrote:
>> On 08/04/2018 03:56 PM, Martin Sebor wrote:
>>> On 08/03/2018 01:00 AM, Jeff Law wrote:
On 07/24/2018 05:18 PM, Bernd Edlinger wrote:
> On 07/24/18 23:46, Jeff Law wrote:
>> On 07/24/2018 01:59
On 08/06/2018 11:15 AM, Martin Sebor wrote:
>>> These examples do not aim to be valid C, they just point out limitations
>>> of the middle-end design, and a good deal of the problems are due
>>> to trying to do things that are not safe within the boundaries given
>>> by the middle-end design.
>> I
On August 6, 2018 6:32:41 PM GMT+02:00, Martin Sebor wrote:
>On 08/06/2018 09:12 AM, Jeff Law wrote:
>> On 08/04/2018 03:56 PM, Martin Sebor wrote:
>>> On 08/03/2018 01:00 AM, Jeff Law wrote:
On 07/24/2018 05:18 PM, Bernd Edlinger wrote:
> On 07/24/18 23:46, Jeff Law wrote:
>> On
On 08/06/2018 11:15 AM, Martin Sebor wrote:
>>> These examples do not aim to be valid C, they just point out limitations
>>> of the middle-end design, and a good deal of the problems are due
>>> to trying to do things that are not safe within the boundaries given
>>> by the middle-end design.
>> I
These examples do not aim to be valid C, they just point out limitations
of the middle-end design, and a good deal of the problems are due
to trying to do things that are not safe within the boundaries given
by the middle-end design.
I really think this is important -- and as such I think we
On 08/06/2018 09:12 AM, Jeff Law wrote:
On 08/04/2018 03:56 PM, Martin Sebor wrote:
On 08/03/2018 01:00 AM, Jeff Law wrote:
On 07/24/2018 05:18 PM, Bernd Edlinger wrote:
On 07/24/18 23:46, Jeff Law wrote:
On 07/24/2018 01:59 AM, Bernd Edlinger wrote:
Hi!
This patch makes strlen range
On 08/02/2018 10:19 PM, Martin Sebor wrote:
> On 08/01/2018 12:55 AM, Bernd Edlinger wrote:
>>> Certainly not every "strlen" has these semantics. For example,
>>> this open-coded one doesn't:
>>>
>>> int len = 0;
>>> for (int i = 0; s.a[i]; ++i)
>>> ++len;
>>>
>>> It computes 2 (with
On 08/05/2018 11:27 AM, Richard Biener wrote:
On August 4, 2018 10:52:02 PM GMT+02:00, Martin Sebor wrote:
On 08/03/2018 01:43 AM, Jakub Jelinek wrote:
On Thu, Aug 02, 2018 at 09:59:13PM -0600, Martin Sebor wrote:
If I call this with foo (2, 1), do you still claim it is not valid
C?
On 07/27/2018 12:48 AM, Bernd Edlinger wrote:
> I have one more example similar to PR86259, that resembles IMHO real world
> code:
>
> Consider the following:
>
>
> int fun (char *p)
> {
> char buf[16];
>
> assert(strlen(p) < 4); //here: security relevant check
>
> sprintf(buf, "echo
On 08/04/2018 03:56 PM, Martin Sebor wrote:
> On 08/03/2018 01:00 AM, Jeff Law wrote:
>> On 07/24/2018 05:18 PM, Bernd Edlinger wrote:
>>> On 07/24/18 23:46, Jeff Law wrote:
On 07/24/2018 01:59 AM, Bernd Edlinger wrote:
> Hi!
>
> This patch makes strlen range computations more
On 08/03/2018 01:48 AM, Jakub Jelinek wrote:
> On Fri, Aug 03, 2018 at 01:19:14AM -0600, Jeff Law wrote:
>> I'm leaning towards a similar conclusion, namely that we can only rely
>> on type information for the pointer that actually gets passed to strlen,
>> which 99.9% of the time is (char *),
On 08/05/18 17:58, Jeff Law wrote:
> On 08/05/2018 12:08 AM, Bernd Edlinger wrote:
>> I see this from a software engineering POV.
>>
>> If we have code like this:
>>
>> void test (const char *x)
>> {
>> assert (strlen (x) < 10);
>> }
>>
>> One would usually expect the program to abort (or at
On August 4, 2018 10:52:02 PM GMT+02:00, Martin Sebor wrote:
>On 08/03/2018 01:43 AM, Jakub Jelinek wrote:
>> On Thu, Aug 02, 2018 at 09:59:13PM -0600, Martin Sebor wrote:
If I call this with foo (2, 1), do you still claim it is not valid
>C?
>>>
>>> String functions like strlen operate on
On 08/04/2018 02:52 PM, Martin Sebor wrote:
> On 08/03/2018 01:43 AM, Jakub Jelinek wrote:
>> On Thu, Aug 02, 2018 at 09:59:13PM -0600, Martin Sebor wrote:
If I call this with foo (2, 1), do you still claim it is not valid C?
>>>
>>> String functions like strlen operate on character strings
On 08/05/2018 12:08 AM, Bernd Edlinger wrote:
> On 08/04/18 23:56, Martin Sebor wrote:
>> On 08/03/2018 01:00 AM, Jeff Law wrote:
>>> On 07/24/2018 05:18 PM, Bernd Edlinger wrote:
On 07/24/18 23:46, Jeff Law wrote:
> On 07/24/2018 01:59 AM, Bernd Edlinger wrote:
>> Hi!
>>
>>
On 08/05/2018 12:51 AM, Bernd Edlinger wrote:
> On 08/04/18 22:52, Martin Sebor wrote:
>> On 08/03/2018 01:43 AM, Jakub Jelinek wrote:
>>> On Thu, Aug 02, 2018 at 09:59:13PM -0600, Martin Sebor wrote:
> If I call this with foo (2, 1), do you still claim it is not valid C?
String
On 08/04/18 22:52, Martin Sebor wrote:
> On 08/03/2018 01:43 AM, Jakub Jelinek wrote:
>> On Thu, Aug 02, 2018 at 09:59:13PM -0600, Martin Sebor wrote:
If I call this with foo (2, 1), do you still claim it is not valid C?
>>>
>>> String functions like strlen operate on character strings stored
On 08/04/18 23:56, Martin Sebor wrote:
> On 08/03/2018 01:00 AM, Jeff Law wrote:
>> On 07/24/2018 05:18 PM, Bernd Edlinger wrote:
>>> On 07/24/18 23:46, Jeff Law wrote:
On 07/24/2018 01:59 AM, Bernd Edlinger wrote:
> Hi!
>
> This patch makes strlen range computations more
On 08/03/2018 01:00 AM, Jeff Law wrote:
On 07/24/2018 05:18 PM, Bernd Edlinger wrote:
On 07/24/18 23:46, Jeff Law wrote:
On 07/24/2018 01:59 AM, Bernd Edlinger wrote:
Hi!
This patch makes strlen range computations more conservative.
Firstly if there is a visible type cast from type A to B
On 08/03/2018 01:43 AM, Jakub Jelinek wrote:
On Thu, Aug 02, 2018 at 09:59:13PM -0600, Martin Sebor wrote:
If I call this with foo (2, 1), do you still claim it is not valid C?
String functions like strlen operate on character strings stored
in character arrays. Calling strlen ([1]) is
On Fri, Aug 03, 2018 at 01:19:14AM -0600, Jeff Law wrote:
> I'm leaning towards a similar conclusion, namely that we can only rely
> on type information for the pointer that actually gets passed to strlen,
> which 99.9% of the time is (char *), potentially with const qualifiers.
You can't derive
On 08/01/2018 09:13 PM, Martin Sebor wrote:
> On 08/01/2018 01:19 AM, Richard Biener wrote:
>> On Tue, 31 Jul 2018, Martin Sebor wrote:
>>
>>> On 07/31/2018 09:48 AM, Jakub Jelinek wrote:
On Tue, Jul 31, 2018 at 09:17:52AM -0600, Martin Sebor wrote:
> On 07/31/2018 12:38 AM, Jakub Jelinek
On Thu, Aug 02, 2018 at 09:59:13PM -0600, Martin Sebor wrote:
> > If I call this with foo (2, 1), do you still claim it is not valid C?
>
> String functions like strlen operate on character strings stored
> in character arrays. Calling strlen ([1]) is invalid because
> [1] is not the address of
On 08/01/2018 01:19 AM, Richard Biener wrote:
> On Tue, 31 Jul 2018, Martin Sebor wrote:
>
>> On 07/31/2018 09:48 AM, Jakub Jelinek wrote:
>>> On Tue, Jul 31, 2018 at 09:17:52AM -0600, Martin Sebor wrote:
On 07/31/2018 12:38 AM, Jakub Jelinek wrote:
> On Mon, Jul 30, 2018 at 09:45:49PM
On 07/25/2018 01:36 PM, Martin Sebor wrote:
>> BUT - for the string_constant and c_strlen functions we are,
>> in all cases we return something interesting, able to look
>> at an initializer which then determines that type. Hopefully.
>> I think the strlen() folding code when it sets SSA ranges
On 07/25/2018 01:23 AM, Richard Biener wrote:
> On Tue, 24 Jul 2018, Bernd Edlinger wrote:
>
>> On 07/24/18 23:46, Jeff Law wrote:
>>> On 07/24/2018 01:59 AM, Bernd Edlinger wrote:
Hi!
This patch makes strlen range computations more conservative.
Firstly if there is a
On 07/24/2018 05:18 PM, Bernd Edlinger wrote:
> On 07/24/18 23:46, Jeff Law wrote:
>> On 07/24/2018 01:59 AM, Bernd Edlinger wrote:
>>> Hi!
>>>
>>> This patch makes strlen range computations more conservative.
>>>
>>> Firstly if there is a visible type cast from type A to B before passing
>>> then
On 08/01/2018 12:55 AM, Bernd Edlinger wrote:
Certainly not every "strlen" has these semantics. For example,
this open-coded one doesn't:
int len = 0;
for (int i = 0; s.a[i]; ++i)
++len;
It computes 2 (with no warning for the out-of-bounds access).
yes, which is questionable as
On 08/01/2018 02:40 AM, Jakub Jelinek wrote:
On Wed, Aug 01, 2018 at 09:19:43AM +0200, Richard Biener wrote:
And if so, what makes it well defined?
The fact that strlen takes a char * argument and thus inline-expansion
of a trivial implementation like
int len = 0;
for (; *p; ++p)
++len;
On 08/02/2018 12:20 PM, Jakub Jelinek wrote:
On Thu, Aug 02, 2018 at 11:00:32AM -0600, Martin Sebor wrote:
As an alternate approach I have been thinking about, if
there is a strong feeling that allowing strlen to iterate
past the subobject boundary is necessary (I don't believe
it is.)
Rather
On 08/02/2018 12:15 PM, Bernd Edlinger wrote:
On 08/02/18 19:00, Martin Sebor wrote:
As an alternate approach I have been thinking about, if
there is a strong feeling that allowing strlen to iterate
past the subobject boundary is necessary (I don't believe
it is.)
Rather than indiscriminately
On Thu, Aug 02, 2018 at 11:00:32AM -0600, Martin Sebor wrote:
> As an alternate approach I have been thinking about, if
> there is a strong feeling that allowing strlen to iterate
> past the subobject boundary is necessary (I don't believe
> it is.)
>
> Rather than indiscriminately expanding the
On 08/02/18 19:00, Martin Sebor wrote:
> As an alternate approach I have been thinking about, if
> there is a strong feeling that allowing strlen to iterate
> past the subobject boundary is necessary (I don't believe
> it is.)
>
> Rather than indiscriminately expanding the provenance of
> the
As an alternate approach I have been thinking about, if
there is a strong feeling that allowing strlen to iterate
past the subobject boundary is necessary (I don't believe
it is.)
Rather than indiscriminately expanding the provenance of
the subobject regardless of what members follow it in
the
On 07/25/2018 01:08 AM, Richard Biener wrote:
>>
>> So ISTM that you really need a stronger justification using the
>> standards compliance and/or real world code that is made less safe by
>> keeping string lengths as accurate as possible.
>
> Note you cannot solely look at what the C standard
On 08/02/2018 04:22 AM, Bernd Edlinger wrote:
Hi,
this is an update of the patch to prevent unsafe optimizations due to strlen
range assuming
always zero-terminated char arrays.
Since the previous version I do no longer try to locate the outermost char
array,
but just bail out if there is a
Hi,
this is an update of the patch to prevent unsafe optimizations due to strlen
range assuming
always zero-terminated char arrays.
Since the previous version I do no longer try to locate the outermost char
array,
but just bail out if there is a typecast, that means, supposed we have a
On 08/01/2018 01:19 AM, Richard Biener wrote:
On Tue, 31 Jul 2018, Martin Sebor wrote:
On 07/31/2018 09:48 AM, Jakub Jelinek wrote:
On Tue, Jul 31, 2018 at 09:17:52AM -0600, Martin Sebor wrote:
On 07/31/2018 12:38 AM, Jakub Jelinek wrote:
On Mon, Jul 30, 2018 at 09:45:49PM -0600, Martin
On Wed, Aug 01, 2018 at 09:19:43AM +0200, Richard Biener wrote:
> > And if so, what makes it well defined?
>
> The fact that strlen takes a char * argument and thus inline-expansion
> of a trivial implementation like
>
> int len = 0;
> for (; *p; ++p)
>++len;
>
> will have
>
> p =
>
>
1 - 100 of 119 matches
Mail list logo
