https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420
--- Comment #24 from Jason Merrill <jason at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #23) > I'd fear about jump-threading vs. __builtin_constant_p issues like PR72785 > and others, were the optimizers break the __builtin_constant_p argument and > the guarded expression apart and something different might be propagated > into them or evaluated differently etc. I really don't think that's a danger with this usage. 72785 is an abuse of __builtin_constant_p to give wildly different values based on its result: if a is 0, then if b is considered constant we get a NaN, and if it isn't we get 0. The threading seen in 72785 could only help this usage, by finding more cases where we don't need the conversion to uintptr_t. About your other comment about the middle-end deciding to do unfriendly things based on undefined behavior in the argument to __builtin_constant_p, the comparison is not undefined, it's unspecified. I wouldn't expect any surprises from the middle-end.
