On 10/6/25 12:21 AM, H.J. Lu wrote:
On Sun, Oct 5, 2025 at 10:59 PM Jason Merrill <[email protected]> wrote:
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.
Since builtin/internal symbols are provided by compiler and won't work
with user provided definitions, treating user provided __stack_chk_guard
like normal builtin symbols requires significant changes to C/C++ parsers.
I don't know what you mean; most built-in declarations of e.g. library
functions work fine with user-provided definitions. Why couldn't we
push the stack guard decl in cxx_init_decl_processing?
Jason
