[LLVMdev] piping into lli broken on darwin

Jack Howarth howarth at bromo.med.uc.edu
Wed Oct 31 17:26:31 PDT 2012


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



More information about the llvm-dev mailing list