[LLVMdev] [lldb-dev] [3.7 Release] We have branched

Mon Jul 27 09:28:50 PDT 2015

Okay, just had a more constructive conversation with someone else on the
Perl mailing list, copied below.

On Sun, Jul 26, 2015 at 2:15 AM, <sisyphus1 at optusnet.com.au> wrote:
>
> AIUI, you're requesting that, in order to work around a clang-cl bug, the
> following code in win32/win32.h:
>
> extern const __declspec(selectany) union { unsigned __int64 __q; double
> __d; }
> __PL_nan_u = { 0x7FF8000000000000UI64 };
>
> be rewritten as:
>
> union U { unsigned __int64 __q; double __d; };
> extern const __declspec(selectany) U __PL_nan_u = {
> 0x7FF8000000000000UI64 };
>

Yes. (With the caveat that presumably the Clang and Microsoft C++ teams
would disagree with each other on which compiler the bug would be more
accurately said to be in - but without taking a position either way on
that, yes, that is what I'm asking.)

With that change in place, does clang-cl then successfully build perl ?
> Or do additional issues then arise ?
>

It gets past that file and goes on for a while more before hitting:

..\perlio.c(3206,8) :  error: no member named '_file' in 'struct _iobuf'
    f->_file = -1;
    ~  ^
..\perlio.c(3394,28) :  error: no member named '_ptr' in 'struct _iobuf'
        STDCHAR *eptr = (STDCHAR*)PerlSIO_get_ptr(s);
                                  ^~~~~~~~~~~~~~~~~~

However, that's not clang specific, it's because Microsoft did some kind of
rearranging of the header files in Visual C++ 2015; clang is using the
Microsoft system header files so both compilers now hit an identical error
there. So all I can say is I know of no more clang-specific issues in
building perl.

If no-one here puts up their hand to implement that change (or provides
> good reason that it ought not be implemented) you should send a bug report
> to perlbug at perl.org.
> Otherwise your request will perhaps "fall through the cracks".
>

Okay, done.

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/llvm-dev/attachments/20150727/5b317a66/attachment.html>