https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80963
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Jan Engelhardt from comment #3) > The question is more like - can it be made to work even if (In reply to > Andrew Pinski from comment #1) > > > > That is Archive in the shared library and in the main executable are > > considered two different classes. > > If that is how UBSAN thinks, then it should say so by uniquely identifying > each "distinct" class, e.g.: > > main.cpp:3:16: runtime error: member call on address 0x000000dcfc20 which > does not point to an object of type 'Archive.1234' > 0x000000dcfc20: note: object is of type 'ArchiveImpl' [Archive.5678] Where would those magic numbers come from? We don't have anything like that. > Secondly, I think that considering them two different classes is only valid > in C, but not under the ODR rules of C++. By using visibility other than default, you intentionally depart from the C++ ODR rules, it is an extension and the classes are not the same anymore in different shared libraries. > Finally, nonwithstanding all the above, it would be nice to have some -f > option to always make UBSAN treat same-name classes as the same thing > irrespective of visibility. Reason: to make UBSAN "work" with this example > meant having to edit configure.ac+Makefile.am (of the particular real-world > program) to not use "-Wl,--version-script=foo.sym -fvisiblity=hidden" at > all, and that was a little more work than just slapping another -f into > CXXFLAGS. The point of UBSAN is to diagnose UB, and your testcase has UB. If you want some -f option, that option is -fvisibility=default, which will make the code well defined and ubsan will not complain about it.
