<feed xmlns='http://www.w3.org/2005/Atom'>
<title>gcc.git, branch basepoints/gcc-15</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/gcc.git/'/>
<entry>
<title>Bump BASE-VER.</title>
<updated>2024-04-26T09:50:36+00:00</updated>
<author>
<name>Jakub Jelinek</name>
<email>jakub@redhat.com</email>
</author>
<published>2024-04-26T09:50:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/gcc.git/commit/?id=48a320a175780a0714741c71b4299a634807ad4b'/>
<id>48a320a175780a0714741c71b4299a634807ad4b</id>
<content type='text'>
2024-04-26  Jakub Jelinek  &lt;jakub@redhat.com&gt;

	* BASE-VER: Set to 15.0.0.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
2024-04-26  Jakub Jelinek  &lt;jakub@redhat.com&gt;

	* BASE-VER: Set to 15.0.0.
</pre>
</div>
</content>
</entry>
<entry>
<title>amdgcn: Add gfx90c target</title>
<updated>2024-04-26T09:23:43+00:00</updated>
<author>
<name>Frederik Harwath</name>
<email>frederik@harwath.name</email>
</author>
<published>2024-04-24T18:29:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/gcc.git/commit/?id=b8e9fd535d6093e3a24af858364d8517a767b0d7'/>
<id>b8e9fd535d6093e3a24af858364d8517a767b0d7</id>
<content type='text'>
Add support for gfx90c GCN5 APU integrated graphics devices.
The LLVM AMDGPU documentation does not list those devices as supported
by rocm-amdhsa, but it passes most libgomp offloading tests.
Although they are constrainted compared to dGPUs, they might be
interesting for learning, experimentation, and testing.

gcc/ChangeLog:

	* config.gcc: Add gfx90c.
	* config/gcn/gcn-hsa.h (NO_SRAM_ECC): Likewise.
	* config/gcn/gcn-opts.h (enum processor_type): Likewise.
	(TARGET_GFX90c): New macro.
	* config/gcn/gcn.cc (gcn_option_override): Handle gfx90c.
	(gcn_omp_device_kind_arch_isa): Likewise.
	(output_file_start): Likewise.
	* config/gcn/gcn.h: Add gfx90c.
	* config/gcn/gcn.opt: Likewise.
	* config/gcn/mkoffload.cc (EF_AMDGPU_MACH_AMDGCN_GFX90c): New macro.
	(get_arch): Handle gfx90c.
	(main): Handle EF_AMDGPU_MACH_AMDGCN_GFX90c
	* config/gcn/t-omp-device: Add gfx90c.
	* doc/install.texi: Likewise.
	* doc/invoke.texi: Likewise.

libgomp/ChangeLog:

	* plugin/plugin-gcn.c (isa_hsa_name): Handle EF_AMDGPU_MACH_AMDGCN_GFX90c.
	(isa_code): Handle gfx90c.
	(max_isa_vgprs): Handle EF_AMDGPU_MACH_AMDGCN_GFX90c.

Signed-off-by: Frederik Harwath &lt;frederik@harwath.name&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add support for gfx90c GCN5 APU integrated graphics devices.
The LLVM AMDGPU documentation does not list those devices as supported
by rocm-amdhsa, but it passes most libgomp offloading tests.
Although they are constrainted compared to dGPUs, they might be
interesting for learning, experimentation, and testing.

gcc/ChangeLog:

	* config.gcc: Add gfx90c.
	* config/gcn/gcn-hsa.h (NO_SRAM_ECC): Likewise.
	* config/gcn/gcn-opts.h (enum processor_type): Likewise.
	(TARGET_GFX90c): New macro.
	* config/gcn/gcn.cc (gcn_option_override): Handle gfx90c.
	(gcn_omp_device_kind_arch_isa): Likewise.
	(output_file_start): Likewise.
	* config/gcn/gcn.h: Add gfx90c.
	* config/gcn/gcn.opt: Likewise.
	* config/gcn/mkoffload.cc (EF_AMDGPU_MACH_AMDGCN_GFX90c): New macro.
	(get_arch): Handle gfx90c.
	(main): Handle EF_AMDGPU_MACH_AMDGCN_GFX90c
	* config/gcn/t-omp-device: Add gfx90c.
	* doc/install.texi: Likewise.
	* doc/invoke.texi: Likewise.

