On Thu, Jan 15, 2015 at 11:06 AM, Joerg Sonnenberger < [email protected]> wrote:
> On Thu, Jan 15, 2015 at 10:41:51AM -0800, Chandler Carruth wrote: > > On Thu, Jan 15, 2015 at 10:29 AM, Joerg Sonnenberger < > > [email protected]> wrote: > > > > > See the inb example. All fixes are pessimations for the code. People > > > complained enough about the (in)ability of __builtin_constant_p to get > > > it delayed to the backend, this is IMO just the same. > > > > > > > I agree it is the same, however I have heard extremely little complaining > > about __builtin_constant_p. I've also not heard any complaints other than > > yours about this change -- most of the complaints I've heard have been > > about the terribly brittle code it uncovered and is now getting fixed. > > Given that I am often the first person to see breakage in random > software, I'm not too surprised. I'm not sure this is true. We had already hit and fixed the pixman issue locally when you reported it. However, it doesn't really matter who hits it first... > So the real question would be -- why is > this not just a warning? I don't think anyone (including me) would > object to that, but it would make it possible to still use the feature > when necessary / useful. Because as a fundamental matter of design, Clang rejects inputs which it cannot validate will succeed in the code generator. This is not new, and an inline assembly constraint is not a compelling reason (to me) to undo this design principle.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
