[llvm-commits] [llvm] r146688 - in /llvm/trunk: include/llvm/Transforms/Utils/ModuleUtils.h lib/Transforms/Instrumentation/AddressSanitizer.cpp lib/Transforms/Utils/ModuleUtils.cpp

[Kostya Serebryany]

On Thu, Dec 15, 2011 at 4:21 PM, Chandler Carruth <chandlerc at google.com>wrote:

> On Thu, Dec 15, 2011 at 4:14 PM, Kostya Serebryany <kcc at google.com> wrote:
>
>>
>>
>> On Thu, Dec 15, 2011 at 4:11 PM, Chandler Carruth <chandlerc at google.com>wrote:
>>
>>> On Thu, Dec 15, 2011 at 1:59 PM, Kostya Serebryany <kcc at google.com>wrote:
>>>
>>>> [asan] fix a bug (issue 19) where dlclose and the following mmap caused
>>>> a false positive. compiler part.
>>>>
>>>
>>> No test case?
>>>
>>
>> There is a full (compile-link-run)
>> test: projects/compiler-rt/lib/asan/tests/dlclose-test*
>> I do not see any need for a separate compiler-only test, do you?
>>
>
> Not everyone will be able to run those tests, and certainly not on every
> platform. The nice thing about regression testing the actual compiler
> transformations in the LLVM regtest suite is that they are completely
> architecture independent, and isolate the functionality under test. Other
> developers need to be able to run the tests and ensure their changes don't
> break your functionality.
>
> It is expected that nearly all of the logic of a compiler transformation
> at the IR level is tested using FileCheck and the LLVM regtest suite. Only
> final integration testing and testing for strange system interactions
> should be pushed down to external projects' test suites.
>

yea, agree.
asan currently (almost) lacks this kind of testing and we will need to add
more tests (not just this one).

For example, the current asan test suite has a test that invokes objdump
and counts how many specific instructions are present in a given function.
FileCheck-like test should be much simpler.

--kcc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20111215/e6b51372/attachment.html>