r225244 - Sema: analyze I,J,K,M,N,O constraints

Chandler Carruth chandlerc at google.com
Thu Jan 15 11:31:19 PST 2015

On Thu, Jan 15, 2015 at 11:06 AM, Joerg Sonnenberger <
joerg at britannica.bec.de> 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 <
> > joerg at britannica.bec.de> 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

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150115/1924f69d/attachment.html>

More information about the cfe-commits mailing list