On 2018-03-17 19:52, Linus Torvalds wrote: > On Sat, Mar 17, 2018 at 12:27 AM, Kees Cook <keesc...@chromium.org> wrote: >> >> Unfortunately my 4.4 test fails quickly: >> >> ./include/linux/jiffies.h: In function ‘jiffies_delta_to_clock_t’: >> ./include/linux/jiffies.h:444: error: first argument to >> ‘__builtin_choose_expr’ not a constant > > Ok, so it really looks like that same "__builtin_constant_p() doesn't > return a constant". > > Which is really odd, but there you have it.
Not really. We do rely on builtin_constant_p not being folded too quickly to a 0/1 answer, so that gcc still generates good code even if the argument is only known to be constant at a late(r) optimization stage (through inlining and all). So unlike types_compatible_p, which can obviously be answered early during parsing, builtin_constant_p is most of the time a yes/no/maybe/it's complicated thing. Sure, when the argument is just a literal or perhaps even any kind of ICE, gcc can fold it to "yes", and I think it does (though the details of when and if gcc does that can obviously be very version-dependent, which may be some of what we've seen). But when it's not that obvious, gcc leaves it in the undetermined state. That's not good enough for builtin_choose_expr, because even the type of the resulting expression depends on that first argument, so that really must be resolved early. So to have some kind of builtin_constant_p control a builtin_choose_expr, it would need to be a "builtin_ice_p" or "builtin_obviously_constant_p" that would always be folded to 0/1 as part of evaluating ICEs. So I don't think there's any way around creating a separate macro for use with compile-time constants. Rasmus
