No applicable method for llvm-integer-type-width
OD 2021.1pre, x86_64-linux
cd $OD/sources && dylan-compiler -build apple-dylan-test-suite-app
...
/home/cgay/dylan/workspaces/od/opendylan/sources/dylan/apple-dylan-test-suite/test-intro-mop.dylan:39.3-42.25: Warning - The binding set-limit is defined but not referenced or exported.
------------------------------
39 class slot limit :: <integer>,
40 init-function: set-initial-limit,
41 setter: set-limit,
42 init-keyword: limit:;
------------------------
[=================================== ] Generating code for library apple...computation t12 := [PRIMOP raw-as-byte-character(^'c')]: Error:
No applicable method, applying {generic function llvm-integer-type-width (<object>) => (#rest)} to
#[{<llvm-pointer-type> #x00000000014F8B00 i8*}].
emit Kanonymous_of_PParef_1F207I: Error:
No applicable method, applying {generic function llvm-integer-type-width (<object>) => (#rest)} to
#[{<llvm-pointer-type> #x00000000014F8B00 i8*}].
computation t12 := [PRIMOP raw-as-byte-character(^'1')]: Error:
No applicable method, applying {generic function llvm-integer-type-width (<object>) => (#rest)} to
#[{<llvm-pointer-type> #x00000000014F8B00 i8*}].
emit Kanonymous_of_PPelement1_6F344I: Error:
No applicable method, applying {generic function llvm-integer-type-width (<object>) => (#rest)} to
#[{<llvm-pointer-type> #x00000000014F8B00 i8*}].
computation t16 := [PRIMOP raw-as-byte-character(^'b')]: Error:
No applicable method, applying {generic function llvm-integer-type-width (<object>) => (#rest)} to
#[{<llvm-pointer-type> #x00000000014F8B00 i8*}].
emit Kanonymous_of_PPelement_1F565I: Error:
No applicable method, applying {generic function llvm-integer-type-width (<object>) => (#rest)} to
#[{<llvm-pointer-type> #x00000000014F8B00 i8*}].
[==================================== ] Generating code for library apple...computation t22 := [PRIMOP machine-word-shift-left-signal-overflow(^'c', ^%2)]: Error:
Type {<llvm-pointer-type> #x00000000014F8B00 i8*} does not match
{<llvm-integer-type> #x0000000002E5E820 i64}
emit Kanonymous_of_PPthird_6F648I: Error:
Type {<llvm-pointer-type> #x00000000014F8B00 i8*} does not match
{<llvm-integer-type> #x0000000002E5E820 i64}
computation t22 := [PRIMOP machine-word-shift-left-signal-overflow(^'b', ^%2)]: Error:
Type {<llvm-pointer-type> #x00000000014F8B00 i8*} does not match
{<llvm-integer-type> #x0000000002E5E820 i64}
emit Kanonymous_of_PPsecond_6F732I: Error:
Type {<llvm-pointer-type> #x00000000014F8B00 i8*} does not match
{<llvm-integer-type> #x0000000002E5E820 i64}
computation t22 := [PRIMOP machine-word-shift-left-signal-overflow(^'a', ^%2)]: Error:
Type {<llvm-pointer-type> #x00000000014F8B00 i8*} does not match
{<llvm-integer-type> #x0000000002E5E820 i64}
emit Kanonymous_of_PPfirst_6F816I: Error:
Type {<llvm-pointer-type> #x00000000014F8B00 i8*} does not match
{<llvm-integer-type> #x0000000002E5E820 i64}
Build of 'apple-dylan-test-suite-app' completed
[OD 2023.1 on x86_64-linux]
Running into (what looks to me like) this again today with the protocol-buffers library.
cd $PB && dylan build protocol-buffers-test-suite
Open Dylan 2023.1
Opened project protocol-buffers-test-suite (/home/cgay/dylan/workspaces/pb/protocol-buffers/sources/test-suite.lid)
[===================================== ] Generating code for library proto...computation {{ byte }} := make-cell(t98): Error:
Type {<llvm-integer-type> #x00007FDF08B71840 i8} does not match
{<llvm-pointer-type> #x00007FDF08B73C00 i8*}
computation if (t86) ... else ... end: Error:
Type {<llvm-integer-type> #x00007FDF08B71840 i8} does not match
{<llvm-pointer-type> #x00007FDF08B73C00 i8*}
emit Kdecode_varintYprotocol_buffers_implVprotocol_buffersI: Error:
Type {<llvm-integer-type> #x00007FDF08B71840 i8} does not match
{<llvm-pointer-type> #x00007FDF08B73C00 i8*}
computation return *t0(1): Error:
Type {<llvm-integer-type> #x00007FDF08B17260 i64} does not match
{<llvm-pointer-type> #x00007FDF08B73C00 i8*}
emit Kinteger_as_rawF23I: Error:
Type {<llvm-integer-type> #x00007FDF08B17260 i64} does not match
{<llvm-pointer-type> #x00007FDF08B73C00 i8*}
Build of 'protocol-buffers-test-suite' completed
When I run the resulting binary I get Illegal instruction.
I'm working on protobuf varint decoding, which necessarily uses generic arithmetic and bit twiddling functions so perhaps the bug is related to that.
The code is here: https://github.com/cgay/protocol-buffers/commit/50744b0fce201ed74bcb77a9c3dc271e4ac1d8fa
The problem did not occur before that last commit, so something in that commit tickled the problem. Unfortunately it's not a very small diff.) It might be a good idea to clone my repo somewhere else in case I end up squashing some of my early work in this repo.
(lldb) run
Process 567215 launched: '/home/cgay/dylan/workspaces/pb/_build/bin/protocol-buffers-test-suite' (x86_64)
Running suite protocol-buffers-test-suite:
Running benchmark benchmark-encode-varint-max-uint64: PASSED in 0.206712s and 4KiB
Running test test-encode/decode-varint:Process 567215 stopped
* thread #1, name = 'Main thread', stop reason = signal SIGILL: illegal instruction operand
frame #0: 0x00007ffff77d73d0 libprotocol-buffers.so`decode-varint at wire-format.dylan:138:5
135 if (high-bit-set?)
136 // Too large for <int>; switch to ga/<integer> for 9th and 10th bytes.
137 let varint :: ga/<integer> = varint;
-> 138 let byte :: <byte> = buf[index];
^
139 high-bit-set? := logbit?(7, byte);
140 varint := ga/logior(varint, ga/ash(logand(byte, 127), shift));
141 format-out("decode-varint: byte: %02X, high-bit?: %=, varint: %d, index: %d, shift: %d\n",
Maybe the bitcode is also useful...here's the whole _build/build/protocol-buffers directory: protocol-buffers-build-dir.tgz
See these brief notes on what's going on here.
Even though I'm logged into Matrix, following the link to it is pretty painful, so I'm copying the comments here:
It seems that https://github.com/dylan-lang/opendylan/issues/1377 happens when you try to call a function such as integer-as-raw (or raw-as-integer) with types that aren't known well enough to inline the call Even though these are marked inline-only, the compiler tries to generate a local outlined version, but since the arguments or the return values are raw values, the return value computation doesn't match the function signature of an IEP The right thing would be to ensure that it never tries to outline an inline-only method