This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix pdftex miscompilation due to get_range_strlen (PR tree-optimization/84478)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Martin Sebor <msebor at gmail dot com>, Richard Biener <rguenther at suse dot de>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 21 Feb 2018 08:29:56 +0100
- Subject: Re: [PATCH] Fix pdftex miscompilation due to get_range_strlen (PR tree-optimization/84478)
- Authentication-results: sourceware.org; auth=none
- References: <20180220171712.GH5867@tucnak> <d959a1e4-5dfd-c9ce-8e3d-e77f3195faec@gmail.com> <20180220204948.GJ5867@tucnak> <6f9446cc-e61c-7f6b-1270-2b47546726f2@gmail.com> <20180221001451.GL5867@tucnak> <9fb6cf46-de50-9239-6fd5-4b623949f4a3@redhat.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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 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 correct to ignore the possibility that unknown
> >> arguments may be shorter than the minimum or longer than
> >> the maximum. The fuzzy argument was meant to differentiate
> >> between two got but I forgot about it when I added the fix
> >> for PR 83671.
> >
> > get_range_strlen (the 2 argument one) is right now called:
> > 3 times from builtins.c for -Wstringop-overflow
> > once from gimple-ssa-sprintf.c for -Wformat-overflow
> > once from tree-ssa-strlen.c for -Wstringop-truncation
> > once from gimple-fold.c for gimple_fold_builtin_strlen value ranges
> Presumably it's the last one that's causing problems and were we should
> focus our effort.
Sure. And that is what my patches do, not change anything for the
warning cases and fix up the non-warning one.
> > Looking at strlenopt-40.c testcase, in the test you clearly rely on
> > fuzzy argument being set for the value ranges case
> > (gimple_fold_builtin_strlen), otherwise many of the
> > subtests would fail.
> Which tests specifically? I did a real quick scan and didn't see
> anything in there that depended on incorrect behavior for the call from
> gimple_fold_builtin_strlen. BUt it was a quick scan and I could have
> missed something.
elim_global_arrays, elim_pointer_to_arrays etc. Basically, calling strlen
on an array of known fixed length and checking that the upper bound of it is
at most the array size minus 1.
Jakub