libgomp/ChangeLog:

	* plugin/plugin-gcn.c (isa_hsa_name): Handle EF_AMDGPU_MACH_AMDGCN_GFX90c.
	(isa_code): Handle gfx90c.
	(max_isa_vgprs): Handle EF_AMDGPU_MACH_AMDGCN_GFX90c.

Signed-off-by: Frederik Harwath &lt;frederik@harwath.name&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>i386: Fix array index overflow in pr105354-2.c</title>
<updated>2024-04-26T09:04:58+00:00</updated>
<author>
<name>Haochen Jiang</name>
<email>haochen.jiang@intel.com</email>
</author>
<published>2024-04-26T08:48:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/gcc.git/commit/?id=4a2e55b3ada20fe6457466bb687a66c8d03e056e'/>
<id>4a2e55b3ada20fe6457466bb687a66c8d03e056e</id>
<content type='text'>
The array index should not be over 8 for v8hi, or it will fail
under -O0 or using -fstack-protector.

gcc/testsuite/ChangeLog:

	PR target/110621
	* gcc.target/i386/pr105354-2.c: As mentioned.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The array index should not be over 8 for v8hi, or it will fail
under -O0 or using -fstack-protector.

gcc/testsuite/ChangeLog:

	PR target/110621
	* gcc.target/i386/pr105354-2.c: As mentioned.
</pre>
</div>
</content>
</entry>
<entry>
<title>Daily bump.</title>
<updated>2024-04-26T00:16:42+00:00</updated>
<author>
<name>GCC Administrator</name>
<email>gccadmin@gcc.gnu.org</email>
</author>
<published>2024-04-26T00:16:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/gcc.git/commit/?id=9353f6f475b92930a582cb42c380da6aebeb9406'/>
<id>9353f6f475b92930a582cb42c380da6aebeb9406</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>bpf: set PREFERRED_DEBUGGING_TYPE to BTF_DEBUG</title>
<updated>2024-04-25T18:53:29+00:00</updated>
<author>
<name>David Faust</name>
<email>david.faust@oracle.com</email>
</author>
<published>2024-04-24T22:01:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/gcc.git/commit/?id=1604f7cebc49220e47d584615bcd91b1fdc1267f'/>
<id>1604f7cebc49220e47d584615bcd91b1fdc1267f</id>
<content type='text'>
BTF is the standard debug info used with BPF programs, so it makes sense
to default to BTF rather than DWARF.

gcc/
	* config/bpf/bpf.h (PREFERRED_DEBUGGING_TYPE): Set to BTF_DEBUG.

gcc/testsuite/
	* gcc.target/bpf/bpf-debug-options-1.c: New test.
	* gcc.target/bpf/bpf-debug-options-2.c: Likewise.
	* gcc.target/bpf/bpf-debug-options-3.c: Likewise.
	* gcc.target/bpf/core-options-4.c: Likewise.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
BTF is the standard debug info used with BPF programs, so it makes sense
to default to BTF rather than DWARF.

gcc/
	* config/bpf/bpf.h (PREFERRED_DEBUGGING_TYPE): Set to BTF_DEBUG.

gcc/testsuite/
	* gcc.target/bpf/bpf-debug-options-1.c: New test.
	* gcc.target/bpf/bpf-debug-options-2.c: Likewise.
	* gcc.target/bpf/bpf-debug-options-3.c: Likewise.
	* gcc.target/bpf/core-options-4.c: Likewise.
