https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646
--- Comment #27 from rguenther at suse dot de <rguenther at suse dot de> --- On April 15, 2016 11:58:39 PM GMT+02:00, "jamborm at gcc dot gnu.org" <gcc-bugzi...@gcc.gnu.org> wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 > >--- Comment #26 from Martin Jambor <jamborm at gcc dot gnu.org> --- >(In reply to Josh Poimboeuf from comment #24) >> >> Yes, I'm looking for a general way to either prevent or try to detect >> potential other cases of the bug throughout the entire kernel. >> >> Can it only occur with the use of __builtin_constant_p(exp) by an >inline >> function (where exp is a constant)? > >Yes and no. Yes, the problematic inlining analysis predicate >condition type IS_NOT_CONSTANT is only created for conditions >containing a call to __builtin_constant_p. But no, a function does >not have to be explicitly marked inline to be an inline candidate. > >This bug can occur when an inlineable function containing a call to >__builtin_constant_p, which checks a parameter or a value it >references and a (possibly indirect) caller of the function actually >passes a constant, but stores it using a type of a different size. > >In your testcase, the array initialization is a series of byte stores >but the "load" in __swab64p is 64-bit. Note that gcc cannot detect >that the parameter in your testcase was actually a compile-time >constant. IPA level does by mistake and removes the slow path which >is later selected for real (this can be improved if deemed worthwhile >but IPA analysis still needs to check the size to be correct). I was arguing that if IPA proves a condition to true/false then it should adjust it that way in modification phase. This would have prevented the bug as well (eventually using the 'wrong' path). At least it would have avoided hitting a unreachable path at runtime which can be very tricky to debug.
