[Bug lto/113208] New: [14 Regression] lto1: error: Alias and target's comdat groups differs

[Bug lto/113208] New: [14 Regression] lto1: error: Alias and target's comdat groups differs

[doko at gcc dot gnu.org]

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

            Bug ID: 113208
           Summary: [14 Regression] lto1: error: Alias and target's comdat
                    groups differs
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: doko at gcc dot gnu.org
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

seen with trunk 20240101, building the poedit package with -flto.

hints where to start the reduction are appreciated.

[...]
g++  -g -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
-ffile-prefix-map=/home/packages/gcc/tmp/poedit-3.4.2=. -flto=auto
-ffat-lto-objects -fstack-protector-strong -fstack-clash-protection -Wformat
-Werror=format-security -fcf-protection
-fdebug-prefix-map=/home/packages/gcc/tmp/poedit-3.4.2=/usr/src/poedit-3.4.2-1
-pthread -I/usr/include -I/usr/include/libsecret-1 -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/libmount
-I/usr/include/blkid -I/usr/include/gio-unix-2.0 -pthread 
-I/usr/lib/x86_64-linux-gnu/wx/include/gtk3-unicode-3.2 -I/usr/include/wx-3.2
-D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread 
-I/usr/include/gtkspell-3.0 -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/gtk-3.0
-I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/freetype2
-I/usr/include/libpng16 -I/usr/include/libmount -I/usr/include/blkid
-I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/pixman-1
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/x86_64-linux-gnu
-I/usr/include/webp -I/usr/include/gio-unix-2.0 -I/usr/include/atk-1.0
-I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0
-I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include
-I/usr/include/enchant-2 -pthread  -I/usr/include/lucene++   -DHAVE_PUGIXML -g
-Wall -O0 -DwxNO_UNSAFE_WXSTRING_CONV=1 "-DPOEDIT_PREFIX=\"/usr\"" 
-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -Wl,-z,relro -Wl,-z,now
-Wl,-z,relro -o poedit attentionbar.o cat_update.o cat_sorting.o catalog.o
catalog_po.o catalog_json.o catalog_xliff.o chooselang.o colorscheme.o
commentdlg.o concurrency.o configuration.o custom_buttons.o customcontrols.o
custom_notebook.o edapp.o edframe.o editing_area.o edlistctrl.o export_html.o
extractors/extractor.o extractors/extractor_gettext.o
extractors/extractor_legacy.o filemonitor.o fileviewer.o findframe.o gexecute.o
hidpi.o icons.o language.o languagectrl.o wx/main_toolbar.o manager.o menus.o
pluralforms/pl_evaluate.o prefsdlg.o pretranslate.o progressinfo.o
propertiesdlg.o qa_checks.o recent_files.o sidebar.o spellchecking.o
syntaxhighlighter.o text_control.o titleless_window.o tm/suggestions.o
tm/transmem.o tm/tmx_io.o unicode_helpers.o utility.o welcomescreen.o
http_client.o http_client_casablanca.o cloud_accounts.o cloud_accounts_ui.o
crowdin_client.o crowdin_gui.o localazy_client.o localazy_gui.o
keychain/keytar_posix.o wx_backports/wx_gtk_activityindicator.o
wx_backports/wx_gtk_nativewin.o compiled_xrc.o -L/usr/lib/x86_64-linux-gnu
-pthread   -lwx_gtk3u_xrc-3.2 -lwx_baseu_xml-3.2 -lwx_gtk3u_webview-3.2
-lwx_gtk3u_core-3.2 -lwx_baseu_net-3.2 -lwx_baseu-3.2  -llucene++  -lcld2
-lpugixml  -lcpprest -lboost_iostreams -lboost_thread -lpthread -lboost_system
-lssl -lcrypto -lsecret-1 -lgio-2.0 -lgobject-2.0 -lglib-2.0 
-L/usr/lib/x86_64-linux-gnu -lboost_thread -lpthread -lboost_regex
-lboost_system -licui18n -licuuc -licudata  -lgtkspell3-3 -lenchant-2 -lgtk-3
-lgdk-3 -lz -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -latk-1.0 -lcairo-gobject
-lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 
lto1: error: Alias and target's comdat groups differs
_ZNSt12__shared_ptrI7CatalogLN9__gnu_cxx12_Lock_policyE2EEC2Ev/70336 (__ct_base
)
  Type: function definition analyzed
  Visibility: externally_visible semantic_interposition no_reorder
