[Bug c/114366] New: computed labels do not reflect true values of instruction pointer ranges when function is inlined

[Bug c/114366] New: computed labels do not reflect true values of instruction pointer ranges when function is inlined

[godmar at gmail dot com]

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

            Bug ID: 114366
           Summary: computed labels do not reflect true values of
                    instruction pointer ranges when function is inlined
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: godmar at gmail dot com
  Target Milestone: ---

Created attachment 57718
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57718&action=edit
using labels as values example

Hi, we recently got tripped up by the following:

```c
#include <assert.h>

void *beginPtr, *endPtr;
int x;
static void smallfunction(void)
{
    beginPtr = &&begin;
    endPtr = &&end;
begin:
    x++;
end:
}

int
main()
{
    smallfunction();
    assert(beginPtr < endPtr);
}
```
When compiled with `-O0`, this program completes successfully. When compiled
with `-O2`, this program fails its assertion because the following assembly
code is produced:

```
.L2:
.L3:
    leaq    .L2(%rip), %rdx
    leaq    .L3(%rip), %rax
    addl    $1, x(%rip)
```

which IMO should be something like:
```
.L2:
    leaq    .L2(%rip), %rdx
    leaq    .L3(%rip), %rax
    addl    $1, x(%rip)
.L3:
```

I understand that using labels as values is a GCC extension, and I have read
the comment in the documentation [1] that warns that &&foo might have a
different value if a function is inlined.  (Adding the noinline attribute fixes
the problem at the cost of some performance.)  Also note that "different
values" is not the same as not being computed correctly.

We encountered this problem building an exception handler.

I will note that gcc will not inline the function if the computed values are
actually used in a goto statement; when trying to force it to inline it, it
throws an error.

Is this a bug, or undocumented behavior? Perhaps the documentation should be
clarified.  

[1] https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html

[Bug c/114366] computed labels do not reflect true values of instruction pointer ranges when function is inlined

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Using labels as values can only be used with computed gotos. This is documented
that way too.

[Bug c/114366] computed labels do not reflect true values of instruction pointer ranges when function is inlined

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
To use these values, you need to be able to jump to one. This is done with the
computed goto statement6

[Bug c/114366] computed labels do not reflect true values of instruction pointer ranges when function is inlined

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |DUPLICATE

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Dup.

*** This bug has been marked as a duplicate of bug 44298 ***