Re: Please build the JIT branch

[Ben Abbott]

On Jul 22, 2012, at 1:41 PM, Max Brister wrote:

> On Sun, Jul 22, 2012 at 11:58 AM, Ben Abbott <address@hidden> wrote:
>> 
>> On Jul 20, 2012, at 10:14 AM, Max Brister wrote:
>> 
>>> On Tue, Jul 17, 2012 at 6:25 AM, Ben Abbott <address@hidden> wrote:
>>>> 
>>>> On Jul 16, 2012, at 4:55 PM, Max Brister wrote:
>>>> 
>>>>> On Fri, Jul 13, 2012 at 6:27 AM, Ben Abbott <address@hidden> wrote:
>>>>>> On Jul 12, 2012, at 11:13 PM, Max Brister wrote:
>>>>>> 
>>>>>>> On Thu, Jul 12, 2012 at 8:18 PM, Ben Abbott <address@hidden> wrote:
>>>>>>>> 
>>>>>>>> On Jul 12, 2012, at 7:52 PM, Ben Abbott wrote:
>>>>>>>> 
>>>>>>>>> On Jul 10, 2012, at 6:00 PM, Max Brister wrote:
>>>>>>>>> 
>>>>>>>>>> JIT is still pretty limited, it will not compile loops with any
>>>>>>>>>> function calls, even builtin functions (except for sin, cos, and 
>>>>>>>>>> exp).
>>>>>>>>>> It also only supports linear matrix indexing. For an example of a
>>>>>>>>>> function which can be compiled, see
>>>>>>>>>> http://jit-octave.blogspot.com/2012/06/realistic-test.html.
>>>>>>>>>> 
>>>>>>>>>> Max Brister
>>>>>>>>> 
>>>>>>>>> Using macports on MacOS 10.7, I did a quick build (without worrying 
>>>>>>>>> about LLVM)
>>>>>>>>> 
>>>>>>>>> With JIT
>>>>>>>>> 
>>>>>>>>>   A = gen_test (1000000);
>>>>>>>>>   K = 500;
>>>>>>>>>   Vectorized: 1.274 sec
>>>>>>>>>   Loopy: 4.875 sec
>>>>>>>>> 
>>>>>>>>> With 3.7.0+
>>>>>>>>> 
>>>>>>>>>   A = gen_test (1000000);
>>>>>>>>>   K = 500;
>>>>>>>>>   Vectorized: 5.944
>>>>>>>>>   Loopy: 16.063
>>>>>>>>> 
>>>>>>>>> I'll try again with LLVM_CONFIG=/opt/local/bin/llvm-config-mp-3.0
>>>>>>>>> 
>>>>>>>>> Ben
>>>>>>> 
>>>>>>> It's odd that there was any change at all between the JIT branch
>>>>>>> (without being able to find llvm) and 3.7.0+. The JIT branch compiled
>>>>>>> without llvm should be mostly the same as 3.7.0+. Almost all of the
>>>>>>> code I have added is inside
>>>>>>> #ifdef LLVM_FOUND
>>>>>>> ....
>>>>>>> #endif // LLVM_FOUND
>>>>>>> 
>>>>>>> Maybe this is a fluke?
>>>>>> 
>>>>>> I didn't check, but I have an automated backup that may have been 
>>>>>> running with 3.7.0
>>>>>> 
>>>>>>>> With LLVM_CONFIG set to the above, I see ...
>>>>>>>> 
>>>>>>>> octave(56971,0x7fff70d62960) malloc: *** error for object 0x106a4c620: 
>>>>>>>> pointer being freed was not allocated
>>>>>>>> *** set a breakpoint in malloc_error_break to debug
>>>>>>>> 
>>>>>>>> Program received signal SIGABRT, Aborted.
>>>>>>>> 0x00007fff850fece2 in __pthread_kill ()
>>>>>>>> (gdb) bt
>>>>>>>> #0  0x00007fff850fece2 in __pthread_kill ()
>>>>>>>> #1  0x00007fff856e57d2 in pthread_kill ()
>>>>>>>> #2  0x00007fff856d6a7a in abort ()
>>>>>>>> #3  0x00007fff8573584c in free ()
>>>>>>>> #4  0x00000001069e2685 in std::string::assign ()
>>>>>>>> #5  0x0000000100b4297c in global constructors keyed to a () at 
>>>>>>>> basic_string.h:500
>>>>>>>> #6  0x00007fff5fc0fda6 in 
>>>>>>>> __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE
>>>>>>>>  ()
>>>>>>>> #7  0x00007fff5fc0faf2 in 
>>>>>>>> __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE
>>>>>>>>  ()
>>>>>>>> #8  0x00007fff5fc0d2e4 in 
>>>>>>>> __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE
>>>>>>>>  ()
>>>>>>>> #9  0x00007fff5fc0d27d in 
>>>>>>>> __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE
>>>>>>>>  ()
>>>>>>>> #10 0x00007fff5fc0e0b7 in 
>>>>>>>> __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE
>>>>>>>>  ()
>>>>>>>> #11 0x00007fff5fc034dd in __dyld__ZN4dyld24initializeMainExecutableEv 
>>>>>>>> ()
>>>>>>>> #12 0x00007fff5fc0760b in 
>>>>>>>> __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ ()
>>>>>>>> #13 0x00007fff5fc01059 in __dyld__dyld_start ()
>>>>>>>> (gdb)
>>>>>>>> 
>>>>>>>> Ben
>>>>>>> 
>>>>>>> The stack trace is not very clear, but it looks like something bad is
>>>>>>> happening during static initialization. I should probably get rid of
>>>>>>> these static variables anyways. Can you try the attached patch? If I
>>>>>>> am right it should fix problem.
>>>>>>> 
>>>>>>> I might be a bit slow to respond the next few days. I have to prepare
>>>>>>> for and get to OctConf!
>>>>>>> 
>>>>>>> Max Brister
>>>>>>> <static_init.patch>
>>>>>> 
>>>>>> I don't see any change
>>>>>> 
>>>>>> done
>>>>>> octave(88684,0x7fff70d62960) malloc: *** error for object 0x106a4b620: 
>>>>>> pointer being freed was not allocated
>>>>>> *** set a breakpoint in malloc_error_break to debug
>>>>>> 
>>>>>> Program received signal SIGABRT, Aborted.
>>>>>> 0x00007fff850fece2 in __pthread_kill ()
>>>>>> (gdb) bt
>>>>>> #0  0x00007fff850fece2 in __pthread_kill ()
>>>>>> #1  0x00007fff856e57d2 in pthread_kill ()
>>>>>> #2  0x00007fff856d6a7a in abort ()
>>>>>> #3  0x00007fff8573584c in free ()
>>>>>> #4  0x00000001069e1685 in std::string::assign ()
>>>>>> #5  0x0000000100b4287c in global constructors keyed to a () at 
>>>>>> basic_string.h:500
>>>>>> #6  0x00007fff5fc0fda6 in 
>>>>>> __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE
>>>>>>  ()
>>>>>> #7  0x00007fff5fc0faf2 in 
>>>>>> __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE
>>>>>>  ()
>>>>>> #8  0x00007fff5fc0d2e4 in 
>>>>>> __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE
>>>>>>  ()
>>>>>> #9  0x00007fff5fc0d27d in 
>>>>>> __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE
>>>>>>  ()
>>>>>> #10 0x00007fff5fc0e0b7 in 
>>>>>> __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE
>>>>>>  ()
>>>>>> #11 0x00007fff5fc034dd in __dyld__ZN4dyld24initializeMainExecutableEv ()
>>>>>> #12 0x00007fff5fc0760b in 
>>>>>> __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ ()
>>>>>> #13 0x00007fff5fc01059 in __dyld__dyld_start ()
>>>>>> (gdb)
>>>>> 
>>>>> I'm not sure what is happening here. If the statics I'm initializing
>>>>> do not cause any issue and Octave runs by its self, I wonder if this
>>>>> problem is caused by llvm? Does just linking llvm into Octave without
>>>>> using jit at all cause this problem?
>>>>> 
>>>>> Max Brister
>>>> 
>>>> What is the best way for me to test that? Do I simply add the part below 
>>>> to ./configure when building the developer's sources from Savannah?
>>>> 
>>>>       LLVM_CONFIG=/opt/local/bin/llvm-config-mp-3.0
>>>> 
>>>> Ben
>>> 
>>> Sorry for the delay. That approach will not work, as the developers
>>> source from savanah does not search for llvm. I have attached a patch
>>> that changes configure.ac to disable HAVE_LLVM (even when LLVM is
>>> found). Then it call llvm::getGlobalContext () in octave_main. This
>>> should show us if LLVM is an issue, or it is my code.
>>> 
>>> Max Brister
>>> <llvm_check.patch>
>> 
>> I've been having trouble running configure on the default branch since JIT 
>> was merged.  WIth Carlo's recent changes, I'm able to configure again! I've 
>> tried three cases.
>> 
>>        (1) Building without LLVM_CONFIG results in a working octave.
>> 
>>        (2) Building with LLVM_CONFIG and without your patch 
>> (llvm_check.patch)  crashes.
>> 
>>        (3) Building with LLVM_CONFIG and with your patch (llvm_check.patch) 
>> also crashes.
> 
> Ok, so this crash looks like it's unrelated to my code. There might be
> a problem with how I'm linking to llvm though.
> 
>> I'm unfamiliar with LLVM. I have several versions of gcc development tools 
>> installed on my Mac (gcc-4.2, gcc-4.4, gcc-4.5, and gcc-4.6).  Might LLVM be 
>> sensitive to compiler choice?
> 
> I'm not sure. It might also be an issue with the compiler flags in my
> config script. Your original error message had a failure in
> std::string::assign, so maybe LLVM is compiled with a different
> version of libstdc++ (this is just a wild guess). Can you see if the
> LLVM examples compile and run? (http://llvm.org/releases/)

I don't see any example at the link.

Linking to more than one libstdc++ may be the case as I have Apple's gcc as 
well as gcc-4.4, gcc-4.5, and gcc-4.6 from MacPorts installed.  However, 
looking at the Octave executable as well as liboctinterp.dylib, 
liboctave.dylib, and libcruft.dylib, the only libstdc++ I see is the one 
associated with gcc-4.5.

$ otool -L src/.libs/octave
src/.libs/octave:
        /usr/local/lib/octave/3.7.0+/liboctinterp.1.dylib (compatibility 
version 2.0.0, current version 2.1.0)
        /usr/local/lib/octave/3.7.0+/liboctave.1.dylib (compatibility version 
2.0.0, current version 2.1.0)
        /opt/local/lib/libfltk_gl.1.3.dylib (compatibility version 1.3.0, 
current version 1.3.0)
        /opt/local/lib/libfltk.1.3.dylib (compatibility version 1.3.0, current 
version 1.3.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 159.1.0)
        /opt/local/lib/libhdf5.7.dylib (compatibility version 8.0.0, current 
version 8.3.0)
        /opt/local/lib/libfontconfig.1.dylib (compatibility version 7.0.0, 
current version 7.0.0)
        /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current 
version 8.1.0)
        /opt/local/lib/libfreetype.6.dylib (compatibility version 15.0.0, 
current version 15.1.0)
        /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current 
