[llvm-dev] Unresolved symbols in compiler-rt

[Jerker Bäck via llvm-dev]

Hi Eli,

Thanks for the reply. I'm new to using clang and I have no idea how common my problem with GNU m4 is. Maybe it's a rare event. Anyway, I'm thinking of recompile the whole clang_rt.builtins-x86_64.lib with clang. At least that's better than cherry-picking symbols when needed I think. Perhaps compiling compiler-rt with clang is a solution that could be defined in the make files, as an alternative. That way the library would be free from concerns of other compilers.

Yes, __SIZEOF_INT128__ would be more logical than a 64-bit define.

Regards Erik

-----Original Message-----
From: Friedman, Eli [mailto:efriedma at codeaurora.org] 
Sent: Friday, December 8, 2017 8:50 PM
To: Jerker Bäck; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Unresolved symbols in compiler-rt

On 12/8/2017 11:27 AM, Jerker Bäck via llvm-dev wrote:
> Hello all,
>
> I get unresolved external symbol __muloti4 when attempting to compile GNU m4
> for Windows commandline.
> See details in bug: https://bugs.llvm.org/show_bug.cgi?id=16404#c22
>
> Looking into this, I see that some parts of compiler-rt are disabled for
> Windows due to the __LP64__ define. The code seem not portable as is to the
> MS compiler, but according to my tests the code compiles and links OK with
> clang: I have not tested functionality though. Regarding the __LP64__
> define, it's wrong to define it for Windows. SUA/Interix have LP64 long type
> model, while Cygwin, mingw and native Windows have LLP64. _M_X64 or
> __x86_64__ is more common.
>
> So I wonder, is the disabled compiler-rt parts intentional and not suitable
> for Windows?
> If not so, what can be done to enable it?

We should be building the __int128_t support bits for any target which 
has an __int128_t type... which I guess includes 64-bit Windows. Patch 
welcome.  (We should probably be checking whether __SIZEOF_INT128__ is 
defined.)

-Eli

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project