https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114383
Bug ID: 114383
Summary: Wrong std::enable_if mangling ?
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
Following this bug on clang side:
https://github.com/llvm/llvm-project/issues/85656 where apparently clang folks
claim they fixed a mangling issue, I found out that clang >= 18 and gcc now
differ in mangling some std::enable_if expression. I am opening this bug to
track an potential mangling change needed on gcc side to be on par with the
current clang logic. I definitely don't have the knowledge to say which
mangling is correct, so I am going to trust clang folks who apparently changed
on purpose ;)
This snippet:
#include <type_traits>
template <typename T> class SomeCondition
{
public:
static constexpr bool value = true;
};
template <typename T, typename std::enable_if<SomeCondition<T>::value,
int>::type = 0> void SomeFunction(const T&);
void f()
{
SomeFunction(0);
}
results in mangling the call to "SomeFunction" as
_Z12SomeFunctionIiTnNSt9enable_ifIXsr13SomeConditionIT_EE5valueEiE4typeELi0EEvRKS1_
by clang >= 18 while gcc for now mangles it as _Z12SomeFunctionIiLi0EEvRKT_.
Does gcc need any long term mangling change to handle this case ?
