https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86983
Bug ID: 86983
Summary: documentation inconsistent with always_inline
diagnostics for computed goto
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Per https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html a function
containing a computed goto can be inlined (so long as no label within it is
used to initialize a static variable):
> The &&foo expressions for the same label might have different values if the
> containing function is inlined or cloned. If a program relies on them being
> always the same, __attribute__((__noinline__,__noclone__)) should be used to
> prevent inlining and cloning. If &&foo is used in a static variable
> initializer, inlining and cloning is forbidden.
However, applying __attribute__((__always_inline__)) to a function containing a
computed goto produces this diagnostic:
> error: function 'void* f(void*)' can never be inlined because it contains a
> computed goto
... which claims that a computed goto prevents inlining. (See
https://godbolt.org/g/XFhwQq)
Also, GCC warns on returning the address of a label from a function, which
makes sense if different invocations of the same function can have different
addresses for their labels (through inlining / cloning), but is a false
positive on an example such as the one at that godbolt.org link otherwise.
So, which is it?
Is GCC reserving the right to inline functions containing computed gotos in
some future version? (In which case, the always_inline diagnostic is somewhere
between misleading and wrong, and should probably be weakened from "can never
be inlined" to something like "was not inlined".)
Or has the computed goto rule been changed to "functions containing computed
goto will never be inlined or cloned"? (In which case the documentation is
wrong, and the warning on returning the address of a label seems questionable,
at least for an enabled-by-default warning, since it warns on reasonable code
and there doesn't seem to be a simple syntactic way to suppress the warning.)
