[Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108718
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #12 from Jakub Jelinek ---
(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.
[Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108718 --- Comment #11 from David Binderman --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108718 --- Comment #10 from Martin Liška --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108718 --- Comment #9 from David Binderman --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108718 --- Comment #8 from David Binderman --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108718 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #7 from David Binderman --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108718 --- Comment #6 from Richard Biener --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108718 --- Comment #5 from Jakub Jelinek --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108718 --- Comment #4 from David Binderman --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108718 --- Comment #3 from Andrew Pinski --- This also changes with -fno-strict-aliasing ...
[Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108718 Jakub Jelinek 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 --- 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.0 -0500 +++ 2 2023-02-08 09:10:22.0 -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.
