On Mon, Aug 31, 2026 at 09:33:21AM +0200, Jakub Jelinek wrote:
> On Mon, Aug 31, 2026 at 08:57:54AM +0200, Stefan Schulze Frielinghaus wrote:
> > +/* TODO: mark constexpr once GCC requires C++17
> > + (std::array::operator[] is not constexpr in C++14). */
>
> You can do it already now,
> #if __cplusplus > 201703L
> constexpr
> #else
> const
> #endif
> Just make sure to test it with a C++14 compiler from time to time that
> it is supported as well.
I very much like this and will change it in a v2.
>
> > +static const auto sched_descr_zEC12 = []{
> > + using T = s390_sched_insn_descr;
> > + std::array<T, ATTR_ENUM_MNEMONIC_COUNT> a{};
> > + a[MNEMONIC_ALC] = T{}.set_groupalone();
>
> There should be a space before ().
Will do.
>
> Also, is this the best way to express this from maintainability POV?
> If not, the usual gcc way is a *.def file where one specifies it in
> some other way, or a generator that generates that from whatever
> format is most maintanable.
> This format is very repetitive, so expressing it as say
> X1 (ALGC, groupalone)
> X2 (CLC, cracked, set_groupalone)
> might help.
I do not have a strong opinion regarding the intermediate representation
as long as the final output are static arrays. I'm wondering whether an
indirection by having CPP macros would help much here. It would just
reduce the level of verbosity for files which barely change and which
typically do not need to be consulted by developers. Anyhow, if there
is consensus in favour of that, I'm happy to change that.
Cheers,
Stefan
