[Bug c++/111300] New: [14 Regression] g++.dg/modules/xtreme-header-2_b.C

[Bug c++/111300] New: [14 Regression] g++.dg/modules/xtreme-header-2_b.C

[hp at gcc dot gnu.org]

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

            Bug ID: 111300
           Summary: [14 Regression] g++.dg/modules/xtreme-header-2_b.C
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hp at gcc dot gnu.org
                CC: redi at gcc dot gnu.org
  Target Milestone: ---

After commit r14-3615-gfcede95472ceb4 "Make --enable-libstdcxx-backtrace=auto
default to yes" there's a regression in test-results for several targets, among
them powerpc64le-unknown-linux-gnu:
https://gcc.gnu.org/pipermail/gcc-testresults/2023-September/794895.html
x86_64-pc-linux-gnu:
https://gcc.gnu.org/pipermail/gcc-testresults/2023-September/794904.html
s390x-ibm-linux-gnu:
https://gcc.gnu.org/pipermail/gcc-testresults/2023-September/795017.html
m68k-unknown-linux-gnu:
https://gcc.gnu.org/pipermail/gcc-testresults/2023-September/795117.html
pru-unknown-elf:
https://gcc.gnu.org/pipermail/gcc-testresults/2023-September/795070.html
cris-axis-elf:
https://gcc.gnu.org/pipermail/gcc-testresults/2023-September/795124.html

From a build-log for cris-axis-elf:
Running /topsrc/gcc/testsuite/g++.dg/modules/modules.exp ...
...
FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors)

From that g++.log (mind the cut-and-paste-artefacts):

/obj/cris-elf/libstdc++-v3/include/stacktrace:202:24: note: a later
'-fabi-version=' (or =0) avoids this error with a c\
hange in mangling^M
compiler exited with status 1
FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors)
Excess errors:
/obj/cris-elf/libstdc++-v3/include/stacktrace:202:24: error: mangling of
'constexpr std::stacktrace_entry::_M_get_info(\
std::string*, std::string*, int*) const::<lambda(void*,
std::stacktrace_entry::uintptr_t, const char*, std::stacktrace_\
entry::uintptr_t, std::stacktrace_entry::uintptr_t)>::operator void (*)(void*,
std::stacktrace_entry::uintptr_t, const \
char*, std::stacktrace_entry::uintptr_t, std::stacktrace_entry::uintptr_t)()
const' as '_ZZNKSt16stacktrace_entry11_M_g\
et_infoEPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES6_PiENKUlPvmPKcmmE_cvPFvS8_mSA_mmEEv'
conflicts with a pr\
evious mangle
/obj/cris-elf/libstdc++-v3/include/stacktrace:202:24: error: mangling of
'static constexpr void std::stacktrace_entry::\
_M_get_info(std::string*, std::string*, int*) const::<lambda(void*,
std::stacktrace_entry::uintptr_t, const char*, std:\
:stacktrace_entry::uintptr_t, std::stacktrace_entry::uintptr_t)>::_FUN(void*,
std::stacktrace_entry::uintptr_t, const c\
har*, std::stacktrace_entry::uintptr_t, std::stacktrace_entry::uintptr_t)' as
'_ZZNKSt16stacktrace_entry11_M_get_infoEP\
NSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES6_PiENUlPvmPKcmmE_4_FUNES8_mSA_mm'
conflicts with a previous mangl\
e
/obj/cris-elf/libstdc++-v3/include/stacktrace:202:24: error: mangling of
'std::stacktrace_entry::_M_get_info(std::strin\
g*, std::string*, int*) const::<lambda(void*, std::stacktrace_entry::uintptr_t,
const char*, std::stacktrace_entry::uin\
tptr_t, std::stacktrace_entry::uintptr_t)>' as
'_ZZNKSt16stacktrace_entry11_M_get_infoEPNSt7__cxx1112basic_stringIcSt11\
char_traitsIcESaIcEEES6_PiENKUlPvmPKcmmE_clES8_mSA_mm' conflicts with a
previous mangle

A guess as to the cause, is that there's a bug at the C++ level (hence
component "c++") exposed by a module test that includes libstdc++ support for
libbacktrace.

[Bug c++/111300] [14 Regression] g++.dg/modules/xtreme-header_b.C

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-09-06
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I'm going to "fix" this by moving the offending inline function out of the
header, into libstdc++exp.a

But it looks like there's a front end bug here, which will still be latent
after that.

[Bug c++/111300] [14 Regression] g++.dg/modules/xtreme-header_b.C

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The FAIL should be gone after r14-3812-gb96b554592c5cb but the underlying g++
problem is latent.

[Bug c++/111300] [14 Regression] g++.dg/modules/xtreme-header_b.C

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Possibly relevant, compiling anything including <stacktrace> with
-Wsystem-headers -Wabi gives these warnings:

