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.