On Thu, Jan 15, 2015 at 06:07:33PM +0000, Eric Christopher wrote: > On Thu Jan 15 2015 at 4:23:00 AM Joerg Sonnenberger <[email protected]> > wrote: > > > On Wed, Jan 14, 2015 at 02:44:44PM -0800, Reid Kleckner wrote: > > > This change simply allows us to reject bad code earlier in a more user > > > friendly way. > > > > How is it bad code or userfriendly? Have you looked at the inb example I > > posted? Forcing macros is stupid and with ToT it is outright impossible > > to produce optimal code. Yes, it depends on the optimizer to do a basic > > job, so what? > > > > > The problem is that if the argument to the function isn't actually constant > then the front end won't be able to diagnose it and at best it'll get > diagnosed in the back end or by the assembler.
The cases I tried are all diagnosed by the common codegen logic.. > The idea is that the front > end handles these sorts of diagnostics and doesn't rely on optimization to > happen to get them. We do have some support for back end diagnostics using > front end locations - but I'm not sure we should use that here. Slippery > slope and all. FWIW this fired a few times in our internal code base and we > just fixed it up. 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. This case is especially annoying as it is not even a default-on warning. Joerg _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
