[Bug c++/113976] New: explicit instantiation of const variable template following implicit instantiation is assembled in .rodata instead of .bss

[Bug c++/113976] New: explicit instantiation of const variable template following implicit instantiation is assembled in .rodata instead of .bss

[tamiko at gentoo dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113976

            Bug ID: 113976
           Summary: explicit instantiation of const variable template
                    following implicit instantiation is assembled in
                    .rodata instead of .bss
           Product: gcc
           Version: 13.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tamiko at gentoo dot org
  Target Milestone: ---

The following snippet of code:

    inline int mpi_type_id(const unsigned long int *) { return 42; }

    /* same for inline, static, extern */
    template <typename T>
    const int mpi_type_id_for_type = mpi_type_id(static_cast<T *>(nullptr));

    /* implicit instantiation */
    void broadcast() {
      int ierr = mpi_type_id_for_type<unsigned long>;
    }

    /* explicit instantiation */
    template const int mpi_type_id_for_type<unsigned long int>;

    int main() {}


leads to a segfault:

    % g++ segfault.cc -o segfault
    % ./segfault
    segmentation fault (core dumped)  ./segfault


The segfault happens because the int mpi_type_id_for_type<unsigned long> gets
assembled into the .rodata section:

    % objdump -xd segfault | grep mpi_type | c++filt
    0000000000002004 u     O .rodata 0000000000000004
mpi_type_id_for_type<unsigned long>
    0000000000004018 u     O .bss    0000000000000008 guard variable for
mpi_type_id_for_type<unsigned long>

and consequently the static initialization segfaults when trying to write into
the read only data section:

000000000000114a <_Z41__static_initialization_and_destruction_0v>:
    <snip>
    1167:       c6 00 01                movb   $0x1,(%rax)
    116a:       bf 00 00 00 00          mov    $0x0,%edi
    116f:       e8 18 00 00 00          call   118c <_Z11mpi_type_idPKm>
    1174:       89 05 8a 0e 00 00       mov    %eax,0xe8a(%rip)        # 2004
<_Z20mpi_type_id_for_typeImE>
    <snip>


Note that *any* other combination of
 - only broadcast() function definition
 - only explicit template instantiation
 - explicit template instantiation *before* broadcast() function definition
assembles mpi_type_id_for_type<unsigned long> correctly into the .bss section

Furthermore, linkage (inline, static, extern) of mpi_type_id_for_type also
doesn't seem to matter.


Reproduced with gcc-13.2.1, gcc-12.3.1, gcc-11.4.1 on gentoo and gcc-13.2.0 on
debian.

(gentoo) % gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/13/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/gcc-13-20240210/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/13
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/13/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/13/python
--enable-objc-gc --enable-languages=c,c++,go,objc,obj-c++,fortran
--enable-obsolete --enable-secureplt --disable-werror --with-system-zlib
--enable-nls --without-included-gettext --disable-libunwind-exceptions
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo Hardened 13.2.1_p20240210 p13'
--with-gcc-major-version-only --enable-libstdcxx-time --enable-lto
--disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-multilib
--with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all
--enable-libgomp --disable-libssp --disable-libada --enable-cet
--disable-systemtap --disable-valgrind-annotations --enable-vtable-verify
--with-zstd --with-isl --disable-isl-version-check --enable-default-pie
--enable-default-ssp --with-build-config=bootstrap-cet
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.1 20240210 (Gentoo Hardened 13.2.1_p20240210 p13)

(debian) % gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/13/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 13.2.0-13'
--with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-13
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-libstdcxx-backtrace --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/reproducible-path/gcc-13-13.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/reproducible-path/gcc-13-13.2.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.0 (Debian 13.2.0-13)

[Bug c++/113976] [11/12/13/14 Regression] explicit instantiation of const variable template following implicit instantiation is assembled in .rodata instead of .bss

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113976

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|explicit instantiation of   |[11/12/13/14 Regression]
                   |const variable template     |explicit instantiation of
                   |following implicit          |const variable template
                   |instantiation is assembled  |following implicit
                   |in .rodata instead of .bss  |instantiation is assembled
                   |                            |in .rodata instead of .bss
   Target Milestone|---                         |11.5
      Known to work|                            |5.1.0, 6.1.0, 7.1.0, 7.5.0
           Keywords|                            |needs-bisection
      Known to fail|                            |10.1.0, 8.1.0, 9.1.0

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed. Worked in GCC 7.x series and before.

[Bug c++/113976] [11/12/13/14 Regression] explicit instantiation of const variable template following implicit instantiation is assembled in .rodata instead of .bss

[sjames at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113976

Sam James <sjames at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-02-18
     Ever confirmed|0                           |1

[Bug c++/113976] [11/12/13/14 Regression] explicit instantiation of const variable template following implicit instantiation is assembled in .rodata instead of .bss

[tamiko at gentoo dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113976

--- Comment #2 from Matthias Maier <tamiko at gentoo dot org> ---
I have bisected the issue to:

commit 2ec399d8a6c9c26d69b73faf77c694fa3915dcec (HEAD, refs/bisect/bad)
Author: Joerg Sonnenberger <joerg@bec.de>
Date:   Fri Sep 1 10:26:00 2017 -0600

    varasm.c (bss_initializer_p): Do not put constants into .bss

            * varasm.c (bss_initializer_p): Do not put constants into .bss
            (categorize_decl_for_section): Handle bss_initializer_p returning
            false when DECL_INITIAL is NULL.

            * gcc.target/i386/const-in-bss.c: New test.

    From-SVN: r251602


(But I have the feeling that the issue really lies in `mpi_type_id_for_type<T>`
being misidentified as a constant (suitable for .rodata). The above commit
might have merely made the issue visible by turning it into a segfault.)



bisect log:
git bisect start
# good: [883312dc79806f513275b72502231c751c14ff72] Use ucontext_t not struct
ucontext in linux-unwind.h files.
git bisect good 883312dc79806f513275b72502231c751c14ff72
# bad: [406c2abec3f998e9064919b22db62f38a7c0e7b9] * gennews (files): Add files
for GCC 8.
git bisect bad 406c2abec3f998e9064919b22db62f38a7c0e7b9
# bad: [9cf7bfd919f394595c0ac561ed67b333a39ae51e] PR 83070 Fix -Wsign-compare
warning
git bisect bad 9cf7bfd919f394595c0ac561ed67b333a39ae51e
# bad: [01f44e44faf37fc34775b9e28e46d1c9243b247d] i386: Update preferred stack
boundary for leaf functions
git bisect bad 01f44e44faf37fc34775b9e28e46d1c9243b247d
# good: [30af3a2bbd315bf82363c066a335a040dede9901] Boolify some parameters.
git bisect good 30af3a2bbd315bf82363c066a335a040dede9901
# good: [3ca3c6ef7110fb842cf8175a58d91d239c418bbe] re PR sanitizer/81902 (new
-fsanitize=pointer-overflow option undocumented)
git bisect good 3ca3c6ef7110fb842cf8175a58d91d239c418bbe
# bad: [0f99f8e6d63038b68e5e7af950ff9e329bdc40ad] Daily bump.
git bisect bad 0f99f8e6d63038b68e5e7af950ff9e329bdc40ad
# bad: [95edbf5e5fb2c57ceda70cdf277d9b7655c1796e] Minor reformatting.
git bisect bad 95edbf5e5fb2c57ceda70cdf277d9b7655c1796e
# bad: [806fcf7183377c7df062a7fa0bcf9d0ce8ea1fc0] trans.c
(adjust_for_implicit_deref): New function.
git bisect bad 806fcf7183377c7df062a7fa0bcf9d0ce8ea1fc0
# bad: [ca1150f0129abd2b0b52ad0c701a6bd7e0a1fc76] re PR sanitizer/81981
(-fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear)
git bisect bad ca1150f0129abd2b0b52ad0c701a6bd7e0a1fc76
# bad: [0c949f0a1ce9cfa8c48e62628493140d60e65ea7] re PR libquadmath/81848 (Add
PowerPC support to libquadmath)
git bisect bad 0c949f0a1ce9cfa8c48e62628493140d60e65ea7
# bad: [beb8b5c154e57f5c2e3e6f372c2bae9a10f619b4] class.c
(finish_struct_methods): Done clear DECL_IN_AGGR_P here.
git bisect bad beb8b5c154e57f5c2e3e6f372c2bae9a10f619b4
# good: [db6bb1ec036f180584d221cdc66dff7bb7180d7a] S/390: PR82012: Implement
CAN_INLINE_P target hook.
git bisect good db6bb1ec036f180584d221cdc66dff7bb7180d7a
# bad: [e035be33793fa4aef8cff3358c9670a648d5d273] Fix excess precision handling
of compound assignments (PR c/82071).
git bisect bad e035be33793fa4aef8cff3358c9670a648d5d273
# bad: [2ec399d8a6c9c26d69b73faf77c694fa3915dcec] varasm.c (bss_initializer_p):
Do not put constants into .bss
git bisect bad 2ec399d8a6c9c26d69b73faf77c694fa3915dcec
# first bad commit: [2ec399d8a6c9c26d69b73faf77c694fa3915dcec] varasm.c
(bss_initializer_p): Do not put constants into .bss

[Bug c++/113976] [11/12/13/14 Regression] explicit instantiation of const variable template following implicit instantiation is assembled in .rodata instead of .bss since r8-2857-g2ec399d8a6c9c2

[law at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113976

--- Comment #3 from Jeffrey A. Law <law at gcc dot gnu.org> ---
What does the standard say about changing const objects?

[Bug c++/113976] [11/12/13/14 Regression] explicit instantiation of const variable template following implicit instantiation is assembled in .rodata instead of .bss since r8-2857-g2ec399d8a6c9c2

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113976

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #3)
> What does the standard say about changing const objects?

It says it is undefined. Note there is no changing const object in this code;
just the const variable is dynamically initialized which is 100% defined.

[Bug c++/113976] [11/12/13/14 Regression] explicit instantiation of const variable template following implicit instantiation is assembled in .rodata instead of .bss since r8-2857-g2ec399d8a6c9c2

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113976

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That sounds like a FE bug to me, rather than middle-end.

[Bug c++/113976] [11/12/13/14 Regression] explicit instantiation of const variable template following implicit instantiation is assembled in .rodata instead of .bss since r8-2857-g2ec399d8a6c9c2

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113976

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug c++/113976] [11/12/13/14 Regression] explicit instantiation of const variable template following implicit instantiation is assembled in .rodata instead of .bss since r8-2857-g2ec399d8a6c9c2

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113976

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Testcase showing that it is just this case of implicit instantiation followed
by explicit that is problematic:
int foo () { return 42; }
template <int N>
const int a = foo ();
const int *b = &a <0>;
template <int N>
const int c = foo ();
template const int c <0>;
template <int N>
const int d = foo ();
const int *e = &d <0>;
template const int d <0>;
template <int N>
const int f = foo ();
template const int f <0>;
const int *g = &f <0>;
int main () {}

[Bug c++/113976] [11/12/13/14 Regression] explicit instantiation of const variable template following implicit instantiation is assembled in .rodata instead of .bss since r8-2857-g2ec399d8a6c9c2

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113976

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|needs-bisection             |
                 CC|                            |jason at gcc dot gnu.org,
                   |                            |mpolacek at gcc dot gnu.org,
                   |                            |ppalka at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, what happens is that during the implicit instantiation we first set
TREE_READONLY
on the just created decl:
#0  c_apply_type_quals_to_decl (type_quals=1, decl=<var_decl 0x7fffea2f6120 d>)
at ../../gcc/c-family/c-common.cc:3851
#1  0x000000000089a73a in cp_apply_type_quals_to_decl (type_quals=1,
decl=<var_decl 0x7fffea2f6120 d>) at ../../gcc/cp/typeck.cc:11747
#2  0x000000000078d061 in tsubst_decl (t=<var_decl 0x7fffea2f6000 d>,
args=<tree_vec 0x7fffea2d1ec0>, complain=3, use_spec_table=false) at
../../gcc/cp/pt.cc:15609
#3  0x00000000007b0faf in instantiate_template (tmpl=<template_decl
0x7ffff7ffa400 d>, orig_args=<tree_vec 0x7fffea2d1ec0>, complain=3) at
../../gcc/cp/pt.cc:22100
#4  0x000000000076dc12 in finish_template_variable (var=<template_id_expr
0x7fffea2f5348>, complain=3) at ../../gcc/cp/pt.cc:10521
then clear it because it has a non-const initializer:
#0  cp_finish_decl (decl=<var_decl 0x7fffea2f6120 d>, init=<init_expr
0x7fffea2f53e8>, init_const_expr_p=false, asmspec_tree=<tree 0x0>, flags=4,
decomp=0x0)
    at ../../gcc/cp/decl.cc:8945
