On 09/13/2017 07:42 AM, Martin Liška wrote: > On 09/13/2017 03:08 PM, Martin Liška wrote: >> On 09/12/2017 05:21 PM, Jeff Law wrote: >>> On 09/12/2017 01:43 AM, Martin Liška wrote: >>>> Hello. >>>> >>>> In transition to simple_case_node, I forgot to initialize m_high to m_low >>>> if a case >>>> does not have CASE_HIGH. >>>> >>>> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. >>>> >>>> Ready to be installed? >>>> Martin >>>> >>>> gcc/ChangeLog: >>>> >>>> 2017-09-11 Martin Liska <mli...@suse.cz> >>>> >>>> PR middle-end/82154 >>>> * stmt.c (struct simple_case_node): Assign low to high when >>>> high is equal to null. >>>> >>>> gcc/testsuite/ChangeLog: >>>> >>>> 2017-09-11 Martin Liska <mli...@suse.cz> >>>> >>>> PR middle-end/82154 >>>> * g++.dg/torture/pr82154.C: New test. >>> OK. >>> >>> THough I have to wonder if we should unify the HIGH handling -- having >>> two different conventions is bound to be confusing. >>> >>> In a CASE_LABEL_EXPR the CASE_HIGH can be NULL, which means the label >>> refers to a singleton value that is found in CASE_LOW. >>> >>> That means we end up doing stuff like this: >>> >>> if (CASE_HIGH (elt)) >>> maxval = fold_convert (index_type, CASE_HIGH (elt)); >>> else >>> maxval = fold_convert (index_type, CASE_LOW (elt)); >>> >>> >>> >>> You could legitimately argue for changing how this works for tree nodes >>> so that there's always a non-null CASE_HIGH. >> >> Hi. >> >> Agree with you that we have a lot of code that does what you just described. >> I tent to change IL representation, where CASE_HIGH is always non-null. >> >> $ git grep 'CASE_HIGH\>' | wc -l >> 125 >> >> Which is reasonable amount of code that should be changed. I'll prepare >> patch for that. > > Hm, there's one question that pops up: Should we compare the values via > pointer equality, > or tree_int_cst_eq should be done? The later one can messy the code a bit. I'd like to say pointer equality, but it's probably safer to use tree_int_cst_eq.
jeff
