[Bug c/108718] New: csmith: possible bad code with -O2

[Bug c/108718] New: csmith: possible bad code with -O2

[dcb314 at hotmail dot com]

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

            Bug ID: 108718
           Summary: csmith: possible bad code with -O2
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 54432
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54432&action=edit
C source code

The attached C code, produced by csmith, does this:

$ ../results/bin/gcc -w -O1 bug883.c && ./a.out
checksum = 7A94E377
$ ../results/bin/gcc -w -O2 bug883.c && ./a.out
checksum = 842F1622
$ 

The bug seems to exist since sometime before 20220703

$ ../results.20220703/bin/gcc -w -O2 bug883.c && ./a.out
checksum = 842F1622
$ 

I will have a go at a reduction.

[Bug c/108718] csmith: possible bad code with -O2

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Bisection shows the result is different between -O1 and -O2 since
r5-1351-gec18e2ebbf6a04097c7204032aba3f2646bede4a

[Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
            Summary|csmith: possible bad code   |[10/11/12/13 Regression]
                   |with -O2                    |csmith: possible bad code
                   |                            |with -O2
   Target Milestone|---                         |10.5
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems the testcase allows to be called with argument 1 and in that case it
prints verbose output, which between r11-1351^ and r11-1351 at -O2 differs
starting with:
--- 1   2023-02-08 09:10:13.000000000 -0500
+++ 2   2023-02-08 09:10:22.000000000 -0500
@@ -48,1210 +48,1210 @@ index = [2][2]
 index = [2][3]
 ...checksum after hashing g_5[i][j].f4 : ADCB0EBF
 index = [2][4]
-...checksum after hashing g_5[i][j].f4 : C953D56F
+...checksum after hashing g_5[i][j].f4 : 367D9AB8
 index = [2][5]
-...checksum after hashing g_5[i][j].f4 : 37A7B1F1
+...checksum after hashing g_5[i][j].f4 : 7EFE68AE
 index = [2][6]
-...checksum after hashing g_5[i][j].f4 : A0619D0A
+...checksum after hashing g_5[i][j].f4 : 6C5E59F1

The only changes in optimized dump as well as in assembly are in main.

[Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This also changes with  -fno-strict-aliasing  ...

[Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2

[dcb314 at hotmail dot com]

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

--- Comment #4 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Andrew Pinski from comment #3)
> This also changes with  -fno-strict-aliasing  ...

So does that mean that csmith is producing C code with UB and so
this bug isn't valid ?

It might also mean that all future uses of csmith I make must have
-fno-strict-aliasing.

[Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to David Binderman from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > This also changes with  -fno-strict-aliasing  ...
> 
> So does that mean that csmith is producing C code with UB and so
> this bug isn't valid ?

Not necessarily.  If something misbehaves with -O2 and behaves as expected with
-O2 -fno-strict-aliasing, then it is usually a good sign that there is or might
be an aliasing violation, but it isn't a proof that there is one.  Only
detailed analysis of the code or e.g. the latter only focused on what exactly
changes with the bisection point can reveal if it is or isn't valid.

[Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Huh, the change for sure triggered some latent issue, either in the testcase or
in GCC.  More analysis is needed (the testcase is large and obfuscated...).

[Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2

[dcb314 at hotmail dot com]

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

David Binderman <dcb314 at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dcb314 at hotmail dot com

--- Comment #7 from David Binderman <dcb314 at hotmail dot com> ---
Created attachment 54449
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54449&action=edit
C source code

After about 20 minutes of reduction, cvise started going the wrong way.

[Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2

[dcb314 at hotmail dot com]

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

--- Comment #8 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to David Binderman from comment #7)
> After about 20 minutes of reduction, cvise started going the wrong way.

Second reduction now running, with better script:

/usr/bin/gcc -c -w bug883.c && \
/home/dcb36/gcc/results/bin/gcc -w -O1 bug883.c && (./a.out 1 | fgrep
"g_5[i][j].f4 : C953D56F") && /home/dcb36/gcc/results/bin/gcc -w -O2 bug883.c
&& (./a.out 1 | fgrep "g_5[i][j].f4 : 367D9AB8")

[Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2

[dcb314 at hotmail dot com]

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

--- Comment #9 from David Binderman <dcb314 at hotmail dot com> ---
Created attachment 54463
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54463&action=edit
C source code

After a further hour of reduction, a partially reduced program.

cvise doesn't seem able to make much further progress with it.

[Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to David Binderman from comment #9)
> Created attachment 54463 [details]
> C source code
> 
> After a further hour of reduction, a partially reduced program.
> 
> cvise doesn't seem able to make much further progress with it.

However, I see a segfault that happens for the code snippet now.

[Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2

[dcb314 at hotmail dot com]

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

--- Comment #11 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Martin Liška from comment #10)
> However, I see a segfault that happens for the code snippet now.

In the compiler or the generated code ?

No crashes here. Are you running an asan+ubsan gcc build on x86_64, perhaps ?

[Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #10)
> (In reply to David Binderman from comment #9)
> > Created attachment 54463 [details]
> > C source code
> > 
> > After a further hour of reduction, a partially reduced program.
> > 
> > cvise doesn't seem able to make much further progress with it.
> 
> However, I see a segfault that happens for the code snippet now.

The reduced testcase has various flaws, i uninitialized at the start of first
loop in main, and the last loop in main iterating endlessly, main_j < 10 should
be probably the condition of the for loop.
Anyway, I think there are aliasing violations again,
*g_45 = &g_5[2][5];
is (implicitly) int while g_5[2][5] has type union { short } and e.g. func_13
stores
it through that g_45 pointer (so writes over g_5[2][5].f4 and g_5[2][6].f4,
that itself is an aliasing violation, and then reads/writes g_5[2][5].f4
through short * pointer in
((--*l_701));
The original testcase has that too:
union U0 {
   uint64_t f0;
   int32_t f1;
   uint64_t f2;
   int32_t f3;
   uint16_t f4;
};
static union U0 g_5[5][10] =
{{{1UL},{18446744073709551610UL},{0x998AB5457D670012LL},{18446744073709551612UL},{0x998AB5457D670012LL},{18446744073709551610UL},{1UL},{1UL},{18446744073709551615UL},{18446744073709551607UL}},{{1UL},{6UL},{0x7F6FB807CFAF425FLL},{0UL},{1UL},{1UL},{0UL},{0x7F6FB807CFAF425FLL},{6UL},{1UL}},{{0xF996F377CC424770LL},{6UL},{18446744073709551615UL},{0xF0488F4F368A9017LL},{18446744073709551612UL},{18446744073709551607UL},{1UL},{18446744073709551607UL},{18446744073709551612UL},{0xF0488F4F368A9017LL}},{{0xF0488F4F368A9017LL},{18446744073709551610UL},{0xF0488F4F368A9017LL},{6UL},{18446744073709551612UL},{3UL},{1UL},{0x998AB5457D670012LL},{0x998AB5457D670012LL},{1UL}},{{18446744073709551612UL},{1UL},{3UL},{3UL},{1UL},{18446744073709551612UL},{6UL},{1UL},{18446744073709551612UL},{18446744073709551615UL}}};
static int32_t *g_45 = &g_5[2][5].f3;
and in func_13
    uint16_t *l_701 = &g_5[2][5].f4;
...
            (*g_45) |= (*g_90);
...
--(*l_701)
on the penultimate line in func_13 among other things.  Though, (*g_45) |=
(*g_90);
actually isn't reached.
But, just setting awatch in -g -O0 compiled #c0, I can see it again doing UB,
e.g. func_26 does:
            l_169[3][4] = (*g_45);
            (*p_27) |= (safe_sub_func_int32_t_s_s(0x191EB41DL, p_29.f0));
where both g_45 and p_27 point to &g_5[2][5].f3 with int * type, and then
func_18 does:
            return g_5[2][5].f4;
which reads it through union as unsigned short.