public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu Date: Mon, 18 Jan 2021 23:04:46 +0000 [thread overview] Message-ID: <bug-98549-4-hWXmC00XNd@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-98549-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549 --- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> --- It is not ice-on-invalid, the invalid in there stands for code that should be rejected by the compiler (emit error). UB at runtime can be even int foo (int x, int y) { return x + y; } but we surely don't want to treat ICE on it as less important because it might cause UB at runtime. While the x + y is conditional UB, e.g. int foo () { return __builtin_unreachable (); } is unconditional UB when that function is called, but that still doesn't mean it will ever be called, the same with whatever ICEs in this PR. Other bug categories are accepts-invalid and rejects-valid, those talk about the same invalid vs. valid categories, we should reject invalid and accept valid code and lack thereof is a bug. For UB at runtime, we can warn, but shouldn't error because the code might never be invoked at runtime.
next prev parent reply other threads:[~2021-01-18 23:04 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-05 21:13 [Bug target/98549] New: " doko at debian dot org 2021-01-06 5:33 ` [Bug target/98549] " marxin at gcc dot gnu.org 2021-01-06 6:05 ` marxin at gcc dot gnu.org 2021-01-14 17:26 ` segher at gcc dot gnu.org 2021-01-14 19:25 ` jakub at gcc dot gnu.org 2021-01-15 1:58 ` segher at gcc dot gnu.org 2021-01-15 7:37 ` jakub at gcc dot gnu.org 2021-01-15 9:35 ` marxin at gcc dot gnu.org 2021-01-15 10:41 ` marxin at gcc dot gnu.org 2021-01-16 16:25 ` segher at gcc dot gnu.org 2021-01-16 16:29 ` segher at gcc dot gnu.org 2021-01-18 8:29 ` marxin at gcc dot gnu.org 2021-01-18 20:27 ` segher at gcc dot gnu.org 2021-01-18 23:04 ` jakub at gcc dot gnu.org [this message] 2021-01-18 23:19 ` segher at gcc dot gnu.org 2021-01-18 23:38 ` joseph at codesourcery dot com 2021-01-19 1:07 ` segher at gcc dot gnu.org 2021-01-19 1:54 ` segher at gcc dot gnu.org 2021-01-19 1:55 ` segher at gcc dot gnu.org 2021-01-19 8:57 ` marxin at gcc dot gnu.org 2021-01-19 8:59 ` marxin at gcc dot gnu.org 2021-01-19 23:28 ` segher at gcc dot gnu.org 2021-01-20 19:02 ` segher at gcc dot gnu.org
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-98549-4-hWXmC00XNd@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).