llvmbot
commented
1 year ago @llvm/issue-subscribers-clang-frontend
Open ericniebler opened 1 year ago
llvmbot
commented
1 year ago @llvm/issue-subscribers-clang-frontend
cor3ntin
commented
1 year ago It seems related to constraint checking @erichkeane
chfast
commented
1 year ago Reduced: https://godbolt.org/z/3cb4K6Wbn
shafik
commented
1 year ago code
template <typename>
bool is_same_v;
template <typename, typename _Up>
concept __same_as = is_same_v<_Up>;
template <class _Fun>
concept __callable = requires(_Fun __fun) { __fun(); };
template <class>
int __v;
using __msuccess = int;
template <int>
struct __i {
template <template <class> class _Fn, class... _Args>
using __g = _Fn<_Args...>;
};
template <class _Arg>
concept __ok = __same_as<_Arg, __msuccess>;
template <class... _Args>
concept _Ok = (__ok<_Args> && ...);
template <template <class> class _Fn, class... _Args>
using __meval = __i<_Ok>::__g<_Fn, _Args...>;
template <class _Fn>
using __minvoke = __meval<_Fn::template __f>;
template <class>
struct __mexpand;
template <class, class _List>
using __mapply = __minvoke<__mexpand<_List>>;
struct __msize;
template <class _Fun>
using __call_result_t = decltype(_Fun()());
template <class... _As>
concept constructible_from = __is_constructible(_As...);
template <class>
concept move_constructible = constructible_from<>;
template <class>
struct __tuple;
struct {
template <class _Fun, class _Fun2>
requires __callable<_Fun2>
auto operator()(_Fun, _Fun2);
} __tuple_apply_fn;
template <class _Fun, class _Continuation>
using __tuple_types_fn =
decltype(__tuple_apply_fn(_Fun(), []<class...>() -> _Continuation {}));
struct __gen_tuple_fun_fn {
auto operator()() {
return [] {};
}
};
template <move_constructible...>
using __gen_tuple_fun_t = __gen_tuple_fun_fn;
template <class...>
using __tuple_t = __tuple<__call_result_t<__gen_tuple_fun_t<>>>;
struct __make_tuple_fn {
__tuple_t<> operator()();
};
template <class _Fun>
struct __mexpand<__tuple<_Fun>> {
template <class _MetaFn>
using __f = __tuple_types_fn<_Fun, _MetaFn>;
};
template <class _Tuple>
constexpr long tuple_size_v = __v<__mapply<__msize, _Tuple>>;
template <class...>
using tuple = __call_result_t<__make_tuple_fn>;
using T = tuple<>;
static_assert(tuple_size_v<T>);
Seems like there are multiple ways to get similar crashes, possible related to: https://github.com/llvm/llvm-project/issues/60778
erichkeane
commented
1 year ago @shafik: That reproducer doesn't seem to compile in GCC either, which makes fixing based off that reproducer really difficult. Any chance you can re-run the minimization with a constraint that its still a valid program?
chfast
commented
1 year ago @shafik: That reproducer doesn't seem to compile in GCC either, which makes fixing based off that reproducer really difficult. Any chance you can re-run the minimization with a constraint that its still a valid program?
Unfortunately, I was not able to compiler the original code in any compiler version (including GCC). The only option I did was to add -Werror -ferror-count=1 to crashing clang to limit the number of syntax errors introduced to the reducing tool.
@ericniebler do you maybe have a variant of this that compiles in any other compiler?
ericniebler
commented
1 year ago I never said the code was valid. It still shouldn't ICE the compiler.
erichkeane
commented
1 year ago I never said the code was valid. It still shouldn't ICE the compiler.
I definitely don't disagree there, we obviously never want to ICE. But 'crash on invalid' is a mix of 'lower priority' and 'harder to debug', so I was hoping that it was valid, but was minimized or preprocessed in a way that caused it to be illegal.
Attached is auto-generated repro script and source. Compile with
-std=c++20.test-560a57.zip