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 c++/108626] GCC doesn't deduplicate string literals for const char*const and const char[] Date: Wed, 01 Feb 2023 18:57:34 +0000 [thread overview] Message-ID: <bug-108626-4-KnQBT4jAC6@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-108626-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108626 --- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Strictly speaking, in this case I think it isn't invalid, puts is a standard function and implementation could treat it as a builtin with known behavior (that it doesn't care about pointer equality of what it prints). But clang++ does that even for static const char* const a = "bla"; static const char b[] = "bla"; extern void foo (const char *); int main() { foo(a); foo(b); } Another TU could have #include <stdlib.h> void foo (const char *p) { static const char *q; if (!q) q = p; else if (q == p) abort (); } This will fail even with GCC -fmerge-all-constants, but in that case we document that the option may cause non-conforming behavior. C++ says https://eel.is/c++draft/lex.string#9 and my reading of it is that different string literals can be overlapping or partially overlapping etc., but am not convinced it is ok to make those overlap other const objects. C 17 says: "String literals, and compound literals with const-qualified types, need not designate distinct objects." and "This allows implementations to share storage for string literals and constant compound literals with the same or overlapping representations." note, but that still doesn't look like allowing them to overlap non-string literal non-constant compound literals objects.
next prev parent reply other threads:[~2023-02-01 18:57 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-02-01 9:50 [Bug c++/108626] New: GCC doesn't combine string literals for const char*const and const char b[] marat at slonopotamus dot org 2023-02-01 16:29 ` [Bug c++/108626] GCC doesn't deduplicate string literals for const char*const and const char[] pinskia at gcc dot gnu.org 2023-02-01 18:19 ` marat at slonopotamus dot org 2023-02-01 18:57 ` jakub at gcc dot gnu.org [this message] 2023-02-02 3:01 ` de34 at live dot cn 2023-02-02 10:09 ` marat at slonopotamus dot org 2023-02-02 11:36 ` de34 at live dot cn 2023-02-02 13:25 ` marat at slonopotamus dot org 2023-02-02 14:31 ` marat at slonopotamus dot org 2023-07-24 2:21 ` de34 at live dot cn
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-108626-4-KnQBT4jAC6@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).