On Mon, Sep 13, 2021 at 1:42 PM Linus Torvalds torvalds@linux-foundation.org wrote:
On Mon, Sep 13, 2021 at 1:16 PM Nick Desaulniers ndesaulniers@google.com 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@google.... 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.