This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] convert MIN_EXPR operands to the same type (PR 87059)
On Mon, Aug 27, 2018 at 4:41 PM Martin Sebor <msebor@gmail.com> wrote:
>
> On 08/27/2018 02:32 AM, Richard Biener wrote:
> > On Sat, Aug 25, 2018 at 9:14 PM Jeff Law <law@redhat.com> wrote:
> >>
> >> On 08/24/2018 01:06 PM, Martin Sebor wrote:
> >>> PR 87059 points out an ICE in the recently enhanced VRP code
> >>> that was traced back to a MIN_EXPR built out of operands of
> >>> types with different sign by expand_builtin_strncmp().
> >>>
> >>> The attached patch adjusts the function to make sure both
> >>> operands have the same type, and to make these mismatches
> >>> easier to detect, also adds an assertion to fold_binary_loc()
> >>> for these expressions.
> >>>
> >>> Bootstrapped on x86_64-linux.
> >>>
> >>> Martin
> >>>
> >>> PS Aldy, I have not tested this on powerpc64le.
> >>>
> >>> gcc-87059.diff
> >>>
> >>>
> >>> PR tree-optimization/87059 - internal compiler error: in set_value_range
> >>>
> >>> gcc/ChangeLog:
> >>>
> >>> PR tree-optimization/87059
> >>> * builtins.c (expand_builtin_strncmp): Convert MIN_EXPR operand
> >>> to the same type as the other.
> >>> * fold-const.c (fold_binary_loc): Assert expectation.
> >> I bootstrapped (but did not regression test) this on ppc64le and also
> >> built the linux kernel (which is where my tester tripped over this problem).
> >>
> >> Approved and installed on the trunk.
> >
> > Please remove the assertion in fold_binary_loc again, we do not do this kind
> > of assertions there.
>
> What kind of assertions are appropriate here and what's a better
> place to make sure the MIN/MAX expression operands are valid, i.e.,
> have the same type or sign or whatever the downstream assumptions
> are?
Generally we have such checks in place for IL verification. There's also
a separate fold-checking mode (but checking unrelated stuff only at the
moment).
fold is heavily used so slowing it down isn't wanted. You'll also run into
existing issues too easily if you really pin down types to requirements
(matching TYPE_MAIN_VARIANT).
So just checking MIN/MAX for matching mode and sign just invites
for more random checks here.
Richard.
>
> Martin
>