[Bug c++/96996] Missed optimzation for constant members of non-constant objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96996 --- Comment #6 from Jonathan Wakely --- const_cast lets you add/remove cv-qualifiers from pointers and references, but that doesn't make it OK to write to an object that was originally defined as const. Similar to how reinterpret_cast from int* to float* doesn't make it OK to violate TBAA rules. You can change the type, but that doesn't mean it's safe to use.
[Bug c++/96996] Missed optimzation for constant members of non-constant objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96996 --- Comment #5 from Matthijs Kooijman --- > But isn't there const_cast<> to change the value of p? Yes, that makes it possible to write to a const object, but actually doing so is undefined behavior (see [dcl.type.cv] I quoted above). The spec even makes this explicit about const_cast, [expr.const.cast] says: > [ Note: Depending on the type of the object, a write operation through > the pointer, lvalue or pointer to data member resulting from a > const_cast that casts away a const-qualifier may produce undefined > behavior (7.1.6.1). — end note ]
[Bug c++/96996] Missed optimzation for constant members of non-constant objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96996 --- Comment #4 from Richard Biener --- But isn't there const_cast<> to change the value of p?
[Bug c++/96996] Missed optimzation for constant members of non-constant objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96996 --- Comment #3 from Jonathan Wakely --- Yes, that's what I said: > I'm not saying the optimization would be invalid
[Bug c++/96996] Missed optimzation for constant members of non-constant objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96996 --- Comment #2 from Matthijs Kooijman --- > Replacing non_constant_test with a new object is possible, and allowed. But > the name "non_constant_test" cannot be used to refer to the new object, so > any calls to non_constant_ref() after the object was replaced would have > undefined behaviour. Which means the compiler can assume there are no such > calls. Thanks for clarifying. But then I could reason that *if* "non_constant_test" is replaced, then accessing it through the old name is undefined behavior, so that would make any value for the constant member variables (such as the original values before replacement) acceptable, right? Hence that does not conflict with applying this optimzation, I'd think.
[Bug c++/96996] Missed optimzation for constant members of non-constant objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96996 Jonathan Wakely changed: What|Removed |Added Component|web |c++ Keywords||missed-optimization --- Comment #1 from Jonathan Wakely --- (In reply to Matthijs Kooijman from comment #0) > There is still the caveat of "during its lifetime", IOW, what if you would > destroy the object and create a new one it is place. However, see > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80794#c5 for a discussion of > this case. In short, replacing non_constant_test with a new object is > possible, but only when it "does not contain any non-static data member > whose type is const-qualified or a reference type", which does not hold for > this object. That's not quite accurate. Replacing non_constant_test with a new object is possible, and allowed. But the name "non_constant_test" cannot be used to refer to the new object, so any calls to non_constant_ref() after the object was replaced would have undefined behaviour. Which means the compiler can assume there are no such calls. I'm not saying the optimization would be invalid, just clarifying what the related discussion says.