</pre>
</div>
</content>
</entry>
<entry>
<title>c++: Fix constexpr evaluation of parameters passed by invisible reference [PR111284]</title>
<updated>2024-04-25T18:45:04+00:00</updated>
<author>
<name>Jakub Jelinek</name>
<email>jakub@redhat.com</email>
</author>
<published>2024-04-25T18:45:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/gcc.git/commit/?id=f541757ba4632e204169dd08a5f10c782199af42'/>
<id>f541757ba4632e204169dd08a5f10c782199af42</id>
<content type='text'>
My r9-6136 changes to make a copy of constexpr function bodies before
genericization modifies it broke the constant evaluation of non-POD
arguments passed by value.
In the callers such arguments are passed as reference to usually a
TARGET_EXPR, but on the callee side until genericization they are just
direct uses of a PARM_DECL with some class type.
In cxx_bind_parameters_in_call I've used convert_from_reference to
pretend it is passed by value and then cxx_eval_constant_expression
is called there and evaluates that as an rvalue, followed by
adjust_temp_type if the types don't match exactly (e.g. const Foo
argument and passing to it reference to Foo TARGET_EXPR).

The reason this doesn't work is that when the TARGET_EXPR in the caller
is constant initialized, this for it is the address of the TARGET_EXPR_SLOT,
but if the code later on pretends the PARM_DECL is just initialized to the
rvalue of the constant evaluation of the TARGET_EXPR, it is as if there
is a bitwise copy of the TARGET_EXPR to the callee, so this in the callee
is then address of the PARM_DECL in the callee.

The following patch attempts to fix that by constexpr evaluation of such
arguments in the caller as an lvalue instead of rvalue, and on the callee
side when seeing such a PARM_DECL, if we want an lvalue, lookup the value
(lvalue) saved in ctx-&gt;globals (if any), and if wanting an rvalue,
recursing with vc_prvalue on the looked up value (because it is there
as an lvalue, nor rvalue).

adjust_temp_type doesn't work for lvalues of non-scalarish types, for
such types it relies on changing the type of a CONSTRUCTOR, but on the
other side we know what we pass to the argument is addressable, so
the patch on type mismatch takes address of the argument value, casts
to reference to the desired type and dereferences it.

2024-04-25  Jakub Jelinek  &lt;jakub@redhat.com&gt;

	PR c++/111284
	* constexpr.cc (cxx_bind_parameters_in_call): For PARM_DECLs with
	TREE_ADDRESSABLE types use vc_glvalue rather than vc_prvalue for
	cxx_eval_constant_expression and if it doesn't have the same
	type as it should, cast the reference type to reference to type
	before convert_from_reference and instead of adjust_temp_type
	take address of the arg, cast to reference to type and then
	convert_from_reference.
	(cxx_eval_constant_expression) &lt;case PARM_DECL&gt;: For lval case
	on parameters with TREE_ADDRESSABLE types lookup result in
	ctx-&gt;globals if possible.  Otherwise if lookup in ctx-&gt;globals
	was successful for parameter with TREE_ADDRESSABLE type,
	recurse with vc_prvalue on the returned value.

	* g++.dg/cpp1z/constexpr-111284.C: New test.
	* g++.dg/cpp1y/constexpr-lifetime7.C: Expect one error on a different
	line.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
My r9-6136 changes to make a copy of constexpr function bodies before
genericization modifies it broke the constant evaluation of non-POD
arguments passed by value.
In the callers such arguments are passed as reference to usually a
TARGET_EXPR, but on the callee side until genericization they are just
direct uses of a PARM_DECL with some class type.
In cxx_bind_parameters_in_call I've used convert_from_reference to
pretend it is passed by value and then cxx_eval_constant_expression
is called there and evaluates that as an rvalue, followed by
adjust_temp_type if the types don't match exactly (e.g. const Foo
argument and passing to it reference to Foo TARGET_EXPR).

The reason this doesn't work is that when the TARGET_EXPR in the caller
is constant initialized, this for it is the address of the TARGET_EXPR_SLOT,
but if the code later on pretends the PARM_DECL is just initialized to the
rvalue of the constant evaluation of the TARGET_EXPR, it is as if there
is a bitwise copy of the TARGET_EXPR to the callee, so this in the callee
is then address of the PARM_DECL in the callee.

