On Friday 04 March 2016 07:52:15 Thiago Macieira wrote: > Found in GCC 6's changelog (http://gcc.gnu.org/gcc-6/changes.html): > > Value range propagation now assumes that the this pointer of C++ member > > functions is non-null. This eliminates common null pointer checks but > > also breaks some non-conforming code-bases (such as Qt-5, Chromium, > > KDevelop). As a temporary work-around -fno-delete-null-pointer-checks > > can be used. Wrong code can be identified by using -fsanitize=undefined. > > Are we free of such mistakes? Or do we need to enable -fno-delete-null- > pointer-checks?
This comes to mind; QPointer<QObject> that = this; // ... if (!that) return; Not sure it's affected, though. Don't know off-handedly anything else that where this == nullptr would be valid. Only way to find out is to enable -fno-delete-null-pointer-checks except for -developer-build and trying to fix the ubsan issues. We should eventually put a ubsan build into the CI, we're not /that/ far away from building cleanly. It's some time since I last checked, but I can't remember any 3rd-party libs triggering in a ubsan Qt builds. /me upgrades to GCC 6. Thanks, Marc -- Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
