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

Russell Wallace russell.wallace at gmail.com
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; } _PLnanu = { 0x7FF8000000000000UI64 }; be rewritten as: _union U { unsigned _int64 _q; double d; }; _extern const _declspec(selectany) U PLnanu = { 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 -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/20150727/5b317a66/attachment.html>

More information about the llvm-dev mailing list