[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
--- Comment #34 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:c39654e7a431992773b48d61f804494b0d70855f
commit r14-10132-gc39654e7a431992773b48d61f804494b0d70855f
Author: Jakub Jelinek
Date: Thu Apr 25 20:37:10 2024 +0200
c++: Retry the aliasing of base/complete cdtor optimization at
import_export_decl time [PR113208]
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)->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
&& fns[0]
&& idx == 1
&& cgraph_node::get_create (fns[0])->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])->set_comdat_group
(comdat_group);
if (symtab_node::get (clone)->same_comdat_group)
symtab_node::get (clone)->remove_from_same_comdat_group ();
symtab_node::get (clone)->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)
&& (SUPPORTS_ONE_ONLY || !DECL_WEAK (fn))
&& (!DECL_ONE_ONLY (fn)
|| (HAVE_COMDAT_GROUP && 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
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #33 from Jakub Jelinek --- It regresses g++.dg/coroutines/torture/co-await-16-template-traits.C g++.dg/cpp0x/pr89403.C g++.dg/tree-ssa/pr46228.C g++.dg/torture/pr104601.C g++.dg/torture/pr89303.C g++.dg/torture/pr91606.C on i686-linux, so I'll need to work on this some more.
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #32 from Jakub Jelinek --- Created attachment 57963 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57963=edit gcc14-pr113208.patch Ah, I shouldn't call expand_or_defer* in that function, that has been called already earlier and causes e.g. redefined_extern_inline.
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #31 from Jakub Jelinek --- Created attachment 57960 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57960=edit gcc14-pr113208.patch Here is my attempt to optimize it in the C++ FE. The ICE is gone and for pr113208_0.C compiled with -std=c++20 -O1 -fkeep-inline-functions it emits the desirable _ZN6vectorI12QualityValueEC2ERKS1_ ctor in the _ZN6vectorI12QualityValueEC5ERKS1_ comdat group as well as an alias to it. But, compared to e.g. 13.2.1, the alias is for some reason no longer inlined into _ZN1kC2ERKS_ call. Honza, any ideas what I'm doing wrong?
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
||ppalka at gcc dot gnu.org
--- Comment #30 from Jakub Jelinek ---
So, the difference is because we without/with constexpr we call on the abstract
_ZN6vectorI12QualityValueEC4ERKS1_ at different times.
Without it it is called from c_parse_final_cleanups ->
instantiate_pending_templates -> instantiate_decl -> instantiate_body ->
expand_or_defer_fn, so at_eof is true in
5071 if (DECL_INTERFACE_KNOWN (fn))
5072/* We've already made a decision as to how this function will
5073 be handled. */;
5074 else if (!at_eof
5075 || DECL_IMMEDIATE_FUNCTION_P (fn)
5076 || DECL_OMP_DECLARE_REDUCTION_P (fn))
5077tentative_decl_linkage (fn);
5078 else
5079import_export_decl (fn);
and so import_export_decl is called. Now import_export_decl sets
3512 else if (DECL_TEMPLOID_INSTANTIATION (decl))
3513{
3514 /* DECL is an implicit instantiation of a function or static
3515 data member. */
3516 if (flag_implicit_templates
3517 || (flag_implicit_inline_templates
3518 && TREE_CODE (decl) == FUNCTION_DECL
3519 && DECL_DECLARED_INLINE_P (decl)))
3520comdat_p = true;
and because of comdat_p being true it does
else if (comdat_p)
{
/* If we decided to put DECL in COMDAT, mark it accordingly at
this point. */
comdat_linkage (decl);
}
which
if (flag_weak)
{
make_decl_one_only (decl, cxx_comdat_group (decl));
Later on expand_or_defer_fn_1 calls maybe_clone_body.
In that function because of the above DECL_ONE_ONLY (fn) is true, so we
if (DECL_ONE_ONLY (fn))
cgraph_node::get_create (clone)->set_comdat_group (cxx_comdat_group
(clone));
and later on
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]*. */
Now, in the constexpr case, expand_or_defer_fn_1 is called much ealier, when
not at_eof, during constant evaluation of a different synthetized constructor:
#1 0x00813795 in expand_or_defer_fn_1 (fn=) at ../../gcc/cp/semantics.cc:5100
#2 0x00813ac3 in expand_or_defer_fn (fn=) at ../../gcc/cp/semantics.cc:5135
#3 0x007c97a7 in instantiate_body (pattern=, args=, d=, nested_p=false)
at ../../gcc/cp/pt.cc:27133
#4 0x007cb08a in instantiate_decl (d=, defer_ok=false, expl_inst_class_mem_p=false) at
../../gcc/cp/pt.cc:27399
#5 0x004936da in cxx_eval_call_expression (ctx=0x7fffb120,
t=, lval=vc_prvalue,
non_constant_p=0x7fffb24f, overflow_p=0x7fffb24e)
at ../../gcc/cp/constexpr.cc:3059
#6 0x004a6319 in cxx_eval_constant_expression (ctx=0x7fffb120,
t=, lval=vc_prvalue,
non_constant_p=0x7fffb24f,
overflow_p=0x7fffb24e, jump_target=0x0) at
../../gcc/cp/constexpr.cc:7532
#7 0x004ac44e in cxx_eval_outermost_constant_expr (t=, allow_non_constant=true, strict=true,
manifestly_const_eval=mce_value::mce_false,
constexpr_dtor=false, object=) at
../../gcc/cp/constexpr.cc:8830
#8 0x004ad558 in maybe_constant_value (t=,
decl=, manifestly_const_eval=mce_value::mce_false) at
../../gcc/cp/constexpr.cc:9118
#9 0x004f90c7 in cp_fold (x=, flags=3) at
../../gcc/cp/cp-gimplify.cc:3409
#10 0x004ee8a1 in cp_fold_r (stmt_p=0x7fffea2df998,
walk_subtrees=0x7fffb554, data_=0x7fffb5f0) at
../../gcc/cp/cp-gimplify.cc:1359
#11 0x01552484 in walk_tree_1 (tp=0x7fffea2df998, func=0x4ee673
, data=0x7fffb5f0, pset=0x0,
lh=0x859385 >*)>)
at ../../gcc/tree.cc:11429
#12 0x004ef1d0 in cp_fold_function (fndecl=) at ../../gcc/cp/cp-gimplify.cc:1488
#13 0x0057cae5 in finish_function (inline_p=false) at
../../gcc/cp/decl.cc:18756
#14 0x00624ec1 in synthesize_method (fndecl=) at ../../gcc/cp/method.cc:1845
Because at_eof is false, we take the
5072/* We've already made a decision as to how this function will
5073 be handled. */;
5074 else if (!at_eof
5075 || DECL_IMMEDIATE_FUNCTION_P (fn)
5076 || DECL_OMP_DECLARE_REDUCTION_P (fn))
5077tentative_decl_linkage (fn);
path, so among other things don't define that the fn will be comdat.
But still maybe_clone_body is called, but because DECL_ONE_ONLY (fn) is not
true, the
if (DECL_ONE_ONLY (fn))
cgraph_node::get_create (clone)->set_comdat_group (cxx_comdat_group
(clone));
is not done,
bool can_alias
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #29 from Jakub Jelinek --- Looking at t1 (i.e. the reduced testcase with constexpr), the difference with -std=c++20 -O1 -fkeep-inline-functions is that in r14-5978 we used to emit _ZN6vectorI12QualityValueEC2ERKS1_ in _ZN6vectorI12QualityValueEC5ERKS1_ comdat section and _ZN6vectorI12QualityValueEC1ERKS1_ as an alias to it (i.e. the r0-97383-g24b3ff2c53806d3d optimization), while with r14-5979 we don't optimize it any longer, i.e. emit _ZN6vectorI12QualityValueEC2ERKS1_ in _ZN6vectorI12QualityValueEC2ERKS1_ comdat and _ZN6vectorI12QualityValueEC2ERKS1_ in _ZN6vectorI12QualityValueEC2ERKS1_ comdat. I thought that ought to be ABI compatible (the latter is what we used to emit before r0-97383), all the involved symbols are weak and either linker keeps the pair of symbols with the _ZN6vectorI12QualityValueEC5ERKS1_ comdat, or one or both of the _ZN6vectorI12QualityValueEC[12]ERKS1_ comdats (depending on if just one or both of those symbols are used), or it keeps all of them and the linker chooses between the 2 symbol definitions one that is actually used. Of course, I'd like to understand why Marek's patch changed the behavior.
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #28 from Jan Hubicka --- So the main problem is that in t2 we have _ZN6vectorI12QualityValueEC1ERKS1_/7 (vector<_Tp>::vector(const vector<_Tp>&) [with _Tp = QualityValue]) Type: function definition analyzed alias cpp_implicit_alias Visibility: semantic_interposition public weak comdat comdat_group:_ZN6vectorI12QualityValueEC5ERKS1_ one_only Same comdat group as: _ZN6vectorI12QualityValueEC2ERKS1_/6 References: _ZN6vectorI12QualityValueEC2ERKS1_/6 (alias) Referring: Function flags: Called by: _Z41__static_initialization_and_destruction_0v/8 (can throw external) Calls: and in t1 we have _ZN6vectorI12QualityValueEC1ERKS1_/2 (constexpr vector<_Tp>::vector(const vector<_Tp>&) [with _Tp = QualityValue]) Type: function definition Visibility: semantic_interposition external public weak comdat comdat_group:_ZN6vectorI12QualityValueEC1ERKS1_ one_only References: Referring: Function flags: Called by: Calls: This is the same symbol name but in two different comdat groups (C1 compared to C5). With -O0 both seems to get the C5 group I can silence the ICE by making aliases undefined during symbol merging (which is kind of hack but should make sanity checks happy), but I am still lost how this is supposed to work in valid code.
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #27 from Jan Hubicka --- OK, but the problem is same. Having comdats with same key defining different set of public symbols is IMO not a good situation for both non-LTO and LTO builds. Unless the additional alias is never used by valid code (which would make it useless and probably we should not generate it) it should be possible to produce a scenario where linker will pick wrong version of comdat and we get undefined symbol in non-LTO builds...
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #26 from Andrew Pinski --- (In reply to Jan Hubicka from comment #25) > > If constexpr changes how the constructor is generated, isn't this violation > of ODR? Note the original code didn't have the constexpr change. And IIRC constexpr in libstdc++ might be different depending on the language, C++11 vs C++17 in many cases too.
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #25 from Jan Hubicka --- So we have comdat groups that diverges in t1.o and t2.o. In one object it has alias in it while in other object it does not Merging nodes for _ZN6vectorI12QualityValueEC2ERKS1_. Candidates: _ZN6vectorI12QualityValueEC2ERKS1_/1 (__ct_base ) Type: function definition analyzed Visibility: externally_visible semantic_interposition prevailing_def_ironly public weak comdat comdat_group:_ZN6vectorI12QualityValueEC2ERKS1_ one_only next sharing asm name: 19 References: Referring: Read from file: t1.o Unit id: 1 Function flags: count:1073741824 (estimated locally) Called by: _Z1n1k/6 (1073741824 (estimated locally),1.00 per call) (can throw external) Calls: _ZN12_Vector_baseI12QualityValueEC2Eii/10 (1073741824 (estimated locally),1.00 per call) (can throw external) _ZNK12_Vector_baseI12QualityValueE1gEv/9 (1073741824 (estimated locally),1.00 per call) (can throw external) _ZN6vectorI12QualityValueEC2ERKS1_/19 (__ct_base ) Type: function definition analyzed Visibility: externally_visible semantic_interposition preempted_ir public weak comdat comdat_group:_ZN6vectorI12QualityValueEC5ERKS1_ one_only Same comdat group as: _ZN6vectorI12QualityValueEC1ERKS1_/20 previous sharing asm name: 1 References: Referring: _ZN6vectorI12QualityValueEC1ERKS1_/20 (alias) Read from file: t2.o Unit id: 2 Function flags: count:1073741824 (estimated locally) Called by: Calls: _ZN12_Vector_baseI12QualityValueEC2Eii/23 (1073741824 (estimated locally),1.00 per call) (can throw external) _ZNK12_Vector_baseI12QualityValueE1gEv/24 (1073741824 (estimated locally),1.00 per call) (can throw external) After resolution: _ZN6vectorI12QualityValueEC2ERKS1_/1 (__ct_base ) Type: function definition analyzed Visibility: externally_visible semantic_interposition prevailing_def_ironly public weak comdat comdat_group:_ZN6vectorI12QualityValueEC2ERKS1_ one_only next sharing asm name: 19 References: Referring: Read from file: t1.o Unit id: 1 Function flags: count:1073741824 (estimated locally) Called by: _Z1n1k/6 (1073741824 (estimated locally),1.00 per call) (can throw external) Calls: _ZN12_Vector_baseI12QualityValueEC2Eii/10 (1073741824 (estimated locally),1.00 per call) (can throw external) _ZNK12_Vector_baseI12QualityValueE1gEv/9 (1073741824 (estimated locally),1.00 per call) (can throw external) We opt for version without alias and later ICE in sanity check verifying that aliases have same comdat group as their targets. I wonder how this is ice-on-valid code, since with normal linking the aliased symbol may or may not appear in the winning comdat group, so using he alias has to break. If constexpr changes how the constructor is generated, isn't this violation of ODR? We probably can go and reset every node in losing comdat group to silence the ICE and getting undefined symbol instead
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #24 from Jakub Jelinek --- As documented in https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-special-ctor-dtor C2 is base object constructor (C1 is complete object constructor, C3 is allocating complete constructor). C5 is an extension we use in the PR3187 r0-97383-g24b3ff2c53806d3d (related discussion starts at https://gcc.gnu.org/legacy-ml/gcc-patches/2009-11/threads.html#00700 and continues to https://gcc.gnu.org/legacy-ml/gcc-patches/2009-12/threads.html#00023 ) optimization for the comdat name containing both the C1 and C2 versions of the constructors as aliases.
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
--- Comment #23 from Richard Biener ---
So we have _ZN6vectorI12QualityValueEC{2,5}ERKS1_ so C2 vs C5, whatever that
exactly means.
When not using -flto and not optimizing the comdat group in both objects is
COMDAT group section [2] `.group' [_ZN6vectorI12QualityValueEC5ERKS1_]
contains 2 sections:
[Index]Name
[9] .text._ZN6vectorI12QualityValueEC2ERKS1_
[ 10] .rela.text._ZN6vectorI12QualityValueEC2ERKS1_
the comdat group doesn't survive to the non-LTO object when optimizing.
I'm a bit lost as to where to look for the error. Honza?
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #22 from Jakub Jelinek --- Reproduces even with just -r -flto -std=c++20 -O1.
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #21 from Richard Biener --- Honza, can you please have a look here?
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-03-25 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #20 from Andrew Pinski --- (In reply to Andrew Pinski from comment #19) > I will redo the reduction to make sure it is valid. I have not had the time to do the re-reduction. so I will let someone else handle that if needed. Note it might be the case where we have ICF doing the alias which causes the difference but I am not 100% sure there. Anyways confirmed with my reduction with the soruces in comment #16, #17 and #18.
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #19 from Andrew Pinski --- (In reply to Andrew Pinski from comment #18) > Created attachment 57805 [details] > t1.cc ~/upstream-gcc-match/bin/g++ -flto t1.cc t2.cc -O1 -std=c++20 I attached the reduced testcase from the reduced testcase; 3 files including one header which is common between the 2 except for the constexpr. I will redo the reduction to make sure it is valid.
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #18 from Andrew Pinski --- Created attachment 57805 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57805=edit t1.cc
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #17 from Andrew Pinski --- Created attachment 57804 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57804=edit t2.cc
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #16 from Andrew Pinski --- Created attachment 57803 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57803=edit t.h
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #15 from Sam James --- Created attachment 57802 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57802=edit src_data_test_QualityValues.cpp.ii.orig.xz
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #14 from Sam James --- Created attachment 57801 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57801=edit src_data_test_MappedRead.cpp.ii.orig.xz Attaching the originals..
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #13 from Andrew Pinski --- (In reply to Sam James from comment #9) > ``` > $ gcc -std=c++20 -flto src_data_test_MappedRead.cpp.ii > src_data_test_QualityValues.cpp.ii -O1 > lto1: error: Alias and target’s comdat groups differs > _ZNSt6vectorIN6PacBio4Data12QualityValueESaIS2_EEC2ERKS4_/8 (__ct_base ) > Type: function definition analyzed > [...] > ``` This testcase seems undefined behavior ... The only difference between the 2 files is one has constexpr on the vector constructor and the other does not ...
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 Sam James changed: What|Removed |Added Summary|[14 Regression] lto1: |[14 Regression] lto1: |error: Alias and target's |error: Alias and target's |comdat groups differs |comdat groups differs since ||r14-5979-g99d114c15523e0 CC||mpolacek at gcc dot gnu.org --- Comment #12 from Sam James --- r14-5979-g99d114c15523e0is the first bad commit commit r14-5979-g99d114c15523e0 Author: Marek Polacek Date: Fri Nov 17 14:48:44 2023 -0500 c++: P2280R4, Using unknown refs in constant expr [PR106650]
