[PATCH] Add test for LinkModules warning on triple, modified by r203009. Datalayout is already tested.
jfb at chromium.org
Mon Mar 10 20:38:39 PDT 2014
I suggest Rafael and Juergen figure this one out, and once they do I'm glad
to make the change.
Rafael originally wrote the test with the "file empty" check, then removed
that check, and Juergen reverted the removal with the following message:
This reverts commit r202283, because when we use GuardMalloc the test will
fail due to additional output to std err.
On Mon, Mar 10, 2014 at 8:25 PM, Pete Cooper <peter_cooper at apple.com> wrote:
> Hi JF
> Would it be possible to make the change to check for ‘WARNING’?
> The reason I ask is that we have a GuardMalloc buildbot which is writing
> the following to stderr and so is failing to have an empty FileCheck line:
> GuardMalloc[bash-30020]: Allocations will be placed on 16 byte boundaries.
> GuardMalloc[bash-30020]: - Some buffer overruns may not be noticed.
> GuardMalloc[bash-30020]: - Applications using vector instructions (e.g.,
> SSE) should work.
> GuardMalloc[bash-30020]: version 25
> On Mar 10, 2014, at 6:27 PM, JF Bastien <jfb at chromium.org> wrote:
> I meant the following (what I suggested earlier) will not work because
>> t.a.err is empty.
>> > ; RUN: cat %t.a.err | FileCheck --check-prefix=WARN-A %s
>> > WARN-A-NOT: WARNING: Linking two modules of different target triples:
>> Your checkin is fine, but I think it is possible to simplify it with
>> ; RUN: llvm-link %s %S/Inputs/targettriple-a.ll -S 2>&1 | FileCheck %s
>> ; RUN: llvm-link %s %S/Inputs/targettriple-b.ll -S 2>&1 | FileCheck %s
>> target triple = "e"
>> ; WARN-A-NOT: WARNING: Linking two modules of different target triples:
>> ; WARN-A: target triple = "e"
>> ; WARN-B: WARNING: Linking two modules of different target triples:
>> ; WARN-B: target triple = "e"
> That could work too, but I think the original intent was to make sure that
> nothing gets emitted. I could change the test to:
> ; WARN-A-NOT: WARNING:
> To check that no warning got emitted, but at that point the existing check
> is strictly more general since it checks that nothing (including warnings)
> got emitted.
> TL;DR: adding WARN-A-NOT is defensive since it's included in the other
> check, but removing the other check means we're testing for strictly less.
> I'm not sure that's a good idea.
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits