<div dir="ltr"><div class="gmail_default" style>On Mon, Jan 14, 2013 at 10:07 PM, John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com" target="_blank" class="cremed">rjmccall@apple.com</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div class="im"><div><div>On Jan 14, 2013, at 2:56 PM, Nick Lewycky <<a href="mailto:nlewycky@google.com" target="_blank" class="cremed">nlewycky@google.com</a>> wrote:</div>
<blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 14 January 2013 14:52, Nick Lewycky <span dir="ltr"><<a href="mailto:nlewycky@google.com" target="_blank" class="cremed">nlewycky@google.com</a>></span> wrote:<br>



<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>This patch adds the -reverse-order flag which reverses the order of evaluation of simple (non-complex non-aggregate) assignment expressions (eg., "a() = b();" where a() returns int& and b() returns int). The idea is to provide a debugging tool that we can use to identify bugs in user code caused by order of evaluation problems. As a starting point, I've only reversed one such evaluation (one that causes me much grief), but I'd also like to change the order of function parameter evaluation. Others may be added on an as-needed basis.</div>




</div></blockquote></div></div></div></blockquote><br></div></div><div>This is an interesting idea, but I'm pretty worried about it.  I understand</div><div>that this isn't your intent, but in effect you *are* talking about</div>
<div>implementing a knob that can be tweaked by users (even if it's an internal</div><div>option that we don't document and never claim to support) in order to force</div><div>a particular evaluation order on the compiler.  Especially when you're</div>
<div>talking about extending it to (accidentally, no doubt!) exactly match GCC's</div><div>argument evaluation.</div><div><br></div><div>Basically, it sounds an awful lot like something that some understaffed</div><div>
porting effort or over-conservative platform maintainer will eventually</div><div>make us regret ever implementing.</div><div><br></div><div>Is there some way you can achieve your goal that doesn't leave us</div><div>
vulnerable to that?</div></div></blockquote><div><br></div><div style>Sorry this didn't make it to the Nick's email, but here is a brief version of the discussion between myself, Richard, and Nick that led to this patch:</div>
<div style><br></div><div style>First, we have two goals. One, we would like to be able to test whether programs which execute "correctly" (in the eyes of their author) when compiled with GCC but execute "incorrectly" when compiled with Clang do so exclusively because of different argument order of evaluation. As a secondary goal, largely related to the UBSan effort, we would like to make it significantly harder to write code which bakes in such invalid assumptions about the behavior of their programs.</div>
<div style><br></div><div style>The primary goal might be addressed by debugging a program and finding the specific case of baked in assumptions which is invalid. However, this can be extremely hard. There is often very little locality between the failure and the programming error. And without finding and fixing a particular broken set of arguments to a function call, we cannot gain confidence that Clang+LLVM is otherwise correct, and there is simply a programmer error here. It is no accident that Nick wants to replicate the order of evaluation that GCC happens to use; being able to do so makes it very easy to test whether the programmer error is specifically this. We would happily accept *any* other means of conclusively identifying these types of bugs, but we do need some way to identify them. Having such errors mechanically identified dramatically lessens the burden of porting code to work with Clang.</div>
<div style><br></div><div style>The secondary goal we hoped to achieve by adding a third option which would evaluate arguments in a permutation of the possible orders selected by a hash of the function call's identifier, potentially salted by the name of the source file in which it occurs, etc. This would yield a stable and yet impossible to predict order that should prevent accidental reliance on the order in most cases.</div>
<div style><br></div><div style>I don't think we're ever going to use this widely, we just want some way to be able to test programs' behavior. Maybe we could implement all of these only when optimizations are disabled so that there is no switch to control the optimized binary's behavior? Some other way to layer defense around this while still gaining the ability to debug and test different behaviors?</div>
</div></div></div>