[PR72835] Incorrect arithmetic optimization involving bitfield arguments

kugan kugan.vivekanandarajah@linaro.org
Tue Aug 9 21:53:00 GMT 2016


Hi Andrew,

On 10/08/16 07:50, Andrew Pinski wrote:
> On Tue, Aug 9, 2016 at 2:42 PM, kugan <kugan.vivekanandarajah@linaro.org> wrote:
>>
>>
>> On 09/08/16 23:43, kugan wrote:
>>>
>>> Hi,
>>>
>>> The test-case in PR72835 is failing with -O2 and passing with
>>> -fno-tree-reassoc. It also passes with -O2 -fno-tree-vrp.
>>>
>>> diff of .115t.dse2 and .116t.reassoc1 for the c++ testcase is as
>>> follows, which looks OK.
>>>
>>> +  unsigned int _16;
>>> +  unsigned int _17;
>>> +  unsigned int _18;
>>>
>>>     <bb 2>:
>>>     _1 = s1.m2;
>>>     _2 = (unsigned int) _1;
>>>     _3 = s1.m3;
>>>     _4 = (unsigned int) _3;
>>> -  _5 = -_4;
>>> -  _6 = _2 * _5;
>>> +  _5 = _4;
>>> +  _6 = _5 * _2;
>>>     var_32.0_7 = var_32;
>>>     _8 = (unsigned int) var_32.0_7;
>>>     _9 = s1.m1;
>>>     _10 = (unsigned int) _9;
>>> -  _11 = -_10;
>>> -  _12 = _8 * _11;
>>> -  c_14 = _6 + _12;
>>> +  _11 = _10;
>>> +  _12 = _11 * _8;
>>> +  _16 = _12 + _6;
>>> +  _18 = _16;
>>> +  _17 = -_18;
>>> +  c_14 = _17;
>>>     if (c_14 != 4098873984)
>>>
>>>
>>> However, I noticed that when we re-associate and assign different
>>> operands to the stmts, we are not resetting the flow information to the
>>> LHS. This looks wrong. Attached patch resets it. With this, the
>>> testcases in TH PR is now working.
>>>
>>>
>>> Bootstrap and regression testing for x86_64-linux-gnu is in progress. Is
>>> this OK for trunk if there is no regression.
>>
>>
>> There was no new regression while testing. I also moved the testcase from
>> gcc.dg/torture/pr72835.c to gcc.dg/tree-ssa/pr72835.c. Is this OK for trunk?
>
>
> Why did you move the test-case from gcc.dg/torture to gcc.dg/tree-ssa?
>  I think most executable testcases (that was using standard options)
> should be in tortue testcases to do a full sweep of the options.

I thought It was unnecessary to run with all the options as -O2 would 
trigger this. I am OK with moving it to gcc.dg/torture/pr72835.c if you 
prefer.

Thanks,
Kugan



More information about the Gcc-patches mailing list