https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
--- Comment #18 from Marc Glisse <glisse at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #17) > Without the #c11 patch (+ removal of the !INTEGRAL_TYPE_P special case from > the above committed change + fixing up ptrs_compare_unequal, or something > equivalent like the VRP change) I am a bit lost with the current status there ;-) (I don't have much time now so I can't really follow anyway, no need to explain it to me) > I'm afraid there isn't much possibilities > left to do, and those changes are too risky for GCC9. I am not in a hurry. I don't personally write code where the performance of string matters, I was forwarding (the first part of) a report by some user. > The problem with your > testcase is that NRV is in place, so we don't even know if s is an automatic > variable or a global variable, or a heap variable etc. NRV complicates things, but even with NRV I think we should be able to say that s and "hello" cannot have the same address, since the caller is supposed to pass the address of a writable buffer as argument. Or can you think of cases where NRV would allow the return object and a string literal to have the same address? Maybe if we store the returned value in a const object and never compare the address of this const object to another one the compiler could skip constructing the object and use a reference to a constant object?
