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

[Nico Weber]

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/20150724/5e02a637/attachment.html>