Compiler crash while using variants. #124326
Labels
clang:frontend
Language frontend issues, e.g. anything involving "Sema"
confirmed
Verified by a second party
crash
Prefer [crash-on-valid] or [crash-on-invalid]
Comments
EugeneZelenko
added
clang:frontend
|
@llvm/issue-subscribers-clang-frontend Author: Victor Bogado da Silva Lins (bogado)
The following program caused the crash:
#include <variant>
#include <utility>
#include <concepts>
#include <cstdint>
#include <array>
template<typename NUMERICAL>
concept is_numeric = requires(const NUMERICAL val) {
{ val + val } -> std::convertible_to<NUMERICAL>;
{ val *val } -> std::convertible_to<NUMERICAL>;
{ 1 * val } -> std::convertible_to<NUMERICAL>;
{ 1.0 * val } -> std::convertible_to<NUMERICAL>;
} && std::three_way_comparable_with<NUMERICAL, NUMERICAL>;
template<is_numeric... NUMERICs>
struct numeric_union
{
using value_type = std::variant<NUMERICs...>;
value_type value;
static constexpr auto type_count = sizeof...(NUMERICs);
template <std::integral auto I>
requires(I >= 0 && I < type_count)
using type = std::variant_alternative_t<I, value_type>;
template <std::integral auto I>
constexpr static auto prototype = type<I>{};
constexpr static auto sizes = []<std::size_t... INDEX>(std::index_sequence<INDEX...>) {
return std::array{ sizeof(prototype<INDEX>)... };
}(std::make_index_sequence<type_count-1>{});
};
using int_value = numeric_union<std::int8_t,
std::int16_t,
std::int32_t,
std::int64_t>;
using unsigned_value = numeric_union<std::uint8_t,
std::uint16_t,
std::uint32_t,
std::uint64_t>;
//using integral_value = numeric_union<int_value, unsigned_value>;
using float_value = numeric_union<float, double>;
static_assert(sizeof(float_value)==sizeof(float_value::value_type));tested on trunk from compiler-explorer and latest fedora. https://compiler-explorer.com/z/96q5d9vj5 Stack dump:
|
|
You can use |
shafik
added
the
needs-reduction
|
The last reproducer here: #75847 has the same backtrace. This could be a duplicate but we need a reduction in order to know for sure. |
|
CC @Endilll |
|
This version works: https://compiler-explorer.com/z/a4zz1PGr3 |
|
Smaller version showing the issue : #include <variant>
#include <concepts>
#include <array>
template<typename... NUMERICs>
struct numeric_union
{
using value_type = std::variant<NUMERICs...>;
template <std::integral auto I>
static constexpr auto prototype = std::variant_alternative_t<I, value_type>{};
constexpr static auto sizes = []<std::size_t... INDEX>(std::index_sequence<INDEX...>) {
return std::array{ sizeof(prototype<INDEX>)... };
}(std::make_index_sequence<std::variant_size_v<value_type>-1>{});
};
using float_value = numeric_union<float, double>;
static_assert(sizeof(float_value)==sizeof(float_value::value_type));while this version seems to work fine: #include <variant>
#include <array>
template<typename... NUMERICs>
struct numeric_union
{
using value_type = std::variant<NUMERICs...>;
template <int I>
using prototype = std::variant_alternative_t<I, value_type>;
constexpr static auto sizes = []<std::size_t... INDEX>(std::index_sequence<INDEX...>) {
return std::array{ sizeof(prototype<INDEX>)... };
}(std::make_index_sequence<std::variant_size_v<value_type>-1>{});
};
static_assert(sizeof(numeric_union<float, double>)==1);Using |
|
Reduced: https://compiler-explorer.com/z/eG7eGjMrb template<typename...>
struct numeric_union
{
template <int>
static constexpr auto prototype = 0;
constexpr static auto sizes = sizeof(prototype<0>);
};
numeric_union<int> a;The difference from #75847 is that the problematic |
They could be the same but it is not conclusive at this point. Once we have a proposed fix it should become more obvious. |
Endilll
removed
the
needs-reduction
|
@shafik It seems that the reduction has been done. Let me know if that's not the case. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The following program caused the crash:
tested on trunk from compiler-explorer and latest fedora.
https://compiler-explorer.com/z/96q5d9vj5
Assertion:
Stack dump:
The text was updated successfully, but these errors were encountered: