[PATCH] Make strlen range computations more conservative

[Maxim Kuvyrkov]

Hi Bernd,

Ack, thanks!  I've just enabled this CI loop, and it is churning through commits since May.

Regards,

--
Maxim Kuvyrkov
www.linaro.org



> On Oct 24, 2018, at 5:04 PM, Bernd Edlinger <bernd.edlinger@hotmail.de> wrote:
> 
> 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): Handle case where the reference's
> 	type does not have a TYPE_SIZE_UNIT.
> 
> 	* gcc.c-torture/compile/dse.c: New test.
> ------------------------------------------------------------------------
> $ svn log -r263906
> ------------------------------------------------------------------------
> r263906 | law | 2018-08-28 06:02:11 +0200 (Tue, 28 Aug 2018) | 6 lines
> 
> 	PR tree-optimization/87110
> 	* tree-ssa-dse.c (compute_trims): Handle non-constant
> 	TYPE_SIZE_UNIT.
> 
> 	PR tree-optimization/87110
> 	* gcc.c-torture/compile/pr87110.c: New test.
> ------------------------------------------------------------------------
> 
> I believe not having those applied is causing the segfault you are seeing.
> 
> 
> Bernd.
> 
> 
> On 10/24/18 7:46 AM, Maxim Kuvyrkov wrote:
>> 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
>> git_branch[linux]=linux-4.14.y
>> git_repo[gcc]=git://gcc.gnu.org/git/gcc.git
>> git_branch[gcc]=master
>> linux_config=allmodconfig
>> ===
>> 
>> The bisection artifacts point at this exact commit:
>> Parent commit 0584c3707994997f5dc9fa79732d01a53c25db6a can build 18083 objects.
>> This commit d0eb64b248a9e40dfa633c4e4baebc3b238fd6eb can build 18076 objects from the same linux tree.
>> 
>> The relevant error (see [1]):
>> ==
>> during GIMPLE pass: dse
>> drivers/md/dm-mpath.c: In function 'multipath_init_per_bio_data':
>> drivers/md/dm-mpath.c:2032:1: internal compiler error: Segmentation fault
>> ==
>> 
>> Full bisection artifacts are at [2].
>> 
>> Bernd, would you please investigate?
>> 
>> IMO, this should be easy to reproduce from the bisection logs, but let me know if it's not straightforward.  Best ping on IRC (I'm maximk) or follow up here.
>> 
>> FYI, there is another regression (either caused or unmasked by Kugan's gcc commit b88c25691cf8b153db44108935db871e1d40db89), but it appears orthogonal to this one.
>> 
>> [1] https://ci.linaro.org/view/tcwg_kernel-gnu/job/tcwg_kernel-bisect-gnu-master-aarch64-lts-allmodconfig/8/artifact/artifacts/build-d0eb64b248a9e40dfa633c4e4baebc3b238fd6eb/5-count_linux_objs/console.log/*view*/
>> 
>> [2] https://ci.linaro.org/view/tcwg_kernel-gnu/job/tcwg_kernel-bisect-gnu-master-aarch64-lts-allmodconfig/8/artifact/artifacts/
>> 
>> Regards,
>> 
>> --
>> Maxim Kuvyrkov
>> www.linaro.org
>> 
>> 
>> 
>>> On Aug 22, 2018, at 2:43 AM, Jeff Law <law@redhat.com> 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.000000000 +0200
>>>> +++ gcc/tree-ssa-dse.c	2018-08-19 14:29:32.344498771 +0200
>>>> @@ -248,6 +248,12 @@ compute_trims (ao_ref *ref, sbitmap live
>>>> 	 residual handling in mem* and str* functions is usually
>>>> 	 reasonably efficient.  */
>>>>       *trim_tail = last_orig - last_live;
>>>> +      /* Don't fold away an out of bounds access, as this defeats proper
>>>> +	 warnings.  */
>>>> +      if (*trim_tail
>>>> +	  && compare_tree_int (TYPE_SIZE_UNIT (TREE_TYPE (ref->base)),
>>>> +			       last_orig) <= 0)
>>>> +	*trim_tail = 0;
>>>>     }
>>>>   else
>>>>     *trim_tail = 0;
>>> This seems like a good change in and of itself and should be able to go
>>> forward without further review work.   Consider this hunk approved,
>>> along with any testsuite you have which tickles this code (I didn't
>>> immediately see one attached to this patch.  But I could have missed it).
>>> 
>>> Jeff
>>