please provide a patch that can be evaluated for discussion/inclusion (or i'll drastically NEEDINFO this bug to get rid of it ;)

So given your comment in bug 446874 (g_type_ensure()), should I take it that this is in fact WONTFIX too?  Cause if marking get_type() functions G_GNUC_CONST is wrong, there's no point in having a patch for discussion.

(In reply to comment #2)
> So given your comment in bug 446874 (g_type_ensure()), should I take it that
> this is in fact WONTFIX too?  Cause if marking get_type() functions
> G_GNUC_CONST is wrong, there's no point in having a patch for discussion.

no, i personally dislike GNUC_CONST for _get_type because it is a gcc abuse and that effectively causes problems in actual practice. 
however, others want the optimization so much that they are willing to patch up for the nasty side effects, even in third-party apps after invalid GNUC_CONST flagging was added to glib/gtk functions. using the same argument, glib-mkenum could support GNUC_CONST optionally (using a command line argument, because it introduces potential breakage).
ideally however, someone persues introduction of __attribute__((constant_registry)) as suggested in bug 446874. that way all current get_type GNUC_CONST cases could be fixed, no workarounds need to be added anywhere and glib-mkenum could support flagging unconditionally.

(In reply to comment #3)
> ideally however, someone persues introduction of
> __attribute__((constant_registry)) as suggested in bug 446874.

or "__attribute__ ((value_constructor))", i.e. anything outlining that the first call ever must not be skipped and subsequent calls may be freely optimized.

(In reply to comment #4)
> (In reply to comment #3)
> > ideally however, someone persues introduction of
> > __attribute__((constant_registry)) as suggested in bug 446874.
> 
> or "__attribute__ ((value_constructor))", i.e. anything outlining that the
> first call ever must not be skipped and subsequent calls may be freely
> optimized.

Submitted: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32911
Called it __attribute__ ((idempotent)) though.

(In reply to comment #5)
> (In reply to comment #4)
> > or "__attribute__ ((value_constructor))", i.e. anything outlining that the
> > first call ever must not be skipped and subsequent calls may be freely
> > optimized.
> 
> Submitted: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32911
> Called it __attribute__ ((idempotent)) though.

thanks, this bug is effectively the main blocker on gcc support for __attribute__ ((idempotent)) now, and others will be marked as duplicates.

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

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

Created attachment 93629 [details] [review]
get_type_G_GNUC_IDEMPOTENT.patch

Reattaching patch from merged bug so it doesn't get lost.

This patch introduces and documents a G_GNUC_IDEMPOTENT macro, currently expanding to nothing, and applies it to all get_type functions in the glib tarball.

We should apply this to glib now in advance of __attribute__((idempotent)) being added to gcc; this would allow get_type() functions elsewhere to be fixed.

(In reply to comment #9)
> Created an attachment (id=93629) [edit]
> get_type_G_GNUC_IDEMPOTENT.patch
> 
> Reattaching patch from merged bug so it doesn't get lost.
> 
> This patch introduces and documents a G_GNUC_IDEMPOTENT macro, currently
> expanding to nothing, and applies it to all get_type functions in the glib
> tarball.
> 
> We should apply this to glib now in advance of __attribute__((idempotent))
> being added to gcc; this would allow get_type() functions elsewhere to be
> fixed.

i don't really want to apply anything API-wise to glib until we can be reasonably sure that future gcc versions will have this. (so if you want to get this patch in, what you really need is to get the gcc people to promise adding ((idempotent)) to future versions and with that name.)

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

I’ve filed a bug against Clang with the same request, here: https://bugs.llvm.org/show_bug.cgi?id=34600

The GCC bug report is here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32911

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/97.