https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66514
--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #1) > There is some minimal support in -fsanitize=vptr, but that catches only > destructed objects with virtual methods (by disabling the clobbers and > clearing the vptr). I see. > Other than that, this is something that is more in line with the address > sanitizer (which also has very limited support for file scope objects, but > only makes the objects unavailable during construction of each TU, so > catches constructor ordering issues within a single TU). Other than that, > the concept of making a chunk of memory available at certain point and > unavailable at another point is something -fsanitize=address is able to do. > The question is what can be done with operator new, e.g. if you have a char > buffer in some class and construct something else at that spot, then > destructing it; reading those bytes afterwards is supposedly UB, but storing > there something say with memcpy shouldn't be invalid. Ok, after reading your caution and test-cases mentioned in the ASAN tracker, I think emitting a poison memory call in a dtor for instances that does not use placement new can be beneficial. However, I can't evaluate if getting such kind of information in doable in GCC?
