https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111080
Bug ID: 111080
Summary: restrict qualifier leaks debug info
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: sagebar at web dot de
Target Milestone: ---
The the following code example, debug information is retained for `struct foo`
even though that structure doesn't end up used:
Compile as `gcc -g -S -o - in.c | grep field_number`
```
struct foo {
int field_number_1;
int field_number_2;
int field_number_3;
int field_number_4;
int field_number_5;
};
typedef int fun_t(struct foo *restrict);
int main() {
return 0;
}
```
Output:
gcc -g -S -o - test.c | grep field_number
.ascii "field_number_1\0"
.ascii "field_number_2\0"
.ascii "field_number_3\0"
.ascii "field_number_4\0"
.ascii "field_number_5\0"
When removing the `restrict` qualifier in the parameter of `funptr_t`, debug
information is not included in the produced assembly (as one would expect).
Here is a list of different declarations and where `struct foo` is leaked in
gcc 12.1.0:
> typedef int fun_t(struct foo *restrict); // Leak
> typedef int fun_t(struct foo *); // No leak
> typedef int (*fun_t)(struct foo *restrict); // Leak
> typedef int (*fun_t)(struct foo *); // No leak
> extern int fun_t(struct foo *restrict); // No leak
> extern int fun_t(struct foo *); // No leak
> extern int (*fun_t)(struct foo *restrict); // Leak
> extern int (*fun_t)(struct foo *); // No leak
> static int fun_t(struct foo *restrict); // No leak
> static int fun_t(struct foo *); // No leak
> static int (*fun_t)(struct foo *restrict); // Leak
> static int (*fun_t)(struct foo *); // Leak (even w/o restrict!)
> int fun_t(struct foo *restrict); // No leak
> int fun_t(struct foo *); // No leak
> int (*fun_t)(struct foo *restrict); // Leak
> int (*fun_t)(struct foo *); // Leak (even w/o restrict!)
There is no difference when using `__restrict` or `__restrict__` instead.
