#159: "%d" with large integer argument gives conversion error
---------------------------------+------------------------------------------
Reporter: ja...@… | Owner: lsansone...@…
Type: defect | Status: new
Priority: major | Milestone:
Component: MacRuby | Keywords:
---------------------------------+------------------------------------------
Comment(by e...@…):
Further testing of my changes showed there was a random crasher, so I've
been trying to track it down. Turns out to be a garbage collector problem
that I fixed with just retaining the floating point object. But the code
that was being generated was causing the optimization code in
RoxorCompiler::compile_optimized_dispatch_call to not work, so I made some
additional changes there, that caused a bug in llvm to surface (bug #5026,
which was fixed in llvm-83656). I tried TOT LLVM, and verified that the
bug went away, but other things weren't working, so I went back and
changed the code yet again. I finally had a version that didn't tickle
bug #5026, didn't cause a crash, and allowed the optimization code to
work.
The code (or at least the IR) being generated, no longer uses the %a
representation to store floating point, but uses native LLVM floating
point values. I've added a compile time option to generate more
descriptive IR, with variables previous just showing as %12, now appear as
%"[sel:inspect]" or %"[float:1.19999999999p0]". This helped be track down
another crasher that was due to the same
RoxorCompiler::compile_optimized_dispatch_call routine generating code
that allowed the divisor to be zero and cause an (uncaught) arithmetic
exception. So I added code to check the divisor being zero, and call a
ruby exception.
While running the spec tests many times, I saw some other problems with
floating point handling, and fixed them. I also got an error due to ruby
previously using an old, internal version of strtod that doesn't recognize
"infinity" or "nan" and convert them to the corresponding floating point
value. Since I changed macruby to use libSystem's strtod, it does know
how to do the conversion, but one of the spec test specifically tests that
"nan".to_f produces 0.0 instead of a real NaN. So I added a strict option
to macruby (as well as an environment variable) that enforces more
strictness, so "nan".to_f produces 0.0, and that %a in sprintf is no
longer recognized.
Then I noticed that even before my changes, the
RoxorCompiler::compile_optimized_dispatch_call optimizations don't work
under the AOT compiler, because it is storing literal values in LLVM
GlobalVariables, and the code in RoxorCompiler::unbox_ruby_constant
doesn't know how to deal with it. Since my changes to create more
descriptive IR also uses GlobalVariables, I thought I could come up with a
fix for both. I added code to detect the LoadInst, then the
GlobalVariable that it referred to, then the actual value of the
GlobalVariable. That works for JIT, but the AOT compiler doesn't store
the real value in the GlobalVariable at this time, but later adds code to
the top of the compiled code to load values into the GlobalVariables. So
I add another std::map variable to RoxorCompiler that could map
GlobalVariables to the real values (either for JIT or AOT) and now the
optimization in RoxorCompiler::compile_optimized_dispatch_call works for
both.
I got sidetracked, and it is late, so it will have to wait until tomorrow
for me to check in my changes to the branch and post a diff file as
well....
--
Ticket URL: <http://www.macruby.org/trac/ticket/159#comment:7>
MacRuby <http://macruby.org/>
_______________________________________________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