#1  0x00000000007c64f5 in instantiate_body (pattern=<template_decl
0x7ffff7ffa400 d>, args=<tree_vec 0x7fffea2d1ec0>, d=<var_decl 0x7fffea2f6120
d>, nested_p=false)
    at ../../gcc/cp/pt.cc:27006
#2  0x00000000007c838f in instantiate_decl (d=<var_decl 0x7fffea2f6120 d>,
defer_ok=false, expl_inst_class_mem_p=false) at ../../gcc/cp/pt.cc:27323
#3  0x00000000005a1145 in mark_used (decl=<var_decl 0x7fffea2f6120 d>,
complain=3) at ../../gcc/cp/decl2.cc:6008
but then mark it TREE_READONLY again in
#0  c_apply_type_quals_to_decl (type_quals=1, decl=<var_decl 0x7fffea2f6120 d>)
at ../../gcc/c-family/c-common.cc:3851
#1  0x000000000089a73a in cp_apply_type_quals_to_decl (type_quals=1,
decl=<var_decl 0x7fffea2f6120 d>) at ../../gcc/cp/typeck.cc:11747
#2  0x0000000000566b7c in grokdeclarator (declarator=0x3ebfa00,
declspecs=0x7fffffffd9e0, decl_context=NORMAL, initialized=0,
attrlist=0x7fffffffda50) at ../../gcc/cp/decl.cc:15267
#3  0x00000000006dc206 in cp_parser_explicit_instantiation
(parser=0x7fffea2dea80) at ../../gcc/cp/parser.cc:19864

