freenode/#clasp - IRC Chatlog
Search
14:40:45
hiro98-
i'm in the process. I am asking to find out if it is an arch problem before I start figuring stuff out.
14:41:05
Bike
we've had a few problems with arch. if you search for "arch" in the logs it should come up.
14:44:24
drmeister
We haven't got an Arch build in our buildbot - but we are expanding our buildbot over the next couple of weeks - I'll bring up the idea of an Arch build.
14:50:52
Bike
drmeister: got the satiation thing working. takes like two seconds to start up and then three to compile (lambda (x y) (+ x y))
14:52:36
Bike
this is also without any kind of stamp caching, so things work at least okay without it
14:54:07
drmeister
Using the 'dev' branch I can go: python3 waf build_cboehm -- so you can use python2 the same way.
14:57:30
Bike
here's a satiated discriminating function i happened to have up https://pastebin.com/wraXUsBR
14:57:48
hiro98-
Shinmera: https://gitlab.com/ita1024/waf/blob/master/waf-light some kind of self extracting archive? (file command says "waf: a /usr/bin/env python script executable (binary data)")
14:57:56
Bike
in the runtime version, the first let is nonexistent, and the outcomes look different.
14:58:47
drmeister
hiro98-: I didn't write it that way - waf is the build system that I hate the least.
15:00:02
Bike
i'm not sure whether bclasp does block and tagbody and empty lets efficiently. i hope so
15:39:28
drmeister
It's got the same look and feel as the crash last week - it's hung up in llvm InstCombiner.
15:41:16
drmeister
Bike: The only function you have moved into fastgf.cc right now is cc_dispatch_miss - correct?
15:44:35
drmeister
No - I don't think bloating is the problem. Only bad code generation would cause a crash like this.
15:45:36
drmeister
I don't understand why having cc_dispatch_miss 'always_inline' in fastgf.cc would lead to bad code generation - but it's looking like that's what is happening.
15:46:19
drmeister
I'm moving cc_dispatch_miss back into link_intrinsics.cc and rebuilding to test my hypothesis.
15:46:20
Bike
why don't you try reverting the commit to see if that fixes it. it's https://github.com/clasp-developers/clasp/commit/061466da2c1746910bcfb775e7813fa6ed858640
15:48:43
drmeister
Is cc_disptach_miss on a code path that returns normally - or does it unwind the stack?
15:50:39
Bike
but then, i'f been getting "bad instruction: 4" when i hit infinite recursion, so maybe everything else is worrying too
15:52:36
drmeister
Well, let's not panic. Everything else appears to be working. I need to get a copy of the module just before it goes to llvm for optimization. Then I might get some clue as to what is going on.
15:58:01
drmeister
Yep - I move that one function out of fixup.cc to link_intrinsics.cc and it builds fine.
15:59:02
drmeister
So add that to the criterion for what goes into fastgf.cc - "Only add functions that don't cause spooky crashes in llvm".
16:00:24
drmeister
Pushing the 'fix' for now - until we figure out what is going on. I don't really care about cc_dispatch_miss - it's on the slow path and there is no downside to putting it in link_intrinsics.cc. But what other functions we might add in the future would cause spooky crashes?!?!?
16:05:03
drmeister
Ok. I'm working to add code for DEBUG_FASTGF that will dump the modules after inlining fastgf bitcode