The following patch attempts to fix that by constexpr evaluation of such
arguments in the caller as an lvalue instead of rvalue, and on the callee
side when seeing such a PARM_DECL, if we want an lvalue, lookup the value
(lvalue) saved in ctx-&gt;globals (if any), and if wanting an rvalue,
recursing with vc_prvalue on the looked up value (because it is there
as an lvalue, nor rvalue).

adjust_temp_type doesn't work for lvalues of non-scalarish types, for
such types it relies on changing the type of a CONSTRUCTOR, but on the
other side we know what we pass to the argument is addressable, so
the patch on type mismatch takes address of the argument value, casts
to reference to the desired type and dereferences it.

2024-04-25  Jakub Jelinek  &lt;jakub@redhat.com&gt;

	PR c++/111284
	* constexpr.cc (cxx_bind_parameters_in_call): For PARM_DECLs with
	TREE_ADDRESSABLE types use vc_glvalue rather than vc_prvalue for
	cxx_eval_constant_expression and if it doesn't have the same
	type as it should, cast the reference type to reference to type
	before convert_from_reference and instead of adjust_temp_type
	take address of the arg, cast to reference to type and then
	convert_from_reference.
	(cxx_eval_constant_expression) &lt;case PARM_DECL&gt;: For lval case
	on parameters with TREE_ADDRESSABLE types lookup result in
	ctx-&gt;globals if possible.  Otherwise if lookup in ctx-&gt;globals
	was successful for parameter with TREE_ADDRESSABLE type,
	recurse with vc_prvalue on the returned value.

	* g++.dg/cpp1z/constexpr-111284.C: New test.
	* g++.dg/cpp1y/constexpr-lifetime7.C: Expect one error on a different
	line.
</pre>
</div>
</content>
</entry>
<entry>
<title>libgcc: Don't use weakrefs for glibc 2.34</title>
<updated>2024-04-25T18:43:13+00:00</updated>
<author>
<name>Jakub Jelinek</name>
<email>jakub@redhat.com</email>
</author>
<published>2024-04-25T18:43:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/gcc.git/commit/?id=fe02f6caac2d9b51ad311889e76ba0c484356ea1'/>
<id>fe02f6caac2d9b51ad311889e76ba0c484356ea1</id>
<content type='text'>
glibc 2.34 and later doesn't have separate libpthread (libpthread.so.0 is a
dummy shared library with just some symbol versions for compatibility, but
all the pthread_* APIs are in libc.so.6).
So, we don't need to do the .weakref dances to check whether a program
has been linked with -lpthread or not, in dynamically linked apps those
will be always true anyway.
In -static linking, this fixes various issues people had when only linking
some parts of libpthread.a and getting weird crashes.  A hack for that was
what e.g. some Fedora glibcs used, where libpthread.a was a library
containing just one giant *.o file which had all the normal libpthread.a
*.o files linked with -r together.

libstdc++-v3 actually does something like this already since r10-10928,
the following patch is meant to fix it even for libgfortran, libobjc and
whatever else uses gthr.h.

2024-04-25  Jakub Jelinek  &lt;jakub@redhat.com&gt;

	* gthr.h (GTHREAD_USE_WEAK): Redefine to 0 for GLIBC 2.34 or later.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
glibc 2.34 and later doesn't have separate libpthread (libpthread.so.0 is a
dummy shared library with just some symbol versions for compatibility, but
all the pthread_* APIs are in libc.so.6).
So, we don't need to do the .weakref dances to check whether a program
has been linked with -lpthread or not, in dynamically linked apps those
will be always true anyway.
In -static linking, this fixes various issues people had when only linking
some parts of libpthread.a and getting weird crashes.  A hack for that was
what e.g. some Fedora glibcs used, where libpthread.a was a library
containing just one giant *.o file which had all the normal libpthread.a
*.o files linked with -r together.

libstdc++-v3 actually does something like this already since r10-10928,
the following patch is meant to fix it even for libgfortran, libobjc and
whatever else uses gthr.h.

2024-04-25  Jakub Jelinek  &lt;jakub@redhat.com&gt;

	* gthr.h (GTHREAD_USE_WEAK): Redefine to 0 for GLIBC 2.34 or later.