prevailing_def_ironly public weak comdat
comdat_group:_ZNSt12__shared_ptrI7CatalogLN9__gnu_cxx12_Lock_policyE2EEC2Ev
one_only visibility_specified
  References: __gxx_personality_v0/23086 (addr) 
  Referring:
_ZNSt12__shared_ptrI7CatalogLN9__gnu_cxx12_Lock_policyE2EEC1Ev/327239 (alias) 
  Read from file: catalog.o
  Unit id: 4
  Function flags: merged_comdat
  Called by: _ZNSt10shared_ptrI7CatalogEC1Ev/70334 
  Calls: _ZNSt14__shared_countILN9__gnu_cxx12_Lock_policyE2EEC1Ev/37977 
_ZNSt12__shared_ptrI7CatalogLN9__gnu_cxx12_Lock_policyE2EEC1Ev/327239
(__ct_comp )
  Type: function definition analyzed alias
  Visibility: externally_visible semantic_interposition prevailing_def_ironly
public weak comdat
comdat_group:_ZNSt12__shared_ptrI7CatalogLN9__gnu_cxx12_Lock_policyE2EEC5Ev
one_only visibility_specified
  References:
_ZNSt12__shared_ptrI7CatalogLN9__gnu_cxx12_Lock_policyE2EEC2Ev/70336 (alias) 
  Referring: 
  Read from file: edframe.o
  Unit id: 16
  Function flags: merged_comdat
  Called by:
_ZNSt12__shared_ptrI7CatalogLN9__gnu_cxx12_Lock_policyE2EE5resetEv/327343 
  Calls: 
during IPA pass: modref
lto1: internal compiler error: verify_cgraph_node failed
0x6b5ef0 cgraph_node::verify_node()
        ../../src/gcc/cgraph.cc:3948
0x1a81c29 symtab_node::verify()
        ../../src/gcc/symtab.cc:1362
0x1a7c774 symtab_node::verify_symtab_nodes()
        ../../src/gcc/symtab.cc:1390
0x1a79917 symtab_node::checking_verify_symtab_nodes()
        ../../src/gcc/cgraph.h:686
0x1a79917 symbol_table::remove_unreachable_nodes(_IO_FILE*)
        ../../src/gcc/ipa.cc:678
0x686e54 read_cgraph_and_symbols(unsigned int, char const**)
        ../../src/gcc/lto/lto-common.cc:2978
0x1fcc99a lto_main()
        ../../src/gcc/lto/lto.cc:654
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <file:///usr/share/doc/gcc-14/README.Bugs> for instructions.
lto-wrapper: fatal error: g++ returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs

[doko at gcc dot gnu.org]

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

--- Comment #1 from Matthias Klose <doko at gcc dot gnu.org> ---
also seen in the pbcopper package

