public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "ebotcazou at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/108498] [11/12/13 Regression] ppc64 big endian generates uninitialized reads with -fstore-merging Date: Tue, 24 Jan 2023 17:33:20 +0000 [thread overview] Message-ID: <bug-108498-4-q6r4muSi4t@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-108498-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108498 --- Comment #23 from Eric Botcazou <ebotcazou at gcc dot gnu.org> --- > The C/C++ FEs since r9-6625-gbec1da64aec26a490 turn some array initializers > into strings. Ouch. I'm not sure that's worthwhile if the arrays are not byte-aligned. > Anyway, I wonder if for GCC 14 we couldn't just treat STRING_CST the same as > INTEGER_CST during the merging into groups and instead deal with all of that > during split_group. > I.e. only at that time see that for this subset of stores we want to merge > them into one STRING_CST store, these others handle differently, etc. And > the preconditions for handling something the STRING_CST way would be > contiguous chunk with byte aligned start/end containg at least one longer > STRING_CST. So, we wouldn't give up e.g. in > the second testcase, but merge the STRING_CSTs stores with the 4 byte > INTEGER_CST store in between them, while handling the bitfield stuff at the > start and/or the end to separate stores. The handling was separate because STRING_CSTs (+ 1-byte INTEGER_CSTs) were supposed to be relatively separate from other INTEGER_CSTs, but GCC 9+'s behavior clearly makes this a bit obsolete. The implementation is ad-hoc at best so any idea to streamline it is warmly welcome; for Ada, we are only interested in bona fide character strings that we want to concatenate as if they were statically concatenated in the source code.
next prev parent reply other threads:[~2023-01-24 17:33 UTC|newest] Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-01-23 14:18 [Bug c/108498] New: " kungfujesus06 at gmail dot com 2023-01-23 15:18 ` [Bug c/108498] " kungfujesus06 at gmail dot com 2023-01-23 15:20 ` [Bug middle-end/108498] " pinskia at gcc dot gnu.org 2023-01-23 15:22 ` kungfujesus06 at gmail dot com 2023-01-23 15:34 ` kungfujesus06 at gmail dot com 2023-01-23 15:38 ` rguenth at gcc dot gnu.org 2023-01-23 15:48 ` kungfujesus06 at gmail dot com 2023-01-23 15:51 ` kungfujesus06 at gmail dot com 2023-01-23 15:54 ` kungfujesus06 at gmail dot com 2023-01-23 17:39 ` pinskia at gcc dot gnu.org 2023-01-23 17:40 ` pinskia at gcc dot gnu.org 2023-01-23 17:42 ` kungfujesus06 at gmail dot com 2023-01-23 17:45 ` pinskia at gcc dot gnu.org 2023-01-23 17:51 ` [Bug tree-optimization/108498] " pinskia at gcc dot gnu.org 2023-01-23 17:51 ` kungfujesus06 at gmail dot com 2023-01-23 18:18 ` kungfujesus06 at gmail dot com 2023-01-23 19:04 ` jakub at gcc dot gnu.org 2023-01-24 12:20 ` [Bug tree-optimization/108498] [11/12/13 Regression] " jakub at gcc dot gnu.org 2023-01-24 12:55 ` jakub at gcc dot gnu.org 2023-01-24 15:35 ` jakub at gcc dot gnu.org 2023-01-24 16:09 ` jakub at gcc dot gnu.org 2023-01-24 16:48 ` ebotcazou at gcc dot gnu.org 2023-01-24 17:10 ` jakub at gcc dot gnu.org 2023-01-24 17:33 ` ebotcazou at gcc dot gnu.org [this message] 2023-01-24 17:46 ` jakub at gcc dot gnu.org 2023-01-25 9:51 ` cvs-commit at gcc dot gnu.org 2023-01-25 10:35 ` [Bug tree-optimization/108498] [11/12 " jakub at gcc dot gnu.org 2023-02-10 17:46 ` cvs-commit at gcc dot gnu.org 2023-02-10 18:00 ` [Bug tree-optimization/108498] [11 " jakub at gcc dot gnu.org 2023-05-02 20:13 ` cvs-commit at gcc dot gnu.org 2023-05-03 10:35 ` jakub 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-108498-4-q6r4muSi4t@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).