Re: [lldb-dev] [3.8 Release] Schedule and call for testers

[Dimitry Andric via lldb-dev]

On 12 Dec 2015, at 00:14, Hans Wennborg  wrote:
> 
> It's not quite time to start the 3.8 release process, but it's time to
> start planning.
> 
> Please let me know if you want to help with testing and building
> release binaries for your favourite platform. (If you were a tester on
> the previous release, you're cc'd on this email.)

Hi Hans,

As usual, I will be taking care of the FreeBSD builds.  I think Ed Maste
will also be able to do some of the legwork.  (Specifically to get our
CMake build in shape. :)


> I propose the following schedule for the 3.8 release:
> 
> - 13 January: Create 3.8 branch. Testing Phase 1: RC1 binaries built
> and tested, bugs fixed. Any almost-complete features need to be
> wrapped up or disabled on the branch ASAP, and definitely before this
> phase ends.
> 
> - 27 January: Testing Phase 2: RC2 binaries built and tested. Only
> critical bug fixes from now on. Further RCs published as we approach..
> 
> - 18 February: Cut the final release, build binaries, ship when ready.

This schedule looks fine to me.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [3.8 Release] RC1 has been tagged

[Dimitry Andric via lldb-dev]

Unfortunately I'm having lots of trouble with rc1 at this point:
* libcxxabi can't build, because it requires unwind.h, which we do not yet have 
on FreeBSD 10.x (Ed Maste is working on it for 11.x, but that is not ready for 
general consumption).
* The test-release.sh script has no option to disable only libcxxabi, you can 
only disable libcxx, libcxxabi and libunwind together (maybe this can be 
improved)
* Last time I hand-built libcxx, it still had a lot of test failures in the 
locale parts, but I haven't had time to investigate.
* OpenMP does not support i386-freebsd, so I have to disable it there
* Last but not least: the host compiler on FreeBSD 10.x is clang 3.4.1 (the 
last version that can build without C++11 support), and it crashes with a 
segfault during building of CGBlocks.cpp.  I'll need to find some way to work 
around this failure, since we cannot upgrade the compiler easily on FreeBSD 
10.x.

I also had to hack the test-release.sh script to fix a number of problems that 
I encountered during the 3.7.1 release, but haven't gotten to upstreaming them. 
 E.g. the way the source code is checked out with symlinks all over the place 
does not work, and I need to add a custom patch to clang-tools-extra to make 
the tests succeed, because there is a race condition in the Makefile.

-Dimitry

> On 20 Jan 2016, at 11:30, Daniel Sanders  wrote:
> 
> This isn't rc1 but the tip of the release branch had some X86 test failures 
> on my most recent build:
> Failing Tests (24):
>libc++ :: 
> std/input.output/file.streams/fstreams/filebuf.virtuals/overflow.pass.cpp
>libc++ :: 
> std/input.output/file.streams/fstreams/filebuf.virtuals/underflow.pass.cpp
>libc++ :: std/input.output/iostream.format/ext.manip/get_time.pass.cpp
>libc++ :: std/input.output/iostream.format/ext.manip/put_time.pass.cpp
>libc++ :: 
> std/input.output/iostreams.base/ios.base/ios.base.callback/register_callback.pass.cpp
>libc++ :: 
> std/input.output/iostreams.base/ios.base/ios.base.locales/imbue.pass.cpp
>libc++ :: 
> std/input.output/iostreams.base/ios/basic.ios.members/imbue.pass.cpp
>libc++ :: 
> std/input.output/stream.buffers/streambuf/streambuf.cons/copy.pass.cpp
>libc++ :: 
> std/input.output/stream.buffers/streambuf/streambuf.cons/default.pass.cpp
>libc++ :: 
> std/input.output/stream.buffers/streambuf/streambuf.protected/streambuf.assign/assign.pass.cpp
>libc++ :: 
> std/input.output/stream.buffers/streambuf/streambuf.protected/streambuf.assign/swap.pass.cpp
>libc++ :: 
> std/localization/locale.categories/category.collate/locale.collate.byname/hash.pass.cpp
>libc++ :: 
> std/localization/locale.categories/category.collate/locale.collate.byname/types.pass.cpp
>libc++ :: 
> std/localization/locale.categories/category.ctype/locale.codecvt.byname/ctor_wchar_t.pass.cpp
>libc++ :: 
> std/localization/locale.categories/category.ctype/locale.ctype.byname/types.pass.cpp
>libc++ :: std/localization/locales/locale/locale.cons/default.pass.cpp
>libc++ :: std/localization/locales/locale/locale.members/name.pass.cpp
>libc++ :: std/localization/locales/locale/locale.operators/eq.pass.cpp
>libc++ :: std/localization/locales/locale/locale.statics/global.pass.cpp
>libc++ :: std/re/re.regex/re.regex.locale/imbue.pass.cpp
>libc++ :: std/re/re.traits/default.pass.cpp
>libc++ :: std/re/re.traits/getloc.pass.cpp
>libc++ :: std/re/re.traits/imbue.pass.cpp
>libomp :: barrier/omp_barrier.c
> 
> Big-endian mips gave this during phase 3:
>   CMake Error at cmake/modules/HandleLLVMOptions.cmake:43 (message):
> Host Clang must be able to find libstdc++4.7 or newer!
> It's possible that this is a machine config issue. We moved offices over the 
> weekend (just across the street) and my normal machine somehow lost the 
> ability to boot in the process. I'm borrowing a replacement at the moment.
> 
> Little-endian mips is just about to finish Phase 2 so I'll know if it's a 
> more general problem soon.
> 
>> -Original Message-
>> From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf
>> Of Hans Wennborg
>> Sent: 19 January 2016 23:56
>> To: Ben Pope; Dimitry Andric; Daniel Sanders; Nikola Smiljanić; Brian Cain;
>> Renato Golin; Sylvestre Ledru
>> Cc: cfe-dev; lldb-dev@lists.llvm.org; openmp-...@lists.llvm.org; llvm-dev
>> Subject: Re: [3.8 Release] RC1 has been tagged
>> 
>> (cc'ing non-legacy llvm-dev this time; apologies if you get this
>> twice. Please don't reply-all to the first one.)
>> 
>> On Tue, Jan 19, 2016 at 3:47 PM, Hans Wennborg 
>> wrote:
>>> Dear testers,
>>> 
>>> Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
>>> r258223. (It took a little longer than I'd planned, sorry about that.)
>>> 
>>> There are still a bunch of open merge requests and bug reports, but I
>>> wanted to get the tag in so we can see what the build and test status
>>> are on the various platforms.
>>> 
>>> I verified tha

Re: [lldb-dev] [3.8 Release] RC1 has been tagged

[Dimitry Andric via lldb-dev]

On 20 Jan 2016, at 18:23, Hans Wennborg  wrote:
> 
> On Wed, Jan 20, 2016 at 5:25 AM, Dimitry Andric  wrote:
>> Unfortunately I'm having lots of trouble with rc1 at this point:
>> * libcxxabi can't build, because it requires unwind.h, which we do not yet 
>> have on FreeBSD 10.x (Ed Maste is working on it for 11.x, but that is not 
>> ready for general consumption).
>> * The test-release.sh script has no option to disable only libcxxabi, you 
>> can only disable libcxx, libcxxabi and libunwind together (maybe this can be 
>> improved)
> 
> Yes, I'd be happy to take a patch for this, or I suppose you could
> just hack it out locally when building.

It's not terribly important right now, as libcxx isn't succeeding its tests 
anyway.  I can locally hack it in, but I hope I won't forget it later. :)


>> * Last time I hand-built libcxx, it still had a lot of test failures in the 
>> locale parts, but I haven't had time to investigate.
> 
> Did we have that for 3.7 too?

With 3.7, we used autoconf builds for FreeBSD, and that skipped libcxx 
altogether.  I did a few builds by hand, and I remember I saw similar failures. 
 This is just something that nobody (from FreeBSD) has seriously looked at, and 
I never had the time for it.  There are only so much hours in a day...

For example, recently with trunk r256945, I saw these:

Failing Tests (39):
libc++ :: std/depr/depr.c.headers/stddef_h.pass.cpp
libc++ :: std/depr/depr.c.headers/wchar_h.pass.cpp
libc++ :: std/language.support/support.types/max_align_t.pass.cpp
libc++ :: 
std/localization/locale.categories/category.collate/locale.collate.byname/compare.pass.cpp
libc++ :: 
std/localization/locale.categories/category.collate/locale.collate.byname/transform.pass.cpp
libc++ :: 
std/localization/locale.categories/category.ctype/locale.ctype.byname/tolower_1.pass.cpp
libc++ :: 
std/localization/locale.categories/category.ctype/locale.ctype.byname/tolower_many.pass.cpp
libc++ :: 
std/localization/locale.categories/category.ctype/locale.ctype.byname/toupper_1.pass.cpp
libc++ :: 
std/localization/locale.categories/category.ctype/locale.ctype.byname/toupper_many.pass.cpp
libc++ :: 
std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_fr_FR.pass.cpp
libc++ :: 
std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_ru_RU.pass.cpp
libc++ :: 
std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_zh_CN.pass.cpp
libc++ :: 
std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_fr_FR.pass.cpp
libc++ :: 
std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_ru_RU.pass.cpp
libc++ :: 
std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_zh_CN.pass.cpp
libc++ :: 
std/localization/locale.categories/category.monetary/locale.moneypunct.byname/curr_symbol.pass.cpp
libc++ :: 
std/localization/locale.categories/category.monetary/locale.moneypunct.byname/grouping.pass.cpp
libc++ :: 
std/localization/locale.categories/category.monetary/locale.moneypunct.byname/neg_format.pass.cpp
libc++ :: 
std/localization/locale.categories/category.monetary/locale.moneypunct.byname/pos_format.pass.cpp
libc++ :: 
std/localization/locale.categories/category.monetary/locale.moneypunct.byname/thousands_sep.pass.cpp
libc++ :: 
std/localization/locale.categories/category.time/locale.time.get.byname/get_date.pass.cpp
libc++ :: 
std/localization/locale.categories/category.time/locale.time.get.byname/get_date_wide.pass.cpp
libc++ :: 
std/localization/locale.categories/category.time/locale.time.get.byname/get_one.pass.cpp
libc++ :: 
std/localization/locale.categories/category.time/locale.time.get.byname/get_one_wide.pass.cpp
libc++ :: 
std/localization/locale.categories/category.time/locale.time.put.byname/put1.pass.cpp
libc++ :: 
std/localization/locale.categories/facet.numpunct/locale.numpunct.byname/grouping.pass.cpp
libc++ :: 
std/localization/locale.categories/facet.numpunct/locale.numpunct.byname/thousands_sep.pass.cpp
libc++ :: std/re/re.alg/re.alg.match/basic.pass.cpp
libc++ :: std/re/re.alg/re.alg.match/ecma.pass.cpp
libc++ :: std/re/re.alg/re.alg.match/extended.pass.cpp
libc++ :: std/re/re.alg/re.alg.search/awk.pass.cpp
libc++ :: std/re/re.alg/re.alg.search/basic.pass.cpp
libc++ :: std/re/re.alg/re.alg.search/ecma.pass.cpp
libc++ :: std/re/re.alg/re.alg.search/extended.pass.cpp
libc++ :: std/re/re.traits/lookup_collatename.pass.cpp
libc++ :: std/re/re.traits/transform_primary.pass.cpp
libc++ :: std/re/re.traits/translate_nocase.pass.cpp
libc++ :: std/strings/string.conversions/stof.pass.cpp
libc++ :: 
std/utilities/

Re: [lldb-dev] [3.8 Release] RC1 has been tagged

[Dimitry Andric via lldb-dev]

On 20 Jan 2016, at 22:26, Hans Wennborg  wrote:
> 
> On Wed, Jan 20, 2016 at 12:18 PM, Dimitry Andric  wrote:
...
>> The way I fixed this during the 3.7 test phase, is by changing 
>> test-release.sh so it exports directly into these locations:
>> 
>> # Exporting llvm 3.7.0-rc3 sources to llvm.src
>> # Exporting cfe 3.7.0-rc3 sources to llvm.src/tools/clang
>> # Exporting clang-tools-extra 3.7.0-rc3 sources to 
>> llvm.src/tools/clang/tools/extra
>> # Exporting compiler-rt 3.7.0-rc3 sources to llvm.src/projects/compiler-rt
>> # Exporting libcxx 3.7.0-rc3 sources to llvm.src/projects/libcxx
>> # Exporting libcxxabi 3.7.0-rc3 sources to llvm.src/projects/libcxxabi
>> # Exporting libunwind 3.7.0-rc3 sources to llvm.src/projects/libunwind
>> # Exporting test-suite 3.7.0-rc3 sources to llvm.src/projects/test-suite
>> 
>> This is probably not so handy if you want to create tarballs of the 
>> individual components, though.
> 
> Actually, I use export.sh for creating the tarballs, so that's not a
> problem. Maybe just exporting into the right directories is the way to
> go.

I have created http://reviews.llvm.org/D16420 for this change.  Please review.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [3.8 Release] RC1 has been tagged

[Dimitry Andric via lldb-dev]

On 20 Jan 2016, at 21:18, Dimitry Andric via llvm-dev  
wrote:
...
>>> * Last but not least: the host compiler on FreeBSD 10.x is clang 3.4.1 (the 
>>> last version that can build without C++11 support), and it crashes with a 
>>> segfault during building of CGBlocks.cpp.  I'll need to find some way to 
>>> work around this failure, since we cannot upgrade the compiler easily on 
>>> FreeBSD 10.x.
>> 
>> This sounds like the biggest problem. Is there a PR for the crash? I
>> suppose the alternatives are either to try not to tickle the crash in
>> our source, or fixing the 3.4.1 compiler?
> 
> There is no PR, but I did a bisection, and the crash turns out to be fixed by 
> r210467 ("[DAG] Expose NoSignedWrap, NoUnsignedWrap and Exact flags to 
> SelectionDAG.") by Andrea DiBiagio.

And I finally found out this was a red herring, and I had already solved this 
issue before, in July 2015 [1], with excellent help from Andrea!  This was 
originally known as PR24249, and eventually turned out to be solved by llvm 
r219009.

However, the two build VMs I have been using for LLVM release testing were 
never updated to include the fix, and were still at the version of FreeBSD from 
roughly May 2015.

I have now been able to do a successful build of the llvm, clang and (for 
amd64) openmp.  Uploaded the following tarballs:

SHA256 (clang+llvm-3.8.0-rc1-amd64-unknown-freebsd10.tar.xz) = 
28b8f7758736dab181da9e5e445eb734b134a579ed79bcf8b040d4a7d5c9d31d
SHA256 (clang+llvm-3.8.0-rc1-i386-unknown-freebsd10.tar.xz) = 
ba9712964c56bcc9ba50f511f2a98757d321d5cd1c7989790029dd64c3db6db4

I will now spend some time to see if I can get more components to build for the 
next release candidate.

-Dimitry

[1] https://svnweb.freebsd.org/base?view=revision&revision=286033
[2] https://llvm.org/bugs/show_bug.cgi?id=24249
[3] http://llvm.org/viewvc/llvm-project?view=revision&revision=219009



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [3.8 Release] RC2 has been tagged

[Dimitry Andric via lldb-dev]

On 02 Feb 2016, at 22:15, Hans Wennborg via Release-testers 
 wrote:
> 
> Release Candidate 2 has just been tagged [1]. Please build, test, and
> upload to the sftp.
> 
> I know there are still outstanding issues from RC1, but there have
> been a lot of merges going into the branch and I think it's time for
> another round of RC testing.
> 
> This RC comes a little behind schedule, sorry about that, but I'm
> still optimistic about hitting the target of releasing towards the end
> of February.

I've had some trouble getting compiler-rt to build on FreeBSD, but after a few 
minor hacks, I managed to make it build and test successfully for i386.  For 
x86_64, however, there is still a problem in the tsan tests:

/tmp/gotsan.WXO5sLCzBa/gotsan.cc:(.text+0x22d9b): undefined reference to 
`__sanitizer::GetRSS()'
/tmp/gotsan.WXO5sLCzBa/gotsan.cc:(.text+0x22e7b): undefined reference to 
`__sanitizer::GetRSS()'
/tmp/gotsan.WXO5sLCzBa/gotsan.cc:(.text+0x22feb): undefined reference to 
`__sanitizer::GetRSS()'
clang-3.8: error: linker command failed with exit code 1 (use -v to see 
invocation)
projects/compiler-rt/lib/tsan/CMakeFiles/GotsanRuntimeCheck.dir/build.make:50: 
recipe for target 'projects/compiler-rt/lib/tsan/CMakeFiles/GotsanRuntimeCheck' 
failed
gmake[3]: *** [projects/compiler-rt/lib/tsan/CMakeFiles/GotsanRuntimeCheck] 
Error 1

E.g., at some point, GetRSS() got added or split out, but there is no FreeBSD 
variant of this function.  So for now I am probably going to attempt to disable 
tsan only, and continue with the rest of the build.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [3.8 Release] RC2 has been tagged

[Dimitry Andric via lldb-dev]

On 04 Feb 2016, at 09:09, Dimitry Andric via Release-testers 
 wrote:
> 
> On 02 Feb 2016, at 22:15, Hans Wennborg via Release-testers 
>  wrote:
>> 
>> Release Candidate 2 has just been tagged [1]. Please build, test, and
>> upload to the sftp.
>> 
>> I know there are still outstanding issues from RC1, but there have
>> been a lot of merges going into the branch and I think it's time for
>> another round of RC testing.
>> 
>> This RC comes a little behind schedule, sorry about that, but I'm
>> still optimistic about hitting the target of releasing towards the end
>> of February.
> 
> I've had some trouble getting compiler-rt to build on FreeBSD, but after a 
> few minor hacks, I managed to make it build and test successfully for i386.  
> For x86_64, however, there is still a problem in the tsan tests:
> 
> /tmp/gotsan.WXO5sLCzBa/gotsan.cc:(.text+0x22d9b): undefined reference to 
> `__sanitizer::GetRSS()'
> /tmp/gotsan.WXO5sLCzBa/gotsan.cc:(.text+0x22e7b): undefined reference to 
> `__sanitizer::GetRSS()'
> /tmp/gotsan.WXO5sLCzBa/gotsan.cc:(.text+0x22feb): undefined reference to 
> `__sanitizer::GetRSS()'
> clang-3.8: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> projects/compiler-rt/lib/tsan/CMakeFiles/GotsanRuntimeCheck.dir/build.make:50:
>  recipe for target 
> 'projects/compiler-rt/lib/tsan/CMakeFiles/GotsanRuntimeCheck' failed
> gmake[3]: *** [projects/compiler-rt/lib/tsan/CMakeFiles/GotsanRuntimeCheck] 
> Error 1
> 
> E.g., at some point, GetRSS() got added or split out, but there is no FreeBSD 
> variant of this function.  So for now I am probably going to attempt to 
> disable tsan only, and continue with the rest of the build.

After disabling tsan for x86_64, the builds finally went OK, and all tests 
succeeded.  So these tarballs now also have compiler-rt in them, though 
unfortunately still no libc++:

SHA256 (clang+llvm-3.8.0-rc2-amd64-unknown-freebsd10.tar.xz) = 
d6a709e38aa274cc58130b755ef3c1c1fc34b36cc2bfcb6bfa4118b23b0c834e
SHA256 (clang+llvm-3.8.0-rc2-i386-unknown-freebsd10.tar.xz) = 
840b3a391ef3dfec20ed5464230caad91f6431e655d0c6ae06cbabdd7ed12a73

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [3.8 Release] RC3 has been tagged

[Dimitry Andric via lldb-dev]

On 23 Feb 2016, at 22:51, Hans Wennborg via Release-testers 
 wrote:
> 
> Release Candidate 3 has just been tagged [1]. Please build, test, and
> upload to the sftp.

Built and tested just fine on FreeBSD 10.  Uploaded the following tarballs:

SHA256 (clang+llvm-3.8.0-rc3-amd64-unknown-freebsd10.tar.xz) = 
0ac847a23b881d27883b83add8926fff8265b650ef6fbf49bae3fc145305399a
SHA256 (clang+llvm-3.8.0-rc3-i386-unknown-freebsd10.tar.xz) = 
91a0f3c108f9baa9e0f374931f2efa1b1e2413b0ae3a6217fb8bf4111c5c4adb

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [3.8 Release] 'final' has been tagged

[Dimitry Andric via lldb-dev]

On 03 Mar 2016, at 01:33, Hans Wennborg via Release-testers 
 wrote:
> 
> My list of blockers is empty, and there were no new problems
> discovered with rc3, so I have gone ahead and tagged 3.8.0-final [1].
> 
> Please build the final binaries and upload to the sftp.

Built and tested successfully on FreeBSD 10.  Uploaded the following:

SHA256 (clang+llvm-3.8.0-i386-unknown-freebsd10.tar.xz) = 
674cf5faac18ffa5c01775460d2d56975426ea454e395332851a6a547140597e
SHA256 (clang+llvm-3.8.0-amd64-unknown-freebsd10.tar.xz) = 
fb5784be4dca2794f1229106c102230cff45d9b00fba28d6624ff2f0009a38ff

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [3.9 Release] Release plan and call for testers

[Dimitry Andric via lldb-dev]

On 10 Jun 2016, at 22:38, Hans Wennborg via cfe-dev  
wrote:
> It's time to start planning for the 3.9 release.
> 
> Please let me know if you'd like to help providing binaries and
> testing for your favourite platform.

As usual, I volunteer for providing FreeBSD binaries and testing.



> I propose the following schedule:
> 
> - 18 July: Create the release branch; build and test RC1 soon thereafter.
> 
> - 1 August: Tag, build and test RC2. Any unfinished features need to
> be turned off by now. As we get closer to the release, the bar for
> merging patches rises.
> 
> - 22 August: Tag 3.9.0-final. The release ships when binaries are ready.

I would put three weeks between RC1 and RC2, to allow more last-minute
bugs to be fixed, and two weeks between RC2 and final, but it is always
little arbitrary.


> Also, I have three more questions for the community:
> 
> 1) Right after the branch, the version number of the trunk will be
> incremented. I assume this means bumping the major version number,
> taking us to 4.0? IIUC, that's what happened after 1.9 and 2.9.

4.0.  Since gcc is already at 7.0, we need to catch up! ;-)


> 2) Following up on the May thread about the release process [1], I'd
> like to make the schedule we've followed for the last few years more
> official by posting somewhere on the web page that we're committed to
> shipping two major releases per year: one in early March (branching
> mid-January), and one early September (branching mid-July), usually
> with one (or sometimes two) "dot" releases in between.

Having predictable release schedules is nice.  If everybody knows the
tree should be in fairly good shape at the point of branching, any heavy
refactoring can be postponed until after such branching (or preferably,
until after the actual release).


> 3) Another follow-up from that thread: it's usually the same people
> who test the releases for their platform. Rather than asking everyone
> each time, I'd like to make a list of who's responsible for each
> platform and put that on the web page. Testers can still sign-up or
> resign as they like, of course. Would you testers be OK with this?

You can put me up for the FreeBSD platform, obviously.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [3.9 Release] Release Candidate 1 has been tagged

[Dimitry Andric via lldb-dev]

On 30 Jul 2016, at 00:57, Hans Wennborg via Release-testers 
 wrote:
> 
> 3.9.0-rc1 was just tagged from the 3.9 branch at r277207.

After fixing two compiler-rt test failures (see r277297 and r277300) and one 
openmp test link failure (see https://reviews.llvm.org/D23084), I'm left with 
only two failing tests:

Failing Tests (2):
ThreadSanitizer-x86_64 :: inlined_memcpy_race2.cc
ThreadSanitizer-x86_64 :: signal_reset.cc

  Expected Passes: 28511
  Expected Failures  : 155
  Unsupported Tests  : 1080
  Unexpected Failures: 2

These both fail because they hang indefinitely, and have to be killed for 
check-all to continue.

Unfortunately this is in TSan, which does not work at all on FreeBSD 11 and 
higher, due to a conflict of initialization order with our jemalloc.  So I am 
not extremely keen on fixing this before the release.

I uploaded the following:

SHA256 (clang+llvm-3.9.0-rc1-amd64-unknown-freebsd10.tar.xz) = 
8d3b1d50c00901d235c110a84afa5c16f0e80683928a47e31f8c189a41268698
SHA256 (clang+llvm-3.9.0-rc1-i386-unknown-freebsd10.tar.xz) = 
602373772b4ff2fc70c97f5483db33e3ecfd24122aed96d6fe083bae3ea0e6f6

For i386 and amd64, this contains llvm, clang, compiler-rt and lldb, while on 
amd64 there is also openmp.  We cannot yet build libc++, libcxxabi and 
libunwind, due to some missing functionality in our system unwinder.  Maybe if 
test-release.sh supported building libc++ separately, I could add it for the 
next RC.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [Release-testers] [3.9 Release] Release Candidate 1 has been tagged

[Dimitry Andric via lldb-dev]

On 03 Aug 2016, at 20:44, Renato Golin  wrote:
> 
> On 3 August 2016 at 19:24, Dimitry Andric via cfe-dev
>  wrote:
>> Unfortunately this is in TSan, which does not work at all on FreeBSD 11 and 
>> higher, due to a conflict of initialization order with our jemalloc.  So I 
>> am not extremely keen on fixing this before the release.
> 
> This sounds really serious. Do we have a bug for that?

I'm not sure if it should be a compiler-rt bug or a FreeBSD bug.  The issue is 
that __tsan_init() should be called before the initialization of malloc(), and 
that is not possible (or extremely difficult) with the version of jemalloc in 
FreeBSD 11 and 12.

The mechanism that TSan uses appears to be a .preinit_array section (though I'm 
not 100% sure it is used on FreeBSD):

__attribute__((section(".preinit_array"), used))
void (*__local_tsan_preinit)(void) = __tsan_init;

This section is then statically linked into the executable.  However, jemalloc 
initializes through a constructor in libc.so:

JEMALLOC_ATTR(constructor)
static void
jemalloc_constructor(void)
{

malloc_init();
}

Since .so files which are required by an executable are *always* loaded and 
initialized before that executable, certainly for the .preinit_array section 
and the constructors, I am unsure how to solve this race.  Maybe the solution 
is to link a small .so into the executable which is loaded even earlier than 
libc.so?

In the past I have tried several ways of working around this, could never get 
it to work, and then dropped it due to other priorities.  But if anybody has 
good ideas, I am all ears. :-)

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [3.9 Release] Release Candidate 2 has been tagged

[Dimitry Andric via lldb-dev]

On 19 Aug 2016, at 03:51, Hans Wennborg via Release-testers 
 wrote:
> 
> 3.9.0-rc2 was just tagged from the 3.9 branch at r279183.
> 
> This is a release candidate in the very real sense that if nothing new
> comes up, this is be what the final release looks like. There are
> currently no open release blockers, and no patches in my merge-queue.

Compiled everything just fine on FreeBSD 10 now, testing went OK except
for the two threadsanitizer failures (hangs) I already reported for rc1.
These aren't going to fixed before the release, so I'll ignore them.

Uploaded:

SHA256 (clang+llvm-3.9.0-rc2-i386-unknown-freebsd10.tar.xz) = 
eb529244055e45d0781b4259e286b5be3b8f044e6d3e65dbf67b597441292ef4
SHA256 (clang+llvm-3.9.0-rc2-amd64-unknown-freebsd10.tar.xz) = 
367ce05bea07be6697418518445c8dc5156f6dd288a4e3397ff7f17b2d009abf

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [3.9 Release] Release Candidate 3 has been tagged

[Dimitry Andric via lldb-dev]

On 25 Aug 2016, at 05:42, Hans Wennborg via Release-testers 
 wrote:
> 
> 3.9.0-rc3 was just tagged from the branch at r279704.
> 
> This one is very similar to rc2. These are the only new commits:
> 
> r279224 - Minor change to OpenCL release notes
> r279260 - [lld] Add a note that 3.9 is a major milestone for us
> r279468, r279474 - Fix gather-root.ll SLP vectorizer test to not expose UB
> r279476 - [lld] Add R_386_TLS_LE as a relocation having an implicit addend.
> r279471 - [msan] Disable prlimit test on glibc < 2.13
> r279477 - [CloneFunction] Don't remove unrelated nodes from the CGSSC
> r279647 - [SCCP] Don't delete side-effecting instructions
> 
> Please take this for a spin. If there are no hiccups, the plan is to
> promote this to 'final' on Friday and ship the release early next
> week.

Built and tested OK on FreeBSD 10 again.  Uploaded:

SHA256 (clang+llvm-3.9.0-rc3-i386-unknown-freebsd10.tar.xz) = 
32a2c03ca51223baf93baf35261254d50f8a948db3cfd17963a540e7a6aa1b36
SHA256 (clang+llvm-3.9.0-rc3-amd64-unknown-freebsd10.tar.xz) = 
feae733036a3932dcb96a807e9ab626d0ece1642323d207815816725c0b5

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [3.9 Release] 'final' has been tagged

[Dimitry Andric via lldb-dev]

On 01 Sep 2016, at 01:49, Hans Wennborg via Release-testers 
 wrote:
> 
> The final version of 3.9.0 was just tagged (from the 3.9 branch at
> r280312). There were no changes after rc3. This took a little longer
> than expected, but on the up side that means it's had more time to be
> tested.

Built and tested OK on FreeBSD 10 again, this time without assertions.  
Uploaded:

SHA256 (clang+llvm-3.9.0-i386-unknown-freebsd10.tar.xz) = 
16c612019ece5ba1f846740e77c7c1a39b813acb5bcfbfe9f8af32d7c28caa60
SHA256 (clang+llvm-3.9.0-amd64-unknown-freebsd10.tar.xz) = 
df35eaeabec7a474b3c3737c798a0c817795ebbd12952c665c52b2f98abcb6de

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Openmp-dev] [4.0 Release] Schedule and call for testers

[Dimitry Andric via lldb-dev]

On 05 Dec 2016, at 19:26, Hans Wennborg via Openmp-dev 
 wrote:
> 
> There's still plenty of time left, but I'd like to get the schedule
> set before folks start disappearing for the holidays.
> 
> Note that this release will also switch us to the new versioning
> scheme where the major version is incremented for each major release
> (i.e., when the 4.0 branch is created, trunk will become 5.0).

Maybe I didn't pay enough attention, but where is the general outline
for this versioning scheme documented?  And are we still going to do
4.1, 4.2, etc?


> If you'd like to help providing binaries and testing for your
> favourite platform, please subscribe to the release-testers mailing
> list [1].
> 
> I propose the following schedule for the 4.0 release:
> 
> - 12 January 2017: Create the 4.0 branch. RC1 tagged soon thereafter.
> 
> - 1 February: Tag RC2. All lose ends should have been tied up by now.
> 
> - 21 February: Final tag. Binaries and release announcement a few days later.
> 
> Unless there are any objections, I'll post this on the web page soon.

Note that this is a pretty close follow-up to the 3.9.1 release.  There
is a minor risk of "release burn-out" here... :)

Otherwise, LGTM.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [4.0.0 Release] Relase Candidate 1 has been tagged

[Dimitry Andric via lldb-dev]

On 18 Jan 2017, at 16:45, Hans Wennborg via Release-testers 
 wrote:
> Dear testers,
> 
> 4.0.0-rc1 was just tagged from the branch, with r292377.
> 
> There are still open merge requests and bugs, but I'd like to get the
> testing started to see what issues come up.

Unfortunately no builds for FreeBSD yet, as the Phase1 clang segfaults when 
building AsmParser.cpp:

[  1%] Building CXX object 
lib/MC/MCParser/CMakeFiles/LLVMMCParser.dir/AsmParser.cpp.o
cd 
/home/dim/llvm-4.0.0/rc1/Phase2/Release/llvmCore-4.0.0-rc1.obj/lib/MC/MCParser 
&& /home/dim/llvm-4.0
.0/rc1/Phase1/Release/llvmCore-4.0.0-rc1.install/usr/local/bin/clang++   
-DGTEST_HAS_RTTI=0 -D__STDC_CO
NSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-I/home/dim/llvm-4.0.0/rc1/Phase2/Release/ll
vmCore-4.0.0-rc1.obj/lib/MC/MCParser 
-I/home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser -I/home/dim/ll
vm-4.0.0/rc1/Phase2/Release/llvmCore-4.0.0-rc1.obj/include 
-I/home/dim/llvm-4.0.0/rc1/llvm.src/include
-I/usr/local/include  -fPIC -fvisibility-inlines-hidden -Wall -W 
-Wno-unused-parameter -Wwrite-strings
-Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long 
-Wcovered-switch-default -Wnon-virtua
l-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -Werror=date-time 
-std=c++11 -ffunction-sections -
fdata-sections -O3 -DNDEBUG-fno-exceptions -fno-rtti -o 
CMakeFiles/LLVMMCParser.dir/AsmParser.cpp.o
 -c /home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp
/home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp:2043:25: 
warning: variable 'CppHashLocL
ineNo' is uninitialized when used here [-Wuninitialized]
LastQueryLine = CppHashLocLineNo;
^~~~
/home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp:2036:32: note: 
initialize the variable
'CppHashLocLineNo' to silence this warning
  unsigned CppHashLocLineNo;
   ^
= 0
/home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp:2155:71: 
warning: variable 'LineNo' is
uninitialized when used here [-Wuninitialized]
  SMDiagnostic NewDiag(*Diag.getSourceMgr(), Diag.getLoc(), Filename, LineNo,
  ^~
/home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp:2152:13: note: 
initialize the variable
'LineNo' to silence this warning
  int LineNo =
^
 = 0
clang-4.0: error: unable to execute command: Segmentation fault (core dumped)
clang-4.0: error: clang frontend command failed due to signal (use -v to see 
invocation)
clang version 4.0.0 (tags/RELEASE_400/rc1)
Target: i386-unknown-freebsd10.3
Thread model: posix
InstalledDir: 
/home/dim/llvm-4.0.0/rc1/Phase1/Release/llvmCore-4.0.0-rc1.install/usr/local/bin
clang-4.0: note: diagnostic msg: PLEASE submit a bug report to 
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and 
associated run script.
clang-4.0: note: diagnostic msg:


PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-4.0: note: diagnostic msg: /home/dim/tmp/AsmParser-c3ca7e.cpp
clang-4.0: note: diagnostic msg: /home/dim/tmp/AsmParser-c3ca7e.sh
clang-4.0: note: diagnostic msg:


gmake[2]: *** [lib/MC/MCParser/CMakeFiles/LLVMMCParser.dir/build.make:87: 
lib/MC/MCParser/CMakeFiles/LLVMMCParser.dir/AsmParser.cpp.o] Error 254

I thought this might be because r292133 was not merged yet, but I was wrong 
about that, it *is* merged.

So I will have to investigate why it crashes here.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [4.0.0 Release] Relase Candidate 1 has been tagged

[Dimitry Andric via lldb-dev]

On 19 Jan 2017, at 16:40, Hans Wennborg  wrote:
> 
> On Thu, Jan 19, 2017 at 12:12 AM, Dimitry Andric  wrote:
>> On 18 Jan 2017, at 16:45, Hans Wennborg via Release-testers 
>>  wrote:
>>> Dear testers,
>>> 
>>> 4.0.0-rc1 was just tagged from the branch, with r292377.
>>> 
>>> There are still open merge requests and bugs, but I'd like to get the
>>> testing started to see what issues come up.
>> 
>> Unfortunately no builds for FreeBSD yet, as the Phase1 clang segfaults when 
>> building AsmParser.cpp:
>> 
>> [  1%] Building CXX object 
>> lib/MC/MCParser/CMakeFiles/LLVMMCParser.dir/AsmParser.cpp.o
>> cd 
>> /home/dim/llvm-4.0.0/rc1/Phase2/Release/llvmCore-4.0.0-rc1.obj/lib/MC/MCParser
>>  && /home/dim/llvm-4.0
>> .0/rc1/Phase1/Release/llvmCore-4.0.0-rc1.install/usr/local/bin/clang++   
>> -DGTEST_HAS_RTTI=0 -D__STDC_CO
>> NSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
>> -I/home/dim/llvm-4.0.0/rc1/Phase2/Release/ll
>> vmCore-4.0.0-rc1.obj/lib/MC/MCParser 
>> -I/home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser -I/home/dim/ll
>> vm-4.0.0/rc1/Phase2/Release/llvmCore-4.0.0-rc1.obj/include 
>> -I/home/dim/llvm-4.0.0/rc1/llvm.src/include
>> -I/usr/local/include  -fPIC -fvisibility-inlines-hidden -Wall -W 
>> -Wno-unused-parameter -Wwrite-strings
>> -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long 
>> -Wcovered-switch-default -Wnon-virtua
>> l-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -Werror=date-time 
>> -std=c++11 -ffunction-sections -
>> fdata-sections -O3 -DNDEBUG-fno-exceptions -fno-rtti -o 
>> CMakeFiles/LLVMMCParser.dir/AsmParser.cpp.o
>> -c /home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp
>> /home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp:2043:25: 
>> warning: variable 'CppHashLocL
>> ineNo' is uninitialized when used here [-Wuninitialized]
>>LastQueryLine = CppHashLocLineNo;
>>^~~~
>> /home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp:2036:32: 
>> note: initialize the variable
>> 'CppHashLocLineNo' to silence this warning
>>  unsigned CppHashLocLineNo;
>>   ^
>>= 0
>> /home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp:2155:71: 
>> warning: variable 'LineNo' is
>> uninitialized when used here [-Wuninitialized]
>>  SMDiagnostic NewDiag(*Diag.getSourceMgr(), Diag.getLoc(), Filename, LineNo,
>>  ^~
>> /home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp:2152:13: 
>> note: initialize the variable
>> 'LineNo' to silence this warning
>>  int LineNo =
>>^
>> = 0
>> clang-4.0: error: unable to execute command: Segmentation fault (core dumped)
>> clang-4.0: error: clang frontend command failed due to signal (use -v to see 
>> invocation)
>> clang version 4.0.0 (tags/RELEASE_400/rc1)
>> Target: i386-unknown-freebsd10.3
>> Thread model: posix
>> InstalledDir: 
>> /home/dim/llvm-4.0.0/rc1/Phase1/Release/llvmCore-4.0.0-rc1.install/usr/local/bin
>> clang-4.0: note: diagnostic msg: PLEASE submit a bug report to 
>> http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, 
>> and associated run script.
>> clang-4.0: note: diagnostic msg:
>> 
>> 
>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
>> Preprocessed source(s) and associated run script(s) are located at:
>> clang-4.0: note: diagnostic msg: /home/dim/tmp/AsmParser-c3ca7e.cpp
>> clang-4.0: note: diagnostic msg: /home/dim/tmp/AsmParser-c3ca7e.sh
>> clang-4.0: note: diagnostic msg:
>> 
>> 
>> gmake[2]: *** [lib/MC/MCParser/CMakeFiles/LLVMMCParser.dir/build.make:87: 
>> lib/MC/MCParser/CMakeFiles/LLVMMCParser.dir/AsmParser.cpp.o] Error 254
>> 
>> I thought this might be because r292133 was not merged yet, but I was wrong 
>> about that, it *is* merged.
>> 
>> So I will have to investigate why it crashes here.
> 
> Is this PR31692 that you filed today?

Yes.  It turned out to be an assertion '(it != OpaqueRValues.end() &&
"no mapping for opaque value!"), function getOpaqueRValueMapping', but
Phase2 is built without assertions, so it segfaulted instead.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [4.0.0 Release] Release Candidate 2 has been tagged

[Dimitry Andric via lldb-dev]

On 9 Feb 2017, at 01:33, Hans Wennborg via Release-testers 
 wrote:
> 
> 4.0.0-rc2 was just tagged from the branch at r294535.

Building on FreeBSD 10 at least didn't crash this time, and lld built just 
fine. :)  I uploaded the following:

SHA256 (clang+llvm-4.0.0-rc2-i386-unknown-freebsd10.tar.xz) = 
0725eed8060a1a9983432a547a51c78e155584575120e449c41bebd80eb64652
SHA256 (clang+llvm-4.0.0-rc2-amd64-unknown-freebsd10.tar.xz) = 
0b71197a3288b4c7c54f12497b4907257eda71d9be0cb26f9497b25539b5a3c3

On i386-freebsd10 there were some interesting test results:


Unexpected Passing Tests (1):
lldb :: Expr/TestCallStdStringFunction.test


Failing Tests (4):
LLVM :: tools/llvm-xray/X86/convert-with-debug-syms.txt
lldb :: Expr/TestCallStopAndContinue.test
lldb :: Expr/TestCallUserAnonTypedef.test
lldb :: Expr/TestCallUserDefinedFunction.test

On amd64-freebsd10 the lldb failures didn't occur, but the 'unexpected passing' 
one did, as did the one xray failure.

The xray failure looks like this:

FAIL: LLVM :: tools/llvm-xray/X86/convert-with-debug-syms.txt (31351 of 33866)
 TEST 'LLVM :: 
tools/llvm-xray/X86/convert-with-debug-syms.txt' FAILED 
Script:
--
/home/dim/llvm-4.0.0/rc2/Phase3/Release/llvmCore-4.0.0-rc2.obj/./bin/llvm-xray 
convert -m 
/home/dim/llvm-4.0.0/rc2/llvm.src/test/tools/llvm-xray/X86/Inputs/elf64-sample-o2.bin
 -y 
/home/dim/llvm-4.0.0/rc2/llvm.src/test/tools/llvm-xray/X86/Inputs/naive-log-simple.xray
 -f=yaml -o - 2>&1 | /home/dim/llvm-4.0.0/rc2/Phase3/Release/llvmCore-4.0
.0-rc2.obj/./bin/FileCheck 
/home/dim/llvm-4.0.0/rc2/llvm.src/test/tools/llvm-xray/X86/convert-with-debug-syms.txt
--
Exit Code: 1

Command Output (stderr):
--
/home/dim/llvm-4.0.0/rc2/llvm.src/test/tools/llvm-xray/X86/convert-with-debug-syms.txt:13:15:
 error: expected string not found in input