[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs

[doko at gcc dot gnu.org]

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

--- Comment #2 from Matthias Klose <doko at gcc dot gnu.org> ---
also in package s2geometry

[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0

[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs

[law at gcc dot gnu.org]

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

Jeffrey A. Law <law at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at gcc dot gnu.org
           Priority|P3                          |P1

[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs

[sjames at gcc dot gnu.org]

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

--- Comment #3 from Sam James <sjames at gcc dot gnu.org> ---
(In reply to Matthias Klose from comment #0)
> seen with trunk 20240101, building the poedit package with -flto.
> 
> hints where to start the reduction are appreciated.
> 

First, take the link command and see if you can prune any objects and still get
the ICE (you can automate this with cvise but it's often not worth bothering,
but see https://wiki.gentoo.org/wiki/GCC_ICE_reporting_guide#LTO_example for an
example)

Once you identify the relevant objects, check if any of them are archives, and
expand them with e.g. 'ar x', replacing them in the link line.

You can then try to replace them with preprocessed versions and LTO those, and
see if it still fails.

[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs

[sjames at gcc dot gnu.org]

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

--- Comment #4 from Sam James <sjames at gcc dot gnu.org> ---
(ah, there's no archives here, so no need to worry about that part)

[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs

[sjames at gcc dot gnu.org]

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

--- Comment #5 from Sam James <sjames at gcc dot gnu.org> ---
I can't reproduce this when building poedit. Don't have pbcopper or s2geometry
packaged.

[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs

[sjames at gcc dot gnu.org]

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

--- Comment #6 from Sam James <sjames at gcc dot gnu.org> ---
Got it with pbcopper. Reducing.

[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs

[sjames at gcc dot gnu.org]

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

--- Comment #7 from Sam James <sjames at gcc dot gnu.org> ---
Created attachment 57791
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57791&action=edit
src_data_test_MappedRead.cpp.ii

[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs

[sjames at gcc dot gnu.org]

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

--- Comment #8 from Sam James <sjames at gcc dot gnu.org> ---
Created attachment 57792
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57792&action=edit
src_data_test_QualityValues.cpp.ii

[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs

[sjames at gcc dot gnu.org]

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

--- Comment #9 from Sam James <sjames at gcc dot gnu.org> ---
```
$ 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
[...]
```

[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs

[sjames at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #57791|0                           |1
        is obsolete|                            |

--- Comment #10 from Sam James <sjames at gcc dot gnu.org> ---
Created attachment 57793
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57793&action=edit
src_data_test_MappedRead.cpp.ii

[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs

[sjames at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #57792|0                           |1
        is obsolete|                            |

--- Comment #11 from Sam James <sjames at gcc dot gnu.org> ---
Created attachment 57794
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57794&action=edit
src_data_test_QualityValues.cpp.ii

[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0

[sjames at gcc dot gnu.org]

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

Sam James <sjames at gcc dot gnu.org> 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 <sjames at gcc dot gnu.org> ---
r14-5979-g99d114c15523e0is the first bad commit
commit r14-5979-g99d114c15523e0
Author: Marek Polacek <polacek@redhat.com>
Date:   Fri Nov 17 14:48:44 2023 -0500

    c++: P2280R4, Using unknown refs in constant expr [PR106650]

[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0

[pinskia at gcc dot gnu.org]

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

--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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

[sjames at gcc dot gnu.org]

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

--- Comment #14 from Sam James <sjames at gcc dot gnu.org> ---
Created attachment 57801
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57801&action=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

[sjames at gcc dot gnu.org]

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

--- Comment #15 from Sam James <sjames at gcc dot gnu.org> ---
Created attachment 57802
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57802&action=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

[pinskia at gcc dot gnu.org]

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

--- Comment #16 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Created attachment 57803
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57803&action=edit
t.h

[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0

[pinskia at gcc dot gnu.org]

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

--- Comment #17 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Created attachment 57804
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57804&action=edit
t2.cc

[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0

[pinskia at gcc dot gnu.org]

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

--- Comment #18 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Created attachment 57805
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57805&action=edit
t1.cc

[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0

[pinskia at gcc dot gnu.org]

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

--- Comment #19 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-03-25
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #20 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> ---
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

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[rguenth at gcc dot gnu.org]

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

--- Comment #23 from Richard Biener <rguenth at gcc dot gnu.org> ---
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

[jakub at gcc dot gnu.org]

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

--- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[hubicka at gcc dot gnu.org]

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

--- Comment #25 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
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

[pinskia at gcc dot gnu.org]

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

--- Comment #26 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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

[hubicka at gcc dot gnu.org]

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

--- Comment #27 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
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

[hubicka at gcc dot gnu.org]

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

--- Comment #28 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
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

[jakub at gcc dot gnu.org]

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

--- Comment #29 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org,
                   |                            |ppalka at gcc dot gnu.org

--- Comment #30 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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))
5077            tentative_decl_linkage (fn);
5078          else
5079            import_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)))
3520            comdat_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  0x0000000000813795 in expand_or_defer_fn_1 (fn=<function_decl
0x7fffea2e0100 __ct >) at ../../gcc/cp/semantics.cc:5100
#2  0x0000000000813ac3 in expand_or_defer_fn (fn=<function_decl 0x7fffea2e0100
__ct >) at ../../gcc/cp/semantics.cc:5135
#3  0x00000000007c97a7 in instantiate_body (pattern=<template_decl
0x7ffff7ffa800 __ct >, args=<tree_vec 0x7fffea2df100>, d=<function_decl
0x7fffea2e0100 __ct >, nested_p=false)
    at ../../gcc/cp/pt.cc:27133
#4  0x00000000007cb08a in instantiate_decl (d=<function_decl 0x7fffea2e0100
__ct >, defer_ok=false, expl_inst_class_mem_p=false) at
../../gcc/cp/pt.cc:27399
#5  0x00000000004936da in cxx_eval_call_expression (ctx=0x7fffffffb120,
t=<aggr_init_expr 0x7fffea2d7e00>, lval=vc_prvalue,
non_constant_p=0x7fffffffb24f, overflow_p=0x7fffffffb24e)
    at ../../gcc/cp/constexpr.cc:3059
#6  0x00000000004a6319 in cxx_eval_constant_expression (ctx=0x7fffffffb120,
t=<aggr_init_expr 0x7fffea2d7e00>, lval=vc_prvalue,
non_constant_p=0x7fffffffb24f, 
    overflow_p=0x7fffffffb24e, jump_target=0x0) at
../../gcc/cp/constexpr.cc:7532
#7  0x00000000004ac44e in cxx_eval_outermost_constant_expr (t=<call_expr
0x7fffea2d7dc0>, allow_non_constant=true, strict=true,
manifestly_const_eval=mce_value::mce_false, 
    constexpr_dtor=false, object=<indirect_ref 0x7fffea2dfbe0>) at
../../gcc/cp/constexpr.cc:8830
#8  0x00000000004ad558 in maybe_constant_value (t=<call_expr 0x7fffea2d7dc0>,
decl=<tree 0x0>, manifestly_const_eval=mce_value::mce_false) at
../../gcc/cp/constexpr.cc:9118
#9  0x00000000004f90c7 in cp_fold (x=<call_expr 0x7fffea2d7dc0>, flags=3) at
../../gcc/cp/cp-gimplify.cc:3409
#10 0x00000000004ee8a1 in cp_fold_r (stmt_p=0x7fffea2df998,
walk_subtrees=0x7fffffffb554, data_=0x7fffffffb5f0) at
../../gcc/cp/cp-gimplify.cc:1359
#11 0x0000000001552484 in walk_tree_1 (tp=0x7fffea2df998, func=0x4ee673
<cp_fold_r(tree*, int*, void*)>, data=0x7fffffffb5f0, pset=0x0, 
    lh=0x859385 <cp_walk_subtrees(tree_node**, int*, tree_node*
(*)(tree_node**, int*, void*), void*, hash_set<tree_node*, false,
default_hash_traits<tree_node*> >*)>)
    at ../../gcc/tree.cc:11429
#12 0x00000000004ef1d0 in cp_fold_function (fndecl=<function_decl
0x7fffea2e4500 __ct >) at ../../gcc/cp/cp-gimplify.cc:1488
#13 0x000000000057cae5 in finish_function (inline_p=false) at
../../gcc/cp/decl.cc:18756
#14 0x0000000000624ec1 in synthesize_method (fndecl=<function_decl
0x7fffea2e4500 __ct >) 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))
5077            tentative_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 = can_alias_cdtor (fn);
is also false because it has:
  /* 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))));
and DECL_INTERFACE_KNOWN (fn) is still false, and

      /* 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]*.  */
isn't done either.
Later on during c_parse_final_cleanups (aka at_eof) import_export_decl is
called
on the clones individually, because they were still deferred, but
maybe_clone_body
isn't called again (it really can't be) and nothing is able to redo the cdtor
optimization at that point by turning one of the clones into an alias to the
other
one and adjusting the comdat group etc.

[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0

[jakub at gcc dot gnu.org]

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

--- Comment #31 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 57960
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57960&action=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

[jakub at gcc dot gnu.org]

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

--- Comment #32 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 57963
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57963&action=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

[jakub at gcc dot gnu.org]

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

--- Comment #33 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #34 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:c39654e7a431992773b48d61f804494b0d70855f

commit r14-10132-gc39654e7a431992773b48d61f804494b0d70855f
Author: Jakub Jelinek <jakub@redhat.com>
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 the complete cdtor alias to the
    base cdtor with adjustments to the comdat group.

    2024-04-25  Jakub Jelinek  <jakub@redhat.com>

            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.

[Bug lto/113208] [15 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
   Target Milestone|14.0                        |15.0
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
            Summary|[14 Regression] lto1:       |[15 Regression] lto1:
                   |error: Alias and target's   |error: Alias and target's
                   |comdat groups differs since |comdat groups differs since
                   |r14-5979-g99d114c15523e0    |r14-5979-g99d114c15523e0

--- Comment #35 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Should be fixed for 14.1 now.
Keeping it open to redo it in stage1 differently as discussed on the mailing
list.