[16] RFR(S): 8248552: C2 crashes with SIGFPE due to division by zero

[Christian Hagedorn]

A test in some later tier testing revealed that the assertion code is 
actually too strong. There can be a Div/Mod node whose zero check was 
removed but that is then spilt through a non-induction-variable phi 
whose inputs have zero in their type range (which is fine, this happens 
in some loop opts after partial peeling was applied earlier). This 
happened, for example, for a phi which merged two nodes from the 
original and a cloned loop. I think we just need to remove the 
additional assertion code.

New webrev:
http://cr.openjdk.java.net/~chagedorn/8248552/webrev.01/

Best regards,
Christian

On 13.07.20 09:19, Christian Hagedorn wrote:
> Thank you Vladimir for your review!
> 
> Best regards,
> Christian
> 
> On 11.07.20 01:25, Vladimir Kozlov wrote:
>> Looks good.
>>
>> Thanks,
>> Vladimir
>>
>> On 7/10/20 12:37 AM, Christian Hagedorn wrote:
>>> Hi
>>>
>>> Please review the following patch:
>>> https://bugs.openjdk.java.net/browse/JDK-8248552
>>> http://cr.openjdk.java.net/~chagedorn/8248552/webrev.00/
>>>
>>> In the failing testcase, C2 removes a zero check for a 
>>> division/modulo node n based on the type information of the loop 
>>> induction variable phi p (always between 1 and 50 and never 0). 
>>> However, n is later split through p and ends up after the AddNode 
>>> which updates the induction variable p. In the last iteration j 
>>> equals 2 and is then updated to 0. The division/modulo node n is now 
>>> executed before the loop limit check which results in a SIGFPE.
>>>
>>> The fix bails out of PhaseIdealLoop::split_thru_phi if a division or 
>>> modulo node has its zero check removed (i.e. control in NULL) and is 
>>> split through a phi which has an input that could be zero. This 
>>> should only happen for an induction variable phi of a trip-counted 
>>> (integer) loop.
>>>
>>> Best regards,
>>> Christian