Division by ZERO on GIMPLE?

Division by ZERO on GIMPLE?

[Bin.Cheng]

Hi,
I just found some GIMPLE like below is generated during boostrap gcc
for x86, tree-vect-loop.c


  <bb 637>:
  # group_size_1432 = PHI <1(497), group_size_1017(660)>
  # scalar_dest_1287 = PHI <scalar_dest_1228(497), scalar_dest_1012(660)>
  ratio_1497 = group_size_1432 / 0;
  goto <bb 501>;

The compilation ends fine, but what is the division by 0?

Thanks,
bin

-- 
Best Regards.

Re: Division by ZERO on GIMPLE?

[Ian Lance Taylor]

On Sat, Dec 7, 2013 at 1:48 AM, Bin.Cheng <amker.cheng@gmail.com> wrote:
>
> I just found some GIMPLE like below is generated during boostrap gcc
> for x86, tree-vect-loop.c
>
>
>   <bb 637>:
>   # group_size_1432 = PHI <1(497), group_size_1017(660)>
>   # scalar_dest_1287 = PHI <scalar_dest_1228(497), scalar_dest_1012(660)>
>   ratio_1497 = group_size_1432 / 0;
>   goto <bb 501>;
>
> The compilation ends fine, but what is the division by 0?

Pretty hard to say without more information.  I just tried, and I
don't see it myself.  I would guess that some optimization split out
the ratio == 0 case for some reason.

Ian

Re: Division by ZERO on GIMPLE?

[Bin.Cheng]

On Sun, Dec 8, 2013 at 9:29 AM, Ian Lance Taylor <iant@google.com> wrote:
> On Sat, Dec 7, 2013 at 1:48 AM, Bin.Cheng <amker.cheng@gmail.com> wrote:
>>
>> I just found some GIMPLE like below is generated during boostrap gcc
>> for x86, tree-vect-loop.c
>>
>>
>>   <bb 637>:
>>   # group_size_1432 = PHI <1(497), group_size_1017(660)>
>>   # scalar_dest_1287 = PHI <scalar_dest_1228(497), scalar_dest_1012(660)>
>>   ratio_1497 = group_size_1432 / 0;
>>   goto <bb 501>;
>>
>> The compilation ends fine, but what is the division by 0?
>
> Pretty hard to say without more information.  I just tried, and I
> don't see it myself.  I would guess that some optimization split out
> the ratio == 0 case for some reason.

It disappeared with Richard's checkin r205730.  Also I am not sure is
why the rest of compiler can live with that code.

The configuration option for me is :
--disable-nls --disable-libmudflap --disable-libada --disable-libssp
--disable-libquadmath --disable-libgomp --disable-libffi
--disable-libstdcxx-pch --disable-tls --with-gnu-as --with-gnu-ld ...
--enable-languages=c,c++

Thanks,
bin

>
> Ian



-- 
Best Regards.

Re: Division by ZERO on GIMPLE?

[Bin.Cheng]

On Sun, Dec 8, 2013 at 8:16 PM, Bin.Cheng <amker.cheng@gmail.com> wrote:
> On Sun, Dec 8, 2013 at 9:29 AM, Ian Lance Taylor <iant@google.com> wrote:
>> On Sat, Dec 7, 2013 at 1:48 AM, Bin.Cheng <amker.cheng@gmail.com> wrote:
>>>
>>> I just found some GIMPLE like below is generated during boostrap gcc
>>> for x86, tree-vect-loop.c
>>>
>>>
>>>   <bb 637>:
>>>   # group_size_1432 = PHI <1(497), group_size_1017(660)>
>>>   # scalar_dest_1287 = PHI <scalar_dest_1228(497), scalar_dest_1012(660)>
>>>   ratio_1497 = group_size_1432 / 0;
>>>   goto <bb 501>;
>>>
>>> The compilation ends fine, but what is the division by 0?
>>
>> Pretty hard to say without more information.  I just tried, and I
>> don't see it myself.  I would guess that some optimization split out
>> the ratio == 0 case for some reason.
>
> It disappeared with Richard's checkin r205730.  Also I am not sure is
> why the rest of compiler can live with that code.
>
> The configuration option for me is :
> --disable-nls --disable-libmudflap --disable-libada --disable-libssp
> --disable-libquadmath --disable-libgomp --disable-libffi
> --disable-libstdcxx-pch --disable-tls --with-gnu-as --with-gnu-ld ...
> --enable-languages=c,c++
>

And the assembly finally generated is like:
.L4387:
    movl    40(%esp), %eax    # 6902    *movsi_internal/1    [length = 4]
    xorl    %ecx, %ecx    # 7442    *movsi_xor    [length = 2]
<----------------------
    xorl    %edx, %edx    # 7443    *movsi_xor    [length = 2]
    divl    %ecx    # 7177    *udivmodsi4_noext    [length = 2]
<----------------------
    movl    %eax, 68(%esp)    # 6903    *movsi_internal/2    [length = 4]
    jmp    .L4474    # 8252    jump    [length = 5]

Thanks,
bin

-- 
Best Regards.

Re: Division by ZERO on GIMPLE?

[Ian Lance Taylor]

