Example crashes on Mac OS X

I am running

Mac OS 10.7.3
Python 2.7.1 (r271:86832, Jun 16 2011, 16:59:05) [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
numpy '2.0.0.dev-26aa3cf'
scipy '0.10.0.dev'

I installed LLVM, llvm-py and numba as explained in the readme. On running the example script, I get this error:

Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) == Args[i]->getType()) && "Calling a function with a bad signature!"), function init, file Instructions.cpp, line 274.
Abort trap: 6

@bayerj

I'm getting the same error on examples/numexpr_compare.py but examples/example.py works. @bayerj do you get this error for examples/example.py

This is my output for example.py, seems valid:

$ py example.py 
; ModuleID = 'sinc_mod'

define double @sinc(double %x) {
Entry:
  %0 = fcmp oeq double %x, 0.000000e+00
  br i1 %0, label %CONT_9, label %IF_FALSE_9

CONT_9:                                           ; preds = %Entry
  ret double 1.000000e+00

IF_FALSE_9:                                       ; preds = %Entry
  %1 = fmul double %x, 0x400921FB54442D18
  %2 = call double @llvm.sin.f64(double %1)
  %3 = fmul double 0x400921FB54442D18, %x
  %4 = fdiv double %2, %3
  ret double %4

RETURN_37:                                        ; No predecessors!
  ret double 0.000000e+00
}

declare double @llvm.sin.f64(double) nounwind readonly

0.059888 1.000000 ** 
; ModuleID = 'sinc_mod'

define double @sinc(double %x) {
Entry:
  %0 = fcmp oeq double %x, 0.000000e+00
  br i1 %0, label %CONT_9, label %IF_FALSE_9

CONT_9:                                           ; preds = %Entry
  ret double 1.000000e+00

IF_FALSE_9:                                       ; preds = %Entry
  %1 = fmul double %x, 0x400921FB54442D18
  %2 = call double @llvm.sin.f64(double %1)
  %3 = fmul double 0x400921FB54442D18, %x
  %4 = fdiv double %2, %3
  ret double %4

RETURN_37:                                        ; No predecessors!
  ret double 0.000000e+00
}

declare double @llvm.sin.f64(double) nounwind readonly

0.059888 1.000000 ** 
[  3.89817183e-17   3.96971926e-02   6.64556414e-02   6.80812328e-02
   4.15063827e-02  -5.12469250e-03  -5.46515558e-02  -8.68921740e-02
  -8.64379535e-02  -4.93794333e-02   1.37553357e-02   8.03754744e-02
   1.23178051e-01   1.20247416e-01   6.44510924e-02  -3.13845935e-02
  -1.35838264e-01  -2.07001488e-01  -2.05197221e-01  -1.06420158e-01
   8.79177183e-02   3.48410566e-01   6.23566834e-01   8.52825194e-01
   9.82960198e-01   9.82960198e-01   8.52825194e-01   6.23566834e-01
   3.48410566e-01   8.79177183e-02  -1.06420158e-01  -2.05197221e-01
  -2.07001488e-01  -1.35838264e-01  -3.13845935e-02   6.44510924e-02
   1.20247416e-01   1.23178051e-01   8.03754744e-02   1.37553357e-02
  -4.93794333e-02  -8.64379535e-02  -8.68921740e-02  -5.46515558e-02
  -5.12469250e-03   4.15063827e-02   6.80812328e-02   6.64556414e-02
   3.96971926e-02   3.89817183e-17]

This is most likely an issue with LLVM and llvm-py. I saw this exact problem using LLVM version 3.2svn (from the head of the development repository), and it was caused by the intrinsic codes in LLVM mismatching with those in llvm-py's _intrinsic_ids.py. Fixed by regenerating these codes in llvm-py.

You can verify this for yourself by doing a comparison of the output of ".../llvm-py/tools/intrgen.py llvm-config --includedir/llvm/Intrisics.gen" with the codes in ".../llvm-py/llvm/_intrinsic_ids.py". Note that you might have multiple installations of LLVM, so check the output of llvm-config --version against the LLVM version you built.

(Sorry about the crappy misuse of the markdown, hopefully this is parse-able.)

Merge pull request #442 from pitrou/devel

Merge pull request #2 from stuartarchibald/pr_4472

Merge pull request #2 from numba/master

Fix GUFunc schedule computation for more complex broadcasting

Applying review comments numba#2

Merge pull request numba#2 from IntelPython/mlir-lowerer-plier-rebased

Merge pull request #2 from numba/master

Pass null pointer args through as is

fix sigabrt in parfors tests

@Stencil

Fix @Stencil serial-path crash on kernel reuse for non-constant modes

Navigation Menu

Repository navigation

Example crashes on Mac OS X #2

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Example crashes on Mac OS X #2

Description

Activity

aterrel commented on Mar 13, 2012

bayerj commented on Mar 13, 2012

jriehl commented on May 8, 2012

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions