[cfe-commits] r64416 - /cfe/trunk/tools/ccc/ccclib/Tools.py

[Daniel Dunbar]

On Fri, Feb 13, 2009 at 10:18 AM, Chris Lattner <clattner at apple.com> wrote:
>
> On Feb 13, 2009, at 9:50 AM, Daniel Dunbar wrote:
>
>> On Fri, Feb 13, 2009 at 8:49 AM, Douglas Gregor <dgregor at apple.com> wrote:
>>>
>>> On Feb 12, 2009, at 11:37 PM, Daniel Dunbar wrote:
>>>
>>>> My intent was that clang's own tests would always use the clang
>>>> compiler binary, not the driver. The idea is that the driver is the
>>>> end-user tool, and as such should go as fast as possible. On the other
>>>> hand, for development and testing we get the alloc/free behavior so we
>>>> shake out bugs like you mentioned.
>>>
>>> Sure, but the real testing---the testing that we care about most---occurs
>>> when we use the driver. Say, when I take the clang that's in my path
>>> (always
>>> a debug version) and try to build some big application with it. Usually,
>>> ownership bugs are going to occur in larger translation units, which will
>>> occur within applications but not necessarily within our test-suite.
>>
>> Understood. I don't see a particularly better alternative; tying to
>> NDEBUG strikes me as bad (although I can be strong armed I suppose).
>
> I don't understand the objection to the #ifndef.  The #ifndef doesn't *hard
> code* the value to a specific state, it just changes the default.  You can
> still use -disable-free=1 or -disable-free=0 to get either state in either
> build.

My objection is that I frequently build Debug/Release/Release-Asserts
builds out of the same tree (this is why the gcc equivalent is not the
same as NDEBUG Mike). It is confusing to have otherwise similar
binaries change behavior.

If we were to tie to NDEBUG, I would at least argue that we should do
it in the driver so that the output of -### and -v always shows
exactly how clang is being run.

 - Daniel