/home/jwakely/gcc/13/include/c++/13.2.1/stacktrace: At global scope:
/home/jwakely/gcc/13/include/c++/13.2.1/stacktrace:201:24: warning: the mangled
name of 'constexpr std::stacktrace_entry::_M_get_info(std::string*,
std::string*, int*) const::<lambda(void*, std::stacktrace_entry::uintptr_t,
const char*, std::stacktrace_entry::uintptr_t,
std::stacktrace_entry::uintptr_t)>::operator void (*)(void*,
std::stacktrace_entry::uintptr_t, const char*,
std::stacktrace_entry::uintptr_t, std::stacktrace_entry::uintptr_t)() const'
changed between '-fabi-version=10'
('_ZZNKSt16stacktrace_entry11_M_get_infoEPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES6_PiENKUlPvmPKcmmE0_cvPFvS8_mSA_mmEEv')
and '-fabi-version=18'
('_ZZNKSt16stacktrace_entry11_M_get_infoEPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES6_PiENKUlPvmPKcmmE_cvPFvS8_mSA_mmEEv')
[-Wabi]
  201 |           auto __cb2 = [](void* __data, uintptr_t, const char*
__symname,
      |                        ^
/home/jwakely/gcc/13/include/c++/13.2.1/stacktrace:201:24: warning: the mangled
name of 'static constexpr void std::stacktrace_entry::_M_get_info(std::string*,
std::string*, int*) const::<lambda(void*, std::stacktrace_entry::uintptr_t,
const char*, std::stacktrace_entry::uintptr_t,
std::stacktrace_entry::uintptr_t)>::_FUN(void*,
std::stacktrace_entry::uintptr_t, const char*,
std::stacktrace_entry::uintptr_t, std::stacktrace_entry::uintptr_t)' changed
between '-fabi-version=10'
('_ZZNKSt16stacktrace_entry11_M_get_infoEPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES6_PiENUlPvmPKcmmE0_4_FUNES8_mSA_mm')
and '-fabi-version=18'
('_ZZNKSt16stacktrace_entry11_M_get_infoEPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES6_PiENUlPvmPKcmmE_4_FUNES8_mSA_mm')
[-Wabi]
/home/jwakely/gcc/13/include/c++/13.2.1/stacktrace:201:24: warning: the mangled
name of 'std::stacktrace_entry::_M_get_info(std::string*, std::string*, int*)
const::<lambda(void*, std::stacktrace_entry::uintptr_t, const char*,
std::stacktrace_entry::uintptr_t, std::stacktrace_entry::uintptr_t)>' changed
between '-fabi-version=10'
('_ZZNKSt16stacktrace_entry11_M_get_infoEPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES6_PiENKUlPvmPKcmmE0_clES8_mSA_mm')
and '-fabi-version=18'
('_ZZNKSt16stacktrace_entry11_M_get_infoEPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES6_PiENKUlPvmPKcmmE_clES8_mSA_mm')
[-Wabi]

e.g. g++ -x c++ /dev/null -include stacktrace -Wsystem-headers -std=c++23
-Wabi=10
(either using GCC 13 built with --enable-libstdcxx-backtrace or using GCC trunk
before r14-3812-gb96b554592c5cb which moved the lambda out of the header into
libstdc++exp.a)

Those -Wabi warnings might be related to the "previous mangle" errors in the
modules test.

[Bug c++/111300] [14 Regression] g++.dg/modules/xtreme-header_b.C

[hp at gcc dot gnu.org]

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

--- Comment #4 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #2)
> The FAIL should be gone after r14-3812-gb96b554592c5cb 

Confirmed

> but the underlying
> g++ problem is latent.

So, keeping this PR open is TRT?
Should the title then change to reflect a description of the latent error?
Suggestion: "Mangling error exposed by <backtrace>", but I'm unsure.

[Bug c++/111300] [14 Regression] g++.dg/modules/xtreme-header_b.C

[hp at gcc dot gnu.org]

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

--- Comment #5 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #2)
> The FAIL should be gone after r14-3812-gb96b554592c5cb

Also: thanks!

[Bug c++/111300] Modules error: mangling of [lambda] conflicts with previous mangle

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[14 Regression]             |Modules error: mangling of
                   |g++.dg/modules/xtreme-heade |[lambda] conflicts with
                   |r_b.C                       |previous mangle

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Hans-Peter Nilsson from comment #4)
> So, keeping this PR open is TRT?

Yes, I think so.

> Should the title then change to reflect a description of the latent error?

I've changed it to something that I think is more descriptive.

I didn't mention the library header name, because the version of the header on
trunk doesn't reveal it now. I haven't succeeded in reducing the error yet.

[Bug c++/111300] Modules error: mangling of [lambda] conflicts with previous mangle

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Given the note, maybe this is an intentional error to avoid creating a compiled
module interface that might not be usable:

note: a later '-fabi-version=' (or =0) avoids this error with a change in
mangling

But since a compiled module can't be used with different versions of the
compiler or even with different flags, I'm not sure how any conflict can
happen.