[MacRuby-devel] [MacRuby] #159: "%d" with large integer argument gives conversion error

[MacRuby]

#159: "%d" with large integer argument gives conversion error
---------------------------------+------------------------------------------
 Reporter:  jamis@…              |       Owner:  lsansonetti@…        
     Type:  defect               |      Status:  new                  
 Priority:  major                |   Milestone:                       
Component:  MacRuby              |    Keywords:                       
---------------------------------+------------------------------------------

Comment(by emoy@…):

 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/>