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. -- H.J.
