Bug 485914 - Strict aliasing warnings and violations in glib2
Strict aliasing warnings and violations in glib2
Product: Fedora
Classification: Fedora
Component: glib2 (Show other bugs)
All Linux
low Severity urgent
: ---
: ---
Assigned To: Matthias Clasen
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-02-17 07:59 EST by Jakub Jelinek
Modified: 2009-03-26 23:11 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-02-17 16:08:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
glib-strict-aliasing.patch (24.59 KB, patch)
2009-02-17 08:00 EST, Jakub Jelinek
no flags Details | Diff

  None (edit)
Description Jakub Jelinek 2009-02-17 07:59:28 EST
gcc in rawhide reports over 500 strict-aliasing warnings during glib2 build, and what's worse, one warning in gthread.h:344 affects over 200 other packages, in some cases could result in miscompiled code.

The problem is with the g_atomic_{pointer,int}_{s,g}et APIs.  They expect gpointer * or gint * first argument, but various users use the former e.g. on gsize * or pointer to pointer pointing to something other than void, the latter
e.g. with guint *.  On some hosts these are implemented by macros, just dereferencing the pointer and either returning what it points to or changing it.
In this case with the callers casting say gsize * to gpointer * and using that
in g_atomic_pointer_get it is an obvious aliasing violation, object with gsize
effective type is read using gpointer type.  The compiler might do anything in that case.  If these aren't implemented as macros, just adding (void *) cast before casting to (gpointer *) is enough to get rid of the aliasing warning, but it would be better to be prepared for -fwhopr etc.

As most of the g_atomic_pointer_get etc. users seem to be buggy, and they shouldn't need to worry thether it is expanded as macro or calls the function,
the patch removes the type punning in the users and handles it in the macros.

It ensures g_atomic_pointer_* is used only on objects of the same size as pointer and similarly for integers.  To be prepared for whole program optimizations, the patch adds may_alias attribute to say that the access in out-of-line functions is done in alias set 0, for inline expansion the access is done using the original type, so this isn't necessary.

With this patch there are no aliasing warnings in glib2 and the warning in gthread.h:344 that triggered on many other packages is gone as well.

Can this be incorporated into glib2 before the mass rebuild (i.e. this week), to avoid having to rebuild all packages using glib2 headers once again?
Comment 1 Jakub Jelinek 2009-02-17 08:00:10 EST
Created attachment 332212 [details]
Comment 2 Matthias Clasen 2009-02-17 10:22:47 EST
Thanks, Jakub. 

I hope to get this into a release (and into rawhide) sometime today.
Comment 3 Ryan Hill 2009-03-26 23:07:18 EDT
can this go upstream as well?
Comment 4 Ryan Hill 2009-03-26 23:11:11 EDT
oops, it already is upstream.  sorry for the noise. ;)

Note You need to log in before you can comment on or make changes to this bug.