https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86369
--- Comment #11 from Aaron Ballman <aaron at aaronballman dot com> --- (In reply to Jakub Jelinek from comment #10) > (In reply to Aaron Ballman from comment #9) > > Doesn't [expr.eq] make it unspecified though? > > Will defer that answer to Jason. > But please have a look at the comment 6 testcase. I strongly hope that > constexpr const char *p = "abc"; > constexpr const char *q = p; > static_assert (p == q, ""); > doesn't actually mean the string literal is evaluated multiple times, because > if it would be, then one pretty much can't use string literals for anything > reliably. Oh yeah, I agree with you in that case. I was talking about the summary example with function calls returning a string literal. Sorry for not being more clear! > I bet the wording in there is for the > constexpr const char *r = "abc"; > constexpr const char *s = "abc"; > case, where the standard doesn't force implementations to unify same string > literals within the same TU but allows it (and also allows say tail merging > of them). From what I can see in the LLVM constant expression evaluation > behavior, it doesn't track what comes from which evaluation of a string > literal (GCC doesn't track that either) and just assumes that it could be > different evaluation, while GCC assumes it is not. Yeah, that sounds plausible.
