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