</pre>
</div>
</content>
</entry>
<entry>
<title>c++: Retry the aliasing of base/complete cdtor optimization at import_export_decl time [PR113208]</title>
<updated>2024-04-25T18:37:10+00:00</updated>
<author>
<name>Jakub Jelinek</name>
<email>jakub@redhat.com</email>
</author>
<published>2024-04-25T18:37:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/gcc.git/commit/?id=c39654e7a431992773b48d61f804494b0d70855f'/>
<id>c39654e7a431992773b48d61f804494b0d70855f</id>
<content type='text'>
When expand_or_defer_fn is called at_eof time, it calls import_export_decl
and then maybe_clone_body, which uses DECL_ONE_ONLY and comdat name in a
couple of places to try to optimize cdtors which are known to have the
same body by making the complete cdtor an alias to base cdtor (and in
that case also uses *[CD]5* as comdat group name instead of the normal
comdat group names specific to each mangled name).
Now, this optimization depends on DECL_ONE_ONLY and DECL_INTERFACE_KNOWN,
maybe_clone_body and can_alias_cdtor use:
      if (DECL_ONE_ONLY (fn))
        cgraph_node::get_create (clone)-&gt;set_comdat_group (cxx_comdat_group (clone));
...
  bool can_alias = can_alias_cdtor (fn);
...
      /* Tell cgraph if both ctors or both dtors are known to have
         the same body.  */
      if (can_alias
          &amp;&amp; fns[0]
          &amp;&amp; idx == 1
          &amp;&amp; cgraph_node::get_create (fns[0])-&gt;create_same_body_alias
               (clone, fns[0]))
        {
          alias = true;
          if (DECL_ONE_ONLY (fns[0]))
            {
              /* For comdat base and complete cdtors put them
                 into the same, *[CD]5* comdat group instead of
                 *[CD][12]*.  */
              comdat_group = cdtor_comdat_group (fns[1], fns[0]);
              cgraph_node::get_create (fns[0])-&gt;set_comdat_group (comdat_group);
              if (symtab_node::get (clone)-&gt;same_comdat_group)
                symtab_node::get (clone)-&gt;remove_from_same_comdat_group ();
              symtab_node::get (clone)-&gt;add_to_same_comdat_group
                (symtab_node::get (fns[0]));
            }
        }
and
  /* Don't use aliases for weak/linkonce definitions unless we can put both
     symbols in the same COMDAT group.  */
  return (DECL_INTERFACE_KNOWN (fn)
          &amp;&amp; (SUPPORTS_ONE_ONLY || !DECL_WEAK (fn))
          &amp;&amp; (!DECL_ONE_ONLY (fn)
              || (HAVE_COMDAT_GROUP &amp;&amp; DECL_WEAK (fn))));
The following testcase regressed with Marek's r14-5979 change,
when pr113208_0.C is compiled where the ctor is marked constexpr,
we no longer perform this optimization, where
_ZN6vectorI12QualityValueEC2ERKS1_ was emitted in the
_ZN6vectorI12QualityValueEC5ERKS1_ comdat group and
_ZN6vectorI12QualityValueEC1ERKS1_ was made an alias to it,
instead we emit _ZN6vectorI12QualityValueEC2ERKS1_ in
_ZN6vectorI12QualityValueEC2ERKS1_ comdat group and the same
content _ZN6vectorI12QualityValueEC1ERKS1_ as separate symbol in
_ZN6vectorI12QualityValueEC1ERKS1_ comdat group.
Now, the linker seems to somehow cope with that, eventhough it
probably keeps both copies of the ctor, but seems LTO can't cope
with that and Honza doesn't know what it should do in that case
(linker decides that the prevailing symbol is
_ZN6vectorI12QualityValueEC2ERKS1_ (from the
_ZN6vectorI12QualityValueEC2ERKS1_ comdat group) and
_ZN6vectorI12QualityValueEC1ERKS1_ alias (from the other TU,
from _ZN6vectorI12QualityValueEC5ERKS1_ comdat group)).

