Created attachment 61682 [details] [review]
gnome-bug-335341.patch

This patch removes the sources of those warnings.

I am pretty sure to recall that the type punned pointer has been discussed various times.

While the warning is annoying, casting to (gpointer) is wrong and may result in the compiler doing the wrong thing, which would be a total pain to the debug.
I seem to recall that the "right" fix is to use an union, but that is very incovenient.
Still if we just want to shut gcc up, let's add a flag to ignore that warning, let's not hardcode wrong casts in the code. IMHO.

Ok, as I do not nearly understand what stupid*) gcc wants to tell me, I believe you, that casting to gpointer is wrong. Just did this cast after asking on the #gtk+ channel, what's a workarround for that problem. Another less convencient workarround I've found, was this:

      GtkWidget **weakref = &dialog;
      g_object_add_weak_pointer (G_OBJECT (dialog), (gpointer*) weakref);

Is gcc also just too stupid to catch the issue there? 
Or is the warning regarding "(gpointer*) &dialog" just a false alert?

I suspect the later one, 'cause gpointer is a kind of "supertype" for GtkWidget* and therefor im my welltested understanding of bits and bytes gpointer* definitly is a "supertype" for GtkWidget**.

Is there a way for getting the gcc devs to sort this out?

*) Stupid regarding that issue. Normally I highly respect this compiler.

Well, I must admit that I don't fully grasp the warning either, I just recall previous discussions about this issue.

From what I gather the 'correct' fix involves using an 

union {
   GtkWidget *w;
   gpointer   p;
}

and then accessing the var through the union. But I really think that this is really not acceptable from a code readability point of view, given that gtk relies heavily on the compiler doing the right thing even without the fix.

Honestly I think we should just use -fno-strict-aliasing and be done with it. At least it will not clutter the code.

If you are interested in the details google turns up quite a bit of stuff.

Here are some of the previous discussions:

http://mail.gnome.org/archives/gtk-devel-list/2004-April/thread.html#00196

http://bugzilla.gnome.org/show_bug.cgi?id=140722

I took some time and experimented with this a while back.  In short, none of these workarounds fixes the problem, they all hide it.

The problem is this: when you have a function like this:

  void f (double *a, int *b);

then in the *body* of that function, gcc assumes that a != b.

Now when you are calling f and use different types of pointers in arguments, gcc is warning you that in the body of the function an assumption of a != b has been made based on the types of the pointers, and your act of casting pointers may make you problems.  Now it's easy to see that no matter how you turn off the warning (union, cast), as long as strict-aliasing is turned on in gcc, you are having the same code, and the same possible problem.  But the problem only happens if you are passing the same object as two different parameters to a function, as two different types.  That's not quite likely anyway...  So most of the time ignoring or hiding the warning is Ok.

First real explaination of the problem I've seen. Thank you Behdad. Maybe we should try to get your explaination into gcc's info pages?

Now that I understand the problem, I also found a proper solution:

To <glib/gmacros.h> we would add this:

#if	__GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 3)
#  define G_GNUC_MAY_ALIAS __attribute__((may_alias))
#else
#  define G_GNUC_MAY_ALIAS
#endif

And wherever we need aliasing, we write this:

      static GtkWidget *G_GNUC_MAY_ALIAS dialog = NULL;

To make this work without warning:

      g_object_add_weak_pointer (G_OBJECT (dialog), (gpointer*) &dialog);


Wondering why there is no function attribute for disabling strict aliasing.

Yes, we definitely need to have G_GNUC_MAY_ALIAS.  More interesting is to add that to all GType and GObjects.  Unfortunately they are not defined using a macro so we cannot automate this in glib.

So, mind if I close this as WONTFIX?

Matthias' patch contains some valid warning fixes not related to strict aliasing.

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.