Multlib support in 3.5

[nenadv]

As of 3.5 multilib support for clang was improved (at least, printing of multilib options is). Now, the print something like this:

# clang-upc -print-multi-lib
.;@m64
32;@m32

Almost a match for gcc that prints something like this:

.;
32;@m32

3.4 version of the compiler reported only m64 option, even though -m32 was functional.

Clang UPC runtime does not support 32 bit compilation on 64 bit machines.

Some of our test suites traverse the multilib support and try to apply appropriate switches. And they fail for -m32 option as there are no appropriate runtime libraries.

There are few options:

• Add multilib runtime. As we looked at this a while back it does not seem doable.
• Disable multilib for UPC. There might be cases (upc2c/upcr) that don;t use Clang UPC runtime and -m32 migh tbe useful for testing.
• Disable multlib iterations in our testings. Probably the best for now.

[nenadv]

Steven, when we build the runtime, we iterate through various options and build the libraries for each of them - packed/struct/../

Would it be possible to detect multilib and build m32 libraries the same way? We just add 'm32' in their names.

[swatanabe]

It should be possible. Do we want to have it before or after the other library options? Also, do we want upc-s-l-m32.a or just upc-s-l-32.a?

[swatanabe]

Or we could be more explicit and use i686 v x86_64.

[swatanabe]

libc++ looks like it's designed to use separate directories. i.e. lib32/ lib64/

[nenadv]

32 is fine, gcc does the same.

On 3/10/15 1:22 PM, swatanabe wrote:

Or we could be more explicit and use i686 v x86_64.

—
Reply to this email directly or view it on GitHub
#74 (comment).

[nenadv]

Maybe keep current directories as is and create '32' directory with the
same directory structure. You will need crt files too?

On 3/10/15 1:24 PM, swatanabe wrote:

libc++ looks like it's designed to use separate directories. i.e. lib32/
lib64/

—
Reply to this email directly or view it on GitHub
#74 (comment).

[PHHargrove]

FYI:

If you look at MIPS you will find two 32-bit ABIs ("32" and "n32"), and one "64" ABI.
The two 32-bit ABIs have different function call conventions and thus cannot call each other.
The gcc internal libs are in %{libdir}, %{libdir}/n32 and %{libdir}/64, where %{libdir} is something like /usr/lib/gcc/mips-linux-gnu/4.6.

There is also a lesser-known x32 ABI for x86-64 that uses the full register set but has 32-bit pointers and long (see http://en.wikipedia.org/wiki/X32_ABI). I suspect the gcc support for this is doing similar to MIPS, with a "x32" subdirectory, but I have not checked.

[nenadv]

Last night builds on Mnt Lion - MacOSx failed.

/usr/local/upc/testers32/llvm-upc/bin/clang-upc -m32 -Wno-duplicate-decl-specifier -Werror=pointer-arith -g   -DSTDOUT_OUTPUT -lm -o pingpongUPC pingpongUPC.c
ld: warning: directory not found for option '-L/usr/local/upc/testers32/llvm-upc/bin/../lib/32'
ld: file not found: upc-crtbegin.o
clang-3.5: error: linker command failed with exit code 1 (use -v to see invocation)

These are the 32-bit builds on 64 bit machine. I think that '-m32' is passed in as an option for the C/C++ compiler when compiler was built.

I rebuilt my centos 32 bit compiler and noticed that upc CRT files are under '32' directories. I don't think they should be there as this is a 32 bit machine.

[nenadv]

Nightly 32 bit tester is being built with this comand:

/sw/bin/cmake  -DCMAKE_INSTALL_PREFIX:PATH=/usr/local/upc/testers32/llvm-upc
       -DLLVM_TARGETS_TO_BUILD:=X86  -DCMAKE_BUILD_TYPE:=Debug
-DLLVM_ENABLE_LIBCXX:BOOL=TRUE
       -DLIBUPC_ENABLE_LINK_SCRIPT=FALSE  -DLLVM_BUILD_32_BITS=TRUE
/usr/local/upc/testers32/llvm-upc/src

[swatanabe]

AMDG

On 03/16/2015 10:00 AM, Nenad Vukicevic wrote:

I rebuilt my centos 32 bit compiler and noticed that upc CRT files are under '32' directories. I don't think they should be there as this is a 32 bit machine.

How important is this? It's much easier
to make the directory solely dependent on
the target triple.

In Christ,
Steven Watanabe

[swatanabe]

AMDG

On 03/16/2015 12:26 PM, Nenad Vukicevic wrote:

Nightly 32 bit tester is being built with this comand:

/sw/bin/cmake  -DCMAKE_INSTALL_PREFIX:PATH=/usr/local/upc/testers32/llvm-upc
       -DLLVM_TARGETS_TO_BUILD:=X86  -DCMAKE_BUILD_TYPE:=Debug
-DLLVM_ENABLE_LIBCXX:BOOL=TRUE
       -DLIBUPC_ENABLE_LINK_SCRIPT=FALSE

This is no longer needed. The link script should work now.

-DLLVM_BUILD_32_BITS=TRUE

I forgot to handle this option when
determining the default set of libraries
to build.

/usr/local/upc/testers32/llvm-upc/src

In Christ,
Steven Watanabe

[nenadv]

Ok. To build UPC library with both 64 and 32 bits I have to do something like this:

-DLIBUPC_MULTILIB:='64;32`

If I do just 32 then I don't get 64 bit default libraries and only -m32 option works.

I wonder if it is possible to determine the need for multilib from the info gathered from '-print-multi-lib' compiler option. If it supports 32 bits then we build 32bits libraries.