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

  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: link
Be 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).