Continuing my GCC documentation readthrough, I'm now up to the description of the "Labels as Values" extension: https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html#Labels-as-Values

I pulled together this code from the examples on the page:

$ cat labels_as_values.c
void unsafe(void *);

static inline int asdf(void)
{
bar:
    void *ptr0;
    static void *ptr1 = &&bar;
    /* ... */
foo:
    ptr0 = &&foo;
    goto *ptr0;
    goto *ptr1;
    unsafe(ptr0);
    unsafe(ptr1);
    return (sizeof(ptr0) + sizeof(ptr1));
}

static inline int zxcv(int i)
{
foo:
    static void *array[] = { &&foo, &&bar, &&hack };
bar:
    goto *array[i];
hack:
    return sizeof(array[i]);
}

int qwerty(int i)
{
foo:
    static const int array[] = { &&foo - &&foo, &&bar - &&foo,
                                 &&hack - &&foo };
bar:
    goto *(&&foo + array[i]);
hack:
    return (zxcv(array[i]) + asdf());
}
$

Compiling the code with "-Wall -Wextra -Wc++-compat -Winline" produces no warnings (-pedantic, on the other hand, produces plenty of warnings, but that's to be expected, since this is an extension). To match this back to things the documentation says:

1. "Note that this does not check whether the subscript is in bounds—array indexing in C never does that." ...ok, but we have -Warray-bounds now; maybe the documentation could be updated to mention that, or would -Warray-bounds have to be updated to handle cases like this first?
2. "You may not use this mechanism to jump to code in a different function. If you do that, totally unpredictable things happen. The best way to avoid this is to store the label address only in automatic variables and never pass it as an argument." ...ok well I store label addresses in non-automatic variables, and pass them as arguments in my example code, and I don't get any warnings; could those be added?
3. "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." ...ok, so shouldn't -Winline say something about my example code, then? But, it doesn't...