On Sun, Dec 8, 2013 at 4:16 AM, Bin.Cheng <amker.cheng@gmail.com> wrote:
> On Sun, Dec 8, 2013 at 9:29 AM, Ian Lance Taylor <iant@google.com> wrote:
>> On Sat, Dec 7, 2013 at 1:48 AM, Bin.Cheng <amker.cheng@gmail.com> wrote:
>>>
>>> I just found some GIMPLE like below is generated during boostrap gcc
>>> for x86, tree-vect-loop.c
>>>
>>>
>>>   <bb 637>:
>>>   # group_size_1432 = PHI <1(497), group_size_1017(660)>
>>>   # scalar_dest_1287 = PHI <scalar_dest_1228(497), scalar_dest_1012(660)>
>>>   ratio_1497 = group_size_1432 / 0;
>>>   goto <bb 501>;
>>>
>>> The compilation ends fine, but what is the division by 0?
>>
>> Pretty hard to say without more information.  I just tried, and I
>> don't see it myself.  I would guess that some optimization split out
>> the ratio == 0 case for some reason.
>
> It disappeared with Richard's checkin r205730.  Also I am not sure is
> why the rest of compiler can live with that code.

The compiler doesn't much care if you divide by zero.  Even if the
programmer doesn't do such a thing, there are many ways that CSE can
produce an integer division by zero.  Code that divides an integer by
zero is valid C/C++ as long as it is never executed.  In fact, code
that divides an integer by zero is valid Go even if it does get
executed--Go defines what happens when an integer division by zero
occurs (you get a runtime panic that can be caught).  So while I
understand that the code looks odd, there is no reason the compiler
shouldn't be able to handle it.

Ian

Re: Division by ZERO on GIMPLE?

[Bin.Cheng]

On Mon, Dec 9, 2013 at 3:03 AM, Ian Lance Taylor <iant@google.com> wrote:
> On Sun, Dec 8, 2013 at 4:16 AM, Bin.Cheng <amker.cheng@gmail.com> wrote:
>> On Sun, Dec 8, 2013 at 9:29 AM, Ian Lance Taylor <iant@google.com> wrote:
>>> On Sat, Dec 7, 2013 at 1:48 AM, Bin.Cheng <amker.cheng@gmail.com> wrote:
>>>>
>>>> I just found some GIMPLE like below is generated during boostrap gcc
>>>> for x86, tree-vect-loop.c
>>>>
>>>>
>>>>   <bb 637>:
>>>>   # group_size_1432 = PHI <1(497), group_size_1017(660)>
>>>>   # scalar_dest_1287 = PHI <scalar_dest_1228(497), scalar_dest_1012(660)>
>>>>   ratio_1497 = group_size_1432 / 0;
>>>>   goto <bb 501>;
>>>>
>>>> The compilation ends fine, but what is the division by 0?
>>>
>>> Pretty hard to say without more information.  I just tried, and I
>>> don't see it myself.  I would guess that some optimization split out
>>> the ratio == 0 case for some reason.
>>
>> It disappeared with Richard's checkin r205730.  Also I am not sure is
>> why the rest of compiler can live with that code.
>
> The compiler doesn't much care if you divide by zero.  Even if the
> programmer doesn't do such a thing, there are many ways that CSE can
> produce an integer division by zero.  Code that divides an integer by
> zero is valid C/C++ as long as it is never executed.  In fact, code
> that divides an integer by zero is valid Go even if it does get
> executed--Go defines what happens when an integer division by zero
> occurs (you get a runtime panic that can be caught).  So while I
> understand that the code looks odd, there is no reason the compiler
> shouldn't be able to handle it.
Hi Ian, thanks for your explanation.

Thanks,
bin

>
> Ian



-- 
Best Regards.

Re: Division by ZERO on GIMPLE?

[Jeff Law]

On 12/08/13 05:16, Bin.Cheng wrote:
> On Sun, Dec 8, 2013 at 9:29 AM, Ian Lance Taylor <iant@google.com> wrote:
>> On Sat, Dec 7, 2013 at 1:48 AM, Bin.Cheng <amker.cheng@gmail.com> wrote:
>>>
>>> I just found some GIMPLE like below is generated during boostrap gcc
>>> for x86, tree-vect-loop.c
>>>
>>>
>>>    <bb 637>:
>>>    # group_size_1432 = PHI <1(497), group_size_1017(660)>
>>>    # scalar_dest_1287 = PHI <scalar_dest_1228(497), scalar_dest_1012(660)>
>>>    ratio_1497 = group_size_1432 / 0;
>>>    goto <bb 501>;
>>>
>>> The compilation ends fine, but what is the division by 0?
>>
>> Pretty hard to say without more information.  I just tried, and I
>> don't see it myself.  I would guess that some optimization split out
>> the ratio == 0 case for some reason.
>
> It disappeared with Richard's checkin r205730.  Also I am not sure is
> why the rest of compiler can live with that code.
Well, in an ideal world we'd detect this, isolate the path, emit a trap 
after the /0, remove all the outgoing edges and issue a warning.    I'll 
put it on the TODO list.

As long as the compiler doesn't try to evaluate that code, then it 
should not cause an problems.  It's not significantly different than if 
there was a divide by an SSA_NAME where the SSA_NAME might have the 
value zero.

jeff