On Mon, Sep 13, 2021 at 1:42 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, Sep 13, 2021 at 1:16 PM Nick Desaulniers > <ndesaulniers@xxxxxxxxxx> wrote: > > > > Do we have access to _Generic in GCC 4.9? > > We've ended up using it unconditionally since last year, so yes. Sorry, grepping would have taken < 1s. I'm very lazy. http://threevirtues.com/ > > In fact, the compiler version tests got removed when we raised the gcc > version requirement to 4.9 in commit 6ec4476ac825 ("Raise gcc version > requirement to 4.9"): > > "In particular, raising the minimum to 4.9 means that we can now just > assume _Generic() exists, which is likely the much better replacement > for a lot of very convoluted built-time magic with conditionals on > sizeof and/or __builtin_choose_expr() with same_type() etc" > > but we haven't used it much since. > > The "seqprop" code for picking the right lock for seqlock is perhaps > the main example, and staring at that code will make you go blind, so > look away. Looking at my patch: https://lore.kernel.org/stable/20210913203201.1844253-1-ndesaulniers@xxxxxxxxxx/ I don't think _Generic helps us in the case of dispatching based on the result of is_signed_type() (the operands could undergo type promotion, so we'd need lots of cases that are more concisely covered by is_signed_type()). It could replace the nested checks in div_64 with nested _Generics, I think. Not sure it's a huge win for readability. Maybe cut the number of expansions of the parameters in half though. Let me give it a try just to see what it looks like. -- Thanks, ~Nick Desaulniers
