public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "haoxintu at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/99694] [9 Regression] gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os since r9-7156-g33579b59aaf02eb7 Date: Wed, 04 Aug 2021 08:31:20 +0000 [thread overview] Message-ID: <bug-99694-4-qbYHajbxuW@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-99694-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99694 --- Comment #11 from Haoxin Tu <haoxintu at gmail dot com> --- Hi all. I hope you all are doing well. I am sorry to bother you again. May I ask a quick question about how do you treat the bug-revealing test case which may include the valid syntax but contain the UB? (e.g.,"b = i / 0;" in the above case is undefined). BTW, I did not find my answer in the document https://www.gnu.org/software/gcc/bugs/management.html. (1)From my understanding, compilers should compile well (no crashing or performance issue) with those test programs although they contain UB. Ideally, programmers may introduce a UB by accident in their program, after compiling, not to mention whether the warning message emitted by compilers is correct or not, compilers should exit normally. Am I correct here? (2)From my experience, those bugs caused by the UB-included program can always occur in the optimization phase. So I think those test cases can be critical as well (compared with wrong-code issues)? How do you categorize the importance of related crashes or performance issues caused by such test programs? I am asking the question because I am thinking whether the effort is worthing or not if I devise a tool that can produce diverse syntactic valid but may contain UB test programs to detect crashes or performance issues in compilers. The motivation is that I noticed the goal of most existing program generators (e.g.,Csmith [1], YARPGen [2]) is to produce UB-free test programs to detect miscompiliation bugs in compilers, few (only CCG [3], a quite old tool so that may be hard to find bugs right now) aims to detect crashs using programs with UB. So I guess our community may lack such test cases to further stress compilers. If such diverse test programs (such as the reported one) can help improve the quality of compilers, I'd like to spend some time on it. Sorry again for my bothering and any suggestions are welcome! [1] https://github.com/csmith-project/csmith [2] https://github.com/intel/yarpgen [3] https://github.com/Mrktn/ccg Thanks! Haoxin
next prev parent reply other threads:[~2021-08-04 8:31 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-21 13:48 [Bug c/99694] New: gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os haoxintu at gmail dot com 2021-03-22 8:14 ` [Bug middle-end/99694] [9/10/11 Regression] gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os since r9-7156-g33579b59aaf02eb7 marxin at gcc dot gnu.org 2021-03-22 8:32 ` jakub at gcc dot gnu.org 2021-03-22 9:05 ` rguenth at gcc dot gnu.org 2021-03-22 13:37 ` cvs-commit at gcc dot gnu.org 2021-03-22 13:38 ` [Bug middle-end/99694] [9/10 " rguenth at gcc dot gnu.org 2021-03-24 14:26 ` cvs-commit at gcc dot gnu.org 2021-03-28 3:27 ` [Bug middle-end/99694] [9 " haoxintu at gmail dot com 2021-03-30 7:31 ` marxin at gcc dot gnu.org 2021-04-12 11:23 ` cvs-commit at gcc dot gnu.org 2021-04-12 11:24 ` rguenth at gcc dot gnu.org 2021-08-04 8:31 ` haoxintu at gmail dot com [this message] 2021-08-04 8:45 ` marxin at gcc dot gnu.org 2021-08-04 8:50 ` haoxintu at gmail dot com 2021-08-04 11:37 ` rguenth at gcc dot gnu.org 2021-08-04 11:51 ` jakub at gcc dot gnu.org 2021-08-04 12:42 ` marxin at gcc dot gnu.org 2021-08-04 13:19 ` haoxintu at gmail dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-99694-4-qbYHajbxuW@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).