Perhaps that
    /* Record constancy and volatility on the DECL itself .  There's
       no need to do this when processing a template; we'll do this
       for the instantiated declaration based on the type of DECL.  */
    if (!processing_template_decl)
      cp_apply_type_quals_to_decl (type_quals, decl);
at the end of grokdeclarator needs some further guarding, not do it if it has
been already implicitly instantiated or something similar.
Because I'm afraid by that point I'm afraid information that the var needs to
be runtime initialized isn't present on the VAR_DECL anymore (except in cleared
TREE_READONLY).

[Bug c++/113976] [11/12/13/14 Regression] explicit instantiation of const variable template following implicit instantiation is assembled in .rodata instead of .bss since r8-2857-g2ec399d8a6c9c2

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113976

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
E.g.
--- gcc/cp/decl.cc.jj   2024-02-15 09:51:34.460065992 +0100
+++ gcc/cp/decl.cc      2024-02-19 18:20:23.423410659 +0100
@@ -15263,7 +15263,14 @@ grokdeclarator (const cp_declarator *dec
     /* Record constancy and volatility on the DECL itself .  There's
        no need to do this when processing a template; we'll do this
        for the instantiated declaration based on the type of DECL.  */
-    if (!processing_template_decl)
+    if (!processing_template_decl
+       /* Don't do it for instantiated variable templates either,
+          cp_apply_type_quals_to_decl should have been called on it
+          already and might have have been overridden in cp_finish_decl
+          if initializer needs runtime initialization.  */
+       && (!VAR_P (decl)
+           || DECL_LANG_SPECIFIC (decl) == NULL
+           || !DECL_USE_TEMPLATE (decl)))
       cp_apply_type_quals_to_decl (type_quals, decl);

     return decl;
fixes it, but it is just a random shot in the dark.  I think we want to
differentiate
between freshly created VAR_DECL from the grokdeclarator vs. existing VAR_DECL
grokdeclarator just looked up.

[Bug c++/113976] [11/12/13/14 Regression] explicit instantiation of const variable template following implicit instantiation is assembled in .rodata instead of .bss since r8-2857-g2ec399d8a6c9c2

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113976

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note, adjusted testcase:
struct S { int a, b; };
int foo () { return 42; }
template <int N>
const S a = { 42, foo () };
const S *b = &a <0>;
template <int N>
const S c =  { 42, foo () };
template const S c <0>;
template <int N>
const S d =  { 42, foo () };
const S *e = &d <0>;
template const S d <0>;
template <int N>
const S f =  { 42, foo () };
template const S f <0>;
const S *g = &f <0>;
int main () {}
started crashing with r6-1525-g350562a75dfb4ac658adf620665871eb47166652
(before that commit it failed to link).
When there is partly constant and partly dynamic initializer, we were never
considering putting it into .bss section.

[Bug c++/113976] [11/12/13/14 Regression] explicit instantiation of const variable template following implicit instantiation is assembled in .rodata instead of .bss since r8-2857-g2ec399d8a6c9c2

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113976

--- Comment #10 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #8)
> E.g.
> --- gcc/cp/decl.cc.jj	2024-02-15 09:51:34.460065992 +0100
> +++ gcc/cp/decl.cc	2024-02-19 18:20:23.423410659 +0100
> @@ -15263,7 +15263,14 @@ grokdeclarator (const cp_declarator *dec
>      /* Record constancy and volatility on the DECL itself .  There's
>         no need to do this when processing a template; we'll do this
>         for the instantiated declaration based on the type of DECL.  */
> -    if (!processing_template_decl)
> +    if (!processing_template_decl
> +	/* Don't do it for instantiated variable templates either,
> +	   cp_apply_type_quals_to_decl should have been called on it
> +	   already and might have have been overridden in cp_finish_decl
> +	   if initializer needs runtime initialization.  */
> +	&& (!VAR_P (decl)
> +	    || DECL_LANG_SPECIFIC (decl) == NULL
> +	    || !DECL_USE_TEMPLATE (decl)))

Maybe checking !DECL_TEMPLATE_INSTANTIATED would be better, since that's set
only when the specialization's definition is instantiated from instantiate_body
as opposed to DECL_USE_TEMPLATE which gets set when the specialization is
formed?

>        cp_apply_type_quals_to_decl (type_quals, decl);
>  
>      return decl;
> fixes it, but it is just a random shot in the dark.  I think we want to
> differentiate
> between freshly created VAR_DECL from the grokdeclarator vs. existing
> VAR_DECL grokdeclarator just looked up.

[Bug c++/113976] [11/12/13/14 Regression] explicit instantiation of const variable template following implicit instantiation is assembled in .rodata instead of .bss since r8-2857-g2ec399d8a6c9c2

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113976

--- Comment #11 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:29ac92436aa5c702e9e02c206e7590ebd806398e

commit r14-9227-g29ac92436aa5c702e9e02c206e7590ebd806398e
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Feb 28 23:20:13 2024 +0100

    c++: Fix explicit instantiation of const variable templates after earlier
implicit instantation [PR113976]

    Already previously instantiated const variable templates had
    cp_apply_type_quals_to_decl called when they were instantiated,
    but if they need runtime initialization, their TREE_READONLY flag
    has been subsequently cleared.
    Explicit variable template instantiation calls grokdeclarator which
    calls cp_apply_type_quals_to_decl on them again, setting TREE_READONLY
    flag again, but nothing clears it afterwards, so we emit such
    instantiations into rodata sections and segfault when the dynamic
    initialization attempts to initialize them.

    The following patch fixes that by not calling cp_apply_type_quals_to_decl
    on already instantiated variable declarations.

    2024-02-28  Jakub Jelinek  <jakub@redhat.com>
                Patrick Palka  <ppalka@redhat.com>

            PR c++/113976
            * decl.cc (grokdeclarator): Don't call cp_apply_type_quals_to_decl
            on DECL_TEMPLATE_INSTANTIATED VAR_DECLs.

            * g++.dg/cpp1y/var-templ87.C: New test.

[Bug c++/113976] [11/12/13 Regression] explicit instantiation of const variable template following implicit instantiation is assembled in .rodata instead of .bss since r8-2857-g2ec399d8a6c9c2

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113976

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[11/12/13/14 Regression]    |[11/12/13 Regression]
                   |explicit instantiation of   |explicit instantiation of
                   |const variable template     |const variable template
                   |following implicit          |following implicit
                   |instantiation is assembled  |instantiation is assembled
                   |in .rodata instead of .bss  |in .rodata instead of .bss
                   |since                       |since
                   |r8-2857-g2ec399d8a6c9c2     |r8-2857-g2ec399d8a6c9c2

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk so far.