[cfe-commits] patch: add cc1 flag to reverse order of evaluation

[Chandler Carruth]

On Mon, Jan 14, 2013 at 10:07 PM, John McCall <rjmccall at apple.com> wrote:

> On Jan 14, 2013, at 2:56 PM, Nick Lewycky <nlewycky at google.com> wrote:
>
> On 14 January 2013 14:52, Nick Lewycky <nlewycky at google.com> wrote:
>
>> 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.
>>
>
> This is an interesting idea, but I'm pretty worried about it.  I understand
> that this isn't your intent, but in effect you *are* talking about
> implementing a knob that can be tweaked by users (even if it's an internal
> option that we don't document and never claim to support) in order to force
> a particular evaluation order on the compiler.  Especially when you're
> talking about extending it to (accidentally, no doubt!) exactly match GCC's
> argument evaluation.
>
> Basically, it sounds an awful lot like something that some understaffed
> porting effort or over-conservative platform maintainer will eventually
> make us regret ever implementing.
>
> Is there some way you can achieve your goal that doesn't leave us
> vulnerable to that?
>

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:

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.

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.

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.

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