Note, the case where some constructor is marked constexpr in one
TU and not in another one happens pretty often in libstdc++ when
one mixes -std= flags used to compile different compilation units.

The reason the optimization doesn't trigger when the constructor is
constexpr is that expand_or_defer_fn is called in that case much earlier
than when it is not constexpr; in the former case it is called when we
try to constant evaluate that constructor.  But DECL_INTERFACE_KNOWN
is false in that case and comdat_linkage hasn't been called either
(I think it is desirable, because comdat group is stored in the cgraph
node and am not sure it is a good idea to create cgraph nodes for
something that might not be needed later on at all), so maybe_clone_body
clones the bodies, but doesn't make them as aliases.

The following patch is an attempt to redo this optimization when
import_export_decl is called at_eof time on the base/complete cdtor
(or deleting dtor).  It will not do anything if maybe_clone_body
hasn't been called uyet (the TREE_ASM_WRITTEN check on the
DECL_MAYBE_IN_CHARGE_CDTOR_P), or when one or both of the base/complete
cdtors have been lowered already, or when maybe_clone_body called
maybe_thunk_body and it was successful.  Otherwise retries the
can_alias_cdtor check and makes the complete cdtor alias to the
base cdtor with adjustments to the comdat group.

2024-04-25  Jakub Jelinek  &lt;jakub@redhat.com&gt;

	PR lto/113208
	* cp-tree.h (maybe_optimize_cdtor): Declare.
	* decl2.cc (import_export_decl): Call it for cloned cdtors.
	* optimize.cc (maybe_optimize_cdtor): New function.

	* g++.dg/abi/comdat2.C: New test.
	* g++.dg/abi/comdat5.C: New test.
	* g++.dg/lto/pr113208_0.C: New test.
	* g++.dg/lto/pr113208_1.C: New file.
	* g++.dg/lto/pr113208.h: New file.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When expand_or_defer_fn is called at_eof time, it calls import_export_decl
and then maybe_clone_body, which uses DECL_ONE_ONLY and comdat name in a
couple of places to try to optimize cdtors which are known to have the
same body by making the complete cdtor an alias to base cdtor (and in
that case also uses *[CD]5* as comdat group name instead of the normal
comdat group names specific to each mangled name).
Now, this optimization depends on DECL_ONE_ONLY and DECL_INTERFACE_KNOWN,
maybe_clone_body and can_alias_cdtor use:
      if (DECL_ONE_ONLY (fn))
        cgraph_node::get_create (clone)-&gt;set_comdat_group (cxx_comdat_group (clone));
...
  bool can_alias = can_alias_cdtor (fn);
...
      /* Tell cgraph if both ctors or both dtors are known to have
         the same body.  */
      if (can_alias
          &amp;&amp; fns[0]
          &amp;&amp; idx == 1
          &amp;&amp; cgraph_node::get_create (fns[0])-&gt;create_same_body_alias
               (clone, fns[0]))
        {
          alias = true;
          if (DECL_ONE_ONLY (fns[0]))
            {
              /* For comdat base and complete cdtors put them
                 into the same, *[CD]5* comdat group instead of
                 *[CD][12]*.  */
              comdat_group = cdtor_comdat_group (fns[1], fns[0]);
              cgraph_node::get_create (fns[0])-&gt;set_comdat_group (comdat_group);
              if (symtab_node::get (clone)-&gt;same_comdat_group)
                symtab_node::get (clone)-&gt;remove_from_same_comdat_group ();
              symtab_node::get (clone)-&gt;add_to_same_comdat_group
                (symtab_node::get (fns[0]));
            }
        }
and
  /* Don't use aliases for weak/linkonce definitions unless we can put both
     symbols in the same COMDAT group.  */
  return (DECL_INTERFACE_KNOWN (fn)
          &amp;&amp; (SUPPORTS_ONE_ONLY || !DECL_WEAK (fn))
          &amp;&amp; (!DECL_ONE_ONLY (fn)
              || (HAVE_COMDAT_GROUP &amp;&amp; DECL_WEAK (fn))));
