public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug c/108718] New: csmith: possible bad code with -O2 @ 2023-02-08 13:53 dcb314 at hotmail dot com 2023-02-08 14:06 ` [Bug c/108718] " jakub at gcc dot gnu.org ` (11 more replies) 0 siblings, 12 replies; 13+ messages in thread From: dcb314 at hotmail dot com @ 2023-02-08 13:53 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c/108718] csmith: possible bad code with -O2 2023-02-08 13:53 [Bug c/108718] New: csmith: possible bad code with -O2 dcb314 at hotmail dot com @ 2023-02-08 14:06 ` jakub at gcc dot gnu.org 2023-02-08 14:12 ` [Bug c/108718] [10/11/12/13 Regression] " jakub at gcc dot gnu.org ` (10 subsequent siblings) 11 siblings, 0 replies; 13+ messages in thread From: jakub at gcc dot gnu.org @ 2023-02-08 14:06 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2 2023-02-08 13:53 [Bug c/108718] New: csmith: possible bad code with -O2 dcb314 at hotmail dot com 2023-02-08 14:06 ` [Bug c/108718] " jakub at gcc dot gnu.org @ 2023-02-08 14:12 ` jakub at gcc dot gnu.org 2023-02-08 17:06 ` pinskia at gcc dot gnu.org ` (9 subsequent siblings) 11 siblings, 0 replies; 13+ messages in thread From: jakub at gcc dot gnu.org @ 2023-02-08 14:12 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2 2023-02-08 13:53 [Bug c/108718] New: csmith: possible bad code with -O2 dcb314 at hotmail dot com 2023-02-08 14:06 ` [Bug c/108718] " jakub at gcc dot gnu.org 2023-02-08 14:12 ` [Bug c/108718] [10/11/12/13 Regression] " jakub at gcc dot gnu.org @ 2023-02-08 17:06 ` pinskia at gcc dot gnu.org 2023-02-09 15:10 ` dcb314 at hotmail dot com ` (8 subsequent siblings) 11 siblings, 0 replies; 13+ messages in thread From: pinskia at gcc dot gnu.org @ 2023-02-08 17:06 UTC (permalink / raw) To: gcc-bugs 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 ... ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2 2023-02-08 13:53 [Bug c/108718] New: csmith: possible bad code with -O2 dcb314 at hotmail dot com ` (2 preceding siblings ...) 2023-02-08 17:06 ` pinskia at gcc dot gnu.org @ 2023-02-09 15:10 ` dcb314 at hotmail dot com 2023-02-09 20:12 ` jakub at gcc dot gnu.org ` (7 subsequent siblings) 11 siblings, 0 replies; 13+ messages in thread From: dcb314 at hotmail dot com @ 2023-02-09 15:10 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2 2023-02-08 13:53 [Bug c/108718] New: csmith: possible bad code with -O2 dcb314 at hotmail dot com ` (3 preceding siblings ...) 2023-02-09 15:10 ` dcb314 at hotmail dot com @ 2023-02-09 20:12 ` jakub at gcc dot gnu.org 2023-02-10 10:19 ` rguenth at gcc dot gnu.org ` (6 subsequent siblings) 11 siblings, 0 replies; 13+ messages in thread From: jakub at gcc dot gnu.org @ 2023-02-09 20:12 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2 2023-02-08 13:53 [Bug c/108718] New: csmith: possible bad code with -O2 dcb314 at hotmail dot com ` (4 preceding siblings ...) 2023-02-09 20:12 ` jakub at gcc dot gnu.org @ 2023-02-10 10:19 ` rguenth at gcc dot gnu.org 2023-02-10 17:07 ` dcb314 at hotmail dot com ` (5 subsequent siblings) 11 siblings, 0 replies; 13+ messages in thread From: rguenth at gcc dot gnu.org @ 2023-02-10 10:19 UTC (permalink / raw) To: gcc-bugs 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...). ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2 2023-02-08 13:53 [Bug c/108718] New: csmith: possible bad code with -O2 dcb314 at hotmail dot com ` (5 preceding siblings ...) 2023-02-10 10:19 ` rguenth at gcc dot gnu.org @ 2023-02-10 17:07 ` dcb314 at hotmail dot com 2023-02-15 8:17 ` dcb314 at hotmail dot com ` (4 subsequent siblings) 11 siblings, 0 replies; 13+ messages in thread From: dcb314 at hotmail dot com @ 2023-02-10 17:07 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2 2023-02-08 13:53 [Bug c/108718] New: csmith: possible bad code with -O2 dcb314 at hotmail dot com ` (6 preceding siblings ...) 2023-02-10 17:07 ` dcb314 at hotmail dot com @ 2023-02-15 8:17 ` dcb314 at hotmail dot com 2023-02-15 10:29 ` dcb314 at hotmail dot com ` (3 subsequent siblings) 11 siblings, 0 replies; 13+ messages in thread From: dcb314 at hotmail dot com @ 2023-02-15 8:17 UTC (permalink / raw) To: gcc-bugs 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") ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2 2023-02-08 13:53 [Bug c/108718] New: csmith: possible bad code with -O2 dcb314 at hotmail dot com ` (7 preceding siblings ...) 2023-02-15 8:17 ` dcb314 at hotmail dot com @ 2023-02-15 10:29 ` dcb314 at hotmail dot com 2023-02-15 10:39 ` marxin at gcc dot gnu.org ` (2 subsequent siblings) 11 siblings, 0 replies; 13+ messages in thread From: dcb314 at hotmail dot com @ 2023-02-15 10:29 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2 2023-02-08 13:53 [Bug c/108718] New: csmith: possible bad code with -O2 dcb314 at hotmail dot com ` (8 preceding siblings ...) 2023-02-15 10:29 ` dcb314 at hotmail dot com @ 2023-02-15 10:39 ` marxin at gcc dot gnu.org 2023-02-15 17:00 ` dcb314 at hotmail dot com 2023-02-16 12:59 ` jakub at gcc dot gnu.org 11 siblings, 0 replies; 13+ messages in thread From: marxin at gcc dot gnu.org @ 2023-02-15 10:39 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2 2023-02-08 13:53 [Bug c/108718] New: csmith: possible bad code with -O2 dcb314 at hotmail dot com ` (9 preceding siblings ...) 2023-02-15 10:39 ` marxin at gcc dot gnu.org @ 2023-02-15 17:00 ` dcb314 at hotmail dot com 2023-02-16 12:59 ` jakub at gcc dot gnu.org 11 siblings, 0 replies; 13+ messages in thread From: dcb314 at hotmail dot com @ 2023-02-15 17:00 UTC (permalink / raw) To: gcc-bugs 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 ? ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2 2023-02-08 13:53 [Bug c/108718] New: csmith: possible bad code with -O2 dcb314 at hotmail dot com ` (10 preceding siblings ...) 2023-02-15 17:00 ` dcb314 at hotmail dot com @ 2023-02-16 12:59 ` jakub at gcc dot gnu.org 11 siblings, 0 replies; 13+ messages in thread From: jakub at gcc dot gnu.org @ 2023-02-16 12:59 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2023-02-16 12:59 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-02-08 13:53 [Bug c/108718] New: csmith: possible bad code with -O2 dcb314 at hotmail dot com 2023-02-08 14:06 ` [Bug c/108718] " jakub at gcc dot gnu.org 2023-02-08 14:12 ` [Bug c/108718] [10/11/12/13 Regression] " jakub at gcc dot gnu.org 2023-02-08 17:06 ` pinskia at gcc dot gnu.org 2023-02-09 15:10 ` dcb314 at hotmail dot com 2023-02-09 20:12 ` jakub at gcc dot gnu.org 2023-02-10 10:19 ` rguenth at gcc dot gnu.org 2023-02-10 17:07 ` dcb314 at hotmail dot com 2023-02-15 8:17 ` dcb314 at hotmail dot com 2023-02-15 10:29 ` dcb314 at hotmail dot com 2023-02-15 10:39 ` marxin at gcc dot gnu.org 2023-02-15 17:00 ` dcb314 at hotmail dot com 2023-02-16 12:59 ` jakub at gcc dot gnu.org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).