libera/#clasp - IRC Chatlog

11:56:40 yitzi Looks like LLVM22 has issues with tagged pointers and memory moving? I get a seg fault on the initial attempted resize of characterinfo in lisp startup. https://p.blueridgedebate.com/?1349c0d17630f038#41mXJB3Bk3TnmKjazwcU7jkKMvRd4NgACQsiPkZuiXJQ

12:59:41 bike is this->_Contents null or something? if you're getting the segfault right there it's probably someting like that

13:00:15 yitzi Its not null.

13:00:51 yitzi Its getting resized I guess. The logic there is bizarre.

13:01:13 yitzi Arch just dropped llvm19, so yay!

13:05:58 yitzi I rewrote that routine and now I got this https://p.blueridgedebate.com/?9647027eaa2afa13#DWs29UHBGCfUbTvvsvVsU2jDRctDDgacsZ1ztRFezNtN

13:06:21 yitzi How is a hashtable pointer 0xffffffffffffffff?

13:09:54 bike garbage is getting passed to setf_gethash, i guess?

13:10:44 bike looks like that table is just made pretty normally with createEqual

13:11:24 yitzi llvm20, 21, 22 have all been like this. I keep looking into the release notes looking for some change in memory handling that has caused the pointers to be garbage. I can't find it.

13:13:03 bike the fact this is in the C++ rather than anything we're generating is concerning. maybe our C++ is ill formed and clang just hasn't noticed before.

13:14:36 yitzi Well, I don't understand some the gc stuff enough, but sometimes I get the sneaky feeling that we are doing stuff like copying twice, etc.

13:15:26 bike copying twice?

13:15:34 bike but yeah, could definitely be something rotten in there

13:15:49 bike this one looks relatively straightforward, i could try going in with udb and seeing where the bad pointer comes from

13:17:34 yitzi If you have time.

13:19:06 yitzi The current llvm22 branch will break at the vector segfault. Do you want that or the hashtable?

13:19:46 yitzi I rewrote the vector stuff, but I'm not sure I did it right. So maybe start with the current branch.

13:20:20 bike of course llvm22 isn't in debian bookworm

13:21:36 yitzi of course

13:22:01 yitzi We should update that to ubuntu. Debian sucks, imho.

13:22:38 bike it's so slooooow

13:22:41 bike i'll just build llvm myself

13:25:25 bike i'll probably need assertions on for when we get to actually generated code, anyway

14:08:26 bike " inlined from ‘virtual void clang::interp::InterpFrame::describe(llvm::raw_ostream&) const’ at /home/bike/src/llvm-project/clang/lib/AST/ByteCode/InterpFrame.cpp:187:5: /home/bike/src/llvm-project/llvm/include/llvm/ADT/APInt.h:192:18: warning: ‘void operator delete [](void*)’ called on a pointer to an unallocated object ‘1’ [-Wfree-nonheap-object]" llvm build has the weirdest warnings

14:12:01 yitzi As bad you think they are now, with more time, they'll make them worse.

14:12:11 bike i know... i know :(

14:19:14 bike "/usr/include/c++/12/bits/char_traits.h:431:56: warning: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ accessing 9223372036854775810 or more bytes at offsets -4611686018427387902 and [-4611686018427387903, 4611686018427387904] may overlap up to 9223372036854775813 bytes at offset -3 [-Wrestrict]"

16:52:35 bike if i specify :llvm-config and it's a string, it gets passed to format and i get an error. if i pass a pathname it apparently gets ignored and i don't get a warning or anything (i just have to check what llvm-config it says it's using)

17:00:10 bike okay, it's because i screwed up the syntax, and i guess if koga fails to read config.sexp it's silently ignored

17:07:12 bike it also doesn't like me using ~ in the path, but i don't know that much can be done about that

17:10:05 bike if i built llvm-config, that llvm-config returns an incorrect --includedir. what

17:10:34 bike it uses the source include, which doesn't include the headers the build makes.