The following testcase regressed with Marek's r14-5979 change,
when pr113208_0.C is compiled where the ctor is marked constexpr,
we no longer perform this optimization, where
_ZN6vectorI12QualityValueEC2ERKS1_ was emitted in the
_ZN6vectorI12QualityValueEC5ERKS1_ comdat group and
_ZN6vectorI12QualityValueEC1ERKS1_ was made an alias to it,
instead we emit _ZN6vectorI12QualityValueEC2ERKS1_ in
_ZN6vectorI12QualityValueEC2ERKS1_ comdat group and the same
content _ZN6vectorI12QualityValueEC1ERKS1_ as separate symbol in
_ZN6vectorI12QualityValueEC1ERKS1_ comdat group.
Now, the linker seems to somehow cope with that, eventhough it
probably keeps both copies of the ctor, but seems LTO can't cope
with that and Honza doesn't know what it should do in that case
(linker decides that the prevailing symbol is
_ZN6vectorI12QualityValueEC2ERKS1_ (from the
_ZN6vectorI12QualityValueEC2ERKS1_ comdat group) and
_ZN6vectorI12QualityValueEC1ERKS1_ alias (from the other TU,
from _ZN6vectorI12QualityValueEC5ERKS1_ comdat group)).

Note, the case where some constructor is marked constexpr in one
TU and not in another one happens pretty often in libstdc++ when
one mixes -std= flags used to compile different compilation units.

The reason the optimization doesn't trigger when the constructor is
constexpr is that expand_or_defer_fn is called in that case much earlier
than when it is not constexpr; in the former case it is called when we
try to constant evaluate that constructor.  But DECL_INTERFACE_KNOWN
is false in that case and comdat_linkage hasn't been called either
(I think it is desirable, because comdat group is stored in the cgraph
node and am not sure it is a good idea to create cgraph nodes for
something that might not be needed later on at all), so maybe_clone_body
clones the bodies, but doesn't make them as aliases.

The following patch is an attempt to redo this optimization when
import_export_decl is called at_eof time on the base/complete cdtor
(or deleting dtor).  It will not do anything if maybe_clone_body
hasn't been called uyet (the TREE_ASM_WRITTEN check on the
DECL_MAYBE_IN_CHARGE_CDTOR_P), or when one or both of the base/complete
cdtors have been lowered already, or when maybe_clone_body called
maybe_thunk_body and it was successful.  Otherwise retries the
can_alias_cdtor check and makes the complete cdtor alias to the
base cdtor with adjustments to the comdat group.

2024-04-25  Jakub Jelinek  &lt;jakub@redhat.com&gt;

	PR lto/113208
	* cp-tree.h (maybe_optimize_cdtor): Declare.
	* decl2.cc (import_export_decl): Call it for cloned cdtors.
	* optimize.cc (maybe_optimize_cdtor): New function.

	* g++.dg/abi/comdat2.C: New test.
	* g++.dg/abi/comdat5.C: New test.
	* g++.dg/lto/pr113208_0.C: New test.
	* g++.dg/lto/pr113208_1.C: New file.
	* g++.dg/lto/pr113208.h: New file.
</pre>
</div>
</content>
</entry>
<entry>
<title>bpf: avoid issues with CO-RE and -gtoggle</title>
<updated>2024-04-25T18:18:17+00:00</updated>
<author>
<name>David Faust</name>
<email>david.faust@oracle.com</email>
</author>
<published>2024-04-25T16:31:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/gcc.git/commit/?id=f175622d25e4146bb7450430831ec48615e6e4cb'/>
<id>f175622d25e4146bb7450430831ec48615e6e4cb</id>
<content type='text'>
Compiling a BPF program with CO-RE relocations (and BTF) while also
passing -gtoggle led to an inconsistent state where CO-RE support was
enabled but BTF would not be generated, and this was not caught by the
existing option parsing.  This led to an ICE when generating the CO-RE
relocation info, since BTF is required for CO-RE.

Update bpf_option_override to avoid this case, and add a few tests for
the interactions of these options.

gcc/
	* config/bpf/bpf.cc (bpf_option_override): Improve handling of CO-RE
	options to avoid issues with -gtoggle.

