[Openmcl-devel] 3 questions - TLS the default? global thread-shared vars? .CDB gen broken?

[Gary Byers]

Hmm.  The Wiki page at <http://trac.clozure.com/ccl/wiki/BuildFFIGEN> is
supposed to be the canonical reference that describes how to obtain/build/install
the FFI translator.  In the past, we've distributed sources and binaries via
other means, but there aren't supposed to be any links to those older versions
and I can't find any links in the documentation.

The current version doesn't have any problem translating /usr/include/link.h
(or with the SIMD vector type referenced in the included file), but I'd certainly
believe that older versions did.  If you got an older version, that'd explain
it; if you remember how you got that version, we should fix any links to it
so that they reference the Wiki page instead.

On Sat, 19 Mar 2011, Jason E. Aten wrote:

> Thank you Raffael. ?I appreciate the pointer. I guess that confirms #1, and
> answers #2. :-)
> 
> For #3, I've managed to locate the source code for the ffigen loader, and
> figured out that :SUBDIR is supposed to be :libc or :elf ?or similar.
> 
> However I do manage to have populate.sh run into an issue:
> 
> +++ /usr/include/link.h
> Need to create info for type:
> ?<vector_type 0x7fab52eacb60
> ?? ?type <real_type 0x7fab53619000 float SF
> ?? ? ? ?size <integer_cst 0x7fab535fba80 constant invariant 32>
> ?? ? ? ?unit size <integer_cst 0x7fab535fb5a0 constant invariant 4>
> ?? ? ? ?align 32 symtab 18 alias set -1 precision 32
> ?? ? ? ?pointer_to_this <pointer_type 0x7fab53619270>>
> ?? ?BLK
> ?? ?size <integer_cst 0x7fab536146f0 type <integer_type 0x7fab536015b0
> bit_size_type> constant invariant 256>
> ?? ?unit size <integer_cst 0x7fab535fb570 type <integer_type 0x7fab536014e0
> long unsigned int> constant invariant 32>
> ?? ?align 256 symtab 341 alias set -1 nunits 8>
> In file included from /usr/include/link.h:36:
> /usr/include/bits/link.h:68: internal compiler error: in
> ffi_create_type_info, at ffi.c:428
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> 
> where the relevant section from /usr/include/bits/link.h, including line 68
> is this:
> 
> /* Registers for entry into PLT on x86-64. ?*/
> # if __GNUC_PREREQ (4,0)
> typedef float La_x86_64_xmm __attribute__ ((__vector_size__ (16)));
> typedef float La_x86_64_ymm __attribute__ ((__vector_size__ (32))); ?/* line
> 68 */
> # else
> typedef float La_x86_64_xmm __attribute__ ((__mode__ (__V4SF__)));
> # endif
> 
> Arg. What should I try? ?Is this the right place to report this?
> 
> Thank you.
> 
> Jason
> 
> 
> On Sat, Mar 19, 2011 at 12:21 AM, Raffael Cavallaro
> <raffaelcavallaro at mac.com> wrote:
>
>       On Mar 19, 2011, at 1:09 AM, Jason E. Aten wrote:
>
>       > In order words, when two different threads need to be able to
>       name the same variable (after locking the thread inspects the
>       shared variable, possibly updates it, then releases the lock),
>       how do I tell lisp this is what I'd like?
> 
> See section 4.8 of the documentation "Static Variables"
> 
> e.g., (defstatic *foo* 3)
> 
> It's an error to dynamically rebind a static variable; its value is
> always the same across all threads. Naturally, as you suggest, you'll
> want to avoid race conditions by using a lock or semaphore.
> 
> warmest regards,
> 
> Ralph
> 
> 
> Raffael Cavallaro
> raffaelcavallaro at me.com
> 
> 
> 
>