[3.7 Release] We have branched

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

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.

Do we have any official documentation of these bullet points? It might be
worth updating http://llvm.org/docs/HowToReleaseLLVM.html with some
information to limit the amount of "tribal knowledge" involved in our
release process (which has bitten us in the past).

-- Sean Silva

I’m getting these errors:

C:\llvm-svn>svn up -r242221
Updating ‘.’:
svn: E730054: Unable to connect to a repository at URL ‘http://llvm.org/svn/llvm-project/llvm/trunk
svn: E730054: Error running context: An existing connection was forcibly closed by the remote host.

C:\llvm-svn>svn up -r242221
Updating ‘.’:
svn: E175012: Unable to connect to a repository at URL ‘http://llvm.org/svn/llvm-project/llvm/trunk
svn: E175012: Connection timed out

Is it the case that the server is down at the moment, or overloaded with a lot of people trying to download 3.7? If so, fair enough, I’ll try again later; just wanting to make sure it’s not the case that I’ve got the wrong address or have forgotten something important about how to use svn or something like that.

Hi Russell,
I tried to check out with command “svn co http://llvm.org/svn/llvm-project/llvm/trunk” , it works. It seems the SVN server is not down.

– Kun Ling

Yeah, works for me now too, must have been a temporary problem. Running some basic tests, will post results when done.

Hi,

I see there's no rc1 tag yet so I'll try the branch directly with D10715 (switch to cmake) and D6563 (enables directly testing branch with test-release.sh) applied.

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

I'm basing them (and the whole release thing, really) on how Bill used
to do it and the emails he sent out.

I think that corresponds pretty well to what's on the HowToReleaseLLVM
page under the "Release Timeline" and "Release Patch Rules". Was there
anything in my email you think is missing from there?

Thanks,
Hans

>
>
>>
>> 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.
>
>
> Do we have any official documentation of these bullet points? It might be
> worth updating http://llvm.org/docs/HowToReleaseLLVM.html with some
> information to limit the amount of "tribal knowledge" involved in our
> release process (which has bitten us in the past).

I'm basing them (and the whole release thing, really) on how Bill used
to do it and the emails he sent out.

I think that corresponds pretty well to what's on the HowToReleaseLLVM
page under the "Release Timeline" and "Release Patch Rules". Was there
anything in my email you think is missing from there?

All 4 bullet points. In particular, the information is relevant for LLVM
developers (rather than the release manager). E.g. who to CC and when, the
policy about in-progress features, the policy on doc changes. I understand
that HowToReleaseLLVM is targeted at the release manager; could you drop
those 4 bullet points into a section in
http://llvm.org/docs/DeveloperPolicy.html? That seems like the best place
for developer-targeted development process information.

-- Sean Silva

Test-release.sh is giving 'make check-all' failures I didn't used to have but there all (except one) for projects we didn't build in 3.6.2 so that's not a big problem.

The failures are:
    AddressSanitizer-mips-linux :: TestCases/Linux/kernel-area.cc
    AddressSanitizer-mips-linux :: TestCases/Posix/coverage-direct-large.cc
    Clang :: Driver/cuda-options.cu
    UBSan-ASan-mips :: TestCases/Float/cast-overflow.cpp
    UBSan-Standalone-mips :: TestCases/Float/cast-overflow.cpp
    libc++abi :: backtrace_test.pass.cpp
    libc++abi :: test_demangle.pass.cpp
I had to kill an excessively long 'llc -march=r600 -mcpu=cypress' process (>500 minutes) to make the tests finish. I assume it's one of those failures.

Tom: Are you aware of any r600 tests that run forever?

Sagar: Could you look into the two ubsan failures?
Kumar: Could you look into the two asan failures?
The test system is running 32-bit Debian Jessie for mips (big-endian) and is a MIPS64r2 CPU. You'll need to configure llvm with -DLLVM_HOST_TRIPLE=mips-linux-gnu.

I should have added Mohit instead of Kumar. Sorry.

Tom: I've identified the problem test as test/CodeGen/AMDGPU/infinite-loop-evergreen.ll. Please see https://llvm.org/bugs/show_bug.cgi?id=24147 for details.

Sagar: The ticket for the ubsan failures is https://llvm.org/bugs/show_bug.cgi?id=24152. I've put them both on the same ticket since it's the same test file.
Mohit: The tickets for the asan failures are https://llvm.org/bugs/show_bug.cgi?id=24150 and https://llvm.org/bugs/show_bug.cgi?id=24151.
Nitesh: The tickets for the libc++abi failures are https://llvm.org/bugs/show_bug.cgi?id=24148 and https://llvm.org/bugs/show_bug.cgi?id=24149.

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?

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)

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?

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

bulk88 <bulk88@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

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

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@perl.org.
Otherwise your request will perhaps “fall through the cracks”.

Okay, done.