On 9/23/25 8:02 AM, H.J. Lu wrote:
On Tue, Sep 23, 2025 at 2:22 PM Florian Weimer <[email protected]> wrote:

* H. J. Lu:

It seems to me this goes in the wrong direction: guard_decl doesn't have
proper location information, so any subsequent diagnostics against it
will look wrong.  I would expect this to be more like the re-declaration

It looks normal to me:

[hjl@gnu-zen4-1 pr121911]$ cat bad.c
extern const int __stack_chk_guard;
[hjl@gnu-zen4-1 pr121911]$ make bad.s
/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/
-O0 -g -fPIC -fstack-protector-all -mstack-protector-guard=global -S
bad.c
bad.c:1:1: error: conflicting types for __stack_chk_guard; have ‘int’,
should be ‘long unsigned int’
     1 | extern const int __stack_chk_guard;
       | ^~~~~~
make: *** [Makefile:43: bad.s] Error 1
[hjl@gnu-zen4-1 pr121911]$

This:

extern const char *__stack_chk_guard;
char
f (void)
{
   return *__stack_chk_guard;
}

gives:

t.c: In function ‘f’:
t.c:5:10: error: invalid type argument of unary ‘*’ (have ‘long unsigned int’)
     5 |   return *__stack_chk_guard;
       |          ^~~~~~~~~~~~~~~~~~

This doesn't look quite right to me.


Here is the v3 patch:

$ cat bad2.c
extern const char *__stack_chk_guard;
char
f (void)
{
   return *__stack_chk_guard;
}
$ make bad2.s
/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/
-O0 -g -fPIC -fstack-protector-all -mstack-protector-guard=global -S
bad2.c
bad2.c:1:1: error: conflicting types for __stack_chk_guard; have
‘const char *’, should be ‘long unsigned int’
     1 | extern const char *__stack_chk_guard;
       | ^~~~~~
make: *** [Makefile:43: bad2.s] Error 1
$

It seems awkward to me to have special handling for stack_protect_guard_name in grokdeclarator/duplicate_decls; could we instead push the stack_protect_guard declaration along with other built-in decls and rely on the normal redeclaration handling? That should also make the special visibility handling unnecessary.

Jason

Reply via email to