| Message ID | d3aeea6e-d50d-fd0a-d3b3-ec5e644e3a35@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | convert MIN_EXPR operands to the same type (PR 87059) | expand |
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. jeff
On Sat, Aug 25, 2018 at 12:13 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. This caused: [hjl@gnu-skl-1 gcc]$ /export/gnu/import/git/gcc-test/bld/gcc/xgcc -B/export/gnu/import/git/gcc-test/bld/gcc/ /export/gnu/import/git/gcc-test/src-trunk/gcc/testsuite/gcc.c-torture/execute/builtins/strnlen.c /export/gnu/import/git/gcc-test/src-trunk/gcc/testsuite/gcc.c-torture/execute/builtins/strnlen-lib.c /export/gnu/import/git/gcc-test/src-trunk/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c -w -O -S during RTL pass: expand /export/gnu/import/git/gcc-test/src-trunk/gcc/testsuite/gcc.c-torture/execute/builtins/strnlen.c: In function \u2018test_strnlen_str_range\u2019: /export/gnu/import/git/gcc-test/src-trunk/gcc/testsuite/gcc.c-torture/execute/builtins/strnlen.c:51:6: internal compiler error: in fold_binary_loc, at fold-const.c:9333 51 | A (strnlen ("", r_0_3) == 0); | ^~~~~~~~~~~~~~~~~~~~~~~ /export/gnu/import/git/gcc-test/src-trunk/gcc/testsuite/gcc.c-torture/execute/builtins/strnlen.c:14:5: note: in definition of macro \u2018A\u2019 14 | ((expr) ? (void)0 \ | ^~~~ 0x61197a fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) ../../src-trunk/gcc/fold-const.c:9333 0xa1ff1a fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) ../../src-trunk/gcc/fold-const.c:12360 0x88b881 expand_builtin_strnlen ../../src-trunk/gcc/builtins.c:3023 0x897d85 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int) ../../src-trunk/gcc/builtins.c:7331 0x9e2177 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../src-trunk/gcc/expr.c:10943 0x9ecf8d expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../src-trunk/gcc/expr.c:8209 0x9ecf8d store_expr(tree_node*, rtx_def*, int, bool, bool) ../../src-trunk/gcc/expr.c:5636 0x9ee887 expand_assignment(tree_node*, tree_node*, bool) ../../src-trunk/gcc/expr.c:5420 0x8ba0a2 expand_call_stmt ../../src-trunk/gcc/cfgexpand.c:2685 0x8ba0a2 expand_gimple_stmt_1 ../../src-trunk/gcc/cfgexpand.c:3575 0x8ba0a2 expand_gimple_stmt ../../src-trunk/gcc/cfgexpand.c:3734 0x8bb307 expand_gimple_basic_block ../../src-trunk/gcc/cfgexpand.c:5770 0x8c04f7 execute ../../src-trunk/gcc/cfgexpand.c:6373 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. [hjl@gnu-skl-1 gcc]$
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. Thanks, Richard. > jeff
On 08/27/2018 10: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. The assert is causing: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87112 Martin > > Thanks, > Richard. > >> jeff
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? Martin
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. I almost called out the assertion. We generally verify this kind of stuff in the verify_gimple routines and haphazard asserts in the folder would be just that -- haphazard. The value in Martin's assertion is to catch the goof earlier. But I won't lose sleep if we drop the assert. jeff
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 >
On Mon, Aug 27, 2018 at 5:27 PM Jeff Law <law@redhat.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. > I almost called out the assertion. We generally verify this kind of > stuff in the verify_gimple routines and haphazard asserts in the folder > would be just that -- haphazard. > > The value in Martin's assertion is to catch the goof earlier. But I > won't lose sleep if we drop the assert. There's gazillion places where we could catch things "earlier" but I think we have to be careful where we start placing stuff and if we do it do it consistently. MIN/MAX doesn't have much coverage so you won't see latent issues (well, one just popped up in the testsuite for MIN/MAX...). Note that fold_* really wants matching TYPE_MAIN_VARIANT but we absolutely know we have entries from GIMPLE where that requirement is not met! So fold_* isn't a good place to do this kind of checks. Richard. > jeff
On 08/27/2018 09:28 AM, Richard Biener wrote: > 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. So where should we check these things (or what's a good way to make this less error-prone -- would documenting what kind of assertions are appropriate be a good way to go? Or add an API that did the validation for all EXPRs that require operands of the same type?) The ICE in the original bug report was hard to reproduce (it didn't trigger in an x86_64 bootstrap and apparently even needed a patched powerpc64le cross compiler to bring about). I added the assertion to catch these kinds of mistakes more readily. FWIW, I had used TYPE_MAIN_VARIANT initially but as you said, it triggered ICEs in the test suite so I relaxed the assertion it to the current state. Martin
On Mon, Aug 27, 2018 at 5:51 PM Martin Sebor <msebor@gmail.com> wrote: > > On 08/27/2018 09:28 AM, Richard Biener wrote: > > 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. > > So where should we check these things (or what's a good way to > make this less error-prone -- would documenting what kind of > assertions are appropriate be a good way to go? Or add an API > that did the validation for all EXPRs that require operands > of the same type?) If you need to catch bogus entries to fold_* then of course the place to instrument is fold_*. > The ICE in the original bug report was hard to reproduce (it > didn't trigger in an x86_64 bootstrap and apparently even needed > a patched powerpc64le cross compiler to bring about). I added > the assertion to catch these kinds of mistakes more readily. > > FWIW, I had used TYPE_MAIN_VARIANT initially but as you said, > it triggered ICEs in the test suite so I relaxed the assertion > it to the current state. But then it's of course less useful. You could go for the GIMPLE requirements given when GENERIC ones are fulfilled GIMPLE ones are as well. That would be types_compatible_p () which of course is even more expensive. So if we decide to go the way of instrumenting fold_* entries then I'd go for sth like if (flag_checking) switch (code) { case ...: verify; default: gcc_unreachable (); } but note that FE specific trees may appear here as well. If we decide we want to verify GIMPLE requirements only then please refactor tree-cfg.c:verify_gimple_assign_binary and friends to split out the type verification part so we could share that from other places and not duplicate things. Be prepared to fix a _lot_ of code (as I did when I originally added the verify_gimple_* stuff). Mostly stuff will be harmless but calling out "exceptions" in the verification code itself is bad. Richard. > Martin >
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. Done after a bootstrap and regression test on x86. jeff
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. diff --git a/gcc/builtins.c b/gcc/builtins.c index b1a79f3..6a992bd 100644 --- a/gcc/builtins.c +++ b/gcc/builtins.c @@ -4759,7 +4759,10 @@ expand_builtin_strncmp (tree exp, ATTRIBUTE_UNUSED rtx target, /* If we are not using the given length, we must incorporate it here. The actual new length parameter will be MIN(len,arg3) in this case. */ if (len != len3) - len = fold_build2_loc (loc, MIN_EXPR, TREE_TYPE (len), len, len3); + { + len = fold_convert_loc (loc, sizetype, len); + len = fold_build2_loc (loc, MIN_EXPR, TREE_TYPE (len), len, len3); + } rtx arg1_rtx = get_memory_rtx (arg1, len); rtx arg2_rtx = get_memory_rtx (arg2, len); rtx arg3_rtx = expand_normal (len); diff --git a/gcc/fold-const.c b/gcc/fold-const.c index b318fc77..1e44a24 100644 --- a/gcc/fold-const.c +++ b/gcc/fold-const.c @@ -9326,6 +9326,14 @@ fold_binary_loc (location_t loc, enum tree_code code, tree type, if (kind == tcc_comparison || code == MIN_EXPR || code == MAX_EXPR) { + if (code == MIN_EXPR || code == MAX_EXPR) + { + tree typ0 = TREE_TYPE (arg0); + tree typ1 = TREE_TYPE (arg1); + gcc_assert (TYPE_SIGN (typ0) == TYPE_SIGN (typ1) + && TYPE_MODE (typ0) == TYPE_MODE (typ1)); + } + STRIP_SIGN_NOPS (arg0); STRIP_SIGN_NOPS (arg1); }