[lldb-dev] [LLVMdev] [3.7 Release] We have branched
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 -D_CONSOLE -DNO_STRICT -DWIN64 -DCONSERVATIVE
>>>> -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -DPERLDLL -DPERL_CORE
>>>> -O1 -MD -Zi -DNDEBUG -GL -fp:precise -DPERL_TEXTMODE_SCRIPTS
>>>> -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -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; } __PL_nan_u = { 0x7FF8000000000000UI64 };
>>>
>>> If it's written like so, clang-cl accepts it:
>>> union U { unsigned __int64 __q; double __d; };
>>> extern const __declspec(selectany) U __PL_nan_u = {
>>> 0x7FF8000000000000UI64 };
>>>
>>> I guess cl.exe applies the declspec to __PL_nan_u 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/show_bug.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/lldb-dev/attachments/20150725/0c8922fa/attachment.html>
More information about the lldb-dev
mailing list