<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Feb 2, 2015 at 1:50 PM, Tim Northover <span dir="ltr"><<a href="mailto:tnorthover@apple.com" target="_blank">tnorthover@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> I'd be in favor or promoting it to an error. We recently started rejecting this code, for example:<br>
<br>
</span>I'm not sure I would. Deciding on the diagnostics for our own intrinsics is one thing, but this would trigger on well-formed programs according to the standard.<br></blockquote><div><br></div><div>I agree that this should not be an error. The builtin does not require a constant; we shouldn't say it's ill-formed if we happen to be able to evaluate the order parameter and find it's out-of-range.</div><div><br></div><div>I think this sort of thing is completely reasonable (perhaps in the implementation of a C++11-compatible atomics library):</div><div><br></div><div>#define atomic_builtin(kind, order, ...) \</div><div>  ({ switch(order) { \</div><div>    case memory_order_relaxed: kind(__VA_ARGS__, __ATOMIC_RELAXED); break; \</div><div>    [...]</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That's rather a bigger step to take, and we should probably be comparing it to situations with that similarity (the only one I know of is ARM64 complaining more strongly about functions without prototypes).<br>
<div class="HOEnZb"><div class="h5"><br>
Cheers.<br>
<br>
Tim.<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div></div>