This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix emission of exception dispatch (PR middle-end/82154).


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  <mliska@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  <mliska@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]