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

Nick Lewycky nlewycky at google.com
Fri Feb 22 17:14:01 PST 2013


Resurrecting this thread. This is a feature I'd still like to have.

There's been some additional ideas off-list since proposing this patch:
disabling it when optimizations are enabled, requiring the user to specify
a line number to apply to reversal before (so that we can bisect it),
changing the flag name.

I'm reposting the same functionality as the previous patch, but rebased to
svn head. Are there any changes folks need to see before it lands in clang?
Do I need to update documentation (I was hoping not, as part of keeping
this functionality strictly internal to the compiler)?

Nick



On 14 January 2013 23:04, Chandler Carruth <chandlerc at google.com> wrote:

> 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/20130222/95c7bb2a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clang-reverse-order-2.patch
Type: application/octet-stream
Size: 3136 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130222/95c7bb2a/attachment.obj>


More information about the cfe-commits mailing list