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

[Gary Byers]

gcc-4.0.0 is several years old, but we (usually) don't care about that;
what generally matters is that the gcc version in question follows the
platform's ABI's rules about how structures are laid out and how their
fields are aligned.  Older GCC versions are generally easier to build
(have fewer dependencies) than newer versions are, and on many platforms
we can patch 4.0.0 and get a working translator; that's what the code
in the ffigen4 svn trunk tries to do.

The construct from /usr/include/bits/link.h that it's choking on (and
it chokes for me as well, though I didn't notice) is the description
of the (relatively new) 256-bit "ymm" vector register type.  ffigen
doesn't believe that such a thing exists.  It happens to be sort of
right about that (it was supposed to have been introduced in Intel's
"Sandy Bridge" chips, which got delayed/recalled and may or may not
exist in shipping systems; I haven't followed it too closely) but the
concept of 256-bit (and possibly larger) SIMD registers has been in
some Linux headers (and kernels/libraries) for the last few years, and
we need to support that.

I checked in a change to ffigen that seems to fix this.

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

> Hmm... that does indeed look like the wiki page I was referencing. ?Is
> gcc-4.0.0 not the current version?
> Here's the exact script (with sequence of commands) that I wrote to preserve
> exactly how I went about acquiring and installing ffigen and h-to-ffi.sh. If
> you have trouble reproducing it, let me know. It's just a stock Ubuntu 10.04
> on x86_64, but I can give you a login on a remote box if need be, or get you
> a virtualbox image.
> Thanks,
> Jason
> 
> jaten at AtenMBP-2:~/research/djitia$ cat install-ffigen.sh?
> #!/bin/bash
> svn co http://svn.clozure.com/publicsvn/ffigen4/trunk/ffigen4
> cd ffigen4/
> wget http://ftp.gnu.org/gnu/gcc/gcc-4.0.0/gcc-core-4.0.0.tar.bz2
> wget http://ftp.gnu.org/gnu/gcc/gcc-4.0.0/gcc-objc-4.0.0.tar.bz2
> make
> # example sudo tar xfz/home/jaten/pkg/llvm28/llvm-2.8/tools/ldc2/ffigen/ffigen4/ffigen-bin-linuxx
> 8664-gcc-4.0.0-2011-03-18-23-40-54.tar.gz -C /usr/local
> export TARBALL=`ls -1 | grep ffigen-bin`
> export HERE=`pwd`
> 
> echo "installing now to: ? ?/usr/local/ffigen ? and ?
> /usr/local/bin/h-to-ffi.sh ? ...with sudo"
> echo "sudo tar xfz `pwd`/`ls -1 | grep ffigen-bin` -C /usr/local"
> sudo tar xfz `pwd`/`ls -1 | grep ffigen-bin` -C /usr/local
> 
> 
> On Sat, Mar 19, 2011 at 11:37 AM, Gary Byers <gb at clozure.com> wrote:
>       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
> 
> 
> 
> 
> 
> 
> 
> --
> Jason E. Aten, Ph.D.
> 
> 
> 
>