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.

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