; CHECK-NEXT: - { type: 0, func-id: 2, function: {{.*foo.*}}, cpu: 37, thread: 
84697, kind: function-enter,
  ^
:11:2: note: scanning from here
 - { type: 0, func-id: 2, function: 'foo(void)', cpu: 37, thread: 84697,
 ^
:19:2: note: possible intended match here
 - { type: 0, func-id: 3, function: main, cpu: 37, thread: 84697, kind: 
function-exit,
 ^

--



The lldb test failures look like this:

FAIL: lldb :: Expr/TestCallUserAnonTypedef.test (32116 of 32394)
 TEST 'lldb :: Expr/TestCallUserAnonTypedef.test' FAILED 

Script:
--
/home/dim/llvm-4.0.0/rc2/Phase2/Release/llvmCore-4.0.0-rc2.install/usr/local/bin/clang++
 
/home/dim/llvm-4.0.0/rc2/llvm.src/tools/lldb/lit/Expr/Inputs/anonymous-struct.cpp
 -g -o 
/home/dim/llvm-4.0.0/rc2/Phase3/Release/llvmCore-4.0.0-rc2.obj/tools/lldb/lit/Expr/Output/TestCallUserAnonTypedef.test.tmp
 && /home/dim/llvm-4.0.0/rc2/Phase3/Release/llvmCore-4.0.0-rc2.obj/./bin/lldb 
-b -s 
/home/dim/llvm-4.0.0/rc2/llvm.src/tools/lldb/lit/Expr/TestCallUserAnonTypedef.test
 -- 
/home/dim/llvm-4.0.0/rc2/Phase3/Release/llvmCore-4.0.0-rc2.obj/tools/lldb/lit/Expr/Output/TestCallUserAnonTypedef.test.tmp
 | 
/home/dim/llvm-4.0.0/rc2/Phase3/Release/llvmCore-4.0.0-rc2.obj/./bin/FileCheck 
/home/dim/llvm-4.0.0/rc2/llvm.src/tools/lldb/lit/Expr/TestCallUserAnonTypedef.test
--
Exit Code: 1

Command Output (stderr):
--
error: Can't run the expression locally: Interpreter doesn't handle one of the 
expression's opcodes
/home/dim/llvm-4.0.0/rc2/llvm.src/tools/lldb/lit/Expr/TestCallUserAnonTypedef.test:11:10:
 error: expected string not found in input
# CHECK: $0 = 1
 ^
:1:1: note: scanning from here
(lldb) target create 
"/home/dim/llvm-4.0.0/rc2/Phase3/Release/llvmCore-4.0.0-rc2.obj/tools/lldb/lit/Expr/Output/TestCallUserAnonTypedef.test.tmp"
^
:10:18: note: possible intended match here
Breakpoint 1: where = TestCallUserAnonTypedef.test.tmp`main + 55 at 
anonymous-struct.cpp:25, address = 0x080486b7
 ^

--



FAIL: lldb :: Expr/TestCallUserDefinedFunction.test (32117 of 32394)
 TEST 'lldb :: Expr/TestCallUserDefinedFunction.test' 
FAILED 
Script:
--
/home/dim/llvm-4.0.0/rc2/Phase2/Release/llvmCore-4.0.0-rc2.install/usr/local/bin/clang++
 /home/dim/llvm-4.0.0/rc2/llvm.src/tools/lldb/lit/Expr/Inputs/call-function.cpp 
-g -o 
/home/dim/llvm-4.0.0/rc2/Phase3/Release/llvmCore-4.0.0-rc2.obj/tools/lldb/lit/Expr/Output/TestCallUserDefinedFunction.test.tmp
 && /home/dim/llvm-4.0.0/rc2/Phase3/Release/llvmCore-4.0.0-rc2.obj/./bin/lldb 
-b -s 
/home/dim/llvm-4.0.0/rc2/llvm.src/tools/lldb/lit/Expr/TestCallUserDefinedFunction.test
 -- 
/home/dim/llvm-4.0.0/rc2/Phase3/Release/llvmCore-4.0.0-rc2.obj/tools/lldb/lit/Expr/Output/TestCallUserDefinedFunction.test.tmp
 | 
/home/dim/llvm-4.0.0/rc2/Phase3/Release/llvmCore-4.0.0-rc2.obj/./bin/FileCheck 
/home/dim/llvm-4.0.0/rc2/llvm.src/tools/lldb/lit/Expr/TestCallUserDefinedFunction.test
--
Exit Code: 1

Command Output (stderr):
--
error: Can't run the e

Re: [lldb-dev] [Release-testers] [4.0.0 Release] Release Candidate 3 has been tagged

[Dimitry Andric via lldb-dev]

On 2 Mar 2017, at 20:47, Hans Wennborg via Release-testers 
 wrote:
> 4.0.0-rc3 was just tagged from the branch at r296762.
> 
> This is a release candidate in the real sense: if no major issues show
> up with this one, it is the version that will be released.
> 
> Please let me know if you find any issues, including in release notes
> or documentation, which will be on the pre-release web site later
> today.
> 
> Please build, test, and upload binaries to the sftp and I'll publish
> them when they're ready.

Built and tested as expected on FreeBSD 10.  I have uploaded the following:

SHA256 (clang+llvm-4.0.0-rc3-amd64-unknown-freebsd10.tar.xz) = 
95d0ad58d546e15f6bb3f275840c774311e05268f9fa45fd5b460f4dea7e91ce
SHA256 (clang+llvm-4.0.0-rc3-i386-unknown-freebsd10.tar.xz) = 
1b160ea41da08f6605b212a6cbf9b3fa373623c5dde54a04d20a5398a1548122

In other news, I have imported branches/release_40 r296509 (almost identical to 
this rc3) into FreeBSD 12-CURRENT yesterday:

https://svnweb.freebsd.org/changeset/base/314564

This also includes lld, and an option to link the FreeBSD base system with it.

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [4.0.0 Release] Release Candidate 3 has been tagged

[Dimitry Andric via lldb-dev]

On 3 Mar 2017, at 21:09, Dimitry Andric via Release-testers 
 wrote:
> 
> On 2 Mar 2017, at 20:47, Hans Wennborg via Release-testers 
>  wrote:
>> 4.0.0-rc3 was just tagged from the branch at r296762.
>> 
>> This is a release candidate in the real sense: if no major issues show
>> up with this one, it is the version that will be released.
>> 
>> Please let me know if you find any issues, including in release notes
>> or documentation, which will be on the pre-release web site later
>> today.
>> 
>> Please build, test, and upload binaries to the sftp and I'll publish
>> them when they're ready.
> 
> Built and tested as expected on FreeBSD 10.  I have uploaded the following:
> 
> SHA256 (clang+llvm-4.0.0-rc3-amd64-unknown-freebsd10.tar.xz) = 
> 95d0ad58d546e15f6bb3f275840c774311e05268f9fa45fd5b460f4dea7e91ce
> SHA256 (clang+llvm-4.0.0-rc3-i386-unknown-freebsd10.tar.xz) = 
> 1b160ea41da08f6605b212a6cbf9b3fa373623c5dde54a04d20a5398a1548122
> 
> In other news, I have imported branches/release_40 r296509 (almost identical 
> to this rc3) into FreeBSD 12-CURRENT yesterday:
> 
> https://svnweb.freebsd.org/changeset/base/314564

Unfortunately I got reports of some source files resulting in excessive compile 
times, which was apparently caused by r287232:

https://bugs.llvm.org/show_bug.cgi?id=32142

I will most likely reverted r287232 locally, but it would be good to have some 
more eyes (and test cases) on that commit...

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [4.0.0 Release] Release Candidate 4 has been tagged

[Dimitry Andric via lldb-dev]

> On 7 Mar 2017, at 22:15, Hans Wennborg via Release-testers 
>  wrote:
> 
> Dear testers,
> 
> 4.0.0-rc4 was just tagged from the branch at r297204.
> 
> This is very similar to rc3, with additional fixes for PR32142 and PR32153.
> 
> Please take it for a quick spin. If nothing new comes up, this is what
> the final release will look like.

Built and tested on FreeBSD 10 without surprises.  I have uploaded:

SHA256 (clang+llvm-4.0.0-rc4-i386-unknown-freebsd10.tar.xz) = 
a0d441c4003d7ab252148ffe37301f468942e1295084c8fe23753ce5a18615cc
SHA256 (clang+llvm-4.0.0-rc4-amd64-unknown-freebsd10.tar.xz) = 
d641a5bba15d8f10f9f04a48734a443ec70b40b57cc29dd3d3a600c6ef2ba540

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [4.0.0 Release] 'final' has been tagged

[Dimitry Andric via lldb-dev]

On 9 Mar 2017, at 01:52, Hans Wennborg via Release-testers 
 wrote:
> The final version of 4.0.0 was just tagged (from the 4.0 branch at
> r297335). There were no changes after rc4.
> 
> Please build the final binaries and upload to the sftp.

Built and tested OK on FreeBSD 10.  I have uploaded:

SHA256 (clang+llvm-4.0.0-i386-unknown-freebsd10.tar.xz) = 
f3bfd0e4778d5e6b94f774e4531a61a662c7688e08b54cef5e5fc53711e65243
SHA256 (clang+llvm-4.0.0-amd64-unknown-freebsd10.tar.xz) = 
e8878b589c2558aeb9733661e9a23fd47d41be0dc200aa50acf7a7eb1ab53eee

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [5.0.0 Release] Release Candidate 1 tagged

[Dimitry Andric via lldb-dev]

On 27 Jul 2017, at 00:41, Hans Wennborg via cfe-dev  
wrote:
> 
> 5.0.0-rc1 has just been tagged.
> 
> Please build, test and upload binaries to the sftp. Let me know if
> there are any issues.

Built and tested rc1.  Test failures on amd64-freebsd10:

FAIL: LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/DummyRPC.TestClearHandlers 
(1346 of 38616)
FAIL: AddressSanitizer-Unit :: 
./Asan-i386-inline-Test/AddressSanitizer.DoubleFreeTest (2480 of 38616)
FAIL: AddressSanitizer-Unit :: 
./Asan-i386-inline-Test/AddressSanitizer.ReallocFreedPointerTest (2505 of 38616)
FAIL: AddressSanitizer-Unit :: 
./Asan-i386-inline-Test/AddressSanitizer.UseThenFreeThenUseTest (2542 of 38616)
FAIL: AddressSanitizer-Unit :: 
./Asan-i386-inline-Test/AddressSanitizer.WrongFreeTest (2546 of 38616)
FAIL: AddressSanitizer-Unit :: 
./Asan-i386-with-calls-Test/AddressSanitizer.DoubleFreeTest (2589 of 38616)
FAIL: AddressSanitizer-Unit :: 
./Asan-i386-with-calls-Test/AddressSanitizer.ReallocFreedPointerTest (2615 of 
38616)
FAIL: AddressSanitizer-Unit :: 
./Asan-i386-with-calls-Test/AddressSanitizer.UseThenFreeThenUseTest (2651 of 
38616)
FAIL: AddressSanitizer-Unit :: 
./Asan-i386-with-calls-Test/AddressSanitizer.WrongFreeTest (2655 of 38616)
FAIL: AddressSanitizer-Unit :: 
./Asan-x86_64-inline-Test/AddressSanitizer.DoubleFreeTest (2698 of 38616)
FAIL: AddressSanitizer-Unit :: 
./Asan-x86_64-inline-Test/AddressSanitizer.ReallocFreedPointerTest (2723 of 
38616)
FAIL: AddressSanitizer-Unit :: 
./Asan-x86_64-inline-Test/AddressSanitizer.UseThenFreeThenUseTest (2762 of 
38616)
FAIL: AddressSanitizer-Unit :: 
./Asan-x86_64-inline-Test/AddressSanitizer.WrongFreeTest (2765 of 38616)
FAIL: AddressSanitizer-Unit :: 
./Asan-x86_64-with-calls-Test/AddressSanitizer.DoubleFreeTest (2808 of 38616)
FAIL: AddressSanitizer-Unit :: 
./Asan-x86_64-with-calls-Test/AddressSanitizer.ReallocFreedPointerTest (2833 of 
38616)
FAIL: AddressSanitizer-Unit :: 
./Asan-x86_64-with-calls-Test/AddressSanitizer.UseThenFreeThenUseTest (2870 of 
38616)
FAIL: AddressSanitizer-Unit :: 
./Asan-x86_64-with-calls-Test/AddressSanitizer.WrongFreeTest (2875 of 38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/asan-sigbus.cpp (2998 of 
38616)
FAIL: AddressSanitizer-i386-freebsd :: 
TestCases/Posix/asan-symbolize-sanity-test.cc (3000 of 38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/closed-fds.cc (3001 of 
38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/deep_thread_stack.cc 
(3005 of 38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/fread_fwrite.cc (3007 of 
38616)
FAIL: AddressSanitizer-i386-freebsd :: 
TestCases/Posix/interception-in-shared-lib-test.cc (3019 of 38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/shared-lib-test.cc (3029 
of 38616)
FAIL: AddressSanitizer-i386-freebsd :: 
TestCases/Posix/stack-use-after-return.cc (3030 of 38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/strndup_oob_test.cc 
(3035 of 38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/wait.cc (3037 of 38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/wait3.cc (3038 of 38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/wait4.cc (3040 of 38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/waitid.cc (3139 of 38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/alloca_big_alignment.cc (3140 
of 38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/alloca_detect_custom_size_.cc 
(3142 of 38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/alloca_overflow_partial.cc 
(3144 of 38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/alloca_overflow_right.cc (3146 
of 38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/alloca_underflow_left.cc (3148 
of 38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/debug_double_free.cc (3163 of 
38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/debug_stacks.cc (3167 of 38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/debug_report.cc (3168 of 38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/deep_stack_uaf.cc (3170 of 
38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/describe_address.cc (3172 of 
38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/double-free.cc (3173 of 38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/frexp_interceptor.cc (3178 of 
38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/global-overflow.cc (3180 of 
38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/heap-overflow.cc (3184 of 
38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/heavy_uar_test.cc (3185 of 
38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/initialization-bug.cc (3188 of 
38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/invalid-free.cc (3195 of 38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/invalid-pointer-pairs.cc (3197 
of 38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/large_func_test.cc (3198 of 
38616)
FAIL: AddressSanitizer-i386-freebsd :: TestCases/null_dere

Re: [lldb-dev] [cfe-dev] [5.0.0 Release] Release Candidate 1 tagged

[Dimitry Andric via lldb-dev]

On 31 Jul 2017, at 19:26, Hans Wennborg  wrote:
> 
> On Sat, Jul 29, 2017 at 4:59 AM, Dimitry Andric  wrote:
>> On 27 Jul 2017, at 00:41, Hans Wennborg via cfe-dev  
>> wrote:
>>> 
>>> 5.0.0-rc1 has just been tagged.
>>> 
>>> Please build, test and upload binaries to the sftp. Let me know if
>>> there are any issues.
>> 
>> Built and tested rc1.  Test failures on amd64-freebsd10:
>> 
>> FAIL: LLVM-Unit :: 
>> ExecutionEngine/Orc/./OrcJITTests/DummyRPC.TestClearHandlers (1346 of 38616)
>> FAIL: AddressSanitizer-Unit :: 
>> ./Asan-i386-inline-Test/AddressSanitizer.DoubleFreeTest (2480 of 38616)
>> FAIL: AddressSanitizer-Unit :: 
>> ./Asan-i386-inline-Test/AddressSanitizer.ReallocFreedPointerTest (2505 of 
>> 38616)
>> FAIL: AddressSanitizer-Unit :: 
>> ./Asan-i386-inline-Test/AddressSanitizer.UseThenFreeThenUseTest (2542 of 
>> 38616)
>> FAIL: AddressSanitizer-Unit :: 
>> ./Asan-i386-inline-Test/AddressSanitizer.WrongFreeTest (2546 of 38616)
...
> Do we know what's up with all of these ASan failures? Is there a bug for it?

I spent a limited amount of debugging on it, but the common problem is that on 
i386 (aka 32-bit x86) all programs compiled with -fsanitize=address now die 
with:

==11122==AddressSanitizer CHECK failed: 
/usr/src/contrib/compiler-rt/lib/asan/asan_poisoning.cc:36 
"((AddrIsAlignedByGranularity(addr))) != (0)" (0x0, 0x0)
#0 0x806f163 in __asan::AsanCheckFailed(char const*, int, char const, 
unsigned long long, unsigned long long) (/share/dim/src/misc/hw+0x806f163)
#1 0x805dce3 in __sanitizer::CheckFailed(char const*, int, char const, 
unsigned long long, unsigned long long) (/share/dim/src/misc/hw+0x805dce3)
#2 0x80dfc65 in __asan::PoisonShadow(unsigned long, unsigned long, unsigned 
char) (/share/dim/src/misc/hw+0x80dfc65)
#3 0x80696dd in __asan::AsanThread::Init(void) 
(/share/dim/src/misc/hw+0x80696dd)
#4 0x806997f in __asan::AsanThread::ThreadStart(unsigned long, 
__sanitizer::atomic_uintptr_t*) (/share/dim/src/misc/hw+0x806997f)
#5 0x806ecf3 in __asan::AsanInitInternal(void) 
(/share/dim/src/misc/hw+0x806ecf3)
#6 0x8092785 in clock_gettime (/share/dim/src/misc/hw+0x8092785)

When I put some printfs in there, it showed that the expected address 
granularity is 8, but the address to be checked was aligned on 4 bytes:

DBG: addr=0x284429f4, granularity=8

Tracing back the definitions, I found:

#define SHADOW_GRANULARITY (1ULL << SHADOW_SCALE)

then:

#define SHADOW_SCALE kDefaultShadowScale


then:

static const u64 kDefaultShadowScale = 3;

So this seems to be hardcoded.  There is a similar declaration in llvm's 
lib/Transforms/Instrumentation/AddressSanitizer.cpp.

I know that it *did* work at some point in the past, but it got broken in 
recent history.  I will have to do some archeology to figure out what happened.

Does anybody know whether the shadow granularity was different at some point?

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [cfe-dev] [5.0.0 Release] Release Candidate 1 tagged

[Dimitry Andric via lldb-dev]

On 31 Jul 2017, at 20:13, Dimitry Andric via Release-testers 
 wrote:
> 
> On 31 Jul 2017, at 19:26, Hans Wennborg  wrote:
>> 
>> On Sat, Jul 29, 2017 at 4:59 AM, Dimitry Andric  wrote:
>>> On 27 Jul 2017, at 00:41, Hans Wennborg via cfe-dev 
>>>  wrote:
 
 5.0.0-rc1 has just been tagged.
 
 Please build, test and upload binaries to the sftp. Let me know if
 there are any issues.
>>> 
>>> Built and tested rc1.  Test failures on amd64-freebsd10:
>>> 
>>> FAIL: LLVM-Unit :: 
>>> ExecutionEngine/Orc/./OrcJITTests/DummyRPC.TestClearHandlers (1346 of 38616)
>>> FAIL: AddressSanitizer-Unit :: 
>>> ./Asan-i386-inline-Test/AddressSanitizer.DoubleFreeTest (2480 of 38616)
>>> FAIL: AddressSanitizer-Unit :: 
>>> ./Asan-i386-inline-Test/AddressSanitizer.ReallocFreedPointerTest (2505 of 
>>> 38616)
>>> FAIL: AddressSanitizer-Unit :: 
>>> ./Asan-i386-inline-Test/AddressSanitizer.UseThenFreeThenUseTest (2542 of 
>>> 38616)
>>> FAIL: AddressSanitizer-Unit :: 
>>> ./Asan-i386-inline-Test/AddressSanitizer.WrongFreeTest (2546 of 38616)
> ...
>> Do we know what's up with all of these ASan failures? Is there a bug for it?
> 
> I spent a limited amount of debugging on it, but the common problem is that 
> on i386 (aka 32-bit x86) all programs compiled with -fsanitize=address now 
> die with:
> 
> ==11122==AddressSanitizer CHECK failed: 
> /usr/src/contrib/compiler-rt/lib/asan/asan_poisoning.cc:36 
> "((AddrIsAlignedByGranularity(addr))) != (0)" (0x0, 0x0)
...
> I know that it *did* work at some point in the past, but it got broken in 
> recent history.  I will have to do some archeology to figure out what 
> happened.
> 
> Does anybody know whether the shadow granularity was different at some point?

Ok, some further research showed that I have been conflating two different 
issues here.

The first issue is that FreeBSD 12-CURRENT recently received an update to 
jemalloc, our default memory allocator, in 
https://reviews.freebsd.org/rS319971.  For some reason, this causes an 
alignment problem now when ASan is initializing.  E.g. exactly the same ASan 
test case works as expected on FreeBSD 10 and 11, but on 12 it results in:

==22338==AddressSanitizer CHECK failed: 
/home/dim/llvm-4.0.1/final/llvm.src/projects/compiler-rt/lib/asan/asan_poisoning.cc:36
 "((AddrIsAlignedByGranularity(addr))) != (0)" (0x0, 0x0)
#0 0x80b5960 in __asan::AsanCheckFailed(char const*, int, char const, 
unsigned long long, unsigned long long) 
/home/dim/llvm-4.0.1/final/llvm.src/projects/compiler-rt/lib/asan/asan_rtl.cc:69:3
#1 0x80c754a in __sanitizer::CheckFailed(char const*, int, char const, 
unsigned long long, unsigned long long) 
/home/dim/llvm-4.0.1/final/llvm.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_termination.cc:79:5
#2 0x80af5e8 in __asan::PoisonShadow(unsigned long, unsigned long, 
unsigned char) 
/home/dim/llvm-4.0.1/final/llvm.src/projects/compiler-rt/lib/asan/asan_poisoning.cc:36:3
#3 0x80b74e7 in ClearShadowForThreadStackAndTLS 
/home/dim/llvm-4.0.1/final/llvm.src/projects/compiler-rt/lib/asan/asan_thread.cc:285:5
#4 0x80b74e7 in __asan::AsanThread::Init(void) 
/home/dim/llvm-4.0.1/final/llvm.src/projects/compiler-rt/lib/asan/asan_thread.cc:232
#5 0x80b768d in __asan::AsanThread::ThreadStart(unsigned long, 
__sanitizer::atomic_uintptr_t*) 
/home/dim/llvm-4.0.1/final/llvm.src/projects/compiler-rt/lib/asan/asan_thread.cc:241:3
#6 0x80b55dc in __asan::AsanInitInternal(void) 
/home/dim/llvm-4.0.1/final/llvm.src/projects/compiler-rt/lib/asan/asan_rtl.cc:591:16
#7 0x807a648 in clock_gettime 
/home/dim/llvm-4.0.1/final/llvm.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:1882:3

While this is pretty unfortunate, it is not really a problem with the 5.0.0 
release, since it also happens with ASan-instrumented executables compiled by 
earlier versions of clang.

The other issue, which I encountered while building 5.0.0 rc1 on FreeBSD 10, is 
in compiler-rt itself.  It's apparently being caused by 
https://reviews.llvm.org/rL305058 ("Fix ASan internal failure in 
AllocateFromLocalPool"), meant to address PR 33206.  Before this commit, on 
FreeBSD 10, I got just two ASan-related failures (both of which are pretty old, 
I think):

Failing Tests (5):
AddressSanitizer-i386-freebsd :: TestCases/Posix/asan-sigbus.cpp
AddressSanitizer-i386-freebsd :: TestCases/Posix/fread_fwrite.cc
LLVM :: Bindings/Go/go.test
LLVM :: DebugInfo/PDB/pdbdump-debug-subsections.test
LLVM :: tools/llvm-objdump/X86/macho-literals.test

After r305058, that ballooned to 55 ASan-related failures:

Failing Tests (58):
AddressSanitizer-Unit :: 
Asan-i386-inline-Test/AddressSanitizer.DoubleFreeTest
AddressSanitizer-Unit :: 
Asan-i386-inline-Test/AddressSanitizer.ReallocFreedPointerTest
AddressSanitizer-Unit :: 
Asan-i386-inline-Test/AddressSanitizer.UseThenFreeThenUseTest

Re: [lldb-dev] [Release-testers] [5.0.0 Release] Release Candidate 2 tagged

[Dimitry Andric via lldb-dev]

On 11 Aug 2017, at 04:00, Hans Wennborg via Release-testers 
 wrote:
> 5.0.0-rc2 was just tagged.
> 
> I know we still have a bunch of open release blockers, but there has
> been a lot of merged patches and I'd like to find out what the status
> is.

As in the last rc, most of the ASan tests failed with either:

[  DEATH   ] ==5754==AddressSanitizer CHECK failed: 
/home/dim/llvm-5.0.0/rc2/llvm.src/projects/compiler-rt/lib/asan/asan_errors.h:99
 "((second_free_stack->size)) > ((0))" (0x0, 0x0)

or:

[  DEATH   ] ==7514==AddressSanitizer CHECK failed: 
/home/dim/llvm-5.0.0/rc2/llvm.src/projects/compiler-rt/lib/asan/asan_descriptions.cc:176
 "((id)) != (0)" (0x0, 0x0)

This is likely due to r305058, as mentioned in my report for rc1.

I could not upload my tarballs, since the upload disk appears to be full:

sftp> df -h
Size UsedAvail   (root)%Capacity
   7.7GB7.3GB192KB425MB  94%

So I have uploaded them to my own server, here:

http://www.andric.com/freebsd/clang/clang+llvm-5.0.0-rc2-amd64-unknown-freebsd10.tar.xz
http://www.andric.com/freebsd/clang/clang+llvm-5.0.0-rc2-i386-unknown-freebsd10.tar.xz

SHA256 (clang+llvm-5.0.0-rc2-amd64-unknown-freebsd10.tar.xz) = 
8e27a2fe43785eff1927100c59bee3d662c3e75f28adf87cb8ce31253a5dd67f
SHA256 (clang+llvm-5.0.0-rc2-i386-unknown-freebsd10.tar.xz) = 
421ccd60c22c751711fca0169f5c7461ef537a110e86c91d619e7d2f5b0452c5

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [5.0.0 Release] Release Candidate 2 tagged

[Dimitry Andric via lldb-dev]

On 24 Aug 2017, at 23:48, Hans Wennborg  wrote:
> 
> On Mon, Aug 14, 2017 at 3:36 AM, Dimitry Andric  wrote:
>> On 11 Aug 2017, at 04:00, Hans Wennborg via Release-testers 
>>  wrote:
>>> 5.0.0-rc2 was just tagged.
>>> 
>>> I know we still have a bunch of open release blockers, but there has
>>> been a lot of merged patches and I'd like to find out what the status
>>> is.
>> 
>> As in the last rc, most of the ASan tests failed with either:
>> 
>> [  DEATH   ] ==5754==AddressSanitizer CHECK failed: 
>> /home/dim/llvm-5.0.0/rc2/llvm.src/projects/compiler-rt/lib/asan/asan_errors.h:99
>>  "((second_free_stack->size)) > ((0))" (0x0, 0x0)
>> 
>> or:
>> 
>> [  DEATH   ] ==7514==AddressSanitizer CHECK failed: 
>> /home/dim/llvm-5.0.0/rc2/llvm.src/projects/compiler-rt/lib/asan/asan_descriptions.cc:176
>>  "((id)) != (0)" (0x0, 0x0)
>> 
>> This is likely due to r305058, as mentioned in my report for rc1.
> 
> Was there ever any progress on this, or at least a bug report filed?

No progress, but I just filed https://bugs.llvm.org/show_bug.cgi?id=34324 so it 
hopefully won't get lost.


> Do you think it's just the tests that are failing, or does it mean
> ASan is broken on FreeBSD? How severe is this issue from your
> perspective?

It looks like the tests are failing, but simple programs compiled with 
-fsanitize=address seem to work.  I haven't tested it extensively, though.

I'm not completely happy with the situation, as we also have some major 
problems with AddressSanitizer on FreeBSD 12.0 (though this isn't the fault of 
compiler-rt).  But there's no need to block the release for this.

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [5.0.0 Release] Release Candidate 3 tagged

[Dimitry Andric via lldb-dev]

On 26 Aug 2017, at 00:52, Hans Wennborg via Release-testers 
 wrote:
> 
> 5.0.0-rc3 was just tagged.
> 
> This is a release candidate in the real sense: if nothing bad comes up
> in testing, this is what the release is going to look like.

Built and tested, no changes with respect to the previous rc.  I've uploaded:

SHA256 (clang+llvm-5.0.0-rc3-amd64-unknown-freebsd10.tar.xz) = 
510d8689239a1b83a154e8ee0230765d0f9054ca534c3a9ed4a2d4e31d8f9704
SHA256 (clang+llvm-5.0.0-rc3-i386-unknown-freebsd10.tar.xz) = 
65b21c280575dcf16449c4c051b14f9950ff5f5d0a43b59852a0e1c65a1f145c

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [5.0.0 Release] Release Candidate 4 tagged

[Dimitry Andric via lldb-dev]

On 30 Aug 2017, at 01:52, Hans Wennborg via Release-testers 
 wrote:
> 
> 5.0.0-rc4 was just tagged.
> 
> There were very few changes after rc3, and if nothing unexpected comes
> up, this is what the final release will look like.

Built and tested on FreeBSD 10, no changes with respect to the previous rc.  
I've uploaded:

SHA256 (clang+llvm-5.0.0-rc4-amd64-unknown-freebsd10.tar.xz) = 
d00277dbbaec71e89fcd12b92ff3d1a69af42b1d4c47a9315a46a9e4b2c656c9
SHA256 (clang+llvm-5.0.0-rc4-i386-unknown-freebsd10.tar.xz) = 
5515f0e03ba4098873b39b3fac99060a622254d86d3a3b04d3b5f90df8aad9c7

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [5.0.0 Release] Release Candidate 5 tagged

[Dimitry Andric via lldb-dev]

On 1 Sep 2017, at 23:07, Hans Wennborg via Release-testers 
 wrote:
> 
> 5.0.0-rc5 was just tagged.
> 
> I had hoped rc4 would be the last one, but I think we needed the fix
> for PR34381.

Built and tested on FreeBSD 10, no changes with respect to the previous rc.  
I've uploaded:

SHA256 (clang+llvm-5.0.0-rc5-amd64-unknown-freebsd10.tar.xz) = 
c10eae93c15ce3f00405fcf9e1c596f91b8f4c1f64b65b426648b07b1e842e9e
SHA256 (clang+llvm-5.0.0-rc5-i386-unknown-freebsd10.tar.xz) = 
0b7f2e18aa1c07b72581dd23fbe3945a4c756f3ee224cd9e3c2dcc56227654dd

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [5.0.0 Release] The final tag is in

[Dimitry Andric via lldb-dev]

On 5 Sep 2017, at 20:24, Hans Wennborg via Release-testers 
 wrote:
> 
> The final version of 5.0.0 has just been tagged. There were no changes
> after rc5.

Built and tested on FreeBSD 10, and uploaded:

SHA256 (clang+llvm-5.0.0-amd64-unknown-freebsd10.tar.xz) = 
e55b646390da0a24e27f9761eecf0b31936483c9a3e84c12de0bb1a0d95bab6c
SHA256 (clang+llvm-5.0.0-i386-unknown-freebsd10.tar.xz) = 
2ea32ad7cd30d8e849113747b5bfda8e6eb0fb2f9b01cbe9eb61e884c0bd69eb

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [6.0.0 Release] Scheduling the release

[Dimitry Andric via lldb-dev]

On 6 Dec 2017, at 18:28, Hans Wennborg via cfe-dev  
wrote:
> 
> It's time to start making plans for the 6.0.0 release.
> 
> Following our regular schedule, the branch would occur about two weeks
> into January, on Wednesday 17 January 2018, with the goal of shipping
> early March. This is the schedule I would propose.
> 
> However, one large consumer of the branch has asked if we could start
> earlier this time, branching on 3 January instead (not moving the ship
> date), to get a longer period for stabilization that syncs with their
> internal process.

I have a few remarks.

1) We are still busy with the 5.0.1 release, and this next (major)
branching is pretty soon afterwards.  Please make sure not to burn out
your testers. :)

2) I would really like some sort of stabilization to take place *before*
major branching occurs.  (In FreeBSD land, we call this the "slush"
period.)  By now, it should be well-known when such major branching
happens, e.g. somewhere at the start of the year, and somewhere in the
middle.

So people should start stabilizing, say, one or two months in advance of
that.  Which means to postpone huge restructuring efforts, or adding big
new untested features, but concentrate on fixing bugs, ensuring test
cases succeed on all platforms, and generally getting the tree in "good
shape".

It would be nice if the release manager(s) sent a reminder about this
well in advance of the actual branch date, explicitly mentioning the
desire to stabilize.  Maybe mails like this could be used for such
reminders.

Having said all that, for me branching earlier is not a problem.  For
corporate contributors it would maybe be a bit soon after the holiday
season... :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [6.0.0 Release] Release Candidate 1 tagged

[Dimitry Andric via lldb-dev]

On 17 Jan 2018, at 18:53, Hans Wennborg via cfe-dev  
wrote:
> 
> Start your engines; 6.0.0-rc1 was just tagged.
> 
> I know there are still open blockers and it's early in the process in
> a way, but I'd like to find out where we are.

For an overview of what failed in the FreeBSD ports collection, with a 6.0.0 
snapshot corresponding to trunk r321545, see here:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224669

Roughly 24,000 ports were built, 500 failed, and those caused ~4,400 other 
ports not to be built.

A number of crashes were already reported on the LLVM bugtracker, and some 
other important packages were already fixed.  But all is definitely not clear 
yet. :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [6.0.0 Release] Release Candidate 1 tagged

[Dimitry Andric via lldb-dev]

On 17 Jan 2018, at 18:53, Hans Wennborg via Release-testers 
 wrote:
> Start your engines; 6.0.0-rc1 was just tagged.
> 
> I know there are still open blockers and it's early in the process in
> a way, but I'd like to find out where we are. Please run the test
> script, let me know the results, and upload binaries.

At the moment I can't compile openmp, since it errors out on libomptarget:

/home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:50:10:
 error: use of undeclared identifier 'malloc'
rc = malloc(size);
 ^
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:76:5:
 error: use of undeclared identifier 'free'
free(device_ptr);
^
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:163:20:
 error: use of undeclared identifier 'malloc'
void *buffer = malloc(length);
   ^

I'm trying a local fix here, namely including  at the top of the file.

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [Release-testers] [6.0.0 Release] Release Candidate 1 tagged

[Dimitry Andric via lldb-dev]

On 18 Jan 2018, at 15:03, Jonas Hahnfeld  wrote:
> 
> Am 2018-01-18 14:55, schrieb Dimitry Andric via llvm-dev:
>> On 17 Jan 2018, at 18:53, Hans Wennborg via Release-testers
>>  wrote:
>>> Start your engines; 6.0.0-rc1 was just tagged.
>>> I know there are still open blockers and it's early in the process in
>>> a way, but I'd like to find out where we are. Please run the test
>>> script, let me know the results, and upload binaries.
>> At the moment I can't compile openmp, since it errors out on libomptarget:
>> /home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:50:10:
>> error: use of undeclared identifier 'malloc'
>>rc = malloc(size);
>> ^
>> /home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:76:5:
>> error: use of undeclared identifier 'free'
>>free(device_ptr);
>>^
>> /home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:163:20:
>> error: use of undeclared identifier 'malloc'
>>void *buffer = malloc(length);
>>   ^
>> I'm trying a local fix here, namely including  at the top of the 
>> file.
> 
> Argh, I have missed that header. Adding  sounds like the right 
> solution, can you submit a patch or directly commit to SVN if it works for 
> you?

I added  to api.cpp, interface.cpp and rtl.cpp, in r322869.  Hans, 
could you please merge it to release_60, or shall I do it?

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Apple LLDB 900.0.64 crash

[Dimitry Andric via lldb-dev]

Hi Johan,

If it is Apple specific, create a report on the Apple Bug Reporter, at 
https://bugreport.apple.com/ .

If you can reproduce the error with stock lldb, please report it on the LLVM 
bugtracker, at https://bugs.llvm.org/enter_bug.cgi 
.

-Dimitry

> On 18 Jan 2018, at 15:08, Johan Øverbye via lldb-dev 
>  wrote:
> 
> Hi :)
> 
> I hope this is an appropriate use of this mailing list, my apologies if not. 
> I couldn't find any form to report LLDB bugs and wasn't sure where to ask.
> 
> With a recent update of Xcode I started getting an LLDB crash frequently 
> while attempting to debug. (Not sure exactly which Xcode release sadly.) 
> Sometimes it occurs when the debugger pauses execution (e.g. due to an 
> assertion failure), other times when I attempt to inspect certain variables.
> 
> Here's the call stack of the offending thread:
> 
> Thread 7 Crashed:: RPC packet thread for client tid 7997 (31127)
> 0   com.apple.LLDB.framework  0x000108f98157 
> clang::ClassTemplateSpecializationDecl::Create(clang::ASTContext&, 
> clang::TagTypeKind, clang::DeclContext*, clang::SourceLocation, 
> clang::SourceLocation, clang::ClassTemplateDecl*, 
> llvm::ArrayRef, 
> clang::ClassTemplateSpecializationDecl*) + 71
> 1   com.apple.LLDB.framework  0x00010a6fc39c 
> lldb_private::ClangASTContext::CreateClassTemplateSpecializationDecl(clang::DeclContext*,
>  clang::ClassTemplateDecl*, int, 
> lldb_private::ClangASTContext::TemplateParameterInfos const&) + 308
> 2   com.apple.LLDB.framework  0x00010a546de4 
> DWARFASTParserClang::ParseTypeFromDWARF(lldb_private::SymbolContext const&, 
> DWARFDIE const&, lldb_private::Log*, bool*) + 5890
> 3   com.apple.LLDB.framework  0x00010a6e2623 
> SymbolFileDWARF::ParseType(lldb_private::SymbolContext const&, DWARFDIE 
> const&, bool*) + 171
> 4   com.apple.LLDB.framework  0x00010a6dc33f 
> SymbolFileDWARF::GetTypeForDIE(DWARFDIE const&, bool) + 369
> 5   com.apple.LLDB.framework  0x00010a6dbc6e 
> SymbolFileDWARF::ResolveType(DWARFDIE const&, bool, bool) + 68
> 6   com.apple.LLDB.framework  0x00010a6dbbed 
> SymbolFileDWARF::ResolveTypeUID(unsigned long long) + 45
> 7   com.apple.LLDB.framework  0x00010a759942 
> lldb_private::Type::ResolveClangType(lldb_private::Type::ResolveStateTag) + 
> 154
> 8   com.apple.LLDB.framework  0x00010a759604 
> lldb_private::Type::GetForwardCompilerType() + 26
> 9   com.apple.LLDB.framework  0x00010a59be5f 
> lldb_private::ValueObjectVariable::GetCompilerTypeImpl() + 37
> 10  com.apple.LLDB.framework  0x00010a58cf67 
> lldb_private::ValueObject::MaybeCalculateCompleteType() + 39
> 11  com.apple.LLDB.framework  0x00010a5912dd 
> lldb_private::ValueObject::GetObjectRuntimeLanguage() + 33
> 12  com.apple.LLDB.framework  0x00010a59167b 
> lldb_private::ValueObject::IsRuntimeSupportValue() + 73
> 13  com.apple.LLDB.framework  0x000107c5faec 
> lldb::SBFrame::GetVariables(lldb::SBVariablesOptions const&) + 624
> 14  com.apple.LLDB.framework  0x000107c5fda4 
> lldb::SBFrame::GetVariables(bool, bool, bool, bool, lldb::DynamicValueType) + 
> 208
> 15  lldb-rpc-server   0x000106220aef 
> rpc_server::_ZN4lldb7SBFrame12GetVariablesENS_16DynamicValueTypeE::HandleRPCCall(rpc_common::Connection&,
>  rpc_common::RPCStream&, rpc_common::RPCStream&) + 219
> 16  lldb-rpc-server   0x0001061e662a 
> rpc_common::Connection::PrivateHandleRPCPacket(rpc_common::RPCPacket&, 
> rpc_common::RPCPacket&, bool&) + 506
> 17  lldb-rpc-server   0x0001061e730c 
> rpc_common::Connection::HandleRPCPacket(rpc_common::RPCPacket&) + 62
> 18  lldb-rpc-server   0x0001061ea862 
> Packets::ProcessPackets() + 254
> 19  lldb-rpc-server   0x0001061ea68b 
> Packets::ReadThread() + 187
> 20  lldb-rpc-server   0x0001061ea5cb 
> Packets::RunReadThread(void*) + 9
> 21  libsystem_pthread.dylib   0x7fff7b8906c1 _pthread_body + 340
> 22  libsystem_pthread.dylib   0x7fff7b89056d _pthread_start + 377
> 23  libsystem_pthread.dylib   0x7fff7b88fc5d thread_start + 13
> 
> The full LLDB crash dump can be downloaded here: 
> https://www.dropbox.com/s/87tpcb31t10679z/lldb-rpc-server_2018-01-18-134410_Johans-MacBook-Pro.crash?dl=0
>  
> 
> 
> The (Apple) LLDB version is lldb-900.0.64. Not sure whether/how this 
> corresponds to "official" LLDB version numbers.
> 
> Unfortunately I'm unable to share the code for confidentiality reasons. I'll 
> attempt to isolate the issue but I thought I'd ask here in case it's a known 
> issue or the cause is obvious.
> 
> 
> Thanks,
> 
> Johan Øverbye
> 
> This m

Re: [lldb-dev] [Release-testers] [6.0.0 Release] Release Candidate 1 tagged

[Dimitry Andric via lldb-dev]

On 17 Jan 2018, at 18:53, Hans Wennborg via Release-testers 
 wrote:
> 
> Start your engines; 6.0.0-rc1 was just tagged.
> 
> I know there are still open blockers and it's early in the process in
> a way, but I'd like to find out where we are. Please run the test
> script, let me know the results, and upload binaries.

Another problem I'm running into is that check-all fails with a Python 
ValueError.  The last part of the log is (this is just after most stuff has 
been built, and lit is starting up):

[100%] Running all regression tests
llvm-lit: /home/dim/llvm-6.0.0/rc1/llvm.src/projects/libunwind/test/lit.cfg:58: 
note: Using configuration variant: libunwind
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:307:
 note: inferred use_system_cxx_lib as: None
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:313:
 note: inferred with_availability as: False
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:345:
 note: inferred use_clang_verify as: True
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:355:
 note: enabling thread-safety annotations
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:535:
 note: inferred language dialect as: c++2a
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:436:
 note: inferred long_tests as: True
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:156:
 note: Using compiler: 
/home/dim/llvm-6.0.0/rc1/Phase2/Release/llvmCore-6.0.0-rc1.install/usr/local/bin/clang++
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:157:
 note: Using flags: ['-v', '-D_LIBCPP_DISABLE_AVAILABILITY', 
'-ftemplate-depth=270']
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:162:
 note: Using compile flags: ['-Werror=thread-safety', '-DLIBUNWIND_NO_TIMER', 
'-fno-exceptions', '-DLIBUNWIND_HAS_NO_EXCEPTIONS', '-funwind-tables', 
'-std=c++2a', '-I/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libunwind/include', 
'-Itest/support']
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:164:
 note: Using warnings: ['-D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER', '-Wall', 
'-Wextra', '-Werror', '-Wuser-defined-warnings', '-Wshadow', 
'-Wno-unused-command-line-argument', '-Wno-attributes', 
'-Wno-pessimizing-move', '-Wno-c++11-extensions', '-Wno-user-defined-literals', 
'-Wno-noexcept-type', '-Wno-aligned-allocation-unavailable', '-Wsign-compare', 
'-Wunused-variable', '-Wunused-parameter', '-Wunreachable-code', 
'-Wno-conversion', '-Wno-unused-local-typedef', '-Wno-#warnings']
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:165:
 note: Using link flags: 
['-L/home/dim/llvm-6.0.0/rc1/Phase3/Release/llvmCore-6.0.0-rc1.obj/./lib', 
'-Wl,-rpath,/home/dim/llvm-6.0.0/rc1/Phase3/Release/llvmCore-6.0.0-rc1.obj/./lib',
 '-nodefaultlibs', '-lc++', '-lc++abi', '-lc', '-lm', '-lpthread', '-lgcc_s', 
'-lcxxrt']
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:168:
 note: Using available_features: ['libc++', 'verify-support', 'clang-6', 
'modules-support', 'locale.en_US.UTF-8', 'diagnose-if-support', 'long_tests', 
'fdelayed-template-parsing', '-faligned-allocation', 'c++2a', 
'locale.fr_CA.ISO8859-1', 'clang', 'locale.fr_FR.UTF-8', 
'libcxxabi-no-exceptions', 'locale.ru_RU.UTF-8', 'fsized-deallocation', 
'locale.zh_CN.UTF-8', 'freebsd10', 'fcoroutines-ts', 'locale.cs_CZ.ISO8859-2', 
'clang-6.0', 'thread-safety']
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:173:
 note: Adding environment variables: {}
llvm-lit: /home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/test/lit.cfg:45: 
note: Using configuration variant: libcxx
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:307:
 note: inferred use_system_cxx_lib as: None
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:313:
 note: inferred with_availability as: False
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:345:
 note: inferred use_clang_verify as: True
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:355:
 note: enabling thread-safety annotations
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:535:
 note: inferred language dialect as: c++2a
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:436:
 note: inferred long_tests as: True
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:156:
 note: Using compiler: 
/home/dim/llvm-6.0.0/rc1/Phase2/Release/llvmCore-6.0.0-rc1.install/usr/local/bin/clang++
llvm-l

Re: [lldb-dev] [llvm-dev] [Release-testers] [6.0.0 Release] Release Candidate 1 tagged

[Dimitry Andric via lldb-dev]

On 19 Jan 2018, at 17:11, Hans Wennborg  wrote:
> 
> On Thu, Jan 18, 2018 at 7:27 PM, Dimitry Andric  wrote:
>> On 18 Jan 2018, at 15:03, Jonas Hahnfeld  wrote:
>>> 
>>> Am 2018-01-18 14:55, schrieb Dimitry Andric via llvm-dev:
 On 17 Jan 2018, at 18:53, Hans Wennborg via Release-testers
  wrote:
> Start your engines; 6.0.0-rc1 was just tagged.
> I know there are still open blockers and it's early in the process in
> a way, but I'd like to find out where we are. Please run the test
> script, let me know the results, and upload binaries.
 At the moment I can't compile openmp, since it errors out on libomptarget:
 /home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:50:10:
 error: use of undeclared identifier 'malloc'
   rc = malloc(size);
^
 /home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:76:5:
 error: use of undeclared identifier 'free'
   free(device_ptr);
   ^
 /home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:163:20:
 error: use of undeclared identifier 'malloc'
   void *buffer = malloc(length);
  ^
 I'm trying a local fix here, namely including  at the top of the 
 file.
>>> 
>>> Argh, I have missed that header. Adding  sounds like the right 
>>> solution, can you submit a patch or directly commit to SVN if it works for 
>>> you?
>> 
>> I added  to api.cpp, interface.cpp and rtl.cpp, in r322869.  Hans, 
>> could you please merge it to release_60, or shall I do it?
> 
> Go ahead if you're set up, otherwise let me know and I'll do it.

Done in r323037.  I have also taken the liberty of merging r322875 and r322879, 
in which I added a '-no-libcxxabi' option to the test-release.sh script.

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [llvm-dev] [6.0.0 Release] Release Candidate 1 tagged

[Dimitry Andric via lldb-dev]

On 20 Jan 2018, at 13:32, Dimitry Andric via Release-testers 
 wrote:
> 
> On 19 Jan 2018, at 17:11, Hans Wennborg  wrote:
>> 
>> On Thu, Jan 18, 2018 at 7:27 PM, Dimitry Andric  wrote:
>>> On 18 Jan 2018, at 15:03, Jonas Hahnfeld  wrote:
 
 Am 2018-01-18 14:55, schrieb Dimitry Andric via llvm-dev:
> On 17 Jan 2018, at 18:53, Hans Wennborg via Release-testers
>  wrote:
>> Start your engines; 6.0.0-rc1 was just tagged.
>> I know there are still open blockers and it's early in the process in
>> a way, but I'd like to find out where we are. Please run the test
>> script, let me know the results, and upload binaries.
...

So, I finally managed to produce some tarballs, and uploaded them:

SHA256 (clang+llvm-6.0.0-rc1-amd64-unknown-freebsd10.tar.xz) = 
d93427fd2b8f5aa0d5278f1bd3020add07b8316ff8a512a203bf3c41639d7baf
SHA256 (clang+llvm-6.0.0-rc1-i386-unknown-freebsd10.tar.xz) = 
9f283235fb10242b9f79527c0d895260e6efa1c1bb761c57396490c7ccd5f5f0

This was an interesting round of testing, since I attempted to build the 'libs' 
part for the first time, and things like libcxx, polly etc are also included.  
I had to apply several patches, one of which was to be able to disable 
libc++abi, which we can't link against yet on FreeBSD.

During the build of the test-suite, I encountered several instances of link 
jobs failing due to the addition of -ldl, which does not exist on FreeBSD.  It 
is really a Linuxism, for which I will commit a few fixes.  In addition, some 
test-suite programs fail to link on FreeBSD 10.x, since it does not yet have 
__cpu_model in the base system's copy of libcompiler-rt.  I solved that with a 
local hack.

On amd64-freebsd10 there were 895 test failures:


Testing Time: 9904.87s

[...]
  Expected Passes: 44958
  Expected Failures  : 185
  Unsupported Tests  : 2938
  Unexpected Failures: 895

On i386-freebsd10 there were 1773 test failures:


Testing Time: 23871.89s

[...]
  Expected Passes: 42648
  Expected Failures  : 194
  Unsupported Tests  : 1953
  Unexpected Failures: 1773

Of these, a great many were in libc++, mostly due to 
-Wtautological-type-limit-compare errors, and "exception_ptr not yet 
implemented" errors.  Also all the dynamic address sanitizer tests failed due 
to -lpthread not being passed to the linker, but it is a problem I have not 
been able to solve.

If anybody is interested in the full error reports, I can upload them 
somewhere; just let me know.

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [6.0.0 Release] Release Candidate 2 tagged

[Dimitry Andric via lldb-dev]

On 7 Feb 2018, at 21:51, Hans Wennborg via Release-testers 
 wrote:
> 
> There's been a lot of merges since rc1, and hopefully the tests are in
> a better state now.
> 
> 6.0.0-rc2 was just tagged, after r324506.
> 
> Please test, let me know how it goes, and upload binaries.

Built, tested and uploaded:

SHA256 (clang+llvm-6.0.0-rc2-amd64-unknown-freebsd10.tar.xz) = 
1334db5949ec0c78cd6e9b798f0b397fe9e99240d98bcfc834e4410258b98372
SHA256 (clang+llvm-6.0.0-rc2-i386-unknown-freebsd10.tar.xz) = 
a7c0b1e4cfe3d608ee77472c7f17fe6b9493c7259aca80fcdd3b8a4fe49ad92d

On amd64-freebsd10 there were 896 unexpected test failures:

  Expected Passes: 45004
  Expected Failures  : 186
  Unsupported Tests  : 2939
  Unexpected Failures: 896

On i386-freebsd10 there were 619 unexpected test failures:

  Expected Passes: 43849
  Expected Failures  : 195
  Unsupported Tests  : 1954
  Unexpected Failures: 619

At least the i386 version looks quite a bit better, down from 1773 to 619 test 
failures. :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [6.0.0 Release] Release Candidate 2 tagged

[Dimitry Andric via lldb-dev]

> On 9 Feb 2018, at 10:20, Hans Wennborg  wrote:
> 
> On Thu, Feb 8, 2018 at 10:43 PM, Dimitry Andric  wrote:
>> On 7 Feb 2018, at 21:51, Hans Wennborg via Release-testers 
>>  wrote:
>>> 
>>> There's been a lot of merges since rc1, and hopefully the tests are in
>>> a better state now.
>>> 
>>> 6.0.0-rc2 was just tagged, after r324506.
>>> 
>>> Please test, let me know how it goes, and upload binaries.
>> 
>> Built, tested and uploaded:
>> 
>> SHA256 (clang+llvm-6.0.0-rc2-amd64-unknown-freebsd10.tar.xz) = 
>> 1334db5949ec0c78cd6e9b798f0b397fe9e99240d98bcfc834e4410258b98372
>> SHA256 (clang+llvm-6.0.0-rc2-i386-unknown-freebsd10.tar.xz) = 
>> a7c0b1e4cfe3d608ee77472c7f17fe6b9493c7259aca80fcdd3b8a4fe49ad92d
>> 
>> On amd64-freebsd10 there were 896 unexpected test failures:
>> 
>>  Expected Passes: 45004
>>  Expected Failures  : 186
>>  Unsupported Tests  : 2939
>>  Unexpected Failures: 896
>> 
>> On i386-freebsd10 there were 619 unexpected test failures:
>> 
>>  Expected Passes: 43849
>>  Expected Failures  : 195
>>  Unsupported Tests  : 1954
>>  Unexpected Failures: 619
>> 
>> At least the i386 version looks quite a bit better, down from 1773 to 619 
>> test failures. :)
> 
> What are all these test failures? Does it seems like they have a
> common root cause and do we have a bug for it?

There are multiple issues, some of which might be easily fixable, others have 
been there since a long time, and might be harder to fix.

A full overview of the failures on amd64:


Testing Time: 7907.21s

Failing Tests (896):
LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/DummyRPC.TestClearHandlers
AddressSanitizer-Unit :: 
./Asan-i386-calls-Test/AddressSanitizer.DoubleFreeTest
AddressSanitizer-Unit :: 
./Asan-i386-calls-Test/AddressSanitizer.ReallocFreedPointerTest
AddressSanitizer-Unit :: 
./Asan-i386-calls-Test/AddressSanitizer.UseThenFreeThenUseTest
AddressSanitizer-Unit :: 
./Asan-i386-calls-Test/AddressSanitizer.WrongFreeTest
AddressSanitizer-Unit :: 
./Asan-i386-inline-Test/AddressSanitizer.DoubleFreeTest
AddressSanitizer-Unit :: 
./Asan-i386-inline-Test/AddressSanitizer.ReallocFreedPointerTest
AddressSanitizer-Unit :: 
./Asan-i386-inline-Test/AddressSanitizer.UseThenFreeThenUseTest
AddressSanitizer-Unit :: 
./Asan-i386-inline-Test/AddressSanitizer.WrongFreeTest
AddressSanitizer-Unit :: 
./Asan-x86_64-calls-Dynamic-Test/AddressSanitizer.DoubleFreeTest
AddressSanitizer-Unit :: 
./Asan-x86_64-calls-Dynamic-Test/AddressSanitizer.LongJmpTest
AddressSanitizer-Unit :: 
./Asan-x86_64-calls-Dynamic-Test/AddressSanitizer.ReallocFreedPointerTest
AddressSanitizer-Unit :: 
./Asan-x86_64-calls-Dynamic-Test/AddressSanitizer.SigLongJmpTest
AddressSanitizer-Unit :: 
./Asan-x86_64-calls-Dynamic-Test/AddressSanitizer.UnderscopeLongJmpTest
AddressSanitizer-Unit :: 
./Asan-x86_64-calls-Dynamic-Test/AddressSanitizer.UseThenFreeThenUseTest
AddressSanitizer-Unit :: 
./Asan-x86_64-calls-Dynamic-Test/AddressSanitizer.WrongFreeTest
AddressSanitizer-Unit :: 
./Asan-x86_64-calls-Dynamic-Test/AddressSanitizerInterface.HandleNoReturnTest
AddressSanitizer-Unit :: 
./Asan-x86_64-calls-Test/AddressSanitizer.DoubleFreeTest
AddressSanitizer-Unit :: 
./Asan-x86_64-calls-Test/AddressSanitizer.LongJmpTest
AddressSanitizer-Unit :: 
./Asan-x86_64-calls-Test/AddressSanitizer.ReallocFreedPointerTest
AddressSanitizer-Unit :: 
./Asan-x86_64-calls-Test/AddressSanitizer.SigLongJmpTest
AddressSanitizer-Unit :: 
./Asan-x86_64-calls-Test/AddressSanitizer.UnderscopeLongJmpTest
AddressSanitizer-Unit :: 
./Asan-x86_64-calls-Test/AddressSanitizer.UseThenFreeThenUseTest
AddressSanitizer-Unit :: 
./Asan-x86_64-calls-Test/AddressSanitizer.WrongFreeTest
AddressSanitizer-Unit :: 
./Asan-x86_64-calls-Test/AddressSanitizerInterface.HandleNoReturnTest
AddressSanitizer-Unit :: 
./Asan-x86_64-inline-Dynamic-Test/AddressSanitizer.DoubleFreeTest
AddressSanitizer-Unit :: 
./Asan-x86_64-inline-Dynamic-Test/AddressSanitizer.ReallocFreedPointerTest
AddressSanitizer-Unit :: 
./Asan-x86_64-inline-Dynamic-Test/AddressSanitizer.UseThenFreeThenUseTest
AddressSanitizer-Unit :: 
./Asan-x86_64-inline-Dynamic-Test/AddressSanitizer.WrongFreeTest
AddressSanitizer-Unit :: 
./Asan-x86_64-inline-Dynamic-Test/AddressSanitizerInterface.HandleNoReturnTest
AddressSanitizer-Unit :: 
./Asan-x86_64-inline-Test/AddressSanitizer.DoubleFreeTest
AddressSanitizer-Unit :: 
./Asan-x86_64-inline-Test/AddressSanitizer.ReallocFreedPointerTest
AddressSanitizer-Unit :: 
./Asan-x86_64-inline-Test/AddressSanitizer.UseThenFreeThenUseTest
AddressSanitizer-Unit :: 
./Asan-x86_64-inline-Test/AddressSanitizer.WrongFreeTest
AddressSanitizer-Unit :: 
./Asan-x86_64-inline-Test/AddressSanitizerInterface.HandleNoReturnTest
AddressSanitizer-i386-freebsd :: TestCases/Posix/asan-sigbus.cpp
AddressSanitizer-i386-freebsd :: 
TestCases/Pos

Re: [lldb-dev] [cfe-dev] [Release-testers] [6.0.0 Release] Release Candidate 2 tagged

[Dimitry Andric via lldb-dev]

On 9 Feb 2018, at 20:40, Dimitry Andric via cfe-dev  
wrote:
> 
>> On 9 Feb 2018, at 10:20, Hans Wennborg  wrote:
...
>> What are all these test failures? Does it seems like they have a
>> common root cause and do we have a bug for it?
...
> The Clang Tools and Extra Tools Unit tests all appear to crash with:
> 
>exception_ptr not yet implemented

This turns out to be caused by libc++ being compiled without -DLIBCXXRT.  (In 
the FreeBSD base system build, we always add this option, so libc++ knows how 
to handle exceptions.)

In the libc++ CMakeFiles, it appears to be governed by LIBCXX_CXX_ABI_LIBNAME, 
but it isn't being set to the correct value of "cxxrt" on FreeBSD.  I am going 
to try the following diff:

--- llvm.src/projects/libcxx/CMakeLists.txt
+++ llvm.src/projects/libcxx/CMakeLists.txt
@@ -135,6 +135,8 @@
   elseif (APPLE)
 set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
 set(LIBCXX_CXX_ABI_SYSTEM 1)
+  elseif (CMAKE_SYSTEM_NAME MATCHES "FreeBSD")
+set(LIBCXX_CXX_ABI_LIBNAME "libcxxrt")
   else()
 set(LIBCXX_CXX_ABI_LIBNAME "default")
   endif()

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Openmp-dev] [cfe-dev] [Release-testers] [6.0.0 Release] Release Candidate 2 tagged

[Dimitry Andric via lldb-dev]

On 9 Feb 2018, at 22:11, Dimitry Andric via Openmp-dev 
 wrote:
> 
> On 9 Feb 2018, at 20:40, Dimitry Andric via cfe-dev  
> wrote:
>> 
>>> On 9 Feb 2018, at 10:20, Hans Wennborg  wrote:
> ...
>>> What are all these test failures? Does it seems like they have a
>>> common root cause and do we have a bug for it?
> ...
>> The Clang Tools and Extra Tools Unit tests all appear to crash with:
>> 
>>   exception_ptr not yet implemented
> 
> This turns out to be caused by libc++ being compiled without -DLIBCXXRT.  (In 
> the FreeBSD base system build, we always add this option, so libc++ knows how 
> to handle exceptions.)
> 
> In the libc++ CMakeFiles, it appears to be governed by 
> LIBCXX_CXX_ABI_LIBNAME, but it isn't being set to the correct value of 
> "cxxrt" on FreeBSD.  I am going to try the following diff:
> 
> --- llvm.src/projects/libcxx/CMakeLists.txt
> +++ llvm.src/projects/libcxx/CMakeLists.txt
> @@ -135,6 +135,8 @@
>   elseif (APPLE)
> set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
> set(LIBCXX_CXX_ABI_SYSTEM 1)
> +  elseif (CMAKE_SYSTEM_NAME MATCHES "FreeBSD")
> +set(LIBCXX_CXX_ABI_LIBNAME "libcxxrt")
>   else()
> set(LIBCXX_CXX_ABI_LIBNAME "default")
>   endif()

... and unfortunately that didn't work, since the CMakeFiles are unable to find 
the libcxxrt headers:

CMake Warning at projects/libcxx/cmake/Modules/HandleLibCXXABI.cmake:67 
(message):
  Failed to find cxxabi.h
Call Stack (most recent call first):
  projects/libcxx/cmake/Modules/HandleLibCXXABI.cmake:112 (setup_abi_lib)
  projects/libcxx/CMakeLists.txt:428 (include)


CMake Warning at projects/libcxx/cmake/Modules/HandleLibCXXABI.cmake:67 
(message):
  Failed to find unwind.h
Call Stack (most recent call first):
  projects/libcxx/cmake/Modules/HandleLibCXXABI.cmake:112 (setup_abi_lib)
  projects/libcxx/CMakeLists.txt:428 (include)


CMake Warning at projects/libcxx/cmake/Modules/HandleLibCXXABI.cmake:67 
(message):
  Failed to find unwind-arm.h
Call Stack (most recent call first):
  projects/libcxx/cmake/Modules/HandleLibCXXABI.cmake:112 (setup_abi_lib)
  projects/libcxx/CMakeLists.txt:428 (include)


CMake Warning at projects/libcxx/cmake/Modules/HandleLibCXXABI.cmake:67 
(message):
  Failed to find unwind-itanium.h
Call Stack (most recent call first):
  projects/libcxx/cmake/Modules/HandleLibCXXABI.cmake:112 (setup_abi_lib)
  projects/libcxx/CMakeLists.txt:428 (include)

The problem is that on FreeBSD, these libcxxrt headers are installed into the 
same location as the base system's libc++ headers, which is 
/usr/include/c++/v1, and if I add that to the include path of libc++'s build, 
it will certainly cause conflicts.

Does anybody have a suggestion on how this could be avoided?

-Dimitry





signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Openmp-dev] [cfe-dev] [Release-testers] [6.0.0 Release] Release Candidate 2 tagged

[Dimitry Andric via lldb-dev]

On 9 Feb 2018, at 22:30, Dimitry Andric  wrote:
> 
> On 9 Feb 2018, at 22:11, Dimitry Andric via Openmp-dev 
>  wrote:
>> 
>> On 9 Feb 2018, at 20:40, Dimitry Andric via cfe-dev  
>> wrote:
>>> 
 On 9 Feb 2018, at 10:20, Hans Wennborg  wrote:
>> ...
 What are all these test failures? Does it seems like they have a
 common root cause and do we have a bug for it?
>> ...
>>> The Clang Tools and Extra Tools Unit tests all appear to crash with:
>>> 
>>>  exception_ptr not yet implemented
>> 
>> This turns out to be caused by libc++ being compiled without -DLIBCXXRT.  
>> (In the FreeBSD base system build, we always add this option, so libc++ 
>> knows how to handle exceptions.)
>> 
>> In the libc++ CMakeFiles, it appears to be governed by 
>> LIBCXX_CXX_ABI_LIBNAME, but it isn't being set to the correct value of 
>> "cxxrt" on FreeBSD.  I am going to try the following diff:
>> 
>> --- llvm.src/projects/libcxx/CMakeLists.txt
>> +++ llvm.src/projects/libcxx/CMakeLists.txt
>> @@ -135,6 +135,8 @@
>>  elseif (APPLE)
>>set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
>>set(LIBCXX_CXX_ABI_SYSTEM 1)
>> +  elseif (CMAKE_SYSTEM_NAME MATCHES "FreeBSD")
>> +set(LIBCXX_CXX_ABI_LIBNAME "libcxxrt")
>>  else()
>>set(LIBCXX_CXX_ABI_LIBNAME "default")
>>  endif()
> 
> ... and unfortunately that didn't work, since the CMakeFiles are unable to 
> find the libcxxrt headers:
> 
> CMake Warning at projects/libcxx/cmake/Modules/HandleLibCXXABI.cmake:67 
> (message):
>  Failed to find cxxabi.h
> Call Stack (most recent call first):
>  projects/libcxx/cmake/Modules/HandleLibCXXABI.cmake:112 (setup_abi_lib)
>  projects/libcxx/CMakeLists.txt:428 (include)

Ok, this turned out to be easier than I thought.  After applying 
https://reviews.llvm.org/D43166, the number of failed tests drops roughly by 
half (from 896 to 512):

  Expected Passes: 45381
  Expected Failures  : 185
  Unsupported Tests  : 2937
  Unexpected Passes  : 1
  Unexpected Failures: 521

I am going to have a look at some other low hanging fruit, and I have also 
created a few PRs to merge test changes into 6.0.

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Openmp-dev] [6.0.0 Release] Release Candidate 3 tagged

[Dimitry Andric via lldb-dev]

On 23 Feb 2018, at 16:14, Hans Wennborg via Openmp-dev 
 wrote:
> 6.0.0-rc3 was just tagged, after r325901 on the branch.
> 
> There are still a few open blockers, but I'm not sure we'll actually
> end up blocking on all of them. So depending on what comes up, this
> release candidate is probably pretty close to what the final release
> will look like (I'm still hoping for more release notes, though).
> 
> I'm hoping we can get to 'final' sometime next week.
> 
> Please test, let me know how it goes, and upload binaries.

Built, tested and uploaded:

SHA256 (clang+llvm-6.0.0-rc3-amd64-unknown-freebsd-10.tar.xz) = 
210089c6bcce118b3defe4084c4e0a0afa482deec42466ad31f0c8de49296ca7
SHA256 (clang+llvm-6.0.0-rc3-i386-unknown-freebsd-10.tar.xz) = 
b4a3678bc86ab949ebf9845b524408fcf7f825de09f37d2a70fb4447cef3d8e6

On amd64-freebsd10 there were 526 unexpected test failures (down from 896 at 
rc2):

  Expected Passes: 45381
  Passes With Retry  : 4
  Expected Failures  : 185
  Unsupported Tests  : 2937
  Unexpected Passes  : 1
  Unexpected Failures: 526

On i386-freebsd10 there were 250 unexpected test failures (down from 619 at 
rc2):

  Expected Passes: 44223
  Passes With Retry  : 4
  Expected Failures  : 194
  Unsupported Tests  : 1954
  Unexpected Passes  : 1
  Unexpected Failures: 250

In both cases, the "unexpected pass" is lldb :: 
Expr/TestCallStdStringFunction.test, no idea where that came from, though.

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [6.0.0 Release] The final tag is in

[Dimitry Andric via lldb-dev]

On 2 Mar 2018, at 13:17, Hans Wennborg via Release-testers 
 wrote:
> 
> The final version of 6.0.0 has just been tagged from the branch after
> r326550. It has the same contents as -rc3 modulo release notes and one
> small x86 fix (r326393).
> 
> Please build the final binaries and upload to the sftp.

Built, tested and uploaded:

SHA256 (clang+llvm-6.0.0-amd64-unknown-freebsd-10.tar.xz) = 
fee8352f5dee2e38fa2bb80ab0b5ef9efef578cbc6892e5c724a1187498119b7
SHA256 (clang+llvm-6.0.0-i386-unknown-freebsd-10.tar.xz) = 
13414a66b680760171e04f32071396eb6e5a179ff0b5a067d48c4b23744840f1

On amd64-freebsd10 there were 523 unexpected test failures (down from 526 at 
rc3):

  Expected Passes: 45388
  Passes With Retry  : 1
  Expected Failures  : 185
  Unsupported Tests  : 2937
  Unexpected Passes  : 1
  Unexpected Failures: 523

On i386-freebsd10 there were 246 unexpected test failures (down from 250 at 
rc3):

  Expected Passes: 44232
  Expected Failures  : 194
  Unsupported Tests  : 1954
  Unexpected Passes  : 1
  Unexpected Failures: 246

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged

[Dimitry Andric via lldb-dev]

On 3 Aug 2018, at 13:37, Hans Wennborg via Release-testers 
 wrote:
> 
> 7.0.0-rc1 was just tagged (from the branch at r338847).
> 
> It's early in the release process, but I'd like to find out what the
> status is of the branch on our various platforms.
> 
> Please run the test script, share the results, and upload binaries.

Hmm, I'm running into a rather nasty snag now on i386-freebsd11, due to our 
lack of atomic 64 bit primitives; Phase2's configure dies with:

-- Performing Test HAVE_CXX_ATOMICS_WITHOUT_LIB
-- Performing Test HAVE_CXX_ATOMICS_WITHOUT_LIB - Success
-- Performing Test HAVE_CXX_ATOMICS64_WITHOUT_LIB
-- Performing Test HAVE_CXX_ATOMICS64_WITHOUT_LIB - Failed
-- Looking for __atomic_load_8 in atomic
-- Looking for __atomic_load_8 in atomic - not found
CMake Error at cmake/modules/CheckAtomic.cmake:75 (message):
  Host compiler appears to require libatomic, but cannot find it.

Interestingly, Phase1 does *not* suffer from this, but there the "host 
compiler" is clang 6.0.0.

Phase1 CMake output:

Performing C++ SOURCE FILE Test HAVE_CXX_ATOMICS64_WITHOUT_LIB succeeded 
with the following output:
Change Dir: 
/home/dim/llvm/7.0.0/rc1/Phase1/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp

Run Build Command:"/usr/local/bin/gmake" "cmTC_845df/fast"
/usr/local/bin/gmake -f CMakeFiles/cmTC_845df.dir/build.make 
CMakeFiles/cmTC_845df.dir/build
gmake[1]: Entering directory 
'/home/dim/llvm/7.0.0/rc1/Phase1/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp'
Building CXX object CMakeFiles/cmTC_845df.dir/src.cxx.o
/usr/bin/c++-DHAVE_CXX_ATOMICS64_WITHOUT_LIB -std=c++11  
-Werror=unguarded-availability-new   -o CMakeFiles/cmTC_845df.dir/src.cxx.o -c 
/home/dim/llvm/7.0.0/rc1/Phase1/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp/src.cxx
Linking CXX executable cmTC_845df
/usr/local/bin/cmake -E cmake_link_script 
CMakeFiles/cmTC_845df.dir/link.txt --verbose=1
/usr/bin/c++   -DHAVE_CXX_ATOMICS64_WITHOUT_LIB -std=c++11  
-Werror=unguarded-availability-newCMakeFiles/cmTC_845df.dir/src.cxx.o  -o 
cmTC_845df -lm
gmake[1]: Leaving directory 
'/home/dim/llvm/7.0.0/rc1/Phase1/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp'

Source file was:

#include 
#include 
std::atomic x (0);
int main() {
  uint64_t i = x.load(std::memory_order_relaxed);
  return 0;
}

Phase2 CMake output:

Performing C++ SOURCE FILE Test HAVE_CXX_ATOMICS64_WITHOUT_LIB failed with 
the following output:
Change Dir: 
/home/dim/llvm/7.0.0/rc1/Phase2/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp

Run Build Command:"/usr/local/bin/gmake" "cmTC_720f3/fast"
/usr/local/bin/gmake -f CMakeFiles/cmTC_720f3.dir/build.make 
CMakeFiles/cmTC_720f3.dir/build
gmake[1]: Entering directory 
'/home/dim/llvm/7.0.0/rc1/Phase2/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp'
Building CXX object CMakeFiles/cmTC_720f3.dir/src.cxx.o

/home/dim/llvm/7.0.0/rc1/Phase1/Release/llvmCore-7.0.0-rc1.install/usr/local/bin/clang++
-DHAVE_CXX_ATOMICS64_WITHOUT_LIB -std=c++11  
-Werror=unguarded-availability-new   -o CMakeFiles/cmTC_720f3.dir/src.cxx.o -c 
/home/dim/llvm/7.0.0/rc1/Phase2/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp/src.cxx
Linking CXX executable cmTC_720f3
/usr/local/bin/cmake -E cmake_link_script 
CMakeFiles/cmTC_720f3.dir/link.txt --verbose=1

/home/dim/llvm/7.0.0/rc1/Phase1/Release/llvmCore-7.0.0-rc1.install/usr/local/bin/clang++
   -DHAVE_CXX_ATOMICS64_WITHOUT_LIB -std=c++11  
-Werror=unguarded-availability-newCMakeFiles/cmTC_720f3.dir/src.cxx.o  -o 
cmTC_720f3 -lm
CMakeFiles/cmTC_720f3.dir/src.cxx.o: In function `main':
src.cxx:(.text+0x33): undefined reference to `__atomic_load_8'
clang-7: error: linker command failed with exit code 1 (use -v to see 
invocation)
gmake[1]: *** [CMakeFiles/cmTC_720f3.dir/build.make:98: cmTC_720f3] Error 1
gmake[1]: Leaving directory 
'/home/dim/llvm/7.0.0/rc1/Phase2/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp'
gmake: *** [Makefile:126: cmTC_720f3/fast] Error 2

Source file was:

#include 
#include 
std::atomic x (0);
int main() {
  uint64_t i = x.load(std::memory_order_relaxed);
  return 0;
}

Apparently, with clang 6.0 it didn't generate libcalls to atomic functions, but 
just put in cmpxchg8b's, I guess?  And with clang 7.0 this seems to have 
changed.

For now, I can only test on amd64 due to this, since I don't have an easy 
workaround.

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged

[Dimitry Andric via lldb-dev]

On 6 Aug 2018, at 18:23, Hans Wennborg  wrote:
> 
> On Sun, Aug 5, 2018 at 5:49 PM, Dimitry Andric  wrote:
>> On 3 Aug 2018, at 13:37, Hans Wennborg via Release-testers 
>>  wrote:
>>> 
>>> 7.0.0-rc1 was just tagged (from the branch at r338847).
...
> 
>> Hmm, I'm running into a rather nasty snag now on i386-freebsd11, due to our 
>> lack of atomic 64 bit primitives; Phase2's configure dies with:
>> 
>>-- Performing Test HAVE_CXX_ATOMICS_WITHOUT_LIB
>>-- Performing Test HAVE_CXX_ATOMICS_WITHOUT_LIB - Success
>>-- Performing Test HAVE_CXX_ATOMICS64_WITHOUT_LIB
>>-- Performing Test HAVE_CXX_ATOMICS64_WITHOUT_LIB - Failed
>>-- Looking for __atomic_load_8 in atomic
>>-- Looking for __atomic_load_8 in atomic - not found
...
>> Apparently, with clang 6.0 it didn't generate libcalls to atomic functions, 
>> but just put in cmpxchg8b's, I guess?  And with clang 7.0 this seems to have 
>> changed.
...
> Did you file a bug to track this? (Sorry if you already did, I haven't
> read through the list today.)

This is a regression caused by https://reviews.llvm.org/rL323281:


r323281 | wmi | 2018-01-23 23:27:57 + (Tue, 23 Jan 2018) | 12 lines

Adjust MaxAtomicInlineWidth for i386/i486 targets.

This is to fix the bug reported in 
https://bugs.llvm.org/show_bug.cgi?id=34347#c6.
Currently, all  MaxAtomicInlineWidth of x86-32 targets are set to 64. However,
i386 doesn't support any cmpxchg related instructions. i486 only supports 
cmpxchg.
So in this patch MaxAtomicInlineWidth is reset as follows:
For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is supported.
For i486, the MaxAtomicInlineWidth should be 32 because it supports cmpxchg.
For others 32 bits x86 cpu, the MaxAtomicInlineWidth should be 64 because of 
cmpxchg8b.

Differential Revision: https://reviews.llvm.org/D42154


I'm not sure whether we should report this as an LLVM bug though, since
the problem really lies with FreeBSD: we never had proper atomic
libcalls in our libc (at least the 64 bit ones for 32-bit x86), nor a
separate libatomic.

Before r323281, and with all released versions of clang to date, it
actually generated incorrect instructions for the default target CPU,
if you used the triple i386-unknown-freebsd, e.g.:

$ ~/obj/clang-323280/bin/clang -m32 -O2 -S atomic-test.cpp -o -
[...]
pushl   %ebp
movl%esp, %ebp
pushl   %ebx
xorl%eax, %eax
xorl%edx, %edx
xorl%ecx, %ecx
xorl%ebx, %ebx
lockcmpxchg8b   x
xorl%eax, %eax
popl%ebx
popl%ebp
retl

After r323281, this is corrected:

$ ~/obj/clang-323281/bin/clang -m32 -O2 -S atomic-test.cpp -o -
[...]
pushl   %ebp
movl%esp, %ebp
pushl   $0
pushl   $x
calll   __atomic_load_8
addl$8, %esp
xorl%eax, %eax
popl%ebp
retl

Targeting i586 or higher makes the cmpxchg8b come back:

$ ~/obj/clang-323281/bin/clang -m32 -march=i586 -O2 -S atomic-test.cpp -o -
[...]
pushl   %ebp
movl%esp, %ebp
pushl   %ebx
xorl%eax, %eax
xorl%edx, %edx
xorl%ecx, %ecx
xorl%ebx, %ebx
lockcmpxchg8b   x
xorl%eax, %eax
popl%ebx
popl%ebp
retl

I think there are other scenarios where you could cause atomic libcalls
to appear, though, even if you target higher CPUs.

That said, we'll have to at least discuss this in the FreeBSD community,
since I think it is high time it is fixed on *that* side.

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged

[Dimitry Andric via lldb-dev]

On 3 Aug 2018, at 13:37, Hans Wennborg via Release-testers 
 wrote:
> 
> Dear testers,
> 
> 7.0.0-rc1 was just tagged (from the branch at r338847).
> 
> It's early in the release process, but I'd like to find out what the
> status is of the branch on our various platforms.
> 
> Please run the test script, share the results, and upload binaries.

I've built and tested for FreeBSD 11 (a.k.a 11-STABLE) this time, since
FreeBSD 10 will be going EOL pretty soon now.  Uploaded:

SHA256 (clang+llvm-7.0.0-rc1-amd64-unknown-freebsd11.tar.xz) = 
ed3191635be26cced8c75d5e57ff7e559f44b927a64c10d22611d8d912cf6df4

I posted the full test results here:

https://gist.github.com/DimitryAndric/64e9a7805a01e6027e2aaabfcda42bed

Summary:
  Expected Passes: 50388
  Expected Failures  : 233
  Unsupported Tests  : 3687
  Unexpected Passes  : 1
  Unexpected Failures: 2490

The failures are distributed as follows:

  2028 libc++
   205 AddressSanitizer-i386-freebsd-dynamic
   200 AddressSanitizer-x86_64-freebsd-dynamic
20 XRay-Unit
11 MemorySanitizer-Unit
 7 lldb-Suite
 4 libunwind
 3 XRay-x86_64-freebsd
 3 lldb
 2 ThreadSanitizer-x86_64
 2 UBSan-MemorySanitizer-x86_64
 2 libFuzzer
 1 SanitizerCommon-asan-i386-FreeBSD
 1 SanitizerCommon-asan-x86_64-FreeBSD
 1 libomp

Almost all libc++ failures are due to FreeBSD missing timespec_get(),
and this became mandatory with https://reviews.llvm.org/rL338419:

In file included from 
/home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/test/libcxx/containers/unord/next_pow2.pass.cpp:26:
In file included from 
/home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/iostream:38:
In file included from 
/home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/ios:216:
In file included from 
/home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/__locale:18:
In file included from 
/home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/mutex:191:
In file included from 
/home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/__mutex_base:15:
In file included from 
/home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/chrono:795:
/home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/ctime:77:9: error: no 
member named 'timespec_get' in the global namespace; did you mean 'timespec'?
using ::timespec_get;
  ~~^~~~
timespec
/usr/include/sys/_timespec.h:44:8: note: 'timespec' declared here
struct timespec {
   ^

We're tracking this in FreeBSD here: https://bugs.freebsd.org/230400,
but for existing FreeBSD releases this isn't fixable, so we could really
use some sort of workaround in libc++. :-)

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged

[Dimitry Andric via lldb-dev]

On 16 Aug 2018, at 00:51, Joerg Sonnenberger via llvm-dev 
 wrote:
> 
> On Tue, Aug 07, 2018 at 09:49:16PM +0200, Dimitry Andric via llvm-dev wrote:
>> This is a regression caused by https://reviews.llvm.org/rL323281:
>> 
>> 
>> r323281 | wmi | 2018-01-23 23:27:57 + (Tue, 23 Jan 2018) | 12 lines
>> 
>> Adjust MaxAtomicInlineWidth for i386/i486 targets.
>> 
>> This is to fix the bug reported in 
>> https://bugs.llvm.org/show_bug.cgi?id=34347#c6.
>> Currently, all  MaxAtomicInlineWidth of x86-32 targets are set to 64. 
>> However,
>> i386 doesn't support any cmpxchg related instructions. i486 only supports 
>> cmpxchg.
>> So in this patch MaxAtomicInlineWidth is reset as follows:
>> For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is 
>> supported.
>> For i486, the MaxAtomicInlineWidth should be 32 because it supports cmpxchg.
>> For others 32 bits x86 cpu, the MaxAtomicInlineWidth should be 64 because of 
>> cmpxchg8b.
> 
> This seems to be somewhat undesirable. Does *anyone* care about real
> i386 support at this point? NetBSD certainly doesn't and I think we are
> already the odd man for a number of cases like this.

It's also affecting i486, which is still the default -march value on
FreeBSD.  Note that clang has been silently generating cmpxchg8b's for
years now, even for the i486 target, but I have never seen any complaint
about crashes due to this.

So basically everybody is running i586 or higher, in practice...

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged

[Dimitry Andric via lldb-dev]

On 16 Aug 2018, at 00:51, Joerg Sonnenberger via llvm-dev 
 wrote:
> On Tue, Aug 07, 2018 at 09:49:16PM +0200, Dimitry Andric via llvm-dev wrote:
>> This is a regression caused by https://reviews.llvm.org/rL323281:
>> 
>> 
>> r323281 | wmi | 2018-01-23 23:27:57 + (Tue, 23 Jan 2018) | 12 lines
>> 
>> Adjust MaxAtomicInlineWidth for i386/i486 targets.
>> 
>> This is to fix the bug reported in 
>> https://bugs.llvm.org/show_bug.cgi?id=34347#c6.
>> Currently, all  MaxAtomicInlineWidth of x86-32 targets are set to 64. 
>> However,
>> i386 doesn't support any cmpxchg related instructions. i486 only supports 
>> cmpxchg.
>> So in this patch MaxAtomicInlineWidth is reset as follows:
>> For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is 
>> supported.
>> For i486, the MaxAtomicInlineWidth should be 32 because it supports cmpxchg.
>> For others 32 bits x86 cpu, the MaxAtomicInlineWidth should be 64 because of 
>> cmpxchg8b.
> 
> This seems to be somewhat undesirable. Does *anyone* care about real
> i386 support at this point? NetBSD certainly doesn't and I think we are
> already the odd man for a number of cases like this.


Yes, and since this causes quite a number of regressions for us, I would
really prefer this revision to be reverted, at least in the 7.0.0
branch.  I have already reverted it locally in our FreeBSD project
branch for importing llvm/clang 7.0.0.  Hans, what is your opinion about
this?

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged

[Dimitry Andric via lldb-dev]

On 22 Aug 2018, at 05:58, Wei Mi  wrote:
> 
> On Fri, Aug 17, 2018 at 1:27 PM, Dimitry Andric  wrote:
> On 16 Aug 2018, at 00:51, Joerg Sonnenberger via llvm-dev 
>  wrote:
> > On Tue, Aug 07, 2018 at 09:49:16PM +0200, Dimitry Andric via llvm-dev wrote:
> >> This is a regression caused by https://reviews.llvm.org/rL323281:
> >>
> >> 
> >> r323281 | wmi | 2018-01-23 23:27:57 + (Tue, 23 Jan 2018) | 12 lines
> >>
> >> Adjust MaxAtomicInlineWidth for i386/i486 targets.
> >>
> >> This is to fix the bug reported in 
> >> https://bugs.llvm.org/show_bug.cgi?id=34347#c6.
> >> Currently, all  MaxAtomicInlineWidth of x86-32 targets are set to 64. 
> >> However,
> >> i386 doesn't support any cmpxchg related instructions. i486 only supports 
> >> cmpxchg.
> >> So in this patch MaxAtomicInlineWidth is reset as follows:
> >> For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is 
> >> supported.
> >> For i486, the MaxAtomicInlineWidth should be 32 because it supports 
> >> cmpxchg.
> >> For others 32 bits x86 cpu, the MaxAtomicInlineWidth should be 64 because 
> >> of cmpxchg8b.
> >
> > This seems to be somewhat undesirable. Does *anyone* care about real
> > i386 support at this point? NetBSD certainly doesn't and I think we are
> > already the odd man for a number of cases like this.
> 
> 
> Yes, and since this causes quite a number of regressions for us, I would
> really prefer this revision to be reverted, at least in the 7.0.0
> branch.  I have already reverted it locally in our FreeBSD project
> branch for importing llvm/clang 7.0.0.  Hans, what is your opinion about
> this?
> 
> -Dimitry
> 
> 
> Sorry I missed the thread for quite a while. Dimitry, I am very confused 
> because you reported the issue in 
> https://bugs.llvm.org/show_bug.cgi?id=34347#c6, so you want r323281 to be 
> reverted and let llvm to generate cmxchg8b instruction for i486?

Since it's been doing this for a number of years now, I don't think it would be 
bad at all, at least not for FreeBSD.  At least, a lot more effort is needed to 
supply properly working atomic libcalls for 64 bit values on i386.  (They can't 
be implemented without at least a bit of kernel assistance.)

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged

[Dimitry Andric via lldb-dev]

On 22 Aug 2018, at 18:45, Hans Wennborg  wrote:
> 
> On Wed, Aug 22, 2018 at 3:48 AM, Dimitry Andric  wrote:
>> On 22 Aug 2018, at 05:58, Wei Mi  wrote:
>>> 
>>> On Fri, Aug 17, 2018 at 1:27 PM, Dimitry Andric  wrote:
>>> On 16 Aug 2018, at 00:51, Joerg Sonnenberger via llvm-dev 
>>>  wrote:
 On Tue, Aug 07, 2018 at 09:49:16PM +0200, Dimitry Andric via llvm-dev 
 wrote:
> This is a regression caused by https://reviews.llvm.org/rL323281:
> 
> 
> r323281 | wmi | 2018-01-23 23:27:57 + (Tue, 23 Jan 2018) | 12 lines
> 
> Adjust MaxAtomicInlineWidth for i386/i486 targets.
> 
> This is to fix the bug reported in 
> https://bugs.llvm.org/show_bug.cgi?id=34347#c6.
> Currently, all  MaxAtomicInlineWidth of x86-32 targets are set to 64. 
> However,
> i386 doesn't support any cmpxchg related instructions. i486 only supports 
> cmpxchg.
> So in this patch MaxAtomicInlineWidth is reset as follows:
> For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is 
> supported.
> For i486, the MaxAtomicInlineWidth should be 32 because it supports 
> cmpxchg.
> For others 32 bits x86 cpu, the MaxAtomicInlineWidth should be 64 because 
> of cmpxchg8b.
 
 This seems to be somewhat undesirable. Does *anyone* care about real
 i386 support at this point? NetBSD certainly doesn't and I think we are
 already the odd man for a number of cases like this.
>>> 
>>> 
>>> Yes, and since this causes quite a number of regressions for us, I would
>>> really prefer this revision to be reverted, at least in the 7.0.0
>>> branch.  I have already reverted it locally in our FreeBSD project
>>> branch for importing llvm/clang 7.0.0.  Hans, what is your opinion about
>>> this?
>>> 
>>> -Dimitry
>>> 
>>> 
>>> Sorry I missed the thread for quite a while. Dimitry, I am very confused 
>>> because you reported the issue in 
>>> https://bugs.llvm.org/show_bug.cgi?id=34347#c6, so you want r323281 to be 
>>> reverted and let llvm to generate cmxchg8b instruction for i486?
>> 
>> Since it's been doing this for a number of years now, I don't think it would 
>> be bad at all, at least not for FreeBSD.  At least, a lot more effort is 
>> needed to supply properly working atomic libcalls for 64 bit values on i386. 
>>  (They can't be implemented without at least a bit of kernel assistance.)
> 
> According to the release schedule we should tag RC2 today. Do you
> think there's any chance of getting this figured out by today?

Since I'm testing on FreeBSD 11.x, and that will take quite a while to get any 
new changes, I'd say it's safer to revert for now, at least on the branch.  At 
least then I can build and test the RCs on i386-freebsd. :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [7.0.0 Release] rc2 has been tagged

[Dimitry Andric via lldb-dev]

On 23 Aug 2018, at 01:59, Hans Wennborg via Release-testers 
 wrote:
> 
> 7.0.0-rc2 was just tagged (from branch revision r340437).
> 
> There have been a bunch of merges since rc1, and hopefully many of the
> issues with the previous candidate are fixed in this one.

By reverting r323281 locally, on top of rc2, I was now able to build and test 
for i386-freebsd11 too.

Main test results on amd64-freebsd11 look better, roughly 2000 less failures, 
mostly due to the libc++ get_timespec fix:

  Expected Passes: 52409 (rc1: 50388)
  Expected Failures  :   232 (rc1:   233)
  Unsupported Tests  :  3687 (rc1:  3687)
  Unexpected Passes  : 1 (rc1: 1)
  Unexpected Failures:   491 (rc1:  2490)

Test-suite test results on amd64-freebsd11:

  Expected Passes: 845
  Unexpected Failures: 61

Test results on i386-freebsd11:

  Expected Passes: 50186
  Expected Failures  : 226
  Unsupported Tests  : 2502
  Unexpected Failures: 306

Unfortunately the test-suite doesn't build on i386, since quite a few of its 
components requires SSE2, and the build shows many errors like:

/home/dim/llvm/7.0.0/rc2/test-suite.src/Bitcode/Benchmarks/Halide/blur/driver.cpp:37:29:
 error: always_inline function '_mm_set1_epi16' requires target feature 'sse2', 
but would be inlined into function 'blur_fast' that is compiled without support 
for 'sse2'
__m128i one_third = _mm_set1_epi16(21846);
^

Uploaded:

SHA256 (clang+llvm-7.0.0-rc2-amd64-unknown-freebsd11.tar.xz) = 
67cddaea2123bd7674c5f1ab8092cd7fb2b43ab03dd235469d117782595128fa
SHA256 (clang+llvm-7.0.0-rc2-i386-unknown-freebsd11.tar.xz) = 
cfaadd88255fc8f6fd3d425f61d8c8ef67c8776a0d5a4d6acd6da8cef95085bb

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged

[Dimitry Andric via lldb-dev]

On 25 Aug 2018, at 00:51, Hans Wennborg  wrote:
> 
> On Wed, Aug 22, 2018 at 10:33 PM, Dimitry Andric  wrote:
>> On 22 Aug 2018, at 18:45, Hans Wennborg  wrote:
>>> 
>>> On Wed, Aug 22, 2018 at 3:48 AM, Dimitry Andric  wrote:
 On 22 Aug 2018, at 05:58, Wei Mi  wrote:
...
> Sorry I missed the thread for quite a while. Dimitry, I am very confused 
> because you reported the issue in 
> https://bugs.llvm.org/show_bug.cgi?id=34347#c6, so you want r323281 to be 
> reverted and let llvm to generate cmxchg8b instruction for i486?
 
 Since it's been doing this for a number of years now, I don't think it 
 would be bad at all, at least not for FreeBSD.  At least, a lot more 
 effort is needed to supply properly working atomic libcalls for 64 bit 
 values on i386.  (They can't be implemented without at least a bit of 
 kernel assistance.)
>>> 
>>> According to the release schedule we should tag RC2 today. Do you
>>> think there's any chance of getting this figured out by today?
>> 
>> Since I'm testing on FreeBSD 11.x, and that will take quite a while to get 
>> any new changes, I'd say it's safer to revert for now, at least on the 
>> branch.  At least then I can build and test the RCs on i386-freebsd. :)
> 
> I've reverted on trunk in r340666 and merged to the 7.0 branch in
> r340667. Also +Craig fyi for X86.
> 
> Unfortunately this happened after RC2 which was tagged yesterday, but
> perhaps you can do a test run against the tip of the branch, and then
> later RC3 of coures?
> 
> Also, is there a bug filed somewhere to track fixing the FreeBSD side?
> It would be great if we could reinstate this patch again before the
> next release.

I've now filed .

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [7.0.0 Release] rc2 has been tagged

[Dimitry Andric via lldb-dev]

On 27 Aug 2018, at 10:29, Hans Wennborg  wrote:
> 
> On Sat, Aug 25, 2018 at 12:46 PM, Dimitry Andric  wrote:
...
>> Unfortunately the test-suite doesn't build on i386, since quite a few of its 
>> components requires SSE2, and the build shows many errors like:
>> 
>> /home/dim/llvm/7.0.0/rc2/test-suite.src/Bitcode/Benchmarks/Halide/blur/driver.cpp:37:29:
>>  error: always_inline function '_mm_set1_epi16' requires target feature 
>> 'sse2', but would be inlined into function 'blur_fast' that is compiled 
>> without support for 'sse2'
>>__m128i one_third = _mm_set1_epi16(21846);
>>^
> 
> The same problem must have been present also with 6.0.0 right?

Yes, this has apparently always been the case.  I'll make a note to either fix 
it post release, or to selectively skip building those tests for i386.

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [7.0.0 Release] rc3 has been tagged

[Dimitry Andric via lldb-dev]

On 10 Sep 2018, at 16:12, Hans Wennborg via Release-testers 
 wrote:
> 7.0.0-rc3 was just tagged (from branch revision r341805).
> 
> No further release candidates are currently planned, so this is a
> release candidate in the real sense: unless any serious issues
> surface, this is what the final release will look like.

Main test results on amd64-freebsd11 look slightly better, 2 less unexpected 
failures:

  Expected Passes: 52422(rc2: 52409)
  Expected Failures  :   232(rc2:   232)
  Unsupported Tests  :  3687(rc2:  3687)
  Unexpected Passes  : 1(rc2: 1)
  Unexpected Failures:   489(rc2:   491)

Test-suite test results on amd64-freebsd11 are also better, 58 less unexpected 
failures:

  Expected Passes:   903(rc2:   845)
  Unexpected Failures: 3(rc2:61)

Test results on i386-freebsd11 were slightly worse, due to a bunch of hanging 
lldb single step tests (these all seem to hang in the STOP state indefinitely, 
and so had to be killed off):

  Expected Passes: 50226(rc2: 50186)
  Expected Failures  :   226(rc2:   226)
  Unsupported Tests  :  2502(rc2:  2502)
  Unexpected Failures:   277(rc2:   306)

The test-suite still doesn't build on i386-freebsd, but that is a known issue.

I have uploaded:

SHA256 (clang+llvm-7.0.0-rc3-amd64-unknown-freebsd11.tar.xz) = 
1b5d72f94e4f18713393ad0ce4f1509ee13b8b41fde114e9a18b2247e2a740cb
SHA256 (clang+llvm-7.0.0-rc3-i386-unknown-freebsd11.tar.xz) = 
4e09e6a9d06982ba35b6e213d74498c9b46b01bfd044728d6f81de50791dbd4a

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [7.0.0 Release] The final tag is in

[Dimitry Andric via lldb-dev]

On 17 Sep 2018, at 13:41, Hans Wennborg via Release-testers 
 wrote:
> 
> The final version of 7.0.0 has been tagged from the branch at r342370.
> It is identical to rc3 modulo release notes and docs changes.

There weren't any code changes relative to rc3, so nothing changed in the test 
results either.  I have uploaded:

SHA256 (clang+llvm-7.0.0-amd64-unknown-freebsd11.tar.xz) = 
95ceb933ccf76e3ddaa536f41ab82c442bbac07cdea6f9fbf6e3b13cc1711255
SHA256 (clang+llvm-7.0.0-i386-unknown-freebsd11.tar.xz) = 
35460d34a8b3d856e0d7c0b2b20d31f0d1ec05908c830a81f586721e8f8fb04f

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] 7.0.1-rc2 release has been tagged please begin testing

[Dimitry Andric via lldb-dev]

On 3 Nov 2018, at 03:35, Tom Stellard via llvm-dev  
wrote:
> 
> The 7.0.1-rc2 release has been tagged and is ready for testing.  I forgot
> to bump the version number to 7.0.1 before I tagged -rc1, which is why we
> are now on -rc2.

Main test results on amd64-freebsd11 are mostly unchanged from 7.0.0 final, 
just a few more Expected Passes:

  Expected Passes: 52432(7.0.0 final: 52422)
  Expected Failures  :   232(7.0.0 final:   232)
  Unsupported Tests  :  3687(7.0.0 final:  3687)
  Unexpected Passes  : 1(7.0.0 final: 1)
  Unexpected Failures:   489(7.0.0 final:   489)

Test-suite results on amd64-freebsd11 did not change:

  Expected Passes:   903(7.0.0 final:   903)
  Unexpected Failures: 3(7.0.0 final: 3)

Test results on i386-freebsd11 were slightly better than 7.0.0 final, still due 
to a bunch of hanging lldb single step tests (these all seem to hang in the 
STOP state indefinitely, and so have to be killed off manually):

  Expected Passes: 50239(7.0.0 final: 50226)
  Expected Failures  :   226(7.0.0 final:   226)
  Unsupported Tests  :  2502(7.0.0 final:  2502)
  Unexpected Failures:   274(7.0.0 final:   277)

The test-suite still doesn't build on i386-freebsd11, but that is a known issue.

I have uploaded:

SHA256 (clang+llvm-7.0.1-rc2-amd64-unknown-freebsd11.tar.xz) = 
4dfc76b7353701e23dc0b8ad54235c16066e3268b3b7bf77c7ad40acafa182fd
SHA256 (clang+llvm-7.0.1-rc2-i386-unknown-freebsd11.tar.xz) = 
9bd92216dcee4b30e84dfdbdac149977fe7d4251f1d118da4410b561be4879a4

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] LLVM 7.0.1-rc3 has been tagged.

[Dimitry Andric via lldb-dev]

On 8 Dec 2018, at 06:29, Tom Stellard via Release-testers 
 wrote:
> 
> I've just tagged 7.0.1-rc3.  This will hopefully be the last release 
> candidate.
> Please test and report results.

Main test results on amd64-freebsd11 have 12 more Expected Passes compared to 
7.0.1 rc2, and 2 more Unexpected Failures:

 Expected Passes: 52444(7.0.1 rc2: 52432)
 Passes With Retry  : 1(7.0.1 rc2:   n/a)
 Expected Failures  :   232(7.0.1 rc2:   232)
 Unsupported Tests  :  3687(7.0.1 rc2:  3687)
 Unexpected Passes  : 1(7.0.1 rc2: 1)
 Unexpected Failures:   491(7.0.1 rc2:   489)

Test-suite results on amd64-freebsd11 did not change:

 Expected Passes:   903(7.0.1 rc2:   903)
 Unexpected Failures: 3(7.0.1 rc2: 3)

Test results on i386-freebsd11 have 14 more Expected Passes compared to 7.0.1 
rc2, and 1 more Unexpected Failure:

 Expected Passes: 50253(7.0.1 rc2: 50239)
 Expected Failures  :   226(7.0.1 rc2:   226)
 Unsupported Tests  :  2502(7.0.1 rc2:  2502)
 Unexpected Failures:   275(7.0.1 rc2:   274)

The test-suite still doesn't build on i386-freebsd11, but that is a known issue.

I have uploaded:

SHA256 (clang+llvm-7.0.1-rc3-amd64-unknown-freebsd11.tar.xz) = 
3aa11d8f59800537dc019c0a1efed970b2e9e5be5817b629fc88be91ba7f0c62
SHA256 (clang+llvm-7.0.1-rc3-i386-unknown-freebsd11.tar.xz) = 
2930a4103c045e92cece8e577b67c8920686505b023551fbe1c9253111a492c6

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] 7.0.1-final has been tagged

[Dimitry Andric via lldb-dev]

On 20 Dec 2018, at 01:23, Tom Stellard via Release-testers 
 wrote:
> 
> I've tagged the 7.0.1 final release.  Testers may begin uploading binaries.

Main test results on amd64-freebsd11 had 1 more Expected Pass compared to 7.0.1 
rc3, and no more Passes With Retry:

Expected Passes: 52445(7.0.1 rc3: 52444)
Passes With Retry  :   n/a(7.0.1 rc3: 1)
Expected Failures  :   232(7.0.1 rc3:   232)
Unsupported Tests  :  3687(7.0.1 rc3:  3687)
Unexpected Passes  : 1(7.0.1 rc3: 1)
Unexpected Failures:   491(7.0.1 rc3:   491)

Test-suite results on amd64-freebsd11 did not change:

Expected Passes:   903(7.0.1 rc3:   903)
Unexpected Failures: 3(7.0.1 rc3: 3)

Test results on i386-freebsd11 had 1 more Expected Pass compared to 7.0.1 rc3, 
and 3 less Unexpected Failures:

Expected Passes: 50254(7.0.1 rc3: 50253)
Passes With Retry  : 2(7.0.1 rc3:   n/a)
Expected Failures  :   226(7.0.1 rc3:   226)
Unsupported Tests  :  2502(7.0.1 rc3:  2502)
Unexpected Failures:   272(7.0.1 rc3:   275)

The test-suite still doesn't build on i386-freebsd11, but that is a known issue.

I have uploaded:

SHA256 (clang+llvm-7.0.1-amd64-unknown-freebsd11.tar.xz) = 
617be68f00c7a80fb77ee5a124b800aadab64dff052acf51428da3af3f58e407
SHA256 (clang+llvm-7.0.1-i386-unknown-freebsd11.tar.xz) = 
1f696728db8cd4850e0d97ea6bb9d8f3a715fa05fec04ff5618a3f2da6ae7d36

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [8.0.0 Release] rc1 has been tagged

[Dimitry Andric via lldb-dev]

On 24 Jan 2019, at 01:49, Hans Wennborg via Release-testers 
 wrote:
> 
> 8.0.0-rc1 was just tagged (from the branch at r351980).
> 
> It took a little longer than planned, but it's looking good.
> 
> Please run the test script, share your results, and upload binaries.

Unfortunately I'm running into a problem with check-all, where it fails to link 
XRayTest-x86_64-Test:

[100%] Generating XRayTest-x86_64-Test
/home/dim/llvm/8.0.0/rc1/Phase3/Release/llvmCore-8.0.0-rc1.obj/./lib/libLLVMSupport.a(Signals.cpp.o):
 In function `llvm::sys::PrintStackTrace(llvm::raw_ostream&)':
Signals.cpp:(.text._ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x24): 
undefined reference to `backtrace'
Signals.cpp:(.text._ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x254): 
undefined reference to `llvm::itaniumDemangle(char const*, char*, unsigned 
long*, int*)'
clang-8: error: linker command failed with exit code 1 (use -v to see 
invocation)
gmake[3]: *** 
[projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/build.make:73:
 projects/compiler-rt/lib/xray/tests/unit/XRayTest-x86_64-Test] Error 1
gmake[3]: Target 
'projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/build'
 not remade because of errors.
gmake[2]: *** [CMakeFiles/Makefile2:33513: 
projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/all]
 Error 2
gmake[2]: Target 'CMakeFiles/check-all.dir/all' not remade because of errors.
gmake[1]: *** [CMakeFiles/Makefile2:737: CMakeFiles/check-all.dir/rule] Error 2
gmake[1]: Target 'check-all' not remade because of errors.
gmake: *** [Makefile:277: check-all] Error 2
[Release Phase3] check-all failed

It appears this is because -lexecinfo is not passed to the link command line, 
but I'm unsure why this only seems to affect the XRay test.  I'm investigating, 
but if anybody has a cluestick, please hit me. :-)

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [8.0.0 Release] rc1 has been tagged

[Dimitry Andric via lldb-dev]

On 24 Jan 2019, at 20:34, Michał Górny  wrote:
> 
> On Thu, 2019-01-24 at 19:58 +0100, Dimitry Andric via Release-testers
> wrote:
>> On 24 Jan 2019, at 01:49, Hans Wennborg via Release-testers 
>>  wrote:
>>> 
>>> 8.0.0-rc1 was just tagged (from the branch at r351980).
>>> 
>>> It took a little longer than planned, but it's looking good.
>>> 
>>> Please run the test script, share your results, and upload binaries.
>> 
>> Unfortunately I'm running into a problem with check-all, where it fails to 
>> link XRayTest-x86_64-Test:
>> 
>> [100%] Generating XRayTest-x86_64-Test
>> /home/dim/llvm/8.0.0/rc1/Phase3/Release/llvmCore-8.0.0-rc1.obj/./lib/libLLVMSupport.a(Signals.cpp.o):
>>  In function `llvm::sys::PrintStackTrace(llvm::raw_ostream&)':
>> Signals.cpp:(.text._ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x24): 
>> undefined reference to `backtrace'
>> Signals.cpp:(.text._ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x254): 
>> undefined reference to `llvm::itaniumDemangle(char const*, char*, unsigned 
>> long*, int*)'
>> clang-8: error: linker command failed with exit code 1 (use -v to see 
>> invocation)
>> gmake[3]: *** 
>> [projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/build.make:73:
>>  projects/compiler-rt/lib/xray/tests/unit/XRayTest-x86_64-Test] Error 1
>> gmake[3]: Target 
>> 'projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/build'
>>  not remade because of errors.
>> gmake[2]: *** [CMakeFiles/Makefile2:33513: 
>> projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/all]
>>  Error 2
>> gmake[2]: Target 'CMakeFiles/check-all.dir/all' not remade because of errors.
>> gmake[1]: *** [CMakeFiles/Makefile2:737: CMakeFiles/check-all.dir/rule] 
>> Error 2
>> gmake[1]: Target 'check-all' not remade because of errors.
>> gmake: *** [Makefile:277: check-all] Error 2
>> [Release Phase3] check-all failed
>> 
>> It appears this is because -lexecinfo is not passed to the link command 
>> line, but I'm unsure why this only seems to affect the XRay test.  I'm 
>> investigating, but if anybody has a cluestick, please hit me. :-)
>> 
> 
> We've been having similar issue on NetBSD in the past.  Long story
> short, the code around there is not using CMake rules to build stuff but
> a custom compiler invocation, and therefore it does not inherit library
> dependencies from CMake.
> 
> Short-term solution is to figure out what's missing and add it, with
> appropriate conditionals.

Yes, I'm attempting again with this diff applied:

--- llvm.src/projects/compiler-rt/cmake/config-ix.cmake
+++ llvm.src/projects/compiler-rt/cmake/config-ix.cmake
@@ -118,6 +118,7 @@ check_library_exists(dl dlopen "" COMPIL
 check_library_exists(rt shm_open "" COMPILER_RT_HAS_LIBRT)
 check_library_exists(m pow "" COMPILER_RT_HAS_LIBM)
 check_library_exists(pthread pthread_create "" COMPILER_RT_HAS_LIBPTHREAD)
+check_library_exists(execinfo backtrace "" COMPILER_RT_HAS_LIBEXECINFO)

 # Look for terminfo library, used in unittests that depend on LLVMSupport.
 if(LLVM_ENABLE_TERMINFO)
--- llvm.src/projects/compiler-rt/lib/xray/tests/CMakeLists.txt
+++ llvm.src/projects/compiler-rt/lib/xray/tests/CMakeLists.txt
@@ -71,13 +71,14 @@ if (NOT APPLE)
 endforeach()

 # We also add the actual libraries to link as dependencies.
-list(APPEND XRAY_UNITTEST_LINK_FLAGS -lLLVMXRay -lLLVMSupport 
-lLLVMTestingSupport)
+list(APPEND XRAY_UNITTEST_LINK_FLAGS -lLLVMXRay -lLLVMSupport 
-lLLVMDemangle -lLLVMTestingSupport)
   endif()

   append_list_if(COMPILER_RT_HAS_LIBM -lm XRAY_UNITTEST_LINK_FLAGS)
   append_list_if(COMPILER_RT_HAS_LIBRT -lrt XRAY_UNITTEST_LINK_FLAGS)
   append_list_if(COMPILER_RT_HAS_LIBDL -ldl XRAY_UNITTEST_LINK_FLAGS)
   append_list_if(COMPILER_RT_HAS_LIBPTHREAD -pthread XRAY_UNITTEST_LINK_FLAGS)
+  append_list_if(COMPILER_RT_HAS_LIBEXECINFO -lexecinfo 
XRAY_UNITTEST_LINK_FLAGS)
 endif()

 macro(add_xray_unittest testname)


Now the next problem is a Asan:DEADLYSIGNAL which keeps on repeating endlessly. 
:-)

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [8.0.0 Release] rc1 has been tagged

[Dimitry Andric via lldb-dev]

On 24 Jan 2019, at 21:25, Dimitry Andric via Release-testers 
 wrote:
> 
> On 24 Jan 2019, at 20:34, Michał Górny  wrote:
>> 
>> On Thu, 2019-01-24 at 19:58 +0100, Dimitry Andric via Release-testers wrote:
>>> On 24 Jan 2019, at 01:49, Hans Wennborg via Release-testers 
>>>  wrote:
 
 8.0.0-rc1 was just tagged (from the branch at r351980).
...
> Yes, I'm attempting again with this diff applied:
> 
> --- llvm.src/projects/compiler-rt/cmake/config-ix.cmake
> +++ llvm.src/projects/compiler-rt/cmake/config-ix.cmake
> @@ -118,6 +118,7 @@ check_library_exists(dl dlopen "" COMPIL
> check_library_exists(rt shm_open "" COMPILER_RT_HAS_LIBRT)
> check_library_exists(m pow "" COMPILER_RT_HAS_LIBM)
> check_library_exists(pthread pthread_create "" COMPILER_RT_HAS_LIBPTHREAD)
> +check_library_exists(execinfo backtrace "" COMPILER_RT_HAS_LIBEXECINFO)
> 
> # Look for terminfo library, used in unittests that depend on LLVMSupport.
> if(LLVM_ENABLE_TERMINFO)
> --- llvm.src/projects/compiler-rt/lib/xray/tests/CMakeLists.txt
> +++ llvm.src/projects/compiler-rt/lib/xray/tests/CMakeLists.txt
> @@ -71,13 +71,14 @@ if (NOT APPLE)
> endforeach()
> 
> # We also add the actual libraries to link as dependencies.
> -list(APPEND XRAY_UNITTEST_LINK_FLAGS -lLLVMXRay -lLLVMSupport 
> -lLLVMTestingSupport)
> +list(APPEND XRAY_UNITTEST_LINK_FLAGS -lLLVMXRay -lLLVMSupport 
> -lLLVMDemangle -lLLVMTestingSupport)
>   endif()
> 
>   append_list_if(COMPILER_RT_HAS_LIBM -lm XRAY_UNITTEST_LINK_FLAGS)
>   append_list_if(COMPILER_RT_HAS_LIBRT -lrt XRAY_UNITTEST_LINK_FLAGS)
>   append_list_if(COMPILER_RT_HAS_LIBDL -ldl XRAY_UNITTEST_LINK_FLAGS)
>   append_list_if(COMPILER_RT_HAS_LIBPTHREAD -pthread XRAY_UNITTEST_LINK_FLAGS)
> +  append_list_if(COMPILER_RT_HAS_LIBEXECINFO -lexecinfo 
> XRAY_UNITTEST_LINK_FLAGS)
> endif()
> 
> macro(add_xray_unittest testname)

Meanwhile, this diff was applied, but I had little time to look at the tests 
again.  As I mentioned in my previous email, I saw many tests failing with an 
Asan:DEADLYSIGNAL error, which kept on endlessly repeating, until my log files 
filled up.

This is specifically happening during the dynamic ASan tests, e.g. 
Asan-x86_64-calls-Dynamic-Test and Asan-x86_64-inline-Dynamic-Test.  Running 
these in gdb shows that it gets into an endless recursion:

Starting program: 
/home/dim/obj/llvm-trunk-r352660/projects/compiler-rt/lib/asan/tests/dynamic/Asan-x86_64-inline-Dynamic-Test

Program received signal SIGSEGV, Segmentation fault.
0x00080097bff1 in __asan::GetCurrentThread() () at 
/home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
408   reinterpret_cast(AsanTSDGet());
(gdb) bt
#0  0x00080097bff1 in __asan::GetCurrentThread() () at 
/home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
#1  0x0008009408b0 in __interceptor___tls_get_addr () at 
/home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107
#2  0x000800973ad7 in AsanTSDGet () at 
/home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68
#3  0x00080097bff6 in __asan::GetCurrentThread() () at 
/home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
#4  0x0008009408b0 in __interceptor___tls_get_addr () at 
/home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107
#5  0x000800973ad7 in AsanTSDGet () at 
/home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68
#6  0x00080097bff6 in __asan::GetCurrentThread() () at 
/home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
#7  0x0008009408b0 in __interceptor___tls_get_addr () at 
/home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107
#8  0x000800973ad7 in AsanTSDGet () at 
/home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68
#9  0x00080097bff6 in __asan::GetCurrentThread() () at 
/home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
#10 0x0008009408b0 in __interceptor___tls_get_addr () at 
/home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107
#11 0x000800973ad7 in AsanTSDGet () at 
/home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68
#12 0x00080097bff6 in __asan::GetCurrentThread() () at 
/home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
#13 0x0008009408b0 in __interceptor___tls_get_addr () at 
/home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107
#14 0x000800973ad7 in AsanTSDGet () at 
/home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68
#15 0x00080097bff6 in __asan::GetCurrentThread() () at 
/home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
[...goes on until gdb crashes :)...]

The _

Re: [lldb-dev] [Release-testers] [8.0.0 Release] rc2 has been tagged

[Dimitry Andric via lldb-dev]

On 7 Feb 2019, at 16:41, Hans Wennborg via Release-testers 
 wrote:
> 8.0.0-rc2 has been tagged from the release_80 branch at r353413.
> 
> Please run the test script, share your results, and upload binaries.

Unfortunately I had to disable compiler-rt for this test run, as most of the 
sanitizers are totally broken.  They get into an endless recursive loop between 
AsanTSDGet() and the __tls_get_addr() interceptor, and crash with DEADLYSIGNAL 
due to stack overflow.  I haven't found the time to further diagnose this.

Main test results on amd64-freebsd11:

  Expected Passes: 53882
  Expected Failures  : 220
  Unsupported Tests  : 1081
  Unresolved Tests   : 10
  Unexpected Passes  : 3
  Unexpected Failures: 60

Main test results on i386-freebsd11:

  Expected Passes: 53729
  Expected Failures  : 236
  Unsupported Tests  : 903
  Unresolved Tests   : 10
  Unexpected Passes  : 5
  Unexpected Failures: 178

The unresolved tests are due to a number of tests hanging in  state, 
forcing me to kill their parent .py processes.

Uploaded:

SHA256 (clang+llvm-8.0.0-rc2-amd64-unknown-freebsd11.tar.xz) = 
81673933ecd33f22f45a3ffa4558f3a23e9dbb8c3a0255ec831c8dd6c97b0bae
SHA256 (clang+llvm-8.0.0-rc2-i386-unknown-freebsd11.tar.xz) = 
663f340568a5c06470616008cdd7c5c118eb64d6acfc80009d5cc2b596fb6242

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [8.0.0 Release] rc3 has been tagged

[Dimitry Andric via lldb-dev]

On 27 Feb 2019, at 19:51, Hans Wennborg via Release-testers 
 wrote:
> 
> 8.0.0-rc3 was just tagged from the release_80 branch at r355015.
> 
> We're running a little behind schedule now, but I think we're also
> close to be able to call this done.

Again, I had to disable compiler-rt for this test run, as most of the 
sanitizers are totally broken.  This is tracked in PR40761.

Main test results on amd64-freebsd11:

  Expected Passes: 53895   (rc2: 53882)
  Expected Failures  :   220   (rc2:   220)
  Unsupported Tests  :  1081   (rc2:  1081)
  Unresolved Tests   :10   (rc2:10)
  Unexpected Passes  : 3   (rc2: 3)
  Unexpected Failures:62   (rc2:60)

Main test results on i386-freebsd11:

 Expected Passes: 53747(rc2: 53729)
 Expected Failures  :   236(rc2:   236)
 Unsupported Tests  :   903(rc2:   903)
 Unresolved Tests   :10(rc2:10)
 Unexpected Passes  : 5(rc2: 5)
 Unexpected Failures:   175(rc2:   178)

The unresolved tests are due to a number of tests hanging in  state, 
forcing me to kill their parent .py processes.

Uploaded:

SHA256 (clang+llvm-8.0.0-rc3-amd64-unknown-freebsd11.tar.xz) = 
bc14dc280c7e2acc8750cd531b17698e943c3f22ee994f5b21db49b48f5e66e4
SHA256 (clang+llvm-8.0.0-rc3-i386-unknown-freebsd11.tar.xz) = 
9003dda7df39f538e74983de74d2e3ff075d079e24671ab3649b702a9417423c

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [8.0.0 Release] rc5 has been tagged

[Dimitry Andric via lldb-dev]

On 12 Mar 2019, at 12:16, Hans Wennborg via cfe-dev  
wrote:
> 8.0.0-rc5 was just tagged from the release_80 branch at r355909.
> 
> This is identical to rc4 with the addition of r355743. Hopefully it is the 
> final release candidate, so please give it a good testing.

Again, I had to disable compiler-rt for this test run, as most of the 
sanitizers are totally broken. This is tracked in PR40761.

Main test results on amd64-freebsd11:

 Expected Passes: 53896  (rc3: 53895)
 Expected Failures  :   220  (rc3:   220)
 Unsupported Tests  :  1081  (rc3:  1081)
 Unresolved Tests   :10  (rc3:10)
 Unexpected Passes  : 3  (rc3: 3)
 Unexpected Failures:65  (rc3:62)

Main test results on i386-freebsd11:

Expected Passes: 53749  (rc3: 53747)
Expected Failures  :   236  (rc3:   236)
Unsupported Tests  :   903  (rc3:   903)
Unresolved Tests   :10  (rc3:10)
Unexpected Passes  : 5  (rc3: 5)
Unexpected Failures:   177  (rc3:   175)

The unresolved tests are due to a number of tests hanging in  state, 
forcing me to kill their parent .py processes.

Uploaded:

SHA256 (clang+llvm-8.0.0-rc5-amd64-unknown-freebsd11.tar.xz) = 
efa082e21a23af219fda1ef374adf2fd24ac2e501d7ae4cfeaa66dab34c027aa
SHA256 (clang+llvm-8.0.0-rc5-i386-unknown-freebsd11.tar.xz) = 
429027112f2e71dec6b980cc3e493fc1a9ab1254929c462b090da952e6fc21eb

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [8.0.0 Release] The final tag is in

[Dimitry Andric via lldb-dev]

On 18 Mar 2019, at 14:04, Hans Wennborg via Release-testers 
 wrote:
> The final version of 8.0.0 was just tagged from the release_80 branch
> at r356364. It's identical to rc5 except for a few documentation
> changes.

Again, I had to disable compiler-rt for this test run, as most of the 
sanitizers are totally broken. This is tracked in PR40761.

Main test results on amd64-freebsd11:

Expected Passes: 53244  (rc5: 53896)
Expected Failures  :   213  (rc5:   220)
Unsupported Tests  :  1716  (rc5:  1081)
Unresolved Tests   : 7  (rc5:10)
Unexpected Passes  : 3  (rc5: 3)
Unexpected Failures:62  (rc5:65)

Main test results on i386-freebsd11:

Expected Passes: 53098  (rc5: 53749)
Expected Failures  :   229  (rc5:   236)
Unsupported Tests  :  1538  (rc5:   903)
Unresolved Tests   : 8  (rc5:10)
Unexpected Passes  : 5  (rc5: 5)
Unexpected Failures:   172  (rc5:   177)

The unresolved tests are due to a number of tests hanging in  state, 
forcing me to kill their parent .py processes.

Uploaded:

SHA256 (clang+llvm-8.0.0-amd64-unknown-freebsd11.tar.xz) = 
af15d14bd25e469e35ed7c43cb7e035bc1b2aa7b55d26ad597a43e72768750a8
SHA256 (clang+llvm-8.0.0-i386-unknown-freebsd11.tar.xz) = 
1ba88663ccda4e9fad93f8f35dde7ce04854abc0bcbb1d12a90cdc863e4a77b8

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] Release 7.1.0 -rc1 has been tagged

[Dimitry Andric via lldb-dev]

On 27 Mar 2019, at 22:27, Tom Stellard via Release-testers 
 wrote:
> 
> I've just tagged 7.1.0-rc1.  Testers, please begin testing and reporting
> results.

Main test results on amd64-freebsd11:

  Expected Passes: 52441
  Expected Failures  : 232
  Unsupported Tests  : 3687
  Unexpected Passes  : 1
  Unexpected Failures: 495

Test suite results on amd64-freebsd11:

  Expected Passes: 903
  Unexpected Failures: 3

Main test results on i386-freebsd11:

  Expected Passes: 50252
  Expected Failures  : 226
  Unsupported Tests  : 2502
  Unexpected Failures: 276

As before, the test suite fails to compile on i386, due to an SSE requirement.

Uploaded:

SHA256 (clang+llvm-7.1.0-rc1-amd64-unknown-freebsd11.tar.xz) = 
f607f8b33838ba31684da09f7956d273e60dbd99e5d4a2066315efccb52556bb
SHA256 (clang+llvm-7.1.0-rc1-i386-unknown-freebsd11.tar.xz) = 
221c31b8dc19965271e47b422c30175fa70446a05fbb6f4dff9ba3f8020e8437

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] LLVM 7.1.0-final has been tagged

[Dimitry Andric via lldb-dev]

On 12 Apr 2019, at 02:00, Tom Stellard via Release-testers 
 wrote:
> 
> I've just tagged LLVM 7.1.0-final.  Testers, please upload the final binaries.

Unfortunately in the 7.x branch, r345199 was not merged, which reverted commits 
r333103 ("Teach __libcpp_is_floating_point that __fp16 and _Float16 are 
floating-point types") and r333108 ("Do not define template specialization 
__libcpp_is_floating_point<__fp16> if the compiler is not clang").

This leads to compile errors when building libunwind, similar to:

In file included from 
/home/dim/llvm/7.1.0/final/llvm.src/projects/libunwind/src/libunwind.cpp:18:
In file included from 
/home/dim/llvm/7.1.0/final/llvm.src/projects/libcxx/include/new:91:
In file included from 
/home/dim/llvm/7.1.0/final/llvm.src/projects/libcxx/include/exception:83:
/home/dim/llvm/7.1.0/final/llvm.src/projects/libcxx/include/type_traits:740:56: 
error: _Float16 is not supported on this target
template <>  struct __libcpp_is_floating_point<_Float16>: public 
true_type {};
   ^

Therefore I have patched my libcxx sources with r345199, after which the 
complete build successfully finished, at least.

Main test results on amd64-freebsd11:

 Expected Passes: 52437 (rc1: 52441)
 Expected Failures  :   232 (rc1:   232)
 Unsupported Tests  :  3687 (rc1:  3687)
 Unexpected Passes  : 1 (rc1: 1)
 Unexpected Failures:   499 (rc1:   495)

Test suite results on amd64-freebsd11:

 Expected Passes:   903 (rc1:   903)
 Unexpected Failures: 3 (rc1: 3)

Main test results on i386-freebsd11:

 Expected Passes: 50254 (rc1: 50252)
 Expected Failures  :   226 (rc1:   226)
 Unsupported Tests  :  2502 (rc1:  2502)
 Unexpected Failures:   274 (rc1:   276)

As before, the test suite fails to compile on i386, due to an SSE requirement.

Uploaded:

SHA256 (clang+llvm-7.1.0-amd64-unknown-freebsd11.tar.xz) = 
183c7949fcd0db5638ed471c138a594b7176d53ff2a6558754e703f4075acb80
SHA256 (clang+llvm-7.1.0-i386-unknown-freebsd11.tar.xz) = 
d43471d32bc2cadd77a6a61e15316a9870a4b2825b3a73b9b362cc063e4a8ae1

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] LLVM 8.0.1-rc2 has been tagged

[Dimitry Andric via lldb-dev]

On 11 Jun 2019, at 05:53, Tom Stellard via Release-testers 
 wrote:
> 
> I've tagged the 8.0.1-rc2 release, testers please begin testing and upload 
> your
> binaries.

As with 8.0.1 rc1, I had to disable compiler-rt for this test run, as most of 
the sanitizers are totally broken. This is tracked in PR40761.

Main test results on amd64-freebsd11:

 Expected Passes: 53259 (rc1: 53253)
 Expected Failures  :   213 (rc1:   213)
 Unsupported Tests  :  1719 (rc1:  1717)
 Unresolved Tests   : 8 (rc1: 8)
 Unexpected Passes  : 3 (rc1: 3)
 Unexpected Failures:63 (rc1:62)

Main test results on i386-freebsd11:

 Expected Passes: 53108 (rc1: 53108)
 Expected Failures  :   229 (rc1:   229)
 Unsupported Tests  :  1541 (rc1:  1539)
 Unresolved Tests   : 9 (rc1: 8)
 Unexpected Passes  : 5 (rc1: 5)
 Unexpected Failures:   178 (rc1:   172)

Uploaded:

SHA256 (clang+llvm-8.0.1-rc2-amd64-unknown-freebsd11.tar.xz) = 
3d25d68cafd3997467211d78e7eafc79c31c3b7d41aa60fa025c6fd4237947b1
SHA256 (clang+llvm-8.0.1-rc2-i386-unknown-freebsd11.tar.xz) = 
67773ce44cabce18338f9209b6de9c3df971c1c7d98c9fd5b66334e1467bc510

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] LLVM 8.0.1-rc3

[Dimitry Andric via lldb-dev]

On 28 Jun 2019, at 00:56, Tom Stellard via Release-testers 
 wrote:
> 
> I've just tagged LLVM 8.0.1-rc3.  Testers, please begin testing and report
> results.

As with 8.0.1 rc2, I had to disable compiler-rt for this test run, as most of 
the sanitizers are totally broken. This is tracked in PR40761.

Main test results on amd64-freebsd11:

Expected Passes: 53266 (rc2: 53259)
Expected Failures  :   213 (rc2:   213)
Unsupported Tests  :  1718 (rc2:  1719)
Unresolved Tests   : 8 (rc2: 8)
Unexpected Passes  : 3 (rc2: 3)
Unexpected Failures:59 (rc2:63)

Main test results on i386-freebsd11:

Expected Passes: 53113 (rc2: 53108)
Expected Failures  :   229 (rc2:   229)
Unsupported Tests  :  1540 (rc2:  1541)
Unresolved Tests   : 7 (rc2: 9)
Unexpected Passes  : 5 (rc2: 5)
Unexpected Failures:   178 (rc2:   178)

Uploaded:

SHA256 (clang+llvm-8.0.1-rc3-amd64-unknown-freebsd11.tar.xz) = 
32d1f5882fa2aba7c98234dba7bc0dcdcb99b20e455da29d2f7ec5063d11
SHA256 (clang+llvm-8.0.1-rc3-i386-unknown-freebsd11.tar.xz) = 
d82d640f3cd9130a80cf2a70094b9b99ebe7192a5b7e8dd091bdcd764ba7f70c

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [Release-testers] LLVM 8.0.1-rc3

[Dimitry Andric via lldb-dev]

On 6 Jul 2019, at 04:36, Christian Gagneraud  wrote:
> 
> On Thu, 4 Jul 2019 at 22:16, Yvan Roux via cfe-dev
>  wrote:
>>> Expected Passes: 53266 (rc2: 53259)
>>> Expected Failures  :   213 (rc2:   213)
>>> Unsupported Tests  :  1718 (rc2:  1719)
>>> Unresolved Tests   : 8 (rc2: 8)
> 
> Does someone knows what unresolved means?

Yes, that's when you have to kill the script that runs the individual
test, for example because the test hangs.

In my case, I have some lldb tests that sometimes sit and hang in a STOP
state (these are apparently tests for the stop/continue logic).  In that
case, I have to kill off the tested program and its parent (most of the
time a forked lit.py), leading to "Unresolved" status for that
particular test.

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] 8.0.1-rc4 release has been tagged.

[Dimitry Andric via lldb-dev]

On 11 Jul 2019, at 05:24, Tom Stellard via Release-testers 
 wrote:
> 
> I've tagged the 8.0.1-rc4 release, please begin testing.  This will 
> (hopefully)
> be the last release candidate.  If all goes well, I will tag the final release
> next Wednesday.

As with 8.0.1 rc3, I had to disable compiler-rt for this test run, as most of 
the sanitizers are totally broken. This is tracked in PR40761.

Main test results on amd64-freebsd11:

Expected Passes: 53262 (rc3: 53266)
Passes With Retry  : 1 (rc3: 0)
Expected Failures  :   213 (rc3:   213)
Unsupported Tests  :  1718 (rc3:  1718)
Unresolved Tests   : 8 (rc3: 8)
Unexpected Passes  : 3 (rc3: 3)
Unexpected Failures:62 (rc3:59)

Main test results on i386-freebsd11:

Expected Passes: 53114 (rc3: 53113)
Passes With Retry  : 1 (rc3: 0)
Expected Failures  :   229 (rc3:   229)
Unsupported Tests  :  1540 (rc3:  1540)
Unresolved Tests   : 8 (rc3: 7)
Unexpected Passes  : 5 (rc3: 5)
Unexpected Failures:   175 (rc3:   178)

Uploaded:

SHA256 (clang+llvm-8.0.1-rc4-amd64-unknown-freebsd11.tar.xz) = 
ffd4546aab6d7944b4063a8fd9f4022be8b4904760becc76ee2ea64d3fa50d7e
SHA256 (clang+llvm-8.0.1-rc4-i386-unknown-freebsd11.tar.xz) = 
52ab6fa940a4143c1ac2fc50f2aa0994b92a56fbf7d8b1146b74a7c5de743607

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] 8.0.1-final has been tagged

[Dimitry Andric via lldb-dev]

On 20 Jul 2019, at 05:21, Tom Stellard via Release-testers 
 wrote:
> The 8.0.1 final release has been tagged.  Testers please upload the final
> binaries.

As with 8.0.1 rc4, I had to disable compiler-rt for this test run, as most of 
the sanitizers are totally broken. This is tracked in PR40761.

Main test results on amd64-freebsd11:

Expected Passes: 53258 (rc4: 53262)
Passes With Retry  : 0 (rc4: 1)
Expected Failures  :   213 (rc4:   213)
Unsupported Tests  :  1718 (rc4:  1718)
Unresolved Tests   : 9 (rc4: 8)
Unexpected Passes  : 3 (rc4: 3)
Unexpected Failures:66 (rc4:62)

Main test results on i386-freebsd11:

Expected Passes: 53113 (rc4: 53114)
Passes With Retry  : 0 (rc4: 1)
Expected Failures  :   229 (rc4:   229)
Unsupported Tests  :  1540 (rc4:  1540)
Unresolved Tests   : 8 (rc4: 8)
Unexpected Passes  : 5 (rc4: 5)
Unexpected Failures:   177 (rc4:   175)

Uploaded:

SHA256 (clang+llvm-8.0.1-amd64-unknown-freebsd11.tar.xz) = 
4ae625169fa0ae56cf534cddc6f8eda76123f89adac0de439d0e47885fccc813
SHA256 (clang+llvm-8.0.1-i386-unknown-freebsd11.tar.xz) = 
f0ab06cce95f9339af3e27e728913414a7b775a5bdb6c90e2a4f67f8cf2a917e

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [9.0.0 Release] Release Candidate 1 is here

[Dimitry Andric via lldb-dev]

On 29 Jul 2019, at 16:32, Hans Wennborg via Release-testers 
 wrote:
> 
> 9.0.0-rc1 was just tagged from the release_90 branch at r367217
> (tagged as llvmorg-9.0.0-rc1 in the Git monorepo).

The sanitizer tests went a lot better now, thanks to Alexander Richardson's 
patches in https://bugs.llvm.org/show_bug.cgi?id=40761 
(https://reviews.llvm.org/D65221 and https://reviews.llvm.org/D65705).

Uploaded:

SHA256 (clang+llvm-9.0.0-rc1-amd64-unknown-freebsd11.tar.xz) = 
6a6c04e2d87ef3d8b8671b175afe0a59d3f5fee6d758d3c3383a6af3031b76a4
SHA256 (clang+llvm-9.0.0-rc1-i386-unknown-freebsd11.tar.xz) = 
d34d0d46d93576c27e6ab2a5fa4712c80fe0580dd5ca9efadd5b0b2a0b1a150f

I had to apply a number of other patches (see attachments) to make the 
sanitizer tests work at all, and for a few other issues:

* https://bugs.llvm.org/show_bug.cgi?id=42892 - After r356631, 
Sanitizer-i386-Test faills to link on FreeBSD
* https://bugs.llvm.org/show_bug.cgi?id=42893 - FreeBSD needs 
LD_32_LIBRARY_PATH support in lit for 32-bit dynamic ASan tests
* https://bugs.llvm.org/show_bug.cgi?id=42894 - FreeBSD needs -pthread link 
flag for dynamic ASan tests

Main test results on amd64-freebsd11:

  
  Unexpected Passing Tests (7):
  AddressSanitizer-i386-freebsd-dynamic :: 
TestCases/interception_failure_test.cc
  AddressSanitizer-x86_64-freebsd-dynamic :: 
TestCases/interception_failure_test.cc
  lldb-Suite :: api/multiple-targets/TestMultipleTargets.py
  lldb-Suite :: functionalities/avoids-fd-leak/TestFdLeak.py
  lldb-Suite :: 
functionalities/data-formatter/data-formatter-skip-summary/TestDataFormatterSkipSummary.py
  lldb-Suite :: lang/cpp/namespace/TestNamespaceLookup.py
  lldb-Suite :: python_api/thread/TestThreadAPI.py

  
  Failing Tests (120):
  AddressSanitizer-Unit :: 
./Asan-i386-calls-Dynamic-Test/AddressSanitizer.ShadowGapTest
  AddressSanitizer-Unit :: 
./Asan-i386-inline-Dynamic-Test/AddressSanitizer.ShadowGapTest
  AddressSanitizer-i386-freebsd :: TestCases/Posix/fread_fwrite.cc
  AddressSanitizer-i386-freebsd-dynamic :: TestCases/Posix/fread_fwrite.cc
  Builtins-i386-freebsd :: floatundixf_test.c
  LLDB :: 
Commands/CommandScriptImmediateOutput/CommandScriptImmediateOutputConsole.test
  LLDB :: 
Commands/CommandScriptImmediateOutput/CommandScriptImmediateOutputFile.test
  LLDB :: Driver/LocalLLDBInit.test
  LLDB :: Driver/TestConvenienceVariables.test
  LLDB :: ExecControl/StopHook/stop-hook-threads.test
  LLDB :: ExecControl/StopHook/stop-hook.test
  LLDB :: Expr/TestIRMemoryMap.test
  LLDB :: Register/x86-64-gp-read.test
  LLDB :: Register/x86-64-gp-write.test
  LLDB :: Register/x86-64-read.test
  LLDB :: Register/x86-64-write.test
  LLDB :: Register/x86-64-ymm-read.test
  LLDB :: Register/x86-64-ymm-write.test
  LLDB :: Register/x86-mm-xmm-read.test
  LLDB :: Register/x86-mm-xmm-write.test
  LLDB :: SymbolFile/DWARF/find-basic-function.cpp
  LLDB :: SymbolFile/DWARF/find-basic-namespace.cpp
  LLDB :: SymbolFile/DWARF/find-basic-type.cpp
  LLDB :: SymbolFile/DWARF/find-basic-variable.cpp
  LLDB :: SymbolFile/DWARF/find-method.cpp
  LLDB :: tools/lldb-mi/breakpoint/break-insert.test
  LLDB :: tools/lldb-mi/data/data-info-line.test
  LLDB :: tools/lldb-mi/exec/exec-interrupt.test
  LLDB :: tools/lldb-mi/exec/exec-next-instruction.test
  LLDB :: tools/lldb-mi/exec/exec-next.test
  LLDB :: tools/lldb-mi/exec/exec-step-instruction.test
  LLDB :: tools/lldb-mi/exec/exec-step.test
  LLVM :: tools/yaml2obj/elf-override-shoffset.yaml
  LLVM :: tools/yaml2obj/elf-override-shsize.yaml
  MemorySanitizer-Unit :: 
./Msan-x86_64-Test/MemorySanitizer.SmallPreAllocatedStackThread
  MemorySanitizer-Unit :: 
./Msan-x86_64-Test/MemorySanitizer.bind_getsockname
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.confstr
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.mbrtowc
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.swprintf
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.valloc
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.SmallPreAllocatedStackThread
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.bind_getsockname
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.confstr
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.mbrtowc
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.swprintf
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.valloc
  MemorySanitizer-X86_64 :: dtls_test.c
  SanitizerCommon-asan-i386-FreeBSD :: Posix/devname_r.cc
  SanitizerCommon-asan-i386-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-asan-x86_64-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-msan-

Re: [lldb-dev] [cfe-dev] [Release-testers] [9.0.0 Release] Release Candidate 1 is here

[Dimitry Andric via lldb-dev]

On 2019-08-06 22:59, Marshall Clow wrote:
> Many of the failing libc++ tests are explicitly XFAILed for NetBSD; I wonder 
> if they should also be for FreeBSD.

If they can't be fixed, then indeed they should be XFAILed.  But maybe not 
right away, see below.


>libcxx/thread/thread.threads/thread.thread.this/sleep_for.pass.cpp
>  I don't know about this one.

Apparently it slept for too long:

Assertion failed: (std::abs(ns.count()) < err.count()), function main, file 
/home/dim/llvm/9.0.0/rc1/llvm.src/projects/libcxx/test/libcxx/thread/thread.threads/thread.thread.this/sleep_for.pass.cpp,
 line 68.

Cause is unknown.


>   libc++ :: std/language.support/support.runtime/ctime.pass.cpp
> Does your C library have "timespec_get" ?

Yes, but it got introduced only in FreeBSD 12.0.  I ran the tests on FreeBSD 
11.3, where it got:

/home/dim/llvm/9.0.0/rc1/llvm.src/projects/libcxx/test/std/language.support/support.runtime/ctime.pass.cpp:25:2:
 error: TIME_UTC not defined

This could be worked around by checking the FreeBSD major version, using e.g. 
"#if __FreeBSD__ >= 12".


>   libc++ ::
>
> std/localization/locale.categories/category.collate/locale.collate.byname/compare.pass.cpp

For this particular test, FreeBSD, Linux and Windows seem to have a different 
opinion than macOS on the result of std::strcoll("aaA", "BaA"), when 
the locale is en_US.UTF-8:

* macOS 10.14 gives 31
* FreeBSD 13.0 gives -13
* Linux (Ubuntu 18.04) gives -1
* Windows 10 (VS 2017) gives -1

E.g. macOS, which the test appears to be based on, is the odd one out here. :)

I won't pretend to fully understand the Unicode collation rules, but it could 
be that macOS does a case insensitive comparison, while the other systems do a 
case sensitive comparison.


>   libc++ ::
>
> std/localization/locale.categories/category.collate/locale.collate.byname/transform.pass.cpp

This test failed because it segfaults on FreeBSD, due to a bug in our 
wcsxfrm_l(3). :-)

I have fixed the bug in FreeBSD 13 here: 
https://svnweb.freebsd.org/changeset/base/350697, but it may take a while 
before it is merged into FreeBSD 12 and 11.


> These contain:
> // NetBSD does not support LC_COLLATE at the moment
> // XFAIL: netbsd
>   libc++ ::
>
> std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_fr_FR.pass.cpp
>   libc++ ::
>
> std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_ru_RU.pass.cpp
>   libc++ ::
>
> std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_zh_CN.pass.cpp
>   libc++ ::
>
> std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_fr_FR.pass.cpp
>   libc++ ::
>
> std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_ru_RU.pass.cpp
>   libc++ ::
>
> std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_zh_CN.pass.cpp
>   libc++ ::
>
> std/localization/locale.categories/category.monetary/locale.moneypunct.byname/curr_symbol.pass.cpp
>   libc++ ::
>
> std/localization/locale.categories/category.monetary/locale.moneypunct.byname/grouping.pass.cpp
>   libc++ ::
>
> std/localization/locale.categories/category.monetary/locale.moneypunct.byname/neg_format.pass.cpp
>   libc++ ::
>
> std/localization/locale.categories/category.monetary/locale.moneypunct.byname/pos_format.pass.cpp
>   libc++ ::
>
> std/localization/locale.categories/category.monetary/locale.moneypunct.byname/thousands_sep.pass.cpp
> These contain:
> // NetBSD does not support LC_MONETARY at the moment
> // XFAIL: netbsd
>   libc++ ::
>
> std/localization/locale.categories/category.time/locale.time.get.byname/get_monthname.pass.cpp
>   libc++ ::
>
> std/localization/locale.categories/category.time/locale.time.get.byname/get_monthname_wide.pass.cpp
>   libc++ ::
>
> std/localization/locale.categories/category.time/locale.time.get.byname/get_one.pass.cpp
>   libc++ ::
>
> std/localization/locale.categories/category.time/locale.time.get.byname/get_one_wide.pass.cpp
>   libc++ ::
>
> std/localization/locale.categories/category.time/locale.time.put.byname/put1.pass.cpp
> These contain:
> // NetBSD does not support LC_TIME at the moment
> // XFAIL: netbsd
>   libc++ ::
>
> std/localization/locale.categories/facet.numpunct/locale.numpunct.byname/grouping.pass.cpp
>   libc++ ::
>
> std/localization/locale.categories/facet.numpunct/locale.numpunct.byname/thousands_sep.pass.cpp
> These contain:
> // NetBSD does not support LC_NUMERIC at the moment
> // XFAIL: netbsd
>   libc++ :: std/re/re.alg/r

Re: [lldb-dev] [Release-testers] [9.0.0 Release] Release Candidate 2 is here

[Dimitry Andric via lldb-dev]

On 14 Aug 2019, at 10:14, Hans Wennborg via Release-testers 
 wrote:
> 
> 9.0.0-rc2 was tagged yesterday from the release_90 branch at r368683.
> In the Git monorepo it's available as the llvmorg-9.0.0-rc2 tag.

For this rc, I only needed one patch, from:

* https://bugs.llvm.org/show_bug.cgi?id=42894 - FreeBSD needs -pthread link 
flag for dynamic ASan tests

Main test results on amd64-freebsd11:

  
  Unexpected Passing Tests (7):
  AddressSanitizer-i386-freebsd-dynamic :: 
TestCases/interception_failure_test.cc
  AddressSanitizer-x86_64-freebsd-dynamic :: 
TestCases/interception_failure_test.cc
  lldb-Suite :: api/multiple-targets/TestMultipleTargets.py
  lldb-Suite :: functionalities/avoids-fd-leak/TestFdLeak.py
  lldb-Suite :: 
functionalities/data-formatter/data-formatter-skip-summary/TestDataFormatterSkipSummary.py
  lldb-Suite :: lang/cpp/namespace/TestNamespaceLookup.py
  lldb-Suite :: python_api/thread/TestThreadAPI.py

  
  Failing Tests (118):
  AddressSanitizer-Unit :: 
./Asan-i386-calls-Dynamic-Test/AddressSanitizer.ShadowGapTest
  AddressSanitizer-Unit :: 
./Asan-i386-inline-Dynamic-Test/AddressSanitizer.ShadowGapTest
  AddressSanitizer-i386-freebsd :: TestCases/Posix/fread_fwrite.cc
  AddressSanitizer-i386-freebsd-dynamic :: TestCases/Posix/fread_fwrite.cc
  Builtins-i386-freebsd :: floatundixf_test.c
  LLDB :: 
Commands/CommandScriptImmediateOutput/CommandScriptImmediateOutputConsole.test
  LLDB :: 
Commands/CommandScriptImmediateOutput/CommandScriptImmediateOutputFile.test
  LLDB :: Driver/LocalLLDBInit.test
  LLDB :: Driver/TestConvenienceVariables.test
  LLDB :: ExecControl/StopHook/stop-hook-threads.test
  LLDB :: ExecControl/StopHook/stop-hook.test
  LLDB :: Register/x86-64-gp-read.test
  LLDB :: Register/x86-64-gp-write.test
  LLDB :: Register/x86-64-read.test
  LLDB :: Register/x86-64-write.test
  LLDB :: Register/x86-64-ymm-read.test
  LLDB :: Register/x86-64-ymm-write.test
  LLDB :: Register/x86-mm-xmm-read.test
  LLDB :: Register/x86-mm-xmm-write.test
  LLDB :: SymbolFile/DWARF/find-basic-function.cpp
  LLDB :: SymbolFile/DWARF/find-basic-type.cpp
  LLDB :: SymbolFile/DWARF/find-basic-variable.cpp
  LLDB :: tools/lldb-mi/breakpoint/break-insert-enable-pending.test
  LLDB :: tools/lldb-mi/data/data-info-line.test
  LLDB :: tools/lldb-mi/exec/exec-continue.test
  LLDB :: tools/lldb-mi/exec/exec-finish.test
  LLDB :: tools/lldb-mi/exec/exec-interrupt.test
  LLDB :: tools/lldb-mi/exec/exec-next-instruction.test
  LLDB :: tools/lldb-mi/exec/exec-next.test
  LLDB :: tools/lldb-mi/exec/exec-step-instruction.test
  LLVM :: tools/yaml2obj/elf-override-shoffset.yaml
  LLVM :: tools/yaml2obj/elf-override-shsize.yaml
  MemorySanitizer-Unit :: 
./Msan-x86_64-Test/MemorySanitizer.SmallPreAllocatedStackThread
  MemorySanitizer-Unit :: 
./Msan-x86_64-Test/MemorySanitizer.bind_getsockname
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.confstr
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.mbrtowc
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.swprintf
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.valloc
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.SmallPreAllocatedStackThread
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.bind_getsockname
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.confstr
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.mbrtowc
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.swprintf
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.valloc
  MemorySanitizer-X86_64 :: dtls_test.c
  SanitizerCommon-asan-i386-FreeBSD :: Posix/devname_r.cc
  SanitizerCommon-asan-i386-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-asan-x86_64-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-msan-x86_64-FreeBSD :: FreeBSD/capsicum.cc
  SanitizerCommon-msan-x86_64-FreeBSD :: Posix/dedup_token_length_test.cc
  SanitizerCommon-msan-x86_64-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/dedup_token_length_test.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-ubsan-i386-FreeBSD :: Posix/dedup_token_length_test.cc
  SanitizerCommon-ubsan-x86_64-FreeBSD :: Posix/dedup_token_length_test.cc
  ThreadSanitizer-x86_64 :: signal_reset.cc
  ThreadSanitizer-x86_64 :: signal_sync2.cc
  XRay-x86_64-freebsd :: TestCases/Posix/fork_basic_logging.cc
  libFuzzer :: initialize.test
  libFuzzer :: merge-sigusr.test
  libFuzzer :: msan.test
  libc++ :: std/language.support/support.runtime/ctime.pass.cpp
  libc++ :: 
std/localizat

Re: [lldb-dev] [Release-testers] [9.0.0 Release] Release Candidate 3 is here

[Dimitry Andric via lldb-dev]

On 30 Aug 2019, at 18:38, Hans Wennborg via Release-testers 
 wrote:
> 
> 9.0.0-rc3 was tagged today from the release_90 branch at r370450. In
> the Git monorepo, it's tagged as llvmorg-9.0.0-rc3.

For this rc, I used two patches, from:

* https://bugs.llvm.org/show_bug.cgi?id=42892 - After r356631, 
Sanitizer-i386-Test faills to link on FreeBSD
* https://bugs.llvm.org/show_bug.cgi?id=42894 - FreeBSD needs -pthread link 
flag for dynamic ASan tests

Uploaded:

SHA256 (clang+llvm-9.0.0-rc3-amd64-unknown-freebsd11.tar.xz) = 
4b5f1e9c62985fdb397ec66e52a24cef0a20a458cd482f7ae318f6c8aab082b5
SHA256 (clang+llvm-9.0.0-rc3-i386-unknown-freebsd11.tar.xz) = 
d040218dc6db3a6e5d5e520047582c6b006905221725d9a503697a3b74763f96

Main test results on amd64-freebsd11:

  
  Unexpected Passing Tests (6):
  AddressSanitizer-i386-freebsd-dynamic :: 
TestCases/interception_failure_test.cc
  AddressSanitizer-x86_64-freebsd-dynamic :: 
TestCases/interception_failure_test.cc
  lldb-Suite :: api/multiple-targets/TestMultipleTargets.py
  lldb-Suite :: 
functionalities/data-formatter/data-formatter-skip-summary/TestDataFormatterSkipSummary.py
  lldb-Suite :: lang/cpp/namespace/TestNamespaceLookup.py
  lldb-Suite :: python_api/thread/TestThreadAPI.py

  
  Failing Tests (401):
  AddressSanitizer-Unit :: 
./Asan-i386-calls-Dynamic-Test/AddressSanitizer.ShadowGapTest
  AddressSanitizer-Unit :: 
./Asan-i386-inline-Dynamic-Test/AddressSanitizer.ShadowGapTest
  AddressSanitizer-i386-freebsd :: TestCases/Posix/fread_fwrite.cc
  AddressSanitizer-i386-freebsd-dynamic :: TestCases/Posix/fread_fwrite.cc
  Builtins-i386-freebsd :: floatundixf_test.c
  LLDB :: ExecControl/StopHook/stop-hook-threads.test
  LLDB :: ExecControl/StopHook/stop-hook.test
  LLDB :: SymbolFile/DWARF/find-basic-function.cpp
  LLDB :: SymbolFile/DWARF/find-basic-namespace.cpp
  LLDB :: SymbolFile/DWARF/find-basic-variable.cpp
  LLDB :: SymbolFile/DWARF/find-variable-file.cpp
  LLDB :: tools/lldb-mi/exec/exec-next.test
  LLDB :: tools/lldb-mi/exec/exec-step-instruction.test
  LLVM :: tools/yaml2obj/elf-override-shoffset.yaml
  LLVM :: tools/yaml2obj/elf-override-shsize.yaml
  MemorySanitizer-Unit :: 
./Msan-x86_64-Test/MemorySanitizer.SmallPreAllocatedStackThread
  MemorySanitizer-Unit :: 
./Msan-x86_64-Test/MemorySanitizer.bind_getsockname
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.confstr
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.mbrtowc
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.swprintf
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.valloc
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.SmallPreAllocatedStackThread
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.bind_getsockname
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.confstr
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.mbrtowc
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.swprintf
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.valloc
  MemorySanitizer-X86_64 :: dtls_test.c
  SanitizerCommon-asan-i386-FreeBSD :: Posix/devname_r.cc
  SanitizerCommon-asan-i386-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-asan-x86_64-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-msan-x86_64-FreeBSD :: FreeBSD/capsicum.cc
  SanitizerCommon-msan-x86_64-FreeBSD :: Posix/dedup_token_length_test.cc
  SanitizerCommon-msan-x86_64-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: FreeBSD/capsicum.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: FreeBSD/fdevname.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/arc4random.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/dedup_token_length_test.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/devname.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/devname_r.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/dump_instruction_bytes.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fpe.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fputc_putc_putchar.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fputs_puts.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fseek.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fts.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/funopen.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getfsent.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getmntinfo.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getpass.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getusershell.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/illegal_read_test.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/illegal_write_test.cc
  SanitizerComm

Re: [lldb-dev] [Release-testers] [9.0.0 Release] Release Candidate 4 is here

[Dimitry Andric via lldb-dev]

On 10 Sep 2019, at 12:26, Hans Wennborg via Release-testers 
 wrote:
> 
> 9.0.0-rc4 was just tagged from the release_90 branch at r371490. In
> the Git monorepo, it's tagged as llvmorg-9.0.0-rc4.

For this rc, I used two patches, from:

* https://bugs.llvm.org/show_bug.cgi?id=42892 - After r356631, 
Sanitizer-i386-Test faills to link on FreeBSD
* https://bugs.llvm.org/show_bug.cgi?id=42894 - FreeBSD needs -pthread link 
flag for dynamic ASan tests

Uploaded:

SHA256 (clang+llvm-9.0.0-rc4-amd64-unknown-freebsd11.tar.xz) = 
e3ec34f97c26b0cae6833f8c565b011c3a111880da5191f131e2491bcace6960
SHA256 (clang+llvm-9.0.0-rc4-i386-unknown-freebsd11.tar.xz) = 
39e9d341838d8966c187ad4baccc2f7ddc45cb3d0dbb76f46098e1963c4b9f31

Main test results on amd64-freebsd11:

  
  Unexpected Passing Tests (6):
  AddressSanitizer-i386-freebsd-dynamic :: 
TestCases/interception_failure_test.cc
  AddressSanitizer-x86_64-freebsd-dynamic :: 
TestCases/interception_failure_test.cc
  lldb-Suite :: api/multiple-targets/TestMultipleTargets.py
  lldb-Suite :: 
functionalities/data-formatter/data-formatter-skip-summary/TestDataFormatterSkipSummary.py
  lldb-Suite :: lang/cpp/namespace/TestNamespaceLookup.py
  lldb-Suite :: python_api/thread/TestThreadAPI.py

  
  Failing Tests (402):
  AddressSanitizer-Unit :: 
./Asan-i386-calls-Dynamic-Test/AddressSanitizer.ShadowGapTest
  AddressSanitizer-Unit :: 
./Asan-i386-inline-Dynamic-Test/AddressSanitizer.ShadowGapTest
  AddressSanitizer-i386-freebsd :: TestCases/Posix/fread_fwrite.cc
  AddressSanitizer-i386-freebsd-dynamic :: TestCases/Posix/fread_fwrite.cc
  Builtins-i386-freebsd :: floatundixf_test.c
  LLDB :: ExecControl/StopHook/stop-hook-threads.test
  LLDB :: ExecControl/StopHook/stop-hook.test
  LLDB :: Expr/TestIRMemoryMap.test
  LLDB :: SymbolFile/DWARF/debug-names-compressed.cpp
  LLDB :: SymbolFile/DWARF/find-basic-variable.cpp
  LLDB :: SymbolFile/DWARF/find-function-regex.cpp
  LLDB :: SymbolFile/DWARF/find-inline-method.s
  LLDB :: SymbolFile/DWARF/find-variable-dwo.cpp
  LLVM :: tools/yaml2obj/elf-override-shoffset.yaml
  LLVM :: tools/yaml2obj/elf-override-shsize.yaml
  MemorySanitizer-Unit :: 
./Msan-x86_64-Test/MemorySanitizer.SmallPreAllocatedStackThread
  MemorySanitizer-Unit :: 
./Msan-x86_64-Test/MemorySanitizer.bind_getsockname
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.confstr
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.mbrtowc
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.swprintf
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.valloc
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.SmallPreAllocatedStackThread
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.bind_getsockname
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.confstr
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.mbrtowc
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.swprintf
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.valloc
  MemorySanitizer-X86_64 :: dtls_test.c
  Profile-x86_64 :: Posix/instrprof-gcov-fork.test
  SanitizerCommon-asan-i386-FreeBSD :: Posix/devname_r.cc
  SanitizerCommon-asan-i386-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-asan-x86_64-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-msan-x86_64-FreeBSD :: FreeBSD/capsicum.cc
  SanitizerCommon-msan-x86_64-FreeBSD :: Posix/dedup_token_length_test.cc
  SanitizerCommon-msan-x86_64-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: FreeBSD/capsicum.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: FreeBSD/fdevname.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/arc4random.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/dedup_token_length_test.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/devname.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/devname_r.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/dump_instruction_bytes.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fpe.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fputc_putc_putchar.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fputs_puts.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fseek.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fts.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/funopen.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getfsent.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getmntinfo.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getpass.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getusershell.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/illegal_read_test.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/il

Re: [lldb-dev] [Release-testers] [9.0.0 Release] Release Candidate 5 is here

[Dimitry Andric via lldb-dev]

On 13 Sep 2019, at 14:06, Hans Wennborg via Release-testers 
 wrote:
> 
> 9.0.0-rc5 was just tagged from the release_90 branch at r371837. In
> the Git monorepo, it's tagged as llvmorg-9.0.0-rc5.

For this rc, I used two patches, from:

* https://bugs.llvm.org/show_bug.cgi?id=42892 - After r356631, 
Sanitizer-i386-Test faills to link on FreeBSD
* https://bugs.llvm.org/show_bug.cgi?id=42894 - FreeBSD needs -pthread link 
flag for dynamic ASan tests

Uploaded:

SHA256 (clang+llvm-9.0.0-rc5-amd64-unknown-freebsd11.tar.xz) = 
0908ebd68ebcb98981b5ee04de0b5bd934646bbe7d19d6f98b8149f8ca301c13
SHA256 (clang+llvm-9.0.0-rc5-i386-unknown-freebsd11.tar.xz) = 
f163d9557005049e0be05b630196319e936d32d59e186e33c56f41a47e268586

Main test results on amd64-freebsd11:

  
  Unexpected Passing Tests (6):
  AddressSanitizer-i386-freebsd-dynamic :: 
TestCases/interception_failure_test.cc
  AddressSanitizer-x86_64-freebsd-dynamic :: 
TestCases/interception_failure_test.cc
  lldb-Suite :: api/multiple-targets/TestMultipleTargets.py
  lldb-Suite :: 
functionalities/data-formatter/data-formatter-skip-summary/TestDataFormatterSkipSummary.py
  lldb-Suite :: lang/cpp/namespace/TestNamespaceLookup.py
  lldb-Suite :: python_api/thread/TestThreadAPI.py

  
  Failing Tests (400):
  AddressSanitizer-Unit :: 
./Asan-i386-calls-Dynamic-Test/AddressSanitizer.ShadowGapTest
  AddressSanitizer-Unit :: 
./Asan-i386-inline-Dynamic-Test/AddressSanitizer.ShadowGapTest
  AddressSanitizer-i386-freebsd :: TestCases/Posix/fread_fwrite.cc
  AddressSanitizer-i386-freebsd-dynamic :: TestCases/Posix/fread_fwrite.cc
  Builtins-i386-freebsd :: floatundixf_test.c
  LLDB :: ExecControl/StopHook/stop-hook-threads.test
  LLDB :: ExecControl/StopHook/stop-hook.test
  LLDB :: SymbolFile/DWARF/find-basic-function.cpp
  LLDB :: SymbolFile/DWARF/find-basic-namespace.cpp
  LLDB :: SymbolFile/DWARF/find-basic-type.cpp
  LLDB :: SymbolFile/DWARF/find-basic-variable.cpp
  LLDB :: SymbolFile/DWARF/find-variable-file.cpp
  LLDB :: tools/lldb-mi/exec/exec-step-instruction.test
  LLVM :: tools/yaml2obj/elf-override-shoffset.yaml
  LLVM :: tools/yaml2obj/elf-override-shsize.yaml
  MemorySanitizer-Unit :: 
./Msan-x86_64-Test/MemorySanitizer.SmallPreAllocatedStackThread
  MemorySanitizer-Unit :: 
./Msan-x86_64-Test/MemorySanitizer.bind_getsockname
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.confstr
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.mbrtowc
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.swprintf
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.valloc
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.SmallPreAllocatedStackThread
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.bind_getsockname
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.confstr
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.mbrtowc
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.swprintf
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.valloc
  MemorySanitizer-X86_64 :: dtls_test.c
  SanitizerCommon-asan-i386-FreeBSD :: Posix/devname_r.cc
  SanitizerCommon-asan-i386-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-asan-x86_64-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-msan-x86_64-FreeBSD :: FreeBSD/capsicum.cc
  SanitizerCommon-msan-x86_64-FreeBSD :: Posix/dedup_token_length_test.cc
  SanitizerCommon-msan-x86_64-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: FreeBSD/capsicum.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: FreeBSD/fdevname.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/arc4random.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/dedup_token_length_test.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/devname.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/devname_r.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/dump_instruction_bytes.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fpe.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fputc_putc_putchar.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fputs_puts.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fseek.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fts.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/funopen.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getfsent.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getmntinfo.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getpass.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getusershell.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/illegal_read_test.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/illegal_write_test.cc
  SanitizerCo

Re: [lldb-dev] [Release-testers] [9.0.0 Release] Release Candidate 6 is here

[Dimitry Andric via lldb-dev]

On 19 Sep 2019, at 16:51, Hans Wennborg via Release-testers 
 wrote:
> 
> On Tue, Sep 17, 2019 at 4:05 PM Hans Wennborg  wrote:
>> 
>> 9.0.0-rc6 was just tagged from the release_90 branch at r372100. In
>> the Git monorepo, it's tagged as llvmorg-9.0.0-rc6.
> 
> This has now been tagged as the final 9.0.0 release. In the Git
> monorepo, it's tagged as llvmorg-9.0.0.

For the final release of 9.0.0, I used two patches, from:

* https://bugs.llvm.org/show_bug.cgi?id=42892 - After r356631, 
Sanitizer-i386-Test faills to link on FreeBSD
* https://bugs.llvm.org/show_bug.cgi?id=42894 - FreeBSD needs -pthread link 
flag for dynamic ASan tests

Uploaded:

SHA256 (clang+llvm-9.0.0-amd64-unknown-freebsd11.tar.xz) = 
2a1f123a9d992c9719ef7677e127182ca707a5984a929f1c3f34fbb95ffbf6f3
SHA256 (clang+llvm-9.0.0-i386-unknown-freebsd11.tar.xz) = 
2d8d0b712946d6bc76317c4093ce77634ef6d502c343e1f3f6b841401db8fa56

Main test results on amd64-freebsd11:

  
  Unexpected Passing Tests (6):
  AddressSanitizer-i386-freebsd-dynamic :: 
TestCases/interception_failure_test.cc
  AddressSanitizer-x86_64-freebsd-dynamic :: 
TestCases/interception_failure_test.cc
  lldb-Suite :: api/multiple-targets/TestMultipleTargets.py
  lldb-Suite :: 
functionalities/data-formatter/data-formatter-skip-summary/TestDataFormatterSkipSummary.py
  lldb-Suite :: lang/cpp/namespace/TestNamespaceLookup.py
  lldb-Suite :: python_api/thread/TestThreadAPI.py

  
  Failing Tests (399):
  AddressSanitizer-Unit :: 
./Asan-i386-calls-Dynamic-Test/AddressSanitizer.ShadowGapTest
  AddressSanitizer-Unit :: 
./Asan-i386-inline-Dynamic-Test/AddressSanitizer.ShadowGapTest
  AddressSanitizer-i386-freebsd :: TestCases/Posix/fread_fwrite.cc
  AddressSanitizer-i386-freebsd-dynamic :: TestCases/Posix/fread_fwrite.cc
  Builtins-i386-freebsd :: floatundixf_test.c
  LLDB :: ExecControl/StopHook/stop-hook-threads.test
  LLDB :: ExecControl/StopHook/stop-hook.test
  LLDB :: SymbolFile/DWARF/find-basic-function.cpp
  LLDB :: SymbolFile/DWARF/find-basic-namespace.cpp
  LLDB :: SymbolFile/DWARF/find-basic-type.cpp
  LLDB :: SymbolFile/DWARF/find-basic-variable.cpp
  LLDB :: SymbolFile/DWARF/find-variable-file.cpp
  LLVM :: tools/yaml2obj/elf-override-shoffset.yaml
  LLVM :: tools/yaml2obj/elf-override-shsize.yaml
  MemorySanitizer-Unit :: 
./Msan-x86_64-Test/MemorySanitizer.SmallPreAllocatedStackThread
  MemorySanitizer-Unit :: 
./Msan-x86_64-Test/MemorySanitizer.bind_getsockname
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.confstr
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.mbrtowc
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.swprintf
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.valloc
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.SmallPreAllocatedStackThread
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.bind_getsockname
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.confstr
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.mbrtowc
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.swprintf
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.valloc
  MemorySanitizer-X86_64 :: dtls_test.c
  SanitizerCommon-asan-i386-FreeBSD :: Posix/devname_r.cc
  SanitizerCommon-asan-i386-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-asan-x86_64-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-msan-x86_64-FreeBSD :: FreeBSD/capsicum.cc
  SanitizerCommon-msan-x86_64-FreeBSD :: Posix/dedup_token_length_test.cc
  SanitizerCommon-msan-x86_64-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: FreeBSD/capsicum.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: FreeBSD/fdevname.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/arc4random.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/dedup_token_length_test.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/devname.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/devname_r.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/dump_instruction_bytes.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fpe.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fputc_putc_putchar.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fputs_puts.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fseek.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fts.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/funopen.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getfsent.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getmntinfo.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getpass.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getusershell.cc
  SanitizerCommon-tsan-x86_64-Free

Re: [lldb-dev] [Release-testers] LLVM 9.0.1-rc1 Release has been tagged

[Dimitry Andric via lldb-dev]

On 23 Nov 2019, at 07:20, Tom Stellard via Release-testers 
 wrote:
> 
> I've tagged the LLVM 9.0.1-rc1 release.  Testers can begin testing and upload
> binaries.  I've also updated the test-release.sh script to pull from GitHub
> instead of SVN, if you run into any issues with the new script, let me know.

For this rc, I used two patches, from:

* https://bugs.llvm.org/show_bug.cgi?id=42892 - After r356631, 
Sanitizer-i386-Test faills to link on FreeBSD
* https://bugs.llvm.org/show_bug.cgi?id=42894 - FreeBSD needs -pthread link 
flag for dynamic ASan tests

Uploaded:

SHA256 (clang+llvm-9.0.1-rc1-amd64-unknown-freebsd11.tar.xz) = 
daeac75e0b6015940cf945d4e0bd173787db8b16e42c20ae0c5deafdadeeb1e7
SHA256 (clang+llvm-9.0.1-rc1-i386-unknown-freebsd11.tar.xz) = 
b29869f2aed037926c98ac66d3ad145ffb42137b317bbcd6e1927ed1de08794f

Main test results on amd64-freebsd11:

  
  Testing Time: 7179.26s
  
  Unexpected Passing Tests (6):
  AddressSanitizer-i386-freebsd-dynamic :: 
TestCases/interception_failure_test.cc
  AddressSanitizer-x86_64-freebsd-dynamic :: 
TestCases/interception_failure_test.cc
  lldb-Suite :: api/multiple-targets/TestMultipleTargets.py
  lldb-Suite :: 
functionalities/data-formatter/data-formatter-skip-summary/TestDataFormatterSkipSummary.py
  lldb-Suite :: lang/cpp/namespace/TestNamespaceLookup.py
  lldb-Suite :: python_api/thread/TestThreadAPI.py

  
  Failing Tests (475):
  AddressSanitizer-Unit :: 
./Asan-i386-calls-Dynamic-Test/AddressSanitizer.ShadowGapTest
  AddressSanitizer-Unit :: 
./Asan-i386-inline-Dynamic-Test/AddressSanitizer.ShadowGapTest
  AddressSanitizer-i386-freebsd :: TestCases/Posix/fread_fwrite.cc
  AddressSanitizer-i386-freebsd-dynamic :: TestCases/Posix/fread_fwrite.cc
  Builtins-i386-freebsd :: floatundixf_test.c
  LLDB :: ExecControl/StopHook/stop-hook-threads.test
  LLDB :: ExecControl/StopHook/stop-hook.test
  LLDB :: SymbolFile/DWARF/find-basic-namespace.cpp
  LLDB :: SymbolFile/DWARF/find-basic-variable.cpp
  LLDB :: SymbolFile/DWARF/find-method.cpp
  LLDB :: tools/lldb-mi/exec/exec-step.test
  LLVM :: tools/yaml2obj/elf-override-shoffset.yaml
  LLVM :: tools/yaml2obj/elf-override-shsize.yaml
  MemorySanitizer-Unit :: 
./Msan-x86_64-Test/MemorySanitizer.SmallPreAllocatedStackThread
  MemorySanitizer-Unit :: 
./Msan-x86_64-Test/MemorySanitizer.bind_getsockname
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.confstr
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.mbrtowc
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.swprintf
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.valloc
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.SmallPreAllocatedStackThread
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.bind_getsockname
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.confstr
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.mbrtowc
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.swprintf
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.valloc
  MemorySanitizer-X86_64 :: dtls_test.c
  MemorySanitizer-lld-X86_64 :: dtls_test.c
  SanitizerCommon-asan-i386-FreeBSD :: Posix/devname_r.cc
  SanitizerCommon-asan-i386-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-asan-x86_64-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-msan-x86_64-FreeBSD :: FreeBSD/capsicum.cc
  SanitizerCommon-msan-x86_64-FreeBSD :: Posix/dedup_token_length_test.cc
  SanitizerCommon-msan-x86_64-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: FreeBSD/capsicum.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: FreeBSD/fdevname.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/arc4random.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/dedup_token_length_test.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/devname.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/devname_r.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/dump_instruction_bytes.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fpe.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fputc_putc_putchar.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fputs_puts.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fseek.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fts.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/funopen.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getfsent.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getmntinfo.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getpass.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getusershell.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/illegal_read_test.cc
  S

Re: [lldb-dev] [Release-testers] LLVM 9.0.1-rc2 has been tagged

[Dimitry Andric via lldb-dev]

On 7 Dec 2019, at 04:03, Tom Stellard via Release-testers 
 wrote:
> I've tagged LLVM 9.0.1-rc2.  Testers can begin testing and uploading binaries.
> If all goes well, this will be the last -rc.

For this rc, I used two patches, from:

* https://bugs.llvm.org/show_bug.cgi?id=42892 - After r356631, 
Sanitizer-i386-Test faills to link on FreeBSD
* https://bugs.llvm.org/show_bug.cgi?id=42894 - FreeBSD needs -pthread link 
flag for dynamic ASan tests

Uploaded:

SHA256 (clang+llvm-9.0.1-rc2-amd64-unknown-freebsd11.tar.xz) = 
72e3a872d5ff2311ec1d68e40dcc86022655c87e24583339b8331744647d8982
SHA256 (clang+llvm-9.0.1-rc2-i386-unknown-freebsd11.tar.xz) = 
b0bbcdc7d164502620fd4f11ef7e16e58c18aadf94441aea38d1890b951ac9da

Main test results on amd64-freebsd11:

  
  Testing Time: 5747.97s
  
  Unexpected Passing Tests (6):
  AddressSanitizer-i386-freebsd-dynamic :: 
TestCases/interception_failure_test.cc
  AddressSanitizer-x86_64-freebsd-dynamic :: 
TestCases/interception_failure_test.cc
  lldb-Suite :: api/multiple-targets/TestMultipleTargets.py
  lldb-Suite :: 
functionalities/data-formatter/data-formatter-skip-summary/TestDataFormatterSkipSummary.py
  lldb-Suite :: lang/cpp/namespace/TestNamespaceLookup.py
  lldb-Suite :: python_api/thread/TestThreadAPI.py

  
  Failing Tests (475):
  AddressSanitizer-Unit :: 
./Asan-i386-calls-Dynamic-Test/AddressSanitizer.ShadowGapTest
  AddressSanitizer-Unit :: 
./Asan-i386-inline-Dynamic-Test/AddressSanitizer.ShadowGapTest
  AddressSanitizer-i386-freebsd :: TestCases/Posix/fread_fwrite.cc
  AddressSanitizer-i386-freebsd-dynamic :: TestCases/Posix/fread_fwrite.cc
  Builtins-i386-freebsd :: floatundixf_test.c
  LLDB :: ExecControl/StopHook/stop-hook-threads.test
  LLDB :: ExecControl/StopHook/stop-hook.test
  LLDB :: Expr/TestIRMemoryMap.test
  LLDB :: SymbolFile/DWARF/find-basic-function.cpp
  LLDB :: SymbolFile/DWARF/find-basic-namespace.cpp
  LLDB :: SymbolFile/DWARF/find-basic-type.cpp
  LLDB :: SymbolFile/DWARF/find-basic-variable.cpp
  LLDB :: SymbolFile/DWARF/find-function-regex.cpp
  LLDB :: SymbolFile/DWARF/find-variable-file.cpp
  LLDB :: tools/lldb-mi/data/data-info-line.test
  LLVM :: tools/yaml2obj/elf-override-shoffset.yaml
  LLVM :: tools/yaml2obj/elf-override-shsize.yaml
  MemorySanitizer-Unit :: 
./Msan-x86_64-Test/MemorySanitizer.SmallPreAllocatedStackThread
  MemorySanitizer-Unit :: 
./Msan-x86_64-Test/MemorySanitizer.bind_getsockname
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.confstr
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.mbrtowc
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.swprintf
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.valloc
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.SmallPreAllocatedStackThread
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.bind_getsockname
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.confstr
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.mbrtowc
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.swprintf
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.valloc
  MemorySanitizer-X86_64 :: dtls_test.c
  MemorySanitizer-lld-X86_64 :: dtls_test.c
  SanitizerCommon-asan-i386-FreeBSD :: Posix/devname_r.cc
  SanitizerCommon-asan-i386-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-asan-x86_64-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-msan-x86_64-FreeBSD :: FreeBSD/capsicum.cc
  SanitizerCommon-msan-x86_64-FreeBSD :: Posix/dedup_token_length_test.cc
  SanitizerCommon-msan-x86_64-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: FreeBSD/capsicum.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: FreeBSD/fdevname.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/arc4random.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/dedup_token_length_test.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/devname.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/devname_r.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/dump_instruction_bytes.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fpe.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fputc_putc_putchar.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fputs_puts.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fseek.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fts.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/funopen.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getfsent.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getmntinfo.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getpass.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: P

Re: [lldb-dev] [Release-testers] LLVM 9.0.1-rc3 has been tagged

[Dimitry Andric via lldb-dev]

On 14 Dec 2019, at 07:34, Tom Stellard via Release-testers 
 wrote:
> 
> I've just tagged LLVM 9.0.1-rc3.  Testers can begin testing and uploading
> binaries.  This will be the last release candidate unless there is a
> major problem.  I'm planning to tag the final release on Dec 19.

For this rc, I used two patches, from:

* https://bugs.llvm.org/show_bug.cgi?id=42892 - After r356631, 
Sanitizer-i386-Test faills to link on FreeBSD
* https://bugs.llvm.org/show_bug.cgi?id=42894 - FreeBSD needs -pthread link 
flag for dynamic ASan tests

Uploaded:

SHA256 (clang+llvm-9.0.1-rc3-amd64-unknown-freebsd11.tar.xz) = 
534f119f9100469899cd4d1e02c6a65f724d560e38d3d27aa99797b16379e25a
SHA256 (clang+llvm-9.0.1-rc3-i386-unknown-freebsd11.tar.xz) = 
874b707b87d07e9f73021e192d935fb8b82d81d10b06af9d591204ebc865c02b

Main test results on amd64-freebsd11:

  
  Testing Time: 5223.66s
  
  Unexpected Passing Tests (6):
  AddressSanitizer-i386-freebsd-dynamic :: 
TestCases/interception_failure_test.cc
  AddressSanitizer-x86_64-freebsd-dynamic :: 
TestCases/interception_failure_test.cc
  lldb-Suite :: api/multiple-targets/TestMultipleTargets.py
  lldb-Suite :: 
functionalities/data-formatter/data-formatter-skip-summary/TestDataFormatterSkipSummary.py
  lldb-Suite :: lang/cpp/namespace/TestNamespaceLookup.py
  lldb-Suite :: python_api/thread/TestThreadAPI.py

  
  Failing Tests (476):
  AddressSanitizer-Unit :: 
./Asan-i386-calls-Dynamic-Test/AddressSanitizer.ShadowGapTest
  AddressSanitizer-Unit :: 
./Asan-i386-inline-Dynamic-Test/AddressSanitizer.ShadowGapTest
  AddressSanitizer-i386-freebsd :: TestCases/Posix/fread_fwrite.cc
  AddressSanitizer-i386-freebsd-dynamic :: TestCases/Posix/fread_fwrite.cc
  Builtins-i386-freebsd :: floatundixf_test.c
  LLDB :: ExecControl/StopHook/stop-hook-threads.test
  LLDB :: ExecControl/StopHook/stop-hook.test
  LLDB :: SymbolFile/DWARF/dwarf5-partial-index.cpp
  LLDB :: SymbolFile/DWARF/find-basic-function.cpp
  LLDB :: SymbolFile/DWARF/find-basic-namespace.cpp
  LLDB :: SymbolFile/DWARF/find-basic-type.cpp
  LLDB :: SymbolFile/DWARF/find-basic-variable.cpp
  LLDB :: SymbolFile/DWARF/find-method.cpp
  LLDB :: SymbolFile/DWARF/find-variable-file.cpp
  LLDB :: tools/lldb-mi/exec/exec-step.test
  LLVM :: tools/yaml2obj/elf-override-shoffset.yaml
  LLVM :: tools/yaml2obj/elf-override-shsize.yaml
  MemorySanitizer-Unit :: 
./Msan-x86_64-Test/MemorySanitizer.SmallPreAllocatedStackThread
  MemorySanitizer-Unit :: 
./Msan-x86_64-Test/MemorySanitizer.bind_getsockname
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.confstr
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.mbrtowc
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.swprintf
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.valloc
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.SmallPreAllocatedStackThread
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.bind_getsockname
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.confstr
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.mbrtowc
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.swprintf
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.valloc
  MemorySanitizer-X86_64 :: dtls_test.c
  MemorySanitizer-lld-X86_64 :: dtls_test.c
  SanitizerCommon-asan-i386-FreeBSD :: Posix/devname_r.cc
  SanitizerCommon-asan-i386-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-asan-x86_64-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-msan-x86_64-FreeBSD :: FreeBSD/capsicum.cc
  SanitizerCommon-msan-x86_64-FreeBSD :: Posix/dedup_token_length_test.cc
  SanitizerCommon-msan-x86_64-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: FreeBSD/capsicum.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: FreeBSD/fdevname.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/arc4random.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/dedup_token_length_test.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/devname.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/devname_r.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/dump_instruction_bytes.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fpe.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fputc_putc_putchar.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fputs_puts.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fseek.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fts.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/funopen.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getfsent.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getmntinfo.cc
  Sanitizer

Re: [lldb-dev] [Release-testers] LLVM 9.0.1-rc3 has been tagged

[Dimitry Andric via lldb-dev]

On 19 Dec 2019, at 23:51, Tom Stellard  wrote:
> 
> On 12/16/2019 10:30 AM, Dimitry Andric wrote:
>> On 14 Dec 2019, at 07:34, Tom Stellard via Release-testers 
>>  wrote:
>>> 
>>> I've just tagged LLVM 9.0.1-rc3.  Testers can begin testing and uploading
>>> binaries.  This will be the last release candidate unless there is a
>>> major problem.  I'm planning to tag the final release on Dec 19.
>> 
>> For this rc, I used two patches, from:
>> 
>> * https://bugs.llvm.org/show_bug.cgi?id=42892 - After r356631, 
>> Sanitizer-i386-Test faills to link on FreeBSD
>> * https://bugs.llvm.org/show_bug.cgi?id=42894 - FreeBSD needs -pthread link 
>> flag for dynamic ASan tests
>> 
>> Uploaded:
>> 
>> SHA256 (clang+llvm-9.0.1-rc3-amd64-unknown-freebsd11.tar.xz) = 
>> 534f119f9100469899cd4d1e02c6a65f724d560e38d3d27aa99797b16379e25a
>> SHA256 (clang+llvm-9.0.1-rc3-i386-unknown-freebsd11.tar.xz) = 
>> 874b707b87d07e9f73021e192d935fb8b82d81d10b06af9d591204ebc865c02b
>> 
> 
> Do these binaries include those patches?

The patches themselves are not in the tarball.  Attaching them for reference.

-Dimitry


fix-clang-1.diff
Description: Binary data


fix-compiler-rt-1.diff
Description: Binary data


signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] LLVM 9.0.1-final has been tagged

[Dimitry Andric via lldb-dev]

On 20 Dec 2019, at 05:06, Tom Stellard via Release-testers 
 wrote:
> 
> I've just tagged the 9.0.1-final release.  Testers can begin uploading 
> binaries.

For the final build, I used two patches, from:

* https://bugs.llvm.org/show_bug.cgi?id=42892 - After r356631, 
Sanitizer-i386-Test faills to link on FreeBSD
* https://bugs.llvm.org/show_bug.cgi?id=42894 - FreeBSD needs -pthread link 
flag for dynamic ASan tests

Uploaded:

SHA256 (clang+llvm-9.0.1-amd64-unknown-freebsd11.tar.xz) = 
4e23de41f67c26f67077e24cf8009e42c59c52c41e930faebfc112a63f7dfd57
SHA256 (clang+llvm-9.0.1-i386-unknown-freebsd11.tar.xz) = 
2947ffb55545230b7fc9a25275ffc6e6653b749a3b6c9f105073541593b0fcba

Main test results on amd64-freebsd11:


Testing Time: 4610.29s

Unexpected Passing Tests (6):
AddressSanitizer-i386-freebsd-dynamic :: 
TestCases/interception_failure_test.cc
AddressSanitizer-x86_64-freebsd-dynamic :: 
TestCases/interception_failure_test.cc
lldb-Suite :: api/multiple-targets/TestMultipleTargets.py
lldb-Suite :: 
functionalities/data-formatter/data-formatter-skip-summary/TestDataFormatterSkipSummary.py
lldb-Suite :: lang/cpp/namespace/TestNamespaceLookup.py
lldb-Suite :: python_api/thread/TestThreadAPI.py


Failing Tests (479):
AddressSanitizer-Unit :: 
./Asan-i386-calls-Dynamic-Test/AddressSanitizer.ShadowGapTest
AddressSanitizer-Unit :: 
./Asan-i386-inline-Dynamic-Test/AddressSanitizer.ShadowGapTest
AddressSanitizer-i386-freebsd :: TestCases/Posix/fread_fwrite.cc
AddressSanitizer-i386-freebsd-dynamic :: TestCases/Posix/fread_fwrite.cc
Builtins-i386-freebsd :: floatundixf_test.c
LLDB :: ExecControl/StopHook/stop-hook-threads.test
LLDB :: ExecControl/StopHook/stop-hook.test
LLDB :: SymbolFile/DWARF/dwarf5-partial-index.cpp
LLDB :: SymbolFile/DWARF/find-basic-function.cpp
LLDB :: SymbolFile/DWARF/find-basic-namespace.cpp
LLDB :: SymbolFile/DWARF/find-basic-type.cpp
LLDB :: SymbolFile/DWARF/find-basic-variable.cpp
LLDB :: SymbolFile/DWARF/find-inline-method.s
LLDB :: SymbolFile/DWARF/find-variable-dwo.cpp
LLDB :: SymbolFile/DWARF/find-variable-file.cpp
LLDB :: tools/lldb-mi/breakpoint/break-insert.test
LLDB :: tools/lldb-mi/data/data-info-line.test
LLDB :: tools/lldb-mi/exec/exec-next.test
LLVM :: tools/yaml2obj/elf-override-shoffset.yaml
LLVM :: tools/yaml2obj/elf-override-shsize.yaml
MemorySanitizer-Unit :: 
./Msan-x86_64-Test/MemorySanitizer.SmallPreAllocatedStackThread
MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.bind_getsockname
MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.confstr
MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.mbrtowc
MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.swprintf
MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.valloc
MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.SmallPreAllocatedStackThread
MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.bind_getsockname
MemorySanitizer-Unit :: ./Msan-x86_64-with-call-Test/MemorySanitizer.confstr
MemorySanitizer-Unit :: ./Msan-x86_64-with-call-Test/MemorySanitizer.mbrtowc
MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.swprintf
MemorySanitizer-Unit :: ./Msan-x86_64-with-call-Test/MemorySanitizer.valloc
MemorySanitizer-X86_64 :: dtls_test.c
MemorySanitizer-lld-X86_64 :: dtls_test.c
SanitizerCommon-asan-i386-FreeBSD :: Posix/devname_r.cc
SanitizerCommon-asan-i386-FreeBSD :: Posix/weak_hook_test.cc
SanitizerCommon-asan-x86_64-FreeBSD :: Posix/weak_hook_test.cc
SanitizerCommon-msan-x86_64-FreeBSD :: FreeBSD/capsicum.cc
SanitizerCommon-msan-x86_64-FreeBSD :: Posix/dedup_token_length_test.cc
SanitizerCommon-msan-x86_64-FreeBSD :: Posix/weak_hook_test.cc
SanitizerCommon-tsan-x86_64-FreeBSD :: FreeBSD/capsicum.cc
SanitizerCommon-tsan-x86_64-FreeBSD :: FreeBSD/fdevname.cc
SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/arc4random.cc
SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/dedup_token_length_test.cc
SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/devname.cc
SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/devname_r.cc
SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/dump_instruction_bytes.cc
SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fpe.cc
SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fputc_putc_putchar.cc
SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fputs_puts.cc
SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fseek.cc
SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fts.cc
SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/funopen.cc
SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getfsent.cc
SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getmntinfo.cc
SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getpass.cc
SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getu

Re: [lldb-dev] [Release-testers] [10.0.0 Release] Release Candidate 1 is here

[Dimitry Andric via lldb-dev]

On 30 Jan 2020, at 20:38, Hans Wennborg via Release-testers 
 wrote:
> 
> It took a bit longer than planned due to master being a somewhat
> unstable at the branch point, but Release Candidate 1 has now been
> tagged as llvmorg-10.0.0-rc1.

For this rc, I used three patches, which are attached.

Main results on amd64-freebsd11 (I will post i386 results as they become
available):

  Expected Passes: 67894
  Expected Failures  : 268
  Unsupported Tests  : 4653
  Unexpected Passes  : 5
  Unexpected Failures: 541
  Individual Timeouts: 18

Uploaded:
SHA256 (clang+llvm-10.0.0-rc1-amd64-unknown-freebsd11.tar.xz) = 
751f2d86eede35a201db524a78ebb0e9d48b71d120b44153f961edb666d30c96

Unfortunately the test-suite did not build at all, as all the Bitcode
compilations failed with segfaults, similar to the following run under
gdb:

Starting program: 
/home/dim/llvm/10.0.0/rc1/Phase3/Release/llvmCore-10.0.0-rc1.install/usr/local/bin/clang++
 -DNDEBUG -O3 -DNDEBUG -w -Werror=date-time -std=c++11 -MD -MT 
Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/__/common/x86_halide_runtime.bc.o
 -MF 
Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/__/common/x86_halide_runtime.bc.o.d
 -o 
Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/__/common/x86_halide_runtime.bc.o
 -c 
/home/dim/llvm/10.0.0/rc1/llvm-test-suite/Bitcode/Benchmarks/Halide/common/x86_halide_runtime.bc

Program received signal SIGSEGV, Segmentation fault.
0x0001000f in ?? ()
(gdb) bt
#0  0x0001000f in ?? ()
#1  0x028ca9c0 in 
llvm::AAResultsWrapperPass::runOnFunction(llvm::Function&) ()
#2  0x02e8edc0 in llvm::FPPassManager::runOnFunction(llvm::Function&) ()
#3  0x02e8f1d3 in llvm::FPPassManager::runOnModule(llvm::Module&) ()
#4  0x02e8f6a9 in llvm::legacy::PassManagerImpl::run(llvm::Module&) ()
#5  0x035de7dc in clang::EmitBackendOutput(clang::DiagnosticsEngine&, 
clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, 
clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout 
const&, llvm::Module*, clang::BackendAction, 
std::__1::unique_ptr >) ()
#6  0x03c17e67 in clang::CodeGenAction::ExecuteAction() ()
#7  0x03b7abca in clang::FrontendAction::Execute() ()
#8  0x03aea761 in 
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) ()
#9  0x03c12905 in 
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) ()
#10 0x01cbaf0e in cc1_main(llvm::ArrayRef, char const*, 
void*) ()
#11 0x01cb8f65 in ExecuteCC1Tool(llvm::SmallVectorImpl&) ()
#12 0x039eb297 in void llvm::function_ref::callback_fn
 >, std::__1::basic_string, 
std::__1::allocator >*, bool*) const::$_1>(long) ()
#13 0x033e406a in 
llvm::CrashRecoveryContext::RunSafely(llvm::function_ref) ()
#14 0x039ea7f0 in 
clang::driver::CC1Command::Execute(llvm::ArrayRef
 >, std::__1::basic_string, 
std::__1::allocator >*, bool*) const ()
#15 0x039bfc5c in 
clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, 
clang::driver::Command const*&) const ()
#16 0x039c01ac in 
clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, 
llvm::SmallVectorImpl >&) 
const ()
#17 0x039d336c in 
clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, 
llvm::SmallVectorImpl >&) ()
#18 0x01cb884f in main ()

Looks like the bitcode compilation path is totally busted?  Anybody know
an open bug for this?

-Dimitry



fix-clang-1.diff
Description: Binary data


fix-compiler-rt-1.diff
Description: Binary data


fix-test-suite-1.diff
Description: Binary data


signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [10.0.0 Release] Release Candidate 1 is here

[Dimitry Andric via lldb-dev]

On 3 Feb 2020, at 10:57, Hans Wennborg  wrote:
> 
> On Fri, Jan 31, 2020 at 9:37 PM Dimitry Andric  wrote:
...
>> Unfortunately the test-suite did not build at all, as all the Bitcode
>> compilations failed with segfaults, similar to the following run under
>> gdb:
>> 
>> Starting program: 
>> /home/dim/llvm/10.0.0/rc1/Phase3/Release/llvmCore-10.0.0-rc1.install/usr/local/bin/clang++
>>  -DNDEBUG -O3 -DNDEBUG -w -Werror=date-time -std=c++11 -MD -MT 
>> Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/__/common/x86_halide_runtime.bc.o
>>  -MF 
>> Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/__/common/x86_halide_runtime.bc.o.d
>>  -o 
>> Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/__/common/x86_halide_runtime.bc.o
>>  -c 
>> /home/dim/llvm/10.0.0/rc1/llvm-test-suite/Bitcode/Benchmarks/Halide/common/x86_halide_runtime.bc
>> 
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0001000f in ?? ()
>> (gdb) bt
>> #0  0x0001000f in ?? ()
>> #1  0x028ca9c0 in 
>> llvm::AAResultsWrapperPass::runOnFunction(llvm::Function&) ()
>> #2  0x02e8edc0 in 
>> llvm::FPPassManager::runOnFunction(llvm::Function&) ()
>> #3  0x02e8f1d3 in llvm::FPPassManager::runOnModule(llvm::Module&) ()
>> #4  0x02e8f6a9 in llvm::legacy::PassManagerImpl::run(llvm::Module&) 
>> ()
>> #5  0x035de7dc in 
>> clang::EmitBackendOutput(clang::DiagnosticsEngine&, 
>> clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, 
>> clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout 
>> const&, llvm::Module*, clang::BackendAction, 
>> std::__1::unique_ptr> std::__1::default_delete >) ()
>> #6  0x03c17e67 in clang::CodeGenAction::ExecuteAction() ()
>> #7  0x03b7abca in clang::FrontendAction::Execute() ()
>> #8  0x03aea761 in 
>> clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) ()
>> #9  0x03c12905 in 
>> clang::ExecuteCompilerInvocation(clang::CompilerInstance*) ()
>> #10 0x01cbaf0e in cc1_main(llvm::ArrayRef, char const*, 
>> void*) ()
>> #11 0x01cb8f65 in ExecuteCC1Tool(llvm::SmallVectorImpl> const*>&) ()
>> #12 0x039eb297 in void llvm::function_ref> ()>::callback_fn
>>  >, std::__1::basic_string, 
>> std::__1::allocator >*, bool*) const::$_1>(long) ()
>> #13 0x033e406a in 
>> llvm::CrashRecoveryContext::RunSafely(llvm::function_ref) ()
>> #14 0x039ea7f0 in 
>> clang::driver::CC1Command::Execute(llvm::ArrayRef
>>  >, std::__1::basic_string, 
>> std::__1::allocator >*, bool*) const ()
>> #15 0x039bfc5c in 
>> clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, 
>> clang::driver::Command const*&) const ()
>> #16 0x039c01ac in 
>> clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, 
>> llvm::SmallVectorImpl >&) 
>> const ()
>> #17 0x039d336c in 
>> clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, 
>> llvm::SmallVectorImpl >&) 
>> ()
>> #18 0x01cb884f in main ()
>> 
>> Looks like the bitcode compilation path is totally busted?  Anybody know
>> an open bug for this?
> 
> I haven't seen one, but I'm behind on email. Can you please file one
> to make sure this gets tracked?

Filed .  I didn't have a
debug build of clang, so not a really informative backtrace yet.

I suppose the pre-supplied .bc files don't really get processed well by
recent versions of clang.  I hope that others can reproduce this.

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [10.0.0 Release] Release Candidate 1 is here

[Dimitry Andric via lldb-dev]

On 30 Jan 2020, at 20:38, Hans Wennborg via Release-testers 
 wrote:
> 
> It took a bit longer than planned due to master being a somewhat
> unstable at the branch point, but Release Candidate 1 has now been
> tagged as llvmorg-10.0.0-rc1.

I tried building rc1 for 32-bit FreeBSD, but ran into a compile error in mlir:

/home/dim/llvm/10.0.0/rc1/llvm-project/mlir/lib/Transforms/DialectConversion.cpp:787:67:
 error: non-constant-expression cannot be narrowed from type 'unsigned int' to 
'Region::iterator::difference_type' (aka 'int') in initializer list 
[-Wc++11-narrowing]
blockActions.push_back(BlockAction::getMove(&block, {®ion, position}));
  ^~~~
/home/dim/llvm/10.0.0/rc1/llvm-project/mlir/lib/Transforms/DialectConversion.cpp:787:67:
 note: insert an explicit cast to silence this issue
blockActions.push_back(BlockAction::getMove(&block, {®ion, position}));
  ^~~~
  
static_cast( )
1 error generated.

I submitted https://bugs.llvm.org/show_bug.cgi?id=44767 for this.

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [10.0.0 Release] Release Candidate 1 is here

[Dimitry Andric via lldb-dev]

On 4 Feb 2020, at 12:06, Dimitry Andric via Release-testers 
 wrote:
> 
> On 30 Jan 2020, at 20:38, Hans Wennborg via Release-testers 
>  wrote:
>> 
>> It took a bit longer than planned due to master being a somewhat
>> unstable at the branch point, but Release Candidate 1 has now been
>> tagged as llvmorg-10.0.0-rc1.
> 
> I tried building rc1 for 32-bit FreeBSD, but ran into a compile error in mlir:

For the i386 build of this rc, I used four patches, which are attached.

Main results on i386-freebsd11:

  Expected Passes: 64948
  Expected Failures  : 251
  Unsupported Tests  : 3082
  Unresolved Tests   : 1
  Unexpected Passes  : 5
  Unexpected Failures: 232
  Individual Timeouts: 10

Uploaded:
SHA256 (clang+llvm-10.0.0-rc1-i386-unknown-freebsd11.tar.xz) = 
2ae94f692d58ecc6833c76a809d2aa4fbc35d597ba7be355f2d15aef10d8b6db

Building the test-suite results in the same segfaults as on amd64, which
is tracked in https://bugs.llvm.org/show_bug.cgi?id=44763.

Note that the test-suite never fully built on i386 anyway, due to its
hardcoded use of SSE instructions, so this is not really a big
regression. :-)

-Dimitry


fix-clang-1.diff
Description: Binary data


fix-compiler-rt-1.diff
Description: Binary data


fix-mlir-1.diff
Description: Binary data


fix-test-suite-1.diff
Description: Binary data


signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [cfe-dev] [10.0.0 Release] Release Candidate 1 is here

[Dimitry Andric via lldb-dev]

On 6 Feb 2020, at 11:16, Yvan Roux via Release-testers 
 wrote:
...
> And a bunch of errors in the testsuite:
> 
> FAILED: 
> Bitcode/simd_ops/CMakeFiles/simd_ops_test_op_usubl_1306.dir/AArch64_halide_runtime.bc.o
> /home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc1/test-suite-build/tools/timeit
> --summary 
> Bitcode/simd_ops/CMakeFiles/simd_ops_test_op_usubl_1306.dir/AArch64_halide_runtime.bc.o.time
> /home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc1/Phase3/Release/llvmCore-10.0.0-rc1.install/usr/local/bin/clang++
> -DNDEBUG  -O3 -DNDEBUG   -w -Werror=date-time -MD -MT
> Bitcode/simd_ops/CMakeFiles/simd_ops_test_op_usubl_1306.dir/AArch64_halide_runtime.bc.o
> -MF 
> Bitcode/simd_ops/CMakeFiles/simd_ops_test_op_usubl_1306.dir/AArch64_halide_runtime.bc.o.d
> -o 
> Bitcode/simd_ops/CMakeFiles/simd_ops_test_op_usubl_1306.dir/AArch64_halide_runtime.bc.o
> -c 
> /home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc1/llvm-test-suite/Bitcode/simd_ops/AArch64_halide_runtime.bc
> double free or corruption (fasttop)
> Stack dump:
> 0. Program arguments:
> /home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc1/Phase3/Release/llvmCore-10.0.0-rc1.install/usr/local/bin/clang++
> -DNDEBUG -O3 -DNDEBUG -w -Werror=date-time -MD -MT
> Bitcode/simd_ops/CMakeFiles/simd_ops_test_op_usubl_1306.dir/AArch64_halide_runtime.bc.o
> -MF 
> Bitcode/simd_ops/CMakeFiles/simd_ops_test_op_usubl_1306.dir/AArch64_halide_runtime.bc.o.d
> -o 
> Bitcode/simd_ops/CMakeFiles/simd_ops_test_op_usubl_1306.dir/AArch64_halide_runtime.bc.o
> -c 
> /home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc1/llvm-test-suite/Bitcode/simd_ops/AArch64_halide_runtime.bc
> 1. Per-module optimization passes
> 2. Running pass 'Global Variable Optimizer' on module
> '/home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc1/llvm-test-suite/Bitcode/simd_ops/AArch64_halide_runtime.bc'.
> malloc_consolidate(): invalid chunk size
> /home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc1/test-suite-build/tools/timeit:
> error: child terminated by signal 6

Yes, this looks almost certainly like 
https://bugs.llvm.org/show_bug.cgi?id=44763.

From the last lines of your output, I assume it is some sort of double
free issue.  Might be worth running it under valgrind, or with ASan
enabled?

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [10.0.0 Release] Release Candidate 2 is here

[Dimitry Andric via lldb-dev]

On 13 Feb 2020, at 23:34, Hans Wennborg via Release-testers 
 wrote:
> 
> Release Candidate 2 was tagged earlier today as llvmorg-10.0.0-rc2. It
> includes 98 commits since the previous release candidate.

For this rc, I used three patches, which are attached.

Main results on amd64-freebsd11:

  Expected Passes: 67927
  Expected Failures  : 266
  Unsupported Tests  : 4654
  Unexpected Passes  : 5
  Unexpected Failures: 539
  Individual Timeouts: 19

Main results on i386-freebsd11:

  Expected Passes: 64981
  Passes With Retry  : 1
  Expected Failures  : 249
  Unsupported Tests  : 3083
  Unresolved Tests   : 1
  Unexpected Passes  : 5
  Unexpected Failures: 231
  Individual Timeouts: 9

Uploaded:
SHA256 (clang+llvm-10.0.0-rc2-amd64-unknown-freebsd11.tar.xz) = 
5d2be46c05f1db55391caec2abfea2558121eaed41ab586281555a0f337e3e1b
SHA256 (clang+llvm-10.0.0-rc2-i386-unknown-freebsd11.tar.xz) = 
203e45a8ded937a6fc2859475329bad1e336676bfc3ad693f96ad52d3693b2ed

On both amd64 and i386, the test-suite build still segfaults (and even
results in one clang-10 process hanging at 100% CPU), which is tracked
in https://bugs.llvm.org/show_bug.cgi?id=44763.

-Dimitry


fix-clang-1.diff
Description: Binary data


fix-compiler-rt-1.diff
Description: Binary data


fix-test-suite-1.diff
Description: Binary data


signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [10.0.0 Release] Release Candidate 4 is here

[Dimitry Andric via lldb-dev]

On 13 Mar 2020, at 20:09, Hans Wennborg via Release-testers 
 wrote:
> 
> Release Candidate 4 was tagged earlier today as llvmorg-10.0.0-rc4 on
> the release branch at b406eab8880. It contains 12 commits since the
> previous release candidate.

For 10.0.0-rc4, I used three patches, which are attached.

Main results on amd64-freebsd11:

  Expected Passes: 67939  (rc2: 67927)
  Expected Failures  :   265  (rc2:   266)
  Unsupported Tests  :  4654  (rc2:  4654)
  Unexpected Passes  : 5  (rc2: 5)
  Unexpected Failures:   540  (rc2:   539)
  Individual Timeouts:18  (rc2:19)

Note that the test suite failures I reported for earlier RCs in PR44763
(segfaults and hangs while processing bitcode) have been resolved via
PR44896 and D74878, so it now worked again, at least for amd64.

Test suite results on amd64-freebsd11:

  Expected Passes: 2398
  Unexpected Failures: 3

The i386 builds are still running, I will upload the tarballs and post the 
results later.

Uploaded:
SHA256 (clang+llvm-10.0.0-rc4-amd64-unknown-freebsd11.tar.xz) = 
ad8ba933fa9e27c022bb0dde7d5ec1414a1be7b32bff99bb65c3873736c720bf

-Dimitry


fix-clang-1.diff
Description: Binary data


fix-compiler-rt-1.diff
Description: Binary data


fix-test-suite-1.diff
Description: Binary data


signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [10.0.0 Release] Release Candidate 4 is here

[Dimitry Andric via lldb-dev]

On 15 Mar 2020, at 10:58, Dimitry Andric via Release-testers 
 wrote:
> 
> On 13 Mar 2020, at 20:09, Hans Wennborg via Release-testers 
>  wrote:
>> 
>> Release Candidate 4 was tagged earlier today as llvmorg-10.0.0-rc4 on
>> the release branch at b406eab8880. It contains 12 commits since the
>> previous release candidate.
> 
> For 10.0.0-rc4, I used three patches, which are attached.
...
> The i386 builds are still running, I will upload the tarballs and post the 
> results later.

Main results on i386-freebsd11:

  Expected Passes: 64993 (rc2: 64981)
  Passes With Retry  : 1 (rc2: 1)
  Expected Failures  :   248 (rc2:   249)
  Unsupported Tests  :  3083 (rc2:  3083)
  Unresolved Tests   : 1 (rc2: 1)
  Unexpected Passes  : 5 (rc2: 5)
  Unexpected Failures:   231 (rc2:   231)
  Individual Timeouts: 9 (rc2: 9)

As usual, the test suite does not build on i386, due to missing SSE and int128 
support.

Uploaded:
SHA256 (clang+llvm-10.0.0-rc4-i386-unknown-freebsd11.tar.xz) = 
d1acc6425ce5410547730f6fce82b34d8f93d207fb61056949b4c8334a15

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [10.0.0 Release] Release Candidate 5 is here

[Dimitry Andric via lldb-dev]

On 19 Mar 2020, at 14:51, Hans Wennborg via Release-testers 
 wrote:
> 
> I had hoped that rc4 would be the last one, but I wanted to pick up
> one more fix, so here we go.
> 
> Release Candidate 5 was just tagged as llvmorg-10.0.0-rc5 on the
> release branch at 35627038123.

For 10.0.0-rc5, I used three patches, which are attached.

Main results on amd64-freebsd11:

  Expected Passes: 67940 (rc4: 67939)
  Expected Failures  :   265 (rc4:   265)
  Unsupported Tests  :  4654 (rc4:  4654)
  Unexpected Passes  : 5 (rc4: 5)
  Unexpected Failures:   540 (rc4:   540)
  Individual Timeouts:18 (rc4:18)

Test suite results on amd64-freebsd11:

  Expected Passes: 2398
  Unexpected Failures: 3

Main results on i386-freebsd11:

  Expected Passes: 64993 (rc4: 64993)
  Passes With Retry  : 0 (rc4: 1)
  Expected Failures  :   248 (rc4:   248)
  Unsupported Tests  :  3083 (rc4:  3083)
  Unresolved Tests   : 1 (rc4: 1)
  Unexpected Passes  : 5 (rc4: 5)
  Unexpected Failures:   231 (rc4:   231)
  Individual Timeouts:11 (rc4: 9)

As usual, the test suite does not build on i386, due to missing SSE and int128 
support.

The i386 builds are still running, I will upload the tarballs and post the 
results later.

Uploaded:
SHA256 (clang+llvm-10.0.0-rc5-amd64-unknown-freebsd11.tar.xz) = 
4b27b1bda0f451612475cce6460dad6e82858e88604078913ee736f9f9d834f8
SHA256 (clang+llvm-10.0.0-rc5-i386-unknown-freebsd11.tar.xz) = 
f6a189006588efe69315cc835b1286403d9b4697ec899ef9935e1bbb10098765

-Dimitry


fix-clang-1.diff
Description: Binary data


fix-compiler-rt-1.diff
Description: Binary data


fix-test-suite-1.diff
Description: Binary data


signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] LLVM 10.0.0 Release

[Dimitry Andric via lldb-dev]

On 24 Mar 2020, at 21:32, Hans Wennborg via Release-testers 
 wrote:
> 
> I am pleased to announce that LLVM 10 is now available.
> 
> Get it here: https://llvm.org/releases/download.html#10.0.0

For 10.0.0-final, I used three patches, which are attached.

Main results on amd64-freebsd11:

  Expected Passes: 67938 (rc5: 67940)
  Expected Failures  :   265 (rc5:   265)
  Unsupported Tests  :  4654 (rc5:  4654)
  Unexpected Passes  : 5 (rc5: 5)
  Unexpected Failures:   541 (rc5:   540)
  Individual Timeouts:19 (rc5:18)

Test suite results on amd64-freebsd11:

  Expected Passes: 2398
  Unexpected Failures:3

Main results on i386-freebsd11:

  Expected Passes: 64993 (rc5: 64993)
  Expected Failures  :   248 (rc5:   248)
  Unsupported Tests  :  3083 (rc5:  3083)
  Unresolved Tests   : 1 (rc5: 1)
  Unexpected Passes  : 5 (rc5: 5)
  Unexpected Failures:   231 (rc5:   231)
  Individual Timeouts:11 (rc5:11)

As usual, the test suite does not build on i386, due to missing SSE and int128 
support.

Uploaded:
SHA256 (clang+llvm-10.0.0-amd64-unknown-freebsd11.tar.xz) = 
56d58da545743d5f2947234d413632fd2b840e38f2bed7369f6e65531af36a52
SHA256 (clang+llvm-10.0.0-i386-unknown-freebsd11.tar.xz) = 
310ed47e957c226b0de17130711505366c225edbed65299ac2c3d59f9a59a41a

-Dimitry


fix-clang-1.diff
Description: Binary data


fix-compiler-rt-1.diff
Description: Binary data


fix-test-suite-1.diff
Description: Binary data


signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

[Dimitry Andric via lldb-dev]

Since Bugzilla numbers are all under 50,000 (at least for now:), can't we 
simply bump the GitHub issue/pull request numbers to 50,000, and start from 
there?

Then it would be easy to identify: < 5 means Bugzilla, >= 5 means 
GitHub.

Now somebody's only gotta find a way to file 5-200 bogus GitHub tickets. :) 
 (Or ask GitHub support to bump the number synthetically.)

-Dimitry

> On 22 Apr 2020, at 09:10, James Henderson via cfe-dev 
>  wrote:
> 
> Similar to other people's experiences, I've worked on a common code base that 
> supported three different platforms, and each platform used a different 
> bugzilla with it's own numbering scheme. I regularly came across references 
> to "BZ123456" with no indication as to which of the three systems that 
> referred to. This would often mean having to go to each in turn and seeing if 
> the corresponding bug looked like it had anything to do with the related 
> topic. Fortunately, given that there were many other things using the same 
> bugzilla instances, this was usually pretty clear, but not always. Typos in 
> bug numbers sometimes made things even harder, since you had to spend three 
> times as long trying to guess.
> 
> In other words +1 to using unique numbers, however we do it.
> 
> On Wed, 22 Apr 2020 at 03:44, Johannes Doerfert via cfe-dev 
> mailto:cfe-...@lists.llvm.org>> wrote:
> 
> On 4/21/20 7:00 PM, Tom Stellard via llvm-dev wrote:
> > On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote:
> >> On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev 
> >> mailto:cfe-...@lists.llvm.org> 
> >> >> wrote:
> >>
> >>  +1 to James's take
> >>
> >>  I'd prefer simplicity of implementation over perfection here.
> >>
> >> If we end up with two different bug numbering systems, that's a problem 
> >> that we will be paying for for many years. It's worth some investment now 
> >> to avoid that problem. And it doesn't seem like it really requires much 
> >> investment.
> >>
> >> Here's another path we could take:
> >>
> >> 1) Fork the llvm repository to a private "bugs" repository. Mirror the 
> >> bugzilla issues there. Iterate until we're happy, as per James's proposal.
> >> 2) Sync the forked repository to the llvm repository, delete the llvm 
> >> repository, rename "bugs" to "llvm", and make it public.
> >>
> >> Then we'll have the first N bugs in llvm-project/llvm being *exactly* the 
> >> bugzilla bugs, and we'll have excised the existing github issues that we 
> >> want to pretend never existed anyway.
> >>
> >>
> >> I think we've missed an important step in the planning here: we've not 
> >> agreed on a set of goals for the transition. Here are mine:
> >>
> >>   * We end up with one single issue tracking system containing all issues, 
> >> both old and new, both open and closed.
> >>   * All links and references to existing bugs still work.
> >>   * We have a single bug numbering system covering all bugs, and old bugs 
> >> retain their numbers.
> > Why are the bug numbers important?  Could you help give some example use 
> > cases that require having
> > a non-intersecting set of bug numbers for bugzilla bugs and github issues?
> 
> 
> While I have no experience in bugzilla or github tooling, the two step
> process described by Richard doesn't seem to be very complicated.
> 
> 
> As mentioned by others, we have commits and tests (and sometimes source
> files) that explicitly mention bug numbers. I do regularly look up bugs
> from a decade ago to determine if a test or some code still has
> relevance or not. If PR3214 can be one of two bugs, it does not only
> increase lookup time but also add confusion to everyone involved.
> 
> 
> Cheers,
> 
>Johannes
> 
> 
> 
> > -Tom
> >
> >
> >> It sounds like we don't all agree that the last point is important, but if 
> >> we can achieve it without any significant additional cost, why not do so?
> >>
> >>  Philip
> >>
> >>  On 4/20/20 4:08 PM, James Y Knight via llvm-dev wrote:
> >>>  In a previous discussion, one other suggestion had been to migrate 
> >>> all the bugzilla bugs to a separate initially-private "bug archive" 
> >>> repository in github. This has a few benefits:
> >>>  1. If the migration is messed up, the repo can be deleted, and the 
> >>> process run again, until we get a result we like.
> >>>  2. The numbering can be fully-controlled.
> >>>  Once the bugs are migrated to /some/ github repository, individual 
> >>> issues can then be "moved" between repositories, and github will redirect 
> >>> from the movefrom-repository's bug to the target repository's bug.
> >>>
> >>>  We could also just have llvm.org/PR###  
> >>> > be the url only 
> >>> for legacy bugzilla issue numbers -- and have it use a file listing the 
> >>> mappings of bugzilla id -> github id to generate the redirects. (GCC just 

Re: [lldb-dev] [Release-testers] 10.0.1-rc1 release has been tagged

[Dimitry Andric via lldb-dev]

On 20 May 2020, at 03:22, Tom Stellard via Release-testers 
 wrote:
> 
> I have just tagged the 10.0.1-rc1 release.  Testers can begin testing and 
> uploading
> binaries.
> 
> If you still want to get a fix into the 10.0.1 release, you still have about 
> a month
> to get your fix in.  To request a patch be backported to the release/10.x 
> branch,
> file a bug and mark it as a blocker of the release-10.0.1 meta bug.

I have uploaded:

SHA256 (clang+llvm-10.0.1-rc1-amd64-unknown-freebsd11.tar.xz) = 
4dbe2041e8aa80ba2b908946052bd4bb20733422707277aa7c297980ed8cd92c
SHA256 (clang+llvm-10.0.1-rc1-i386-unknown-freebsd11.tar.xz) = 
5fad007fdabe085de126513875a8e601b1f341889eb36423d2980dd3d34b1d80

but none of the regression tests could run, due to a lit/googletest exception:

llvm-lit: 
/home/dim/llvm/10.0.1/rc1/llvm-project/llvm/utils/lit/lit/formats/googletest.py:43:
 warning: unable to discover google-tests in 
'/home/dim/llvm/10.0.1/rc1/Phase3/Release/llvmCore-10.0.1-rc1.obj/tools/mlir/unittests/Dialect/SPIRV/./MLIRSPIRVTests':
 Command 
'['/home/dim/llvm/10.0.1/rc1/Phase3/Release/llvmCore-10.0.1-rc1.obj/tools/mlir/unittests/Dialect/SPIRV/./MLIRSPIRVTests',
 '--gtest_list_tests']' returned non-zero exit status 1.. Process output: b''
Traceback (most recent call last):
  File 
"/home/dim/llvm/10.0.1/rc1/llvm-project/llvm/utils/lit/lit/formats/googletest.py",
 line 39, in getGTestTests
env=localConfig.environment)
  File "/usr/local/lib/python3.7/subprocess.py", line 411, in check_output
**kwargs).stdout
  File "/usr/local/lib/python3.7/subprocess.py", line 512, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command 
'['/home/dim/llvm/10.0.1/rc1/Phase3/Release/llvmCore-10.0.1-rc1.obj/tools/mlir/unittests/Dialect/SPIRV/./MLIRSPIRVTests',
 '--gtest_list_tests']' returned non-zero exit status 1.

Running the MLIRSPIRVTests executable shows the actual problem:

$ 
/home/dim/llvm/10.0.1/rc1/Phase3/Release/llvmCore-10.0.1-rc1.obj/tools/mlir/unittests/Dialect/SPIRV/./MLIRSPIRVTests
Shared object "libc++abi.so.1" not found, required by "MLIRSPIRVTests"

On FreeBSD we use libcxxrt, not libc++abi. Does anybody have an idea why this 
appears to have changed between 10.0.0 and 10.0.1? And if so, how I tell the 
build not to link against libc++abi?

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev