GNOME Bugzilla – Bug 769183
Use -fno-strict-aliasing for everything
Last modified: 2018-02-05 07:55:44 UTC
+++ This bug was initially created as a clone of Bug #769167 +++ gcc strict aliasing can break code that performs type-punning, unless said type punning uses unions. See: http://www.cocoawithlove.com/2008/04/using-pointers-to-recast-in-c-is-bad.html for more details. This basically applies to all code that does things like if I understand correctly. > SomeObject *obj = ...; > ParentObject *parent = PARENT_OBJECT(obj); > > obj->foo = 123; > parent->foo = 456; > some_method(obj) // might see parent->foo == 456 or not We don't assign struct fields directly much though, need some analysis of the impact of all this.
The scary thing about the strict aliasing optimization is that it could break with future compiler versions in some pretty subtle ways, even if it works fine today. Therefore I think it's best either to carefully audit all the code for this kind of issue (including the heavily used object macros), or just turn off strict aliasing everywhere. Given the difficulty of the former, turning off strict aliasing may be best, and it's what many other projects have done. This is another very good article illustrating a subtle breakage: http://blog.qt.io/blog/2011/06/10/type-punning-and-strict-aliasing/ Some people have very strong opinions about strict aliasing: http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg01647.html And here's a list of things that can go wrong with the optimization: http://stackoverflow.com/questions/2958633/gcc-strict-aliasing-and-horror-stories
So, I assume we still want to do this? Should be safe to do in any case, no? And GLib defaults to it too.
It's safe but has potential negative performance impact. However, we should enable it. There's too much code, when using GObject, that does not follow the strict aliasing rules.