gcc/testsuite/
	* gcc.target/bpf/core-options-1.c: New test.
	* gcc.target/bpf/core-options-2.c: Likewise.
	* gcc.target/bpf/core-options-3.c: Likewise.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Compiling a BPF program with CO-RE relocations (and BTF) while also
passing -gtoggle led to an inconsistent state where CO-RE support was
enabled but BTF would not be generated, and this was not caught by the
existing option parsing.  This led to an ICE when generating the CO-RE
relocation info, since BTF is required for CO-RE.

Update bpf_option_override to avoid this case, and add a few tests for
the interactions of these options.

gcc/
	* config/bpf/bpf.cc (bpf_option_override): Improve handling of CO-RE
	options to avoid issues with -gtoggle.

gcc/testsuite/
	* gcc.target/bpf/core-options-1.c: New test.
	* gcc.target/bpf/core-options-2.c: Likewise.
	* gcc.target/bpf/core-options-3.c: Likewise.
</pre>
</div>
</content>
</entry>
<entry>
<title>openmp: Copy DECL_LANG_SPECIFIC and DECL_LANG_FLAG_? to tree-nested decl copy [PR114825]</title>
<updated>2024-04-25T18:09:35+00:00</updated>
<author>
<name>Jakub Jelinek</name>
<email>jakub@redhat.com</email>
</author>
<published>2024-04-25T18:09:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/gcc.git/commit/?id=14d48516e588ad2b35e2007b3970bdcb1b3f145c'/>
<id>14d48516e588ad2b35e2007b3970bdcb1b3f145c</id>
<content type='text'>
tree-nested.cc creates in 2 spots artificial VAR_DECLs, one of them is used
both for debug info and OpenMP/OpenACC lowering purposes, the other solely for
OpenMP/OpenACC lowering purposes.
When the decls are used in OpenMP/OpenACC lowering, the OMP langhooks (mostly
Fortran, C just a little and C++ doesn't have nested functions) then inspect
the flags on the vars and based on that decide how to lower the corresponding
clauses.

Unfortunately we weren't copying DECL_LANG_SPECIFIC and DECL_LANG_FLAG_?, so
the langhooks made decisions on the default flags on those instead.
As the original decl isn't necessarily a VAR_DECL, could be e.g. PARM_DECL,
using copy_node wouldn't work properly, so this patch just copies those
flags in addition to other flags it was copying already.  And I've removed
code duplication by introducing a helper function which does copying common
to both uses.

2024-04-25  Jakub Jelinek  &lt;jakub@redhat.com&gt;

	PR fortran/114825
	* tree-nested.cc (get_debug_decl): New function.
	(get_nonlocal_debug_decl): Use it.
	(get_local_debug_decl): Likewise.

	* gfortran.dg/gomp/pr114825.f90: New test.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
tree-nested.cc creates in 2 spots artificial VAR_DECLs, one of them is used
both for debug info and OpenMP/OpenACC lowering purposes, the other solely for
OpenMP/OpenACC lowering purposes.
When the decls are used in OpenMP/OpenACC lowering, the OMP langhooks (mostly
Fortran, C just a little and C++ doesn't have nested functions) then inspect
the flags on the vars and based on that decide how to lower the corresponding
clauses.

Unfortunately we weren't copying DECL_LANG_SPECIFIC and DECL_LANG_FLAG_?, so
the langhooks made decisions on the default flags on those instead.
As the original decl isn't necessarily a VAR_DECL, could be e.g. PARM_DECL,
using copy_node wouldn't work properly, so this patch just copies those
flags in addition to other flags it was copying already.  And I've removed
code duplication by introducing a helper function which does copying common
to both uses.

2024-04-25  Jakub Jelinek  &lt;jakub@redhat.com&gt;

	PR fortran/114825
	* tree-nested.cc (get_debug_decl): New function.
	(get_nonlocal_debug_decl): Use it.
	(get_local_debug_decl): Likewise.

	* gfortran.dg/gomp/pr114825.f90: New test.
</pre>
</div>
</content>
</entry>
</feed>
