piping into lli broken on darwin

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

I am able to break this test up into sections with...

% 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

tempfile

which produces a file that fails to pipe into lli on darwin...

% cat tempfile | lli
LLVM ERROR: Could not resolve external global address: stdout

but works fine with lli built on x86_64 Fedora 15...

$ cat tempfile | ~/llvm_build/bin/lli
Output 2147483646

The tempfile test file is attached to the original PR I opened for the darwin specific polly testsuite failures...

http://llvm.org/bugs/show_bug.cgi?id=14142

Any idea how to fix this issue? Also should I open a unique PR for this issue or just leave it
as part of PR14142? Thanks in advance.
       Jack

  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

I am able to break this test up into sections with...

% 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
> tempfile

which produces a file that fails to pipe into lli on darwin...

% cat tempfile | lli
LLVM ERROR: Could not resolve external global address: stdout

but works fine with lli built on x86_64 Fedora 15...

$ cat tempfile | ~/llvm_build/bin/lli
Output 2147483646

The tempfile test file is attached to the original PR I opened for the darwin specific polly testsuite failures...

http://llvm.org/bugs/show_bug.cgi?id=14142

Any idea how to fix this issue? Also should I open a unique PR for this issue or just leave it
as part of PR14142? Thanks in advance.
       Jack

  The same error occurs if the tempfile is passed as an argument to lli on darwin but not linux.
Running this command on darwin under bugpoint, I see...

% bugpoint --run-custom --exec-command=lli 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:
  /usr/bin/gcc -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: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 (s).
bugpoint-test-program.bc:14:Unknown pseudo-op: .size
bugpoint-test-program.bc:14:Rest of line ignored. 1st junk character valued 115 (s).
bugpoint-test-program.bc:17:Alignment too large: 15. assumed.
bugpoint-test-program.bc:18:Unknown pseudo-op: .type
bugpoint-test-program.bc:18:Rest of line ignored. 1st junk character valued 109 (m).
bugpoint-test-program.bc:32:junk `@PLT' after expression
bugpoint-test-program.bc:39:Unknown pseudo-op: .size
bugpoint-test-program.bc:39:Rest of line ignored. 1st junk character valued 109 (m).
bugpoint-test-program.bc:41:Unknown pseudo-op: .type
bugpoint-test-program.bc:41:Rest of line ignored. 1st junk character valued 65 (A).
bugpoint-test-program.bc:43:Unknown pseudo-op: .type
bugpoint-test-program.bc:43:Rest of line ignored. 1st junk character valued 46 (.).
bugpoint-test-program.bc:44:unknown section type: @progbits
bugpoint-test-program.bc:44:Rest of line ignored. 1st junk character valued 46 (.).
bugpoint-test-program.bc:46:Unknown pseudo-op: .size
bugpoint-test-program.bc:46:Rest of line ignored. 1st junk character valued 46 (.).
bugpoint-test-program.bc:49:segment-name: ".note.GNU-stack" too long (maximum 16 characters)
bugpoint-test-program.bc:49:Rest of line ignored. 1st junk character valued 64 (@).
*** There is a bug running the "safe" backend. Either debug it (for example with the -run-jit bugpoint option, if JIT is being used as the "safe" backend), or fix the error some other way.
*** Debugging code generator crash!

Checking to see if we can delete global inits:
  - Removing all global inits hides problem!

*** Attempting to reduce the number of global variables in the testcase
Checking for crash with only these global variables: A .str:

*** Attempting to reduce the number of functions in the testcase
Checking for crash with only these functions: single_do_loop_int_max_iterations main:
Checking for crash with only these blocks: entry entry:
Checking for crash with only 13 instructions:

*** Attempting to reduce testcase by deleting instructions: Simplification Level #1
Checking instruction: fence seq_cst
Checking instruction: store i32 2147483646, i32* getelementptr inbounds ([20 x i32]* @A, i64 0, i64 0), align 4
Checking instruction: fence seq_cst
Checking instruction: store i32 0, i32* getelementptr inbounds ([20 x i32]* @A, i64 0, i64 0), align 4
Checking instruction: fence seq_cst
Checking instruction: store i32 2147483646, i32* getelementptr inbounds ([20 x i32]* @A, i64 0, i64 0), align 4
Checking instruction: fence seq_cst
Checking instruction: %tmp = load %struct._IO_FILE** @stdout, align 8
Checking instruction: %tmp1 = load i32* getelementptr inbounds ([20 x i32]* @A, i64 0, i64 0), align 4
Checking instruction: %call = tail call i32 (%struct._IO_FILE*, i8*, ...)* @fprintf(%struct._IO_FILE* %tmp, i8* getelementptr inbounds ([11 x i8]* @.str, i64 0, i64 0), i32 %tmp1) nounwind
Checking instruction: %tmp2 = load i32* getelementptr inbounds ([20 x i32]* @A, i64 0, i64 0), align 4
Checking instruction: %not.cmp = icmp ne i32 %tmp2, 2147483646
Checking instruction: %. = zext i1 %not.cmp to i32

*** Attempting to reduce testcase by deleting instructions: Simplification Level #0
Checking instruction: fence seq_cst
Checking instruction: store i32 2147483646, i32* getelementptr inbounds ([20 x i32]* @A, i64 0, i64 0), align 4
Checking instruction: fence seq_cst
Checking instruction: store i32 0, i32* getelementptr inbounds ([20 x i32]* @A, i64 0, i64 0), align 4
Checking instruction: fence seq_cst
Checking instruction: store i32 2147483646, i32* getelementptr inbounds ([20 x i32]* @A, i64 0, i64 0), align 4
Checking instruction: fence seq_cst
Checking instruction: %tmp = load %struct._IO_FILE** @stdout, align 8
Checking instruction: %tmp1 = load i32* getelementptr inbounds ([20 x i32]* @A, i64 0, i64 0), align 4
Checking instruction: %call = tail call i32 (%struct._IO_FILE*, i8*, ...)* @fprintf(%struct._IO_FILE* %tmp, i8* getelementptr inbounds ([11 x i8]* @.str, i64 0, i64 0), i32 %tmp1) nounwind
Checking instruction: %tmp2 = load i32* getelementptr inbounds ([20 x i32]* @A, i64 0, i64 0), align 4
Checking instruction: %not.cmp = icmp ne i32 %tmp2, 2147483646
Checking instruction: %. = zext i1 %not.cmp to i32

*** Attempting to perform final cleanups:
Emitted bitcode to 'bugpoint-reduced-simplified.bc'

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

> 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 smells like the issues I solved in gnutls...

where .align was being used instead of the more appropriate .balign (since i386/x86_64 darwin doesn't support
.align > 15) as well as the unsupported .type (and perhaps .size) assembly being used on darwin.
         Jack

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,@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.
         Jack

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?
              Jack

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

True. And I believe Polly should go the same road. Let's keep execution test to the LLVM test-suite. Introducing them was OK when we where not able to compile the llvm test-suite. Nowadays, we should just remove them.

Cheers
Tobi