[LLVMdev] piping into lli broken on darwin

[Eli Friedman]

On Wed, Oct 31, 2012 at 5:26 PM, Jack Howarth <howarth at bromo.med.uc.edu> wrote:
> On Wed, Oct 31, 2012 at 05:17:28PM -0700, Eli Friedman wrote:
>> On Wed, Oct 31, 2012 at 5:01 PM, Jack Howarth <howarth at bromo.med.uc.edu> wrote:
>> > On Wed, Oct 31, 2012 at 04:43:42PM -0700, Eli Friedman wrote:
>> >> On Wed, Oct 31, 2012 at 4:33 PM, Jack Howarth <howarth at bromo.med.uc.edu> wrote:
>> >> > On Wed, Oct 31, 2012 at 03:53:50PM -0700, Eli Friedman wrote:
>> >> >> On Wed, Oct 31, 2012 at 8:43 AM, Jack Howarth <howarth at bromo.med.uc.edu> wrote:
>> >> >> >   While testing llvm/polly svn on x86_64-apple-darwin10/11/12, I noticed that three darwin
>> >> >> > specific polly-test regressions exist. At least part of these failures appear to be due
>> >> >> > to lli on darwin not accepting piped input such that the test...
>> >> >> >
>> >> >> > opt -load /sw/src/fink.build/llvm32-3.2-0/llvm-3.2/build/lib/LLVMPolly.so
>> >> >> > -basicaa -polly-prepare -polly-region-simplify -O3
>> >> >> > /sw/src/fink.build/llvm32-3.2-0/llvm-3.2/tools/polly/test/CodeGen/single_do_loop_int_max_iterations.ll
>> >> >> > | lli
>> >> >> >
>> >> >> > produces the error...
>> >> >> >
>> >> >> > LLVM ERROR: Could not resolve external global address: stdout
>> >> >>
>> >> >> This error means you're generating a reference to a symbol named
>> >> >> stdout, which does not exist on OS X.  Why do you think this is a bug
>> >> >> in lli?
>> >> >
>> >> > Eli,
>> >> >    What about the output that I see from bugpoint...
>> >> >
>> >> > http://llvm.org/bugs/show_bug.cgi?id=14142#c4
>> >> >
>> >> > which seems to suggest that the actual problem is an alignment issue.
>> >> >
>> >> > ugpoint-test-program.bc.llc.s.gcc.exe -lm -O2
>> >> > bugpoint-test-program.bc:4:Alignment too large: 15. assumed.
>> >> > bugpoint-test-program.bc:5:Unknown pseudo-op: .type
>> >> > bugpoint-test-program.bc:5:Rest of line ignored. 1st junk character valued 115
>> >>
>> >> This is a bugpoint issue; try passing "-gcc=clang" to bugpoint.
>> >>
>> >> -Eli
>> >
>> > Eli,
>> >    I still get...
>> >
>> > % bugpoint --run-custom --exec-command=lli -gcc=clang tempfile
>> > Read input file      : 'tempfile'
>> > *** All input ok
>> > Initializing execution environment: Found command in: /sw/opt/llvm-3.2/bin/lli
>> > Running the code generator to test for a crash:
>> > Generating reference output from raw program: <llc><gcc>
>> > Error running tool:
>> >   /sw/opt/llvm-3.2/bin/clang -x assembler bugpoint-test-program.bc.llc.s -x none -o bugpoint-test-program.bc.llc.s.gcc.exe -lm -O2
>> > bugpoint-test-program.bc.llc.s:5:2: error: unknown directive
>> >         .type   single_do_loop_int_max_iterations, at function
>> >         ^
>> > bugpoint-test-program.bc.llc.s:14:2: error: unknown directive
>> >         .size   single_do_loop_int_max_iterations, .Ltmp0-single_do_loop_int_max_iterations
>> >         ^
>> > which was the other half for the gnutls fix.
>>
>> Can you check if the IR file specifies a target triple which doesn't
>> match the current platform?
>>
>> -Eli
>
> Eli,
>    The polly testsuite only has a single file for CodeGen/single_do_loop_scev_replace.ll which has...
>
> ; RUN: opt %loadPolly %defaultOpts -polly-cloog -analyze %s | FileCheck %s
> ; RUN: opt %loadPolly %defaultOpts %s | lli %EatErrOnX86
> ; RUN: opt %loadPolly %defaultOpts -polly-codegen %s | lli %EatErrOnX86
> ; ModuleID = 'single_do_loop_scev_replace.s'
> target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
> target triple = "x86_64-unknown-linux-gnu"
>
> I assume this was generated from CodeGen/single_do_loop_scev_replace.c but it is unclear exactly
> what command was used. Interestingly almost all of the polly testsuite seems to use .ll files generated
> on the x86_64-unknown-linux-gnu target triple but we only fail 3 tests...
>
>   Expected Passes    : 125
>   Expected Failures  : 29
>   Unsupported Tests  : 2
>   Unexpected Failures: 3
>
> How is this issue handled in the main llvm testsuite?

Ignoring the JIT tests, which are carefully written to be
platform-independent, the regression tests in llvm/test/ generally
don't run anything; our runtime tests mostly consist of C and C++
code.

-Eli