https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121891
Bug ID: 121891
Summary: [14/15/16 Regression] ICE:
cp_emit_debug_info_for_using(tree_node*, tree_node*)
gcc/cp/name-lookup.cc:9240
Product: gcc
Version: 14.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dimitar.yordanov at sap dot com
Target Milestone: ---
Hi,
we hit an ICE with:
cat > foo.cc << EOF
template <int val> struct integral_constant {
static const int value = val;
};
template <bool B> using bool_constant = integral_constant<B>;
template <typename, typename>
const bool is_same_v = bool_constant<false>::value;
struct conditional {
using type = integral_constant<0>;
};
template <bool, class, class> using conditional_t = conditional;
template <typename T> struct ICI {
template <typename Tp = T>
int makeObject(int)
requires(is_same_v<decltype(Tp()), T>);
static constexpr char makeObject(long);
constexpr static bool value = sizeof(char) == sizeof(makeObject(1));
using type = bool_constant<value>;
};
template <class T>
struct IC
: conditional_t<0, typename ICI<T>::type, int> {};
template <class T> struct imc : IC<T>::type {};
template <class T>
const bool imc_v = imc<T>::value;
template <class Tp2> struct pair {
using first_type = int;
using raw_second = Tp2;
pair(pair &&)
requires(imc_v<raw_second>);
};
template <class> struct unary_function {};
template <class PairT>
struct select1st : unary_function<typename PairT::first_type> {};
template <class KeyOfValue> struct bin_tree {
KeyOfValue key_of_value_;
};
template <class ImpType> struct M {
ImpType equal_range;
};
template <class Val> struct m : M<bin_tree<select1st<pair<const Val>>>> {
using M<bin_tree<select1st<pair<const Val>>>>::equal_range;
};
void collectCallstacks() {
struct BCA {};
m<BCA> blockedBy0;
}
EOF
g++ -std=c++20 -c foo.cc
First appeared after:
commit 8651991fe2ea90a7276e91673b15b5c3865f14d7 (HEAD)
Author: Marek Polacek <pola...@redhat.com>
Date: Fri Mar 15 09:23:28 2024 -0400
c++: ICE with noexcept and local specialization, again [PR114349]
Patrick noticed that my r14-9339-gdc6c3bfb59baab patch is wrong;
we're dealing with a noexcept-spec there, not a noexcept-expr, so
setting cp_noexcept_operand et al is incorrect. Back to the drawing
board then.
To fix noexcept84.C, we should probably avoid doing push_to_top_level
in certain cases. maybe_push_to_top_level didn't work here as-is, so
I changed it to not push to top level if decl_function_context is
non-null, when we are not dealing with a lambda.
This also fixes c++/114349, introduced by r14-9339.
PR c++/114349
gcc/cp/ChangeLog:
* name-lookup.cc (maybe_push_to_top_level): For a non-lambda,
don't push to top level if decl_function_context is non-null.
* pt.cc (maybe_instantiate_noexcept): Use maybe_push_to_top_level.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/noexcept85.C: New test.
* g++.dg/cpp0x/noexcept86.C: New test.
Best wishes
Dimitar
