[Bug c/105401] New: Improved diagnostics for code from "Labels as Values" documentation

["egallager at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105401

            Bug ID: 105401
           Summary: Improved diagnostics for code from "Labels as Values"
                    documentation
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Keywords: diagnostic, documentation
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: egallager at gcc dot gnu.org
  Target Milestone: ---

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...