Matthias, may I commit this, with proper doc updates?

I was a bit disappointed when I looked up may_alias in the gcc docs
and discovered it only applies to types, not to individual declarations
or function parameters. That makes it more or less useless for solving
our strict aliasing issues, no ?

gcc's docs are typically lacking in details.  The following sample is from 'info gcc':

typedef short __attribute__((__may_alias__)) short_a;

int
main (void)
{
  int a = 0x12345678;
  short_a *b = &a;

  b[1] = 0;

  if (a == 0x12345678)
    abort();

  exit(0);
}

where if the "short_a *b" is replaced with "short *b", it aborts.

Now expanding short_a and replacing the short_a *b line with:

  short __attribute__((__may_alias__)) *b = &a;

doesn't fix it; it still aborts.  BUT, applying the may_alias attribute to "int a" actually works.  So:

int
main (void)
{
  __attribute__((__may_alias__)) int a = 0x12345678;
  short *b = &a;

  b[1] = 0;

  if (a == 0x12345678)
    abort();

  exit(0);
}

doesn't abort.

I still need to test it more, in function prototypes and such, and see if it helps there.

Before I lose it again, to understand what exactly the strict-aliasing warning from gcc means and why double-casting is just hiding the warning, not fixing it, see this comment:

  http://bugzilla.gnome.org/show_bug.cgi?id=335341#c5

Behdad, that extract from the gcc docs cannot explain be the whole thing, because the little example you quote above in comment 3 does not have a function call.

In any case, in all the cases I've seen this warning, IIRC, what one wants to ‘set an attibute on’ is not the variable or the type but the _use_ of the variable, like on the beloved g_object_add_weak_pointer calls in the terminal code. If we make all gobject types non-aliasing, or take some other similarly draconian measure, then probably we would lose optimizations, I imagine.

The practice of adding to code such as

  g_object_add_weak_pointer (G_OBJECT (screen->priv->title_editor),
                             (void**) &screen->priv->title_editor);

an extra cast to (void*) may not be the most legible thing, but precisely says: in this particular instance, I know what I am doing; dressing it up into a G_PLEASE_TRUST_ME_I_KNOW_WHAT_I_MEAN() macro might turn it into something we can all introduce to our parents.

(In reply to comment #5)

> The practice of adding to code such as
> 
>   g_object_add_weak_pointer (G_OBJECT (screen->priv->title_editor),
>                              (void**) &screen->priv->title_editor);
> 
> an extra cast to (void*) may not be the most legible thing, but precisely says:
> in this particular instance, I know what I am doing; dressing it up into a
> G_PLEASE_TRUST_ME_I_KNOW_WHAT_I_MEAN() macro might turn it into something we
> can all introduce to our parents.

Right.  But in this very particular case, you are passing the same object to the same function with too different types.  This is exactly one of the few situations that the warning may actually mean something useful.  From experience, it seems like most of the aliasing problems don't happen for a majority of users/systems.  We've see FreeType breaking badly on Solaris.  Or there's only one report about gtk+ breaking by strict aliasing.  So, for the uncommon day that this bites us, I'd rather we have not forced the warning off without being 100% sure what we mean.

If you really want to get the warning shut up, try -Wno-strict-aliasing

*** Bug 373910 has been marked as a duplicate of this bug. ***

Created attachment 77028 [details]
attachment showing example uses of G_GNUC_MAY_ALIAS

here's an example program, showing off a typedef and non-typedef use of G_GNUC_MAY_ALIAS. since use of this compiler attribute is the only proper way to avoid gcc's aliasing warnings, i'll ad the macro to glib.

Wed Nov 22 16:09:13 2006  Tim Janik  <timj@gtk.org>

        * glib/gmacros.h: added G_GNUC_MAY_ALIAS, suggested by Mathias
        Hasselmann in bug #335341, fixes bug #335853.