[LLVMdev] [lldb-dev] [3.7 Release] We have branched (original) (raw)

Russell Wallace russell.wallace at gmail.com
Sat Jul 25 02:31:00 PDT 2015

Done. I'd link the reply but none of the perl5-porters archives seems to work, so copying here:

bulk88 <bulk88 at hotmail.com> 8:19 AM (2 hours ago)

to me, perl5-porters

I tried a cl clang build about 1.5 years ago, some things had to be fixed in /win32, colored warnings and errors were interesting with clang. I never published the patch and I deleted it or lost it.

A big design choice with using llvm on win32 is, what toolchain is clang supposed to use on Win32 Perl? clang with MS SDK and cl.exe/VC emulation, or clang with mingw headers and gcc emulation?

Next question, who will maintain such a port? I added ICC on Win32 build (ICC on Win32 pretends its VC), but the build isn't completely perfect (it fails a FP math test), and it doesn't use ICC's __regcall calling convention and it is missing ICC's long double support.

Now about that ticket/selectany on anon type, all Visual Cs compile that code. Anonymous types are standard features of C/C++. The fact that clang cl can't generate a C++ symbol name for the var while MS cl.exe can is a bug. The C++ mangled name of __PL_nan_u is "?__PL_nan_u@@3T__unnamed@@B" on 32 bit VC 2003.

3=unqualified type T=Complex Type (union) B=const

C:>UNDNAME.EXE ?__PL_nan_u@@3T__unnamed@@B Microsoft (R) C++ Name Undecorator Copyright (C) Microsoft Corporation 1981-2001. All rights reserved.

Undecoration of :- "?__PL_nan_u@@3T__unnamed@@B" is :- "union __unnamed const __PL_nan_u" C:>

Here is another bug in clang. I changed the line to extern __declspec( dllexport ) const union { unsigned __int64 __q; double __d; } __PL_nan_u = { 0x7FF8000000000000UI64 };

then recompiled, result is a fatal error with clang-cl.exe but not with cl.exe.

clang-cl -c -nologo -GF -W3 -TP -EHsc -I..\lib\CORE -I.\include -I. -I.. -DWIN32 -D_CONSOLE -DNO_STRICT -DPERLDLL -DPERL_CORE -O1 -MD -Zi -DNDEBUG - DPERL_EXTERNAL_GLOB -DPERL_IS_MINIPERL -Fomini\av.obj ..\av.c In file included from ..\av.c:24: In file included from ../perl.h:28: .\config.h(3008,29) : warning: '/' within block comment [-Wcomment] /#define PERL_MALLOC_WRAP /**/ ^ In file included from ..\av.c:24: In file included from ../perl.h:3060: .\win32.h(286,1) : error: '__PL_nan_u' must have external linkage when declared

  'dllexport'

__PL_nan_u = { 0x7FF8000000000000UI64 }; ^

On Fri, Jul 24, 2015 at 10:06 PM, Nico Weber <thakis at chromium.org> wrote:

On Fri, Jul 24, 2015 at 12:05 PM, Nico Weber <thakis at chromium.org> wrote:

On Thu, Jul 16, 2015 at 8:08 AM, Nico Weber <thakis at chromium.org> wrote:

On Wed, Jul 15, 2015 at 10:45 AM, Russell Wallace <_ _russell.wallace at gmail.com> wrote:

Basic test results on Windows 7, visual studio 2013 (64 bit):

Build clang with visual studio - okay Build clang with itself - okay Build Python - okay Build Ruby - fails on conftest.c, but 3.6 also failed so this is not a regression bug Build Perl - fails. 3.6 also failed, but I think the error message was different, so this could be a regression bug but hopefully it's actually an improvement. Current error message: cl -c -I. -nologo -GF -W3 -I..\lib\CORE -I.\include -I. -I.. -DWIN32 -DCONSOLE -DNOSTRICT -DWIN64 -DCONSERVATIVE -DCRTSECURENODEPRECATE -DCRTNONSTDCNODEPRECATE -DPERLDLL -DPERLCORE -O1 -MD -Zi -DNDEBUG -GL -fp:precise -DPERLTEXTMODESCRIPTS -DPERLIMPLICITCONTEXT -DPERLIMPLICITSYS -TP -EHsc -Foperllib.obj perllib.c clang-cl.exe: warning: argument unused during compilation: '-GL' In file included from perllib.c:10: In file included from ..\lib\CORE\perl.h:3060: In file included from .\win32thread.h:4: ./win32.h(284,25) : error: 'selectany' can only be applied to data items with external linkage

That line is: _extern const _declspec(selectany) union { unsigned _int64 q; double __d; } PLnanu = { 0x7FF8000000000000UI64 }; If it's written like so, clang-cl accepts it: _union U { unsigned _int64 _q; double d; }; _extern const _declspec(selectany) U PLnanu = { 0x7FF8000000000000UI64 }; _I guess cl.exe applies the declspec to PLnanu while we try to apply it to the type? (Even though it's written before "union", so according to https://msdn.microsoft.com/en-us/library/dabb5z75.aspx it should apply to the variable.) Is there a bug filed for this? (Filed https://llvm.org/bugs/showbug.cgi?id=24251) After some discussion on that bug, we think it'd be better if perl could change that header, given that it's pretty new code (see the bug above for details). Russel, could you try to reach out to upstream perl?

On Wed, Jul 15, 2015 at 1:25 AM, Hans Wennborg <hans at chromium.org> wrote: Hi all, The 3.7 release branch was created from trunk at r242221 today (around 10:40 pm UTC). Branch policy: - Any doc changes can go in. Updates to the release notes are highly encouraged, and should be committed directly to the branch. - All other patches should be approved by the release manager (me) and the appropriate code owner. To get a change merged, commit it to trunk, and then reply to the commit email with myself and the code owner cc'd, asking for approval. - Fixes to complete existing features may be merged. However, the features must be completed before Phase II of testing starts, otherwise they should be disabled. If you recently committed something experimental to trunk, please make sure it's disabled on the branch. - For any bug fixes that you think might apply to the release branch, please cc me on the commit message. Cheers, Hans

LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

lldb-dev mailing list lldb-dev at cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150725/0c8922fa/attachment.html>

More information about the llvm-dev mailing list