[Bug tree-optimization/113271] New: [Regression] Wrong code at -O1/2/3 since GCC-9 (could be due to wrong optimization)

[Bug tree-optimization/113271] New: [Regression] Wrong code at -O1/2/3 since GCC-9 (could be due to wrong optimization)

[652023330028 at smail dot nju.edu.cn]

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

            Bug ID: 113271
           Summary: [Regression] Wrong code at -O1/2/3 since GCC-9 (could
                    be due to wrong optimization)
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: 652023330028 at smail dot nju.edu.cn
  Target Milestone: ---

Hello, we note that gcc may introduce erroneous code due to optimization:

https://godbolt.org/z/8vbn3KdqP

#include <iostream>
int a, b, c;
void func() {
    a=-b;
    //std::cout<<-a<<std::endl;    //Line 5
    c=(a)/(-2147483647-1);
}

int main(){
    b= -2147483647 - 1;
    func();
    std::cout<<c;
}

The output of GCC-O0 is:
1

The output of GCC-O3 is:
0

If we uncomment the fifth line:
#include <iostream>
int a, b, c;
void func() {
    a=-b;
    std::cout<<-a<<std::endl;    //Line 5
    c=(a)/(-2147483647-1);
}

int main(){
    b= -2147483647 - 1;
    func();
    std::cout<<c;
}

we get the correct output (GCC-O3):
-2147483648
1

This issue is probably due to a bad optimization of "func" by gcc -O3:
func():
        mov     DWORD PTR c[rip], 0
        mov     eax, DWORD PTR b[rip]
        neg     eax
        mov     DWORD PTR a[rip], eax
        ret

Thank you very much for your time and effort! We look forward to hearing from
you.

[Bug tree-optimization/113271] [Regression] Wrong code at -O1/2/3 since GCC-9 (could be due to wrong optimization)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Garbage in, garbage out.
This is UB, as can be seen if you compile with -fsanitize=undefined:
runtime error: negation of -2147483648 cannot be represented in type 'int';
cast to an unsigned type to negate this value to itself

[Bug tree-optimization/113271] [Regression] Wrong code at -O1/2/3 since GCC-9 (could be due to wrong optimization)

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xry111 at gcc dot gnu.org

--- Comment #2 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
-fsanitize=undefined is even explicitly mentioned in the bug report guideline
at https://gcc.gnu.org/bugs/.  And the red banner in the new bug page also
mentions -fwrapv.

[Bug tree-optimization/113271] [Regression] Wrong code at -O1/2/3 since GCC-9 (could be due to wrong optimization)

[652023330028 at smail dot nju.edu.cn]

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

--- Comment #3 from Yi <652023330028 at smail dot nju.edu.cn> ---
(In reply to Xi Ruoyao from comment #2)
> -fsanitize=undefined is even explicitly mentioned in the bug report
> guideline at https://gcc.gnu.org/bugs/.  And the red banner in the new bug
> page also mentions -fwrapv.

I'm sorry about this issue. I knew what you mentioned. I seemed a little out of
my mind when I brought up the issue.



(In reply to Jakub Jelinek from comment #1)
> This is UB, as can be seen if you compile with -fsanitize=undefined:

I'm sorry again.