<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jun 1, 2012, at 11:28 AM, Douglas Gregor wrote:</div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On May 31, 2012, at 7:51 PM, Lang Hames <<a href="mailto:lhames@gmail.com">lhames@gmail.com</a>> wrote:</div><blockquote type="cite"><div>Yep - I'm not sure what to do about that. At the moment all we have in the way of defaults is the language options DefaultFPContract value. Perhaps it's reasonable to have a per-target DefaultFPContract value that can override the language default. When it comes to explicitly referencing the pragma I'm not sure what the best way to handle that is - As I understand it we won't know how many functions it applies to (and thus whether it's a good candidate as a global default) until we've already parsed them.<br></div></blockquote><div><br></div><div>I think it's completely reasonable to have the target provide the default, and only add the FPContract attribute to the AST if it is either (a) specified directly by the user, or (b) under control of a #pragma that provides a value that is not the default for that target. The accessor for "get the effective FPContract value" will then check for the attribute and, if not present, return the target's default. </div><div><br></div><div>I think this gives us what we want---per-target control, low memory usage in the common case, and a clean way to fit it into the AST.</div></div></div></blockquote><br></div><div>To keep the list informed:  I'd missed that this pragma was a C feature that we hadn't been supporting.  Given that, we really should design our AST to support the actual language feature, which includes lexically scoping the pragma.  We should also support applying these semantics to expressions at global scope; that's not possible in C (because floating-point expressions can't be constant expressions), but it is in C++ (because C++11 constant expressions are much broader than C's and, more importantly, because C++ permits non-constant initializers).  Both of these strongly suggest remembering this as a bit on UnaryOperator and BinaryOperator, to be set at parse-time and preserved through all transformations.</div><div><br></div><div>John.</div></body></html>