[Bug middle-end/109578] New: fail to remove dead code due to division by zero

[Bug middle-end/109578] New: fail to remove dead code due to division by zero

[vincent-gcc at vinc17 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109578

            Bug ID: 109578
           Summary: fail to remove dead code due to division by zero
           Product: gcc
           Version: 12.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

This is about the opposite of the invalid bug 29968:

#include <stdio.h>

int f (int i, int k)
{
  if (k == 0)
    printf ("k = 0\n");
  return i/k;
}

int main (void)
{
  return f (1, 0);
}

With gcc-12 (Debian 12.2.0-14) 12.2.0 and -O3 optimization, I get:

k = 0
zsh: illegal hardware instruction (core dumped)  ./tst

But since the case k == 0 corresponds to an undefined behavior (which is the
justification behind that GCC is correct in bug 29968), the code

  if (k == 0)
    printf ("k = 0\n");

should have been removed as an optimization.

[Bug middle-end/109578] fail to remove dead code due to division by zero

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109578

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
We don't removing code before undefined behavior ...
That is GCC does not know that printf  does not have side effects.

[Bug middle-end/109578] fail to remove dead code due to division by zero

[vincent-gcc at vinc17 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109578

--- Comment #2 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Andrew Pinski from comment #1)
> We don't removing code before undefined behavior ...
> That is GCC does not know that printf  does not have side effects.

Then GCC is incorrect in bug 29968, because it does the division *before* the
printf.

[Bug middle-end/109578] fail to remove dead code due to division by zero

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109578

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Vincent Lefèvre from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > We don't removing code before undefined behavior ...
> > That is GCC does not know that printf  does not have side effects.
> 
> Then GCC is incorrect in bug 29968, because it does the division *before*
> the printf.

Or was a bug which has since been fixed.

For sparc GCC 12.2.0 we get:
        sethi   %hi(.LC0), %o0
        call    puts, 0
         or     %o0, %lo(.LC0), %o0
        ta      5

Anyways maybe the issue with PR 29968 was a scheduling issue which was fixed
later on that GCC didn't realize divide could trap.

[Bug middle-end/109578] fail to remove dead code due to division by zero

[vincent-gcc at vinc17 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109578

--- Comment #4 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Andrew Pinski from comment #3)
> Anyways maybe the issue with PR 29968 was a scheduling issue which was fixed
> later on that GCC didn't realize divide could trap.

OK, thanks, I can see your update marking PR 29968 as a duplicate of PR 41239
(fixed).

[Bug middle-end/109578] fail to remove dead code due to division by zero

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109578

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #3)
> Anyways maybe the issue with PR 29968 was a scheduling issue which was fixed
> later on that GCC didn't realize divide could trap.

I was right on that, it was a dup of bug 41239 which was fixed in GCC 4.5.0.
The problem was exactly what I thought it was, a trapping instruction being
scheduled before the call. And yes it has been fixed for a long time, 13 years
in fact.