version 1.2.7)
        /opt/local/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current 
version 1.0.6)
        /opt/local/lib/libexpat.1.dylib (compatibility version 8.0.0, current 
version 8.0.0)
        /opt/local/lib/libX11.6.dylib (compatibility version 10.0.0, current 
version 10.0.0)
        /opt/local/lib/libxcb.1.dylib (compatibility version 3.0.0, current 
version 3.0.0)
        /opt/local/lib/libXau.6.dylib (compatibility version 7.0.0, current 
version 7.0.0)
        /opt/local/lib/libXdmcp.6.dylib (compatibility version 7.0.0, current 
version 7.0.0)
        /usr/local/lib/octave/3.7.0+/libcruft.1.dylib (compatibility version 
2.0.0, current version 2.0.0)
        /opt/local/lib/libmetis.dylib (compatibility version 0.0.0, current 
version 0.0.0)
        /opt/local/lib/libqrupdate.1.dylib (compatibility version 0.0.0, 
current version 0.0.0)
        /opt/local/lib/libfftw3.3.dylib (compatibility version 7.0.0, current 
version 7.2.0)
        /opt/local/lib/libfftw3f.3.dylib (compatibility version 7.0.0, current 
version 7.2.0)
        /opt/local/lib/libreadline.6.2.dylib (compatibility version 6.0.0, 
current version 6.2.0)
        /opt/local/lib/libncurses.5.dylib (compatibility version 5.0.0, current 
version 5.0.0)
        /opt/local/lib/libpcre.1.dylib (compatibility version 2.0.0, current 
version 2.0.0)
        /opt/local/lib/gcc45/libstdc++.6.dylib (compatibility version 7.0.0, 
current version 7.14.0)
        /opt/local/lib/gcc45/libgfortran.3.dylib (compatibility version 4.0.0, 
current version 4.0.0)
        /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa 
(compatibility version 1.0.0, current version 17.0.0)
        
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
 (compatibility version 1.0.0, current version 41.0.0)
        /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 
(compatibility version 1.0.0, current version 1.0.0)
        /System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility 
version 1.0.0, current version 1.0.0)
        /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 
1105.0.0)
        /opt/local/lib/gcc45/libgcc_s.1.dylib (compatibility version 1.0.0, 
current version 1.0.0)

Ben