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

[Dimitry Andric via lldb-dev]

On 30 Nov 2021, at 07:07, Tom Stellard via llvm-dev  
wrote:
> 
> I've tagged 13.0.1-rc1.  Testers can begin testing and uploading binaries.

For 13.0.1 rc1, I have built and tested on both FreeBSD 12 and 13. No
additional patches were needed.

For the 32-builds I used -no-flang, as flang is currently not 32-bit
clean, and I do not expect it will ever be.


Main results on amd64-freebsd12:

  Skipped: 3 (13.0.0: 3)
  Unsupported:  6353 (13.0.0:  6353)
  Passed : 91833 (13.0.0: 91836)
  Expectedly Failed  :   320 (13.0.0:   320)
  Timed Out  : 1 (13.0.0: 0)
  Failed :   301 (13.0.0:   294)
  Unexpectedly Passed: 2 (13.0.0: 2)

Test suite results on amd64-freebsd12:

  Passed: 2419 (13.0.0: 2419)
  Failed:3 (13.0.0:3)


Main results on amd64-freebsd13:

  Skipped: 3 (13.0.0: 3)
  Unsupported:  6352 (13.0.0:  6352)
  Passed : 91797 (13.0.0: 91841)
  Passed With Retry  : 0 (13.0.0: 1)
  Expectedly Failed  :   320 (13.0.0:   320)
  Timed Out  : 2 (13.0.0: 1)
  Failed :   337 (13.0.0:   324)
  Unexpectedly Passed: 2 (13.0.0: 2)

Test suite results on amd64-freebsd13:

  Passed: 2419 (13.0.0: 2419)
  Failed:3 (13.0.0:3)


Main results on i386-freebsd12:

  Skipped: 3 (13.0.0: 3)
  Unsupported:  4738 (13.0.0:  4738)
  Passed : 87561 (13.0.0: 87556)
  Expectedly Failed  :   295 (13.0.0:   295)
  Failed :   198 (13.0.0:   198)
  Unexpectedly Passed: 1 (13.0.0: 1)

Main results on i386-freebsd13:

  Skipped: 3 (13.0.0: 3)
  Unsupported:  4738 (13.0.0:  4738)
  Passed : 87558 (13.0.0: 87554)
  Passed With Retry  : 1 (13.0.0: 0)
  Expectedly Failed  :   295 (13.0.0:   295)
  Failed :   200 (13.0.0:   200)
  Unexpectedly Passed: 1 (13.0.0: 1)


Uploaded:
SHA256 (clang+llvm-13.0.1-rc1-amd64-unknown-freebsd12.tar.xz) = 
11b38cf5de77b72881b8eaed9571af32993ed2aea6c93b6826f0e1dc9ab65f76
SHA256 (clang+llvm-13.0.1-rc1-amd64-unknown-freebsd13.tar.xz) = 
5320a41da51ba451f080c10d2a16d195265e4e5756642863daeb0be9734c3124
SHA256 (clang+llvm-13.0.1-rc1-i386-unknown-freebsd12.tar.xz) = 
175ef64e9922783ecb2e0b3b67f39f9a64de22f1f3ecf3548a8d14912a93
SHA256 (clang+llvm-13.0.1-rc1-i386-unknown-freebsd13.tar.xz) = 
84d49f5bce83fed921c002e4e4b57315623875c4b7f27ff376bc1eab31850551

-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] 13.0.0-rc3 has been tagged

[Dimitry Andric via lldb-dev]

On 14 Sep 2021, at 06:40, Tom Stellard via Release-testers 
 wrote:
> 
> I've tagged 13.0.0-rc3.  This will likely be the last rc unless there are
> critical bugs that are found.  Please test the release and report results.

For 13.0.0 rc3, I have built and tested on both FreeBSD 12 and 13. No
additional patches were needed, as they were merged.

For the 32-builds I used -no-flang, as flang is currently not 32-bit
clean, and I do not expect it will ever be. (Also, these builds consume
a huge amount of RAM, making native compilation likely impossible.)


Main results on amd64-freebsd12:

  Skipped: 3 (rc2: 3)
  Unsupported:  6353 (rc2:  6353)
  Passed With Retry  : 91823 (rc2: 0)
  Passed : 1 (rc2: 91855)
  Expectedly Failed  :   320 (rc2:   320)
  Timed Out  : 2 (rc2: 2)
  Failed :   300 (rc2:   295)
  Unexpectedly Passed: 2 (rc2: 2)

Test suite results on amd64-freebsd12:

  Passed: 2419 (rc2: 2419)
  Failed:3 (rc2:3)


Main results on amd64-freebsd13:

  Skipped: 3 (rc2: 3)
  Unsupported:  6352 (rc2:  6352)
  Passed : 91789 (rc2: 91792)
  Expectedly Failed  :   320 (rc2:   320)
  Failed :   338 (rc2:   324)
  Unexpectedly Passed: 2 (rc2: 2)

Test suite results on amd64-freebsd13:

  Passed: 2419 (rc2: 2419)
  Failed:3 (rc2:3)


Main results on i386-freebsd12:

  Skipped: 3 (rc2: 3)
  Unsupported:  4738 (rc2:  4736)
  Passed : 87552 (rc2: 87542)
  Expectedly Failed  :   295 (rc2:   295)
  Failed :   198 (rc2:   200)
  Unexpectedly Passed: 1 (rc2: 1)


Main results on i386-freebsd13:

  Skipped: 3 (rc2: 3)
  Unsupported:  4738 (rc2:  4736)
  Passed : 87550 (rc2: 87540)
  Expectedly Failed  :   295 (rc2:   295)
  Failed :   200 (rc2:   202)
  Unexpectedly Passed: 1 (rc2: 1)


Uploaded:
SHA256 (clang+llvm-13.0.0-rc3-amd64-unknown-freebsd12.tar.xz) = 
9f20ba1bbec09588c3fb630d29890f29885102408deb5e563b7e3f94a47c7ce1
SHA256 (clang+llvm-13.0.0-rc3-amd64-unknown-freebsd13.tar.xz) = 
946ad0e3b720fe0c2faaf19c62cee6692d2cc0f022d7ba8a0ffb60f2883a638b
SHA256 (clang+llvm-13.0.0-rc3-i386-unknown-freebsd12.tar.xz) = 
3f74f48c0a09d9f0c86efd8a3c1a7ee16d9cb4d0991c8abeb8163600f107df41
SHA256 (clang+llvm-13.0.0-rc3-i386-unknown-freebsd13.tar.xz) = 
5afd93f47f0d93159d0e67e2298a0a9b499e41090dd92372276fd93f01d088d9

-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] 13.0.0-rc2 has been tagged

[Dimitry Andric via lldb-dev]

On 27 Aug 2021, at 07:20, Tom Stellard via Release-testers 
 wrote:
> 
> I've tagged the 13.0.0-rc2 release.  Testers can begin testing and uploading
> binaries.
> 
> 13.0.0-rc3 is scheduled to be released on Sep. 7, so we'll continue to accept
> bug fixes in the branch until then.

For 13.0.0 rc2, I have built and tested on both FreeBSD 12 and 13. I
used 2 patches, which are attached.

For the 32-builds I used -no-flang, as flang is currently not 32-bit
clean, and I do not expect it will ever be.


Main results on amd64-freebsd12:

  Skipped: 3 (rc1: 3)
  Unsupported:  6353 (rc1:  6352)
  Passed : 91855 (rc1: 91852)
  Expectedly Failed  :   320 (rc1:   320)
  Timed Out  : 2 (rc1: 2)
  Failed :   295 (rc1:   290)
  Unexpectedly Passed: 2 (rc1: 2)

Test suite results on amd64-freebsd12:

  Passed: 2419 (rc1: 2419)
  Failed:3 (rc1:3)


Main results on amd64-freebsd13:

  Skipped: 3 (rc1: 3)
  Unsupported:  6352 (rc1:  6352)
  Passed : 91792 (rc1: 91815)
  Passed With Retry  : 0 (rc1: 1)
  Expectedly Failed  :   320 (rc1:   320)
  Timed Out  : 1 (rc1: 1)
  Failed :   324 (rc1:   327)
  Unexpectedly Passed: 2 (rc1: 2)

Test suite results on amd64-freebsd13:

  Passed: 2419 (rc1: 2419)
  Failed:3 (rc1:3)


Main results on i386-freebsd12:

  Skipped: 3 (rc1: 3)
  Unsupported:  4736 (rc1:  4735)
  Passed : 87542 (rc1: 87533)
  Expectedly Failed  :   295 (rc1:   295)
  Failed :   200 (rc1:   201)
  Unexpectedly Passed: 1 (rc1: 1)


Main results on i386-freebsd13:

  Skipped: 3 (rc1: 3)
  Unsupported:  4736 (rc1:  4735)
  Passed : 87540 (rc1: 87532)
  Expectedly Failed  :   295 (rc1:   295)
  Failed :   202 (rc1:   202)
  Unexpectedly Passed: 1 (rc1: 1)


Uploaded:
SHA256 (clang+llvm-13.0.0-rc2-amd64-unknown-freebsd12.tar.xz) = 
6999f1995449d07c99c4585f918e81fd697677036d6d287782e7090d148a1fd4
SHA256 (clang+llvm-13.0.0-rc2-amd64-unknown-freebsd13.tar.xz) = 
22022a1ca4cc61315c6c9d1e9145a94239948bbdf72a52d6593d25371fa3474b
SHA256 (clang+llvm-13.0.0-rc2-i386-unknown-freebsd12.tar.xz) = 
c7009939b80922bf04035a6e2650c5a94a6044f19892f89ade802275f40a2c26
SHA256 (clang+llvm-13.0.0-rc2-i386-unknown-freebsd13.tar.xz) = 
3191de961d27366c69aa761e4faab52053bbd05f45c2c238fd5caffee8cab0f8

-Dimitry



fix-openmp-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] 13.0.0-rc1 has been tagged

[Dimitry Andric via lldb-dev]

On 3 Aug 2021, at 09:20, Tom Stellard via Release-testers 
 wrote:
> 
> I've tagged the 13.0.0-rc1 release.  Testers, please test and upload binaries.

For 13.0.0 rc1, I have built and tested on both FreeBSD 12 and 13. I
used 6 patches, which are attached. (Most of these are already merged
for the next rc.)

For the 32-builds I used -no-flang, as flang is currently not 32-bit
clean, and I do not expect it will ever be.


Main results on amd64-freebsd12:

  Skipped: 3
  Unsupported:  6352
  Passed : 91852
  Expectedly Failed  :   320
  Timed Out  : 2
  Failed :   290
  Unexpectedly Passed: 2

Test suite results on amd64-freebsd12:

  Passed: 2419
  Failed:3


Main results on amd64-freebsd13:

  Skipped: 3
  Unsupported:  6352
  Passed : 91815
  Passed With Retry  : 1
  Expectedly Failed  :   320
  Timed Out  : 1
  Failed :   327
  Unexpectedly Passed: 2

Test suite results on amd64-freebsd13:

  Passed: 2419
  Failed:3


Main results on i386-freebsd12:

  Skipped: 3
  Unsupported:  4735
  Passed : 87533
  Expectedly Failed  :   295
  Failed :   201
  Unexpectedly Passed: 1


Main results on i386-freebsd13:

  Skipped: 3
  Unsupported:  4735
  Passed : 87532
  Expectedly Failed  :   295
  Failed :   202
  Unexpectedly Passed: 1


Uploaded:
SHA256 (clang+llvm-13.0.0-rc1-amd64-unknown-freebsd12.tar.xz) = 
49bd21a069e655b42ba017520357db6cf119108cd6b6c3fa407b95675721051f
SHA256 (clang+llvm-13.0.0-rc1-amd64-unknown-freebsd13.tar.xz) = 
9bb9b6b4a4790f5410f42bfc43accffa07699a6a0414ae8917243d0da7a34d6b
SHA256 (clang+llvm-13.0.0-rc1-i386-unknown-freebsd12.tar.xz) = 
e8feda2f48a51572d0fa1649e7f49b5cf3e2e7fb6c54274d02208c9ae01564ff
SHA256 (clang+llvm-13.0.0-rc1-i386-unknown-freebsd13.tar.xz) = 
e9f187a47106ce8269363e31af0c6f1961f8b692b28e5bfb610b66e093b6f393

-Dimitry



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


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


fix-mlir-1.diff
Description: Binary data


fix-openmp-1.diff
Description: Binary data


fix-openmp-2.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] 12.0.1-rc4 release has been tagged

[Dimitry Andric via lldb-dev]

On 2 Jul 2021, at 22:59, Tom Stellard via Release-testers 
 wrote:
> 
> I've tagged the 12.0.1-rc4 release.  This will hopefully be the last release
> candidate.  Please test and upload binaries.

For 12.0.1 rc4, I have built and tested on both FreeBSD 11 and 12. No
additional patches were needed.


Main results on amd64-freebsd11:

  Unsupported:  5562 (rc2:  5562)
  Passed : 80208 (rc2: 80205)
  Expectedly Failed  :   247 (rc2:   247)
  Timed Out  : 2 (rc2: 5)
  Failed :96 (rc2:96)
  Unexpectedly Passed: 2 (rc2: 2)

Test suite results on amd64-freebsd11:

  Passed: 2399 (rc2: 2399)
  Failed:3 (rc2:3)


Main results on amd64-freebsd12:

  Unsupported:  5562 (rc2:  5562)
  Passed : 80208 (rc2: 80209)
  Expectedly Failed  :   243 (rc2:   243)
  Timed Out  : 5 (rc2: 6)
  Failed :93 (rc2:91)
  Unexpectedly Passed: 6 (rc2: 6)

Test suite results on amd64-freebsd12:

  Passed: 2399 (rc2: 2399)
  Failed:3 (rc2:3)


Main results on i386-freebsd11:

  Unsupported:  3976 (rc2:  3976)
  Passed : 76754 (rc2: 76753)
  Expectedly Failed  :   224 (rc2:   224)
  Failed :53 (rc2:54)
  Unexpectedly Passed: 1 (rc2: 1)


Main results on i386-freebsd12:

  Unsupported:  3976 (rc2:  3976)
  Passed : 76756 (rc2: 76755)
  Expectedly Failed  :   222 (rc2:   222)
  Failed :51 (rc2:52)
  Unexpectedly Passed: 3 (rc2: 3)

Uploaded:
SHA256 (clang+llvm-12.0.1-rc4-amd64-unknown-freebsd11.tar.xz) = 
3117f9d9f38ecaf4d453bbed9796ad5daa913ac800b4ef91c0ad7ba76d3ba5bd
SHA256 (clang+llvm-12.0.1-rc4-amd64-unknown-freebsd12.tar.xz) = 
46ede5c86e6eb6f71c0d87efae97121675814c6d0f96ce3ab1f57afc92ac07b6
SHA256 (clang+llvm-12.0.1-rc4-i386-unknown-freebsd11.tar.xz) = 
f19882d7b7d3ae4271906a256a432c46ec69bd7226c809d75127ab735df7c68f
SHA256 (clang+llvm-12.0.1-rc4-i386-unknown-freebsd12.tar.xz) = 
bedd5bb312abbdf5d6de8705f97d7710663b79f58f6f6a9db2ab8a744abb5a5d

-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] 12.0.1-rc3 has been tagged

[Dimitry Andric via lldb-dev]

On 26 Jun 2021, at 07:49, Tom Stellard via cfe-dev  
wrote:
> 
> I've tagged the 12.0.1-rc3 release.  Testers please test and upload binaries.

For 12.0.1 rc3, I have built and tested on both FreeBSD 11 and 12. No
additional patches were needed.


Main results on amd64-freebsd11:

  Unsupported:  5562 (rc2:  5562)
  Passed : 80205 (rc2: 80200)
  Expectedly Failed  :   247 (rc2:   247)
  Timed Out  : 5 (rc2: 1)
  Failed :96 (rc2:96)
  Unexpectedly Passed: 2 (rc2: 2)

Test suite results on amd64-freebsd11:

  Passed: 2399 (rc2: 2399)
  Failed:3 (rc2:3)


Main results on amd64-freebsd12:

  Unsupported:  5562 (rc2:  5562)
  Passed : 80209 (rc2: 80202)
  Expectedly Failed  :   243 (rc2:   243)
  Timed Out  : 6 (rc2: 3)
  Failed :91 (rc2:92)
  Unexpectedly Passed: 6 (rc2: 6)

Test suite results on amd64-freebsd12:

  Passed: 2399 (rc2: 2399)
  Failed:3 (rc2:3)


Main results on i386-freebsd11:

  Unsupported:  3976 (rc2:  3976)
  Passed : 76753 (rc2: 76743)
  Expectedly Failed  :   224 (rc2:   224)
  Timed Out  : 0 (rc2: 1)
  Failed :54 (rc2:54)
  Unexpectedly Passed: 1 (rc2: 1)


Main results on i386-freebsd12:

  Unsupported:  3976 (rc2:  3976)
  Passed : 76755 (rc2: 76747)
  Expectedly Failed  :   222 (rc2:   222)
  Failed :52 (rc2:51)
  Unexpectedly Passed: 3 (rc2: 3)

Uploaded:
SHA256 (clang+llvm-12.0.1-rc3-amd64-unknown-freebsd11.tar.xz) = 
71e67a22c913aa2334b8da0b407798c2e95898e85cf31d8068bc435cb0155ec3
SHA256 (clang+llvm-12.0.1-rc3-amd64-unknown-freebsd12.tar.xz) = 
90ccc84dca63bc79ceb6bfeed586e5b6d80d3a76ea4795f338642b67c9d79650
SHA256 (clang+llvm-12.0.1-rc3-i386-unknown-freebsd11.tar.xz) = 
bde0fae8782464082d6b9d70775f897483ca71303aa9c9e2e173e91de23e20ef
SHA256 (clang+llvm-12.0.1-rc3-i386-unknown-freebsd12.tar.xz) = 
9a2255e120f483cc1636478d0b6c001566b35c95aef1d39d736f833f5d016fdc

-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 12.0.1-rc2 tagged + extended deadline for requesting backports

[Dimitry Andric via lldb-dev]

On 17 Jun 2021, at 08:53, Tom Stellard via Release-testers 
 wrote:
> 
> I've tagged the 12.0.1-rc2 release, so testers may begin testing and uploading
> binaries.

For 12.0.1 rc2, I have built and tested on both FreeBSD 11 and 12. No
additional patches were needed.


Main results on amd64-freebsd11:

  Unsupported:  5562 (rc1:  5562)
  Passed : 80200 (rc1: 80189)
  Expectedly Failed  :   247 (rc1:   247)
  Timed Out  : 1 (rc1: 2)
  Failed :96 (rc1:97)
  Unexpectedly Passed: 2 (rc1: 2)

Test suite results on amd64-freebsd11:

  Passed: 2399 (rc1: 2399)
  Failed:3 (rc1:3)


Main results on amd64-freebsd12:

  Unsupported:  5562 (rc1:  5562)
  Passed : 80202 (rc1: 80194)
  Expectedly Failed  :   243 (rc1:   243)
  Timed Out  : 3 (rc1: 2)
  Failed :92 (rc1:92)
  Unexpectedly Passed: 6 (rc1: 6)

Test suite results on amd64-freebsd12:

  Passed: 2399 (rc1: 2399)
  Failed:3 (rc1:3)


Main results on i386-freebsd11:

  Unsupported:  3976 (rc1:  3976)
  Passed : 76743 (rc1: 76736)
  Expectedly Failed  :   224 (rc1:   224)
  Timed Out  : 1 (rc1: 0)
  Failed :54 (rc1:53)
  Unexpectedly Passed: 1 (rc1: 1)


Main results on i386-freebsd12:

  Unsupported:  3976 (rc1:  3976)
  Passed : 76747 (rc1: 76739)
  Expectedly Failed  :   222 (rc1:   222)
  Failed :51 (rc1:50)
  Unexpectedly Passed: 3 (rc1: 3)

Uploaded:
SHA256 (clang+llvm-12.0.1-rc2-amd64-unknown-freebsd11.tar.xz) = 
1b9f9e1924307adcba85085f7f90a63a87d46bcd53caea5406d755977040f8c0
SHA256 (clang+llvm-12.0.1-rc2-amd64-unknown-freebsd12.tar.xz) = 
bcdadf59384d910938fa752bcfa89d9bd9683d63f94280181cb726c92e0d74d8
SHA256 (clang+llvm-12.0.1-rc2-i386-unknown-freebsd11.tar.xz) = 
9c55ca566b4bad83993e52c6598eca1c8a201fb962583e692622d7a1d672e932
SHA256 (clang+llvm-12.0.1-rc2-i386-unknown-freebsd12.tar.xz) = 
be1606a3a8a696868455fa9c9458c938d4fda3e4364278d635971ae2e79befda

-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] 12.0.1-rc1 release has been tagged

[Dimitry Andric via lldb-dev]

On 26 May 2021, at 09:15, Tom Stellard via Release-testers 
 wrote:
> 
> I've tagged the 12.0.1-rc1 release.  Testers may upload binaries and report 
> results.

For 12.0.1 rc1, I have built and tested on both FreeBSD 11 and 12. No
additional patches were needed.


Main results on amd64-freebsd11:

  Unsupported:  5562 (12.0.0 final:  5562)
  Passed : 80189 (12.0.0 final: 80179)
  Expectedly Failed  :   247 (12.0.0 final:   247)
  Timed Out  : 2 (12.0.0 final: 2)
  Failed :97 (12.0.0 final:96)
  Unexpectedly Passed: 2 (12.0.0 final: 2)

Test suite results on amd64-freebsd11:

  Passed: 2399 (12.0.0 final: 2399)
  Failed:3 (12.0.0 final:3)


Main results on amd64-freebsd12:

  Unsupported:  5562 (12.0.0 final:  5562)
  Passed : 80194 (12.0.0 final: 80181)
  Expectedly Failed  :   243 (12.0.0 final:   243)
  Timed Out  : 2 (12.0.0 final: 3)
  Failed :92 (12.0.0 final:93)
  Unexpectedly Passed: 6 (12.0.0 final: 6)

Test suite results on amd64-freebsd12:

  Passed: 2399 (12.0.0 final: 2399)
  Failed:3 (12.0.0 final:3)


Main results on i386-freebsd11:

  Unsupported:  3976 (12.0.0 final:  3976)
  Passed : 76736 (12.0.0 final: 76723)
  Expectedly Failed  :   224 (12.0.0 final:   224)
  Failed :53 (12.0.0 final:55)
  Unexpectedly Passed: 1 (12.0.0 final: 1)


Main results on i386-freebsd12:

  Unsupported:  3976 (12.0.0 final:  3976)
  Passed : 76739 (12.0.0 final: 76725)
  Expectedly Failed  :   222 (12.0.0 final:   222)
  Failed :50 (12.0.0 final:53)
  Unexpectedly Passed: 3 (12.0.0 final: 3)


Uploaded:
SHA256 (clang+llvm-12.0.1-rc1-amd64-unknown-freebsd11.tar.xz) = 
68ccfa684f181d69adc581c28cbc1d52a12396c444d3ba3543e99eb6e8b94d14
SHA256 (clang+llvm-12.0.1-rc1-amd64-unknown-freebsd12.tar.xz) = 
6847c90d33eb8a597b372706fa1a9b6dac3ebcaffcd0b956287d0ac173ec8c50
SHA256 (clang+llvm-12.0.1-rc1-i386-unknown-freebsd11.tar.xz) = 
7335ab91bfdab488071527345b4c5066544b34a0a11efd31f49ecf01ac08b096
SHA256 (clang+llvm-12.0.1-rc1-i386-unknown-freebsd12.tar.xz) = 
a20428ff308583f9d44f3f4eb86b720f3cd319592eb7805b54973f7b886cf862

-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 12.0.0-rc5 has been tagged

[Dimitry Andric via lldb-dev]

On 8 Apr 2021, at 03:44, Tom Stellard via Release-testers 
 wrote:
> 
> I've tagged 12.0.0-rc5, testers can begin testing and upload binaries.

For 12.0.0 rc5, I have built and tested on both FreeBSD 11 and 12. No
additional patches were needed.


Main results on amd64-freebsd11:

  Unsupported:  5562 (rc4:  5562)
  Passed : 80178 (rc4: 80177)
  Expectedly Failed  :   247 (rc4:   247)
  Timed Out  : 2 (rc4: 2)
  Failed :97 (rc4:98)
  Unexpectedly Passed: 2 (rc4: 2)

Test suite results on amd64-freebsd11:

  Passed: 2399 (rc4: 2399)
  Failed:3 (rc4:3)


Main results on amd64-freebsd12:

  Unsupported:  5562 (rc4:  5562)
  Passed : 80181 (rc4: 80182)
  Expectedly Failed  :   243 (rc4:   243)
  Timed Out  : 4 (rc4: 2)
  Failed :92 (rc4:93)
  Unexpectedly Passed: 6 (rc4: 6)

Test suite results on amd64-freebsd12:

  Passed: 2399 (rc4: 2399)
  Failed:3 (rc4:3)


Main results on i386-freebsd11:

  Unsupported:  3976 (rc4:  3976)
  Passed : 76723 (rc4: 76724)
  Expectedly Failed  :   224 (rc4:   224)
  Failed :55 (rc4:54)
  Unexpectedly Passed: 1 (rc4: 1)


Main results on i386-freebsd12:

  Unsupported:  3976 (rc4:  3976)
  Passed : 76725 (rc4: 76724)
  Expectedly Failed  :   222 (rc4:   222)
  Failed :53 (rc4:54)
  Unexpectedly Passed: 3 (rc4: 3)


Uploaded:
SHA256 (clang+llvm-12.0.0-rc5-amd64-unknown-freebsd11.tar.xz) = 
2c49e882d1ea399be16e524d49820e305e9362e3fe89728feee742705fe280a9
SHA256 (clang+llvm-12.0.0-rc5-amd64-unknown-freebsd12.tar.xz) = 
d624cc84ac87682fa788e1399a11f9d9b4bc591dbcbc82fce2f5d4f92a866979
SHA256 (clang+llvm-12.0.0-rc5-i386-unknown-freebsd11.tar.xz) = 
00ad426ccfacaba3999c66481e74983fb60daf6ae22b750d2af4ea9dd8f0009f
SHA256 (clang+llvm-12.0.0-rc5-i386-unknown-freebsd12.tar.xz) = 
e6e9bdccf2d4ea8300a9b926cb91ae7054c9322f1681e1c82d4324994245df31

-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 12.0.0-rc3 has been tagged

[Dimitry Andric via lldb-dev]

On 10 Mar 2021, at 16:10, Tom Stellard via Release-testers 
 wrote:
> 
> I've tagged LLVM 12.0.0-rc3.  Testers may begin testing and uploading 
> binaries.
> If all goes well, this will be the last RC.

For 12.0.0 rc3, I have built and tested on both FreeBSD 11 and 12. No
additional patches were needed.


Main results on amd64-freebsd11:

  Unsupported:  5562 (rc2:  5562)
  Passed : 80174 (rc2: 80165)
  Expectedly Failed  :   247 (rc2:   247)
  Timed Out  : 3 (rc2: 6)
  Failed :93 (rc2:94)
  Unexpectedly Passed: 2 (rc2: 2)

Test suite results on amd64-freebsd11:

  Passed: 2399 (rc2: 2399)
  Failed:3 (rc2:3)


Main results on amd64-freebsd12:

  Unsupported:  5562 (rc2:  5562)
  Passed : 80178 (rc2: 80172)
  Expectedly Failed  :   243 (rc2:   243)
  Timed Out  : 3 (rc2: 4)
  Failed :89 (rc2:89)
  Unexpectedly Passed: 6 (rc2: 6)

Test suite results on amd64-freebsd12:

  Passed: 2399 (rc2: 2399)
  Failed:3 (rc2:3)


Main results on i386-freebsd11:

  Unsupported:  3976 (rc2:  3976)
  Passed : 76718 (rc2: 76713)
  Expectedly Failed  :   224 (rc2:   224)
  Timed Out  : 0 (rc2: 1)
  Failed :53 (rc2:52)
  Unexpectedly Passed: 1 (rc2: 1)


Main results on i386-freebsd12:

  Unsupported:  3976 (rc2:  3976)
  Passed : 76722 (rc2: 76718)
  Expectedly Failed  :   222 (rc2:   222)
  Failed :49 (rc2:48)
  Unexpectedly Passed: 3 (rc2: 3)


Uploaded:
SHA256 (clang+llvm-12.0.0-rc3-amd64-unknown-freebsd11.tar.xz) = 
abd3e061b5385d390b8d39e27f8171269594f42636b5cd1363e9088f54066ca0
SHA256 (clang+llvm-12.0.0-rc3-amd64-unknown-freebsd12.tar.xz) = 
8499b45cc791dbb75f7b12ce3a7ee2e734dd34b5316b9823a83687929c0cd64c
SHA256 (clang+llvm-12.0.0-rc3-i386-unknown-freebsd11.tar.xz) = 
be5c39b3ceae6d9cebdda19dbdc264157bd135800a6b44bd5dabbdd1037d9174
SHA256 (clang+llvm-12.0.0-rc3-i386-unknown-freebsd12.tar.xz) = 
d79e44bfcb37f6795a2e0f75c3ac3508dd10f4ab2d0b6f39414a37d70bc38a93

-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 12.0.0-rc2 has been tagged

[Dimitry Andric via lldb-dev]

On 24 Feb 2021, at 05:45, Tom Stellard via Release-testers 
 wrote:
> LLVM 12.0.0-rc2 has been tagged.  Please test and report any issues in 
> bugzilla.

For 12.0.0 rc2, I have built and tested on both FreeBSD 11 and 12. No
additional patches were needed anymore (i.e. fixes for both issues I
found in rc1 were merged).


Main results on amd64-freebsd11:

  Unsupported:  5562 (rc1:  5557)
  Passed : 80165 (rc1: 80122)
  Expectedly Failed  :   247 (rc1:   246)
  Timed Out  : 6 (rc1: 2)
  Failed :94 (rc1:95)
  Unexpectedly Passed: 2 (rc1: 2)

Test suite results on amd64-freebsd11:

  Passed: 2399 (rc1: 2399)
  Failed:3 (rc1:3)


Main results on amd64-freebsd12:

  Unsupported:  5562 (rc1:  5557)
  Passed : 80172 (rc1: 80125)
  Expectedly Failed  :   243 (rc1:   242)
  Timed Out  : 4 (rc1: 4)
  Failed :89 (rc1:90)
  Unexpectedly Passed: 6 (rc1: 6)

Test suite results on amd64-freebsd12:

  Passed: 2399 (rc1: 2399)
  Failed:3 (rc1:3)


Main results on i386-freebsd11:

  Unsupported:  3976 (rc1:  3971)
  Passed : 76713 (rc1: 76669)
  Expectedly Failed  :   224 (rc1:   223)
  Timed Out  : 1 (rc1: 0)
  Failed :52 (rc1:51)
  Unexpectedly Passed: 1 (rc1: 1)


Main results on i386-freebsd12:

  Unsupported:  3976 (rc1:  3971)
  Passed : 76718 (rc1: 76672)
  Expectedly Failed  :   222 (rc1:   221)
  Failed :48 (rc1:48)
  Unexpectedly Passed: 3 (rc1: 3)


Uploaded:
SHA256 (clang+llvm-12.0.0-rc2-amd64-unknown-freebsd11.tar.xz) = 
4ab6e35a6c36931dd47615f807020657d037cc468ba1347e868430b334f01cd7
SHA256 (clang+llvm-12.0.0-rc2-amd64-unknown-freebsd12.tar.xz) = 
a413da1b4c1f0d34038b3ad6a91e80af4fe27aa1c7400b7f065f9844db017a6e
SHA256 (clang+llvm-12.0.0-rc2-i386-unknown-freebsd11.tar.xz) = 
cabf6006a0f2a573bc5fedb1a1f3ff0a803149e36e92847b2726daf2723f2ca6
SHA256 (clang+llvm-12.0.0-rc2-i386-unknown-freebsd12.tar.xz) = 
c3a701051d9d75dad96dbb31caaee40986573a91e4b033cb5db3ffa5cf06b2c4

-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 11.1.0-final has been tagged.

[Dimitry Andric via lldb-dev]

On 18 Feb 2021, at 05:06, Tom Stellard via Release-testers 
 wrote:
> 
> I've tagged 11.1.0-final, testers may begin uploading binaries now.

For 11.1.0 final, I have built and tested on both FreeBSD 11 and 12
again. No additional patches were needed.


Main results on amd64-freebsd11:

  Unsupported:  5122 (11.1.0 rc3:  5122)
  Passed : 69795 (11.1.0 rc3: 69797)
  Expectedly Failed  :   246 (11.1.0 rc3:   246)
  Timed Out  :18 (11.1.0 rc3:16)
  Failed :   479 (11.1.0 rc3:   479)
  Unexpectedly Passed: 2 (11.1.0 rc3: 2)

Test suite results on amd64-freebsd11:

  Passed: 2399 (11.1.0 rc3: 2399)
  Failed:3 (11.1.0 rc3:3)


Main results on amd64-freebsd12:

  Unsupported:  5122 (11.1.0 rc3:  5122)
  Passed : 70257 (11.1.0 rc3: 70257)
  Expectedly Failed  :   242 (11.1.0 rc3:   242)
  Timed Out  :44 (11.1.0 rc3:43)
  Failed :68 (11.1.0 rc3:69)
  Unexpectedly Passed: 6 (11.1.0 rc3: 6)

Test suite results on amd64-freebsd12:

  Passed: 2399 (11.1.0 rc3: 2399)
  Failed:3 (11.1.0 rc3:3)


Main results on i386-freebsd11:

  Unsupported:  3513 (11.1.0 rc3:  3513)
  Passed : 66681 (11.1.0 rc3: 66681)
  Expectedly Failed  :   231 (11.1.0 rc3:   231)
  Timed Out  : 7 (11.1.0 rc3: 7)
  Failed :   311 (11.1.0 rc3:   311)
  Unexpectedly Passed: 1 (11.1.0 rc3: 1)


Main results on i386-freebsd12:

  Unsupported:  3513 (11.1.0 rc3:  3513)
  Passed : 66678 (11.1.0 rc3: 66679)
  Expectedly Failed  :   229 (11.1.0 rc3:   229)
  Timed Out  : 7 (11.1.0 rc3: 7)
  Failed :   314 (11.1.0 rc3:   313)
  Unexpectedly Passed: 3 (11.1.0 rc3: 3)


Uploaded:
SHA256 (clang+llvm-11.1.0-amd64-unknown-freebsd11.tar.xz) = 
645e24018aa2694d8ccb44139f44a0d3af97fa8eab785faecb7a228ebe76ac7e
SHA256 (clang+llvm-11.1.0-amd64-unknown-freebsd12.tar.xz) = 
430284b75248ab2dd3ebb8718d8bbb19cc8b9b62f4707ae47a61827b3ba59836
SHA256 (clang+llvm-11.1.0-i386-unknown-freebsd11.tar.xz) = 
ddc451c1094d0c8912160912d7c20d28087782758e0a8d145f301a18ddcea558
SHA256 (clang+llvm-11.1.0-i386-unknown-freebsd12.tar.xz) = 
3c23d3b97f869382b33878d8a5210056c60d5e749acfeea0354682bb013f5a20

-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] [llvm-dev] 12.0.0-rc1 Release has been tagged

[Dimitry Andric via lldb-dev]

On 19 Feb 2021, at 19:14, Tom Stellard  wrote:
> 
> On 2/13/21 1:44 PM, Louis Dionne wrote:
>>> On Feb 13, 2021, at 12:04, Dimitry Andric  wrote:
>>> On 28 Jan 2021, at 05:05, Tom Stellard via llvm-dev 
>>>  wrote:
 
 I've tagged the 12.0.0-rc1 release.  Testers can begin testing and upload 
 binaries.
>>> 
>>> During 12.0.0-rc1 test builds on FreeBSD, I encountered this unittest 
>>> failure, which turned out to be caused by recent libc++ changes:
...
>>> If you think this is a reasonable approach, I will create a review for it. 
>>> Otherwise, I will have to patch the test-release.sh script to pass 
>>> -DLIBCXX_ENABLE_NEW_DELETE_DEFINITIONS=ON to the CMake command line on 
>>> FreeBSD.
>> The correct approach would be to have a CMake cache file under 
>> libcxx/cmake/cache/FreeBSD.cmake that sets the right configuration for 
>> building libcxx as a system library on freebsd. That way, the cmake code 
>> itself can stay free of platform specific logic.
>> Also note that I remember asking vendors before making that change, but I 
>> guess I either forgot to ask Freebsd or you told me OK without thinking 
>> about this. I can’t verify which one happened because I’m on my phone, but 
>> I’ll check it out to make sure I have your contact information if I need to 
>> ask that sort of questions in the future. It could be useful to have some 
>> sort of libcxx-vendors group in Phabricator that I could tag whenever I want 
>> to ping you folks.
>> Please send a Phab and I’ll revise it quickly (probably on Monday morning).
> 
> Has this been fixed in the branch yet?

Yes, I submitted https://bugs.llvm.org/show_bug.cgi?id=49197, and you merged 
the fix in d14016d869ac. Thanks! :)

(That said, more work should probably be done on this particular issue, but the 
merged fix is good enough for the release.)

-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] [llvm-dev] 12.0.0-rc1 Release has been tagged

[Dimitry Andric via lldb-dev]

On 28 Jan 2021, at 05:05, Tom Stellard via llvm-dev  
wrote:
> 
> I've tagged the 12.0.0-rc1 release.  Testers can begin testing and upload 
> binaries.

For 12.0.0 rc1, I have built and tested on both FreeBSD 11 and 12. I
used two patches, which are attached.


Main results on amd64-freebsd11:

  Unsupported:  5557
  Passed : 80122
  Expectedly Failed  :   246
  Timed Out  : 2
  Failed :95
  Unexpectedly Passed: 2

Test suite results on amd64-freebsd11:

  Passed: 2399
  Failed:3


Main results on amd64-freebsd12:

  Unsupported:  5557
  Passed : 80125
  Expectedly Failed  :   242
  Timed Out  : 4
  Failed :90
  Unexpectedly Passed: 6

Test suite results on amd64-freebsd12:

  Passed: 2399
  Failed:3


Main results on i386-freebsd11:

  Unsupported:  3971
  Passed : 76669
  Expectedly Failed  :   223
  Failed :51
  Unexpectedly Passed: 1


Main results on i386-freebsd12:

  Unsupported:  3971
  Passed : 76672
  Expectedly Failed  :   221
  Failed :48
  Unexpectedly Passed: 3


Uploaded:
SHA256 (clang+llvm-12.0.0-rc1-amd64-unknown-freebsd11.tar.xz) = 
435e727287b9a3bf3f2da9bfec9d37b1118a59774885f0dd3597018f89515a4f
SHA256 (clang+llvm-12.0.0-rc1-amd64-unknown-freebsd12.tar.xz) = 
b2e49f56880fefe4bff2c45e74bfb55b2186fc16757a1b5d1b19f17dff9f49dd
SHA256 (clang+llvm-12.0.0-rc1-i386-unknown-freebsd11.tar.xz) = 
10f0e81e4d516b46aff8dc22af1cc6eb9db0ec9c3a43b6941b51a6728255d311
SHA256 (clang+llvm-12.0.0-rc1-i386-unknown-freebsd12.tar.xz) = 
077719695ebe6be1f55fb82eae483a9c550512809c6b272abfef9b2f84ada58e

-Dimitry


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


fix-libcxx-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] [llvm-dev] 12.0.0-rc1 Release has been tagged

[Dimitry Andric via lldb-dev]

On 28 Jan 2021, at 05:05, Tom Stellard via llvm-dev  
wrote:
> 
> I've tagged the 12.0.0-rc1 release.  Testers can begin testing and upload 
> binaries.

During 12.0.0-rc1 test builds on FreeBSD, I encountered this unittest failure, 
which turned out to be caused by recent libc++ changes:

  FAILED: tools/clang/bindings/python/tests/CMakeFiles/check-clang-python
  cd /home/dim/llvm/12.0.0/llvm-project/clang/bindings/python && 
/usr/local/bin/cmake -E env 
CLANG_LIBRARY_PATH=/home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib 
/usr/local/bin/python3.7 -m unittest discover
  

The '' signifies 8 errors, which become more clear if "unittest 
discover" is run with the -f (fail immediately) and -v (verbose) options:

  $ cd /home/dim/llvm/12.0.0/llvm-project/clang/bindings/python && 
/usr/local/bin/cmake -E env 
CLANG_LIBRARY_PATH=/home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib 
/usr/local/bin/python3.7 -m unittest discover -f -v
  test_access_specifiers 
(tests.cindex.test_access_specifiers.TestAccessSpecifiers)
  Ensure that C++ access specifiers are available on cursors ... ERROR

  ==
  ERROR: test_access_specifiers 
(tests.cindex.test_access_specifiers.TestAccessSpecifiers)
  Ensure that C++ access specifiers are available on cursors
  --
  Traceback (most recent call last):
File 
"/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
line 4173, in get_cindex_library
  library = cdll.LoadLibrary(self.get_filename())
File "/usr/local/lib/python3.7/ctypes/__init__.py", line 442, in LoadLibrary
  return self._dlltype(name)
File "/usr/local/lib/python3.7/ctypes/__init__.py", line 364, in __init__
  self._handle = _dlopen(self._name, mode)
  OSError: 
/home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib/../lib/libc++.so.1: 
Undefined symbol "_ZnamSt11align_val_t"

  During handling of the above exception, another exception occurred:

  Traceback (most recent call last):
File 
"/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/tests/cindex/test_access_specifiers.py",
 line 29, in test_access_specifiers
  """, lang = 'cpp')
File 
"/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/tests/cindex/util.py",
 line 41, in get_tu
  source)])
File 
"/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
line 2812, in from_source
  index = Index.create()
File 
"/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
line 2699, in create
  return Index(conf.lib.clang_createIndex(excludeDecls, 0))
File 
"/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
line 212, in __get__
  value = self.wrapped(instance)
File 
"/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
line 4147, in lib
  lib = self.get_cindex_library()
File 
"/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
line 4178, in get_cindex_library
  raise LibclangError(msg)
  clang.cindex.LibclangError: 
/home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib/../lib/libc++.so.1: 
Undefined symbol "_ZnamSt11align_val_t". To provide a path to libclang use 
Config.set_library_path() or Config.set_library_file().

  --
  Ran 1 test in 0.027s

  FAILED (errors=1)

It turns out that libc++.so.1 now depends on the symbol '_ZnamSt11align_val_t', 
which is 'operator new [](unsigned long, std::align_val_t)'. Embarassingly, 
libc++.so.1 has always depended on this C++17 specific variant of operator new. 
But FreeBSD's C++ ABI library, libcxxrt, has never supported this variant!

Previously, this never was a problem, because libc++ provided its own weak 
definitions of these operators. But recently the define 
_LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS was toggled to on by default, which 
disables those definitions. This happened in 
9b40ee8eb0c194f4b2787801ac6f9ef8fc1b8f46 ("[libc++] Define new/delete in 
libc++abi only by default") by Louis Dionne.

While this is reasonable for the libc++abi situation, where it might lead to 
circular dependencies, I would like to turn the definitions on again in case 
libcxxrt is used for the C++ ABI, such as on FreeBSD.

If you think this is a reasonable approach, I will create a review for it. 
Otherwise, I will have to patch the test-release.sh script to pass 
-DLIBCXX_ENABLE_NEW_DELETE_DEFINITIONS=ON to the CMake command line on FreeBSD.

-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 11.1.0-rc3 has been tagged

[Dimitry Andric via lldb-dev]

On 8 Feb 2021, at 18:14, Tom Stellard via Release-testers 
 wrote:
> 
> I've tagged LLVM 11.1.0-rc3.  If there are no issues, then I'll be tagging
> the final release in 1 week.  Testers please test and upload binaries.

For 11.1.0 rc3, I have built and tested on both FreeBSD 11 and 12 again.
No additional patches were needed.

(Note that I upgraded my FreeBSD 12 build machine from 12.1-RELEASE to
12.2-RELEASE, due to the former going out of support as of 2021-01-31.
This is likely the reason for more passing test cases.)


Main results on amd64-freebsd11:

  Unsupported:  5122 (11.1.0 rc2:  5122)
  Passed : 69797 (11.1.0 rc2: 69797)
  Expectedly Failed  :   246 (11.1.0 rc2:   246)
  Timed Out  :16 (11.1.0 rc2:16)
  Failed :   479 (11.1.0 rc2:   479)
  Unexpectedly Passed: 2 (11.1.0 rc2: 2)

Test suite results on amd64-freebsd11:

  Passed: 2399 (11.1.0 rc2: 2399)
  Failed:3 (11.1.0 rc2:3)


Main results on amd64-freebsd12:

  Unsupported:  5122 (11.1.0 rc2:  5122)
  Passed : 70257 (11.1.0 rc2: 69794)
  Expectedly Failed  :   242 (11.1.0 rc2:   246)
  Timed Out  :43 (11.1.0 rc2:17)
  Failed :69 (11.1.0 rc2:   481)
  Unexpectedly Passed: 6 (11.1.0 rc2: 2)

Test suite results on amd64-freebsd12:

  Passed: 2399 (11.1.0 rc2: 2399)
  Failed:3 (11.1.0 rc2:3)


Main results on i386-freebsd11:

  Unsupported:  3513 (11.1.0 rc2:  3513)
  Passed : 66681 (11.1.0 rc2: 66675)
  Expectedly Failed  :   231 (11.1.0 rc2:   231)
  Timed Out  : 7 (11.1.0 rc2: 7)
  Failed :   311 (11.1.0 rc2:   317)
  Unexpectedly Passed: 1 (11.1.0 rc2: 1)


Main results on i386-freebsd12:

  Unsupported:  3513 (11.1.0 rc2:  3513)
  Passed : 66679 (11.1.0 rc2: 66670)
  Expectedly Failed  :   229 (11.1.0 rc2:   231)
  Timed Out  : 7 (11.1.0 rc2: 7)
  Failed :   313 (11.1.0 rc2:   322)
  Unexpectedly Passed: 3 (11.1.0 rc2: 1)


Uploaded:
SHA256 (clang+llvm-11.1.0-rc3-amd64-unknown-freebsd11.tar.xz) = 
e3a845bd2f0d7a1be0ec4f6622b2c26fa5f3c25b9111be2d05578c41aae71e9d
SHA256 (clang+llvm-11.1.0-rc3-amd64-unknown-freebsd12.tar.xz) = 
b21fd658b9612b78beede211f8c1b72e1c3c53f1c04284e0caa0a60b8e9876e4
SHA256 (clang+llvm-11.1.0-rc3-i386-unknown-freebsd11.tar.xz) = 
48e2e32e94909e89ae4ed524a9a1f3a7a88a51afcb1b26d070d3ba0250653f28
SHA256 (clang+llvm-11.1.0-rc3-i386-unknown-freebsd12.tar.xz) = 
1318f259879f727f427e8a3bf946db7c36cd099583c8c517ce33ed9bdf79e694

-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 11.1.0-rc1 has been tagged

[Dimitry Andric via lldb-dev]

On 14 Jan 2021, at 02:46, Tom Stellard via Release-testers 
 wrote:
> 
> LLVM 11.1.0-rc1 has been tagged.  This is a special release with a 
> libclang.so ABI fix to ensure libclang.so remains compatible with LLVM 10 and 
> LLVM 12.  Testers may begin testing and upload binaries.

For 11.1.0 rc1, I have built and tested on both FreeBSD 11 and 12 again.
No additional patches were needed.


Main results on amd64-freebsd11:

  Unsupported:  5122 (11.0.1 final:  5122)
  Passed : 69796 (11.0.1 final: 69797)
  Expectedly Failed  :   246 (11.0.1 final:   246)
  Timed Out  :16 (11.0.1 final:16)
  Failed :   480 (11.0.1 final:   479)
  Unexpectedly Passed: 2 (11.0.1 final: 2)

Test suite results on amd64-freebsd11:

  Passed: 2399 (11.0.1 final: 2399)
  Failed:3 (11.0.1 final:3)


Main results on amd64-freebsd12:

  Unsupported:  5122 (11.0.1 final:  5122)
  Passed : 69794 (11.0.1 final: 69794)
  Expectedly Failed  :   246 (11.0.1 final:   246)
  Timed Out  :16 (11.0.1 final:16)
  Failed :   482 (11.0.1 final:   482)
  Unexpectedly Passed: 2 (11.0.1 final: 2)

Test suite results on amd64-freebsd12:

  Passed: 2399 (11.0.1 final: 2399)
  Failed:3 (11.0.1 final:3)


Main results on i386-freebsd11:

  Unsupported:  3513 (11.0.1 final:  3513)
  Passed : 66675 (11.0.1 final: 66675)
  Expectedly Failed  :   231 (11.0.1 final:   231)
  Timed Out  : 7 (11.0.1 final: 7)
  Failed :   317 (11.0.1 final:   317)
  Unexpectedly Passed: 1 (11.0.1 final: 1)


Main results on i386-freebsd12:

  Unsupported:  3513 (11.0.1 final:  3513)
  Passed : 66670 (11.0.1 final: 66670)
  Expectedly Failed  :   231 (11.0.1 final:   231)
  Timed Out  : 7 (11.0.1 final: 7)
  Failed :   322 (11.0.1 final:   322)
  Unexpectedly Passed: 1 (11.0.1 final: 1)


Uploaded:
SHA256 (clang+llvm-11.1.0-rc1-amd64-unknown-freebsd11.tar.xz) = 
c8970b2950bb45c17bb1e2ae0eab1c89d082a23ffcd0433543f08d3900b11995
SHA256 (clang+llvm-11.1.0-rc1-amd64-unknown-freebsd12.tar.xz) = 
3fd6a11d405c1a671a8685c52acbf5de34e50fb1abb8685b0b61a63d82a5750d
SHA256 (clang+llvm-11.1.0-rc1-i386-unknown-freebsd11.tar.xz) = 
59c0f94d0ebaefcd65ad46ad1e0499ba0dbd617cb3375d47bd509d4f4a968407
SHA256 (clang+llvm-11.1.0-rc1-i386-unknown-freebsd12.tar.xz) = 
4796b3acbd3550c2ca2d058f32f1383c84aef42566fe0acd7b5eb70442f26fbe

-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 11.0.1-final has been tagged

[Dimitry Andric via lldb-dev]

On 6 Jan 2021, at 04:21, Tom Stellard via Release-testers 
 wrote:
> 
> I've tagged LLVM 11.0.1-final.  Testers can upload the final binaries now.

For 11.0.1 release, I have built and tested on both FreeBSD 11 and 12
this time. No additional patches were needed.


Main results on amd64-freebsd11:

  Unsupported:  5122 (11.0.1 rc2:  5122)
  Passed : 69797 (11.0.1 rc2: 69796)
  Expectedly Failed  :   246 (11.0.1 rc2:   246)
  Timed Out  :16 (11.0.1 rc2:16)
  Failed :   479 (11.0.1 rc2:   480)
  Unexpectedly Passed: 2 (11.0.1 rc2: 2)

Test suite results on amd64-freebsd11:

  Passed: 2399 (11.0.1 rc2: 2399)
  Failed:3 (11.0.1 rc2:3)


Main results on amd64-freebsd12:

  Unsupported:  5122 (11.0.1 rc2:  5122)
  Passed : 69794 (11.0.1 rc2: 69793)
  Expectedly Failed  :   246 (11.0.1 rc2:   246)
  Timed Out  :16 (11.0.1 rc2:16)
  Failed :   482 (11.0.1 rc2:   483)
  Unexpectedly Passed: 2 (11.0.1 rc2: 2)

Test suite results on amd64-freebsd12:

  Passed: 2399 (11.0.1 rc2: 2399)
  Failed:3 (11.0.1 rc2:3)


Main results on i386-freebsd11:

  Unsupported:  3513 (11.0.1 rc2:  3513)
  Passed : 66675 (11.0.1 rc2: 66675)
  Expectedly Failed  :   231 (11.0.1 rc2:   231)
  Timed Out  : 7 (11.0.1 rc2: 7)
  Failed :   317 (11.0.1 rc2:   317)
  Unexpectedly Passed: 1 (11.0.1 rc2: 1)


Main results on i386-freebsd12:

  Unsupported:  3513 (11.0.1 rc2:  3513)
  Passed : 66670 (11.0.1 rc2: 66670)
  Expectedly Failed  :   231 (11.0.1 rc2:   231)
  Timed Out  : 7 (11.0.1 rc2: 7)
  Failed :   322 (11.0.1 rc2:   322)
  Unexpectedly Passed: 1 (11.0.1 rc2: 1)


Uploaded:
SHA256 (clang+llvm-11.0.1-amd64-unknown-freebsd11.tar.xz) = 
cd0a6da1825bc7440c5a8dfa22add4ee91953c45aa0e5597ba1a5caf347f807d
SHA256 (clang+llvm-11.0.1-amd64-unknown-freebsd12.tar.xz) = 
2daa205f87d2b81a281f3883c2102cd69ac017193b19ea30f914b57f904c7c4b
SHA256 (clang+llvm-11.0.1-i386-unknown-freebsd11.tar.xz) = 
e32ad587e800145a7868449b1416e25d05a6ca08c071ecc8173cf9e1b0b7dcdd
SHA256 (clang+llvm-11.0.1-i386-unknown-freebsd12.tar.xz) = 
46e88ce3a5efef198cade0cf29ee152f3361ca4488fd7701cc79485c06aa93b8

-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 11.0.1-rc2 has been tagged

[Dimitry Andric via lldb-dev]

On 19 Dec 2020, at 07:33, Tom Stellard via Release-testers 
 wrote:
> 
> I've just tagged LLVM 11.0.1-rc2, hopefully this will be the last release 
> candidate.  Testers can begin testing and uploading binaries.

For 11.0.1 rc2, I have built and tested on both FreeBSD 11 and 12 this
time. No additional patches were needed.


Main results on amd64-freebsd11:

  Unsupported:  5122 (11.0.1 rc1:  5122)
  Passed : 69796 (11.0.1 rc1: 69779)
  Expectedly Failed  :   246 (11.0.1 rc1:   245)
  Timed Out  :16 (11.0.1 rc1:16)
  Failed :   480 (11.0.1 rc1:   478)
  Unexpectedly Passed: 2 (11.0.1 rc1: 2)

Test suite results on amd64-freebsd11:

  Passed: 2399 (11.0.1 rc1: 2400)
  Failed:3 (11.0.1 rc1:2)


Main results on amd64-freebsd12:

  Unsupported:  5122 (11.0.1 rc1:  5122)
  Passed : 69793 (11.0.1 rc1: 69776)
  Expectedly Failed  :   246 (11.0.1 rc1:   245)
  Timed Out  :16 (11.0.1 rc1:16)
  Failed :   483 (11.0.1 rc1:   481)
  Unexpectedly Passed: 2 (11.0.1 rc1: 2)

Test suite results on amd64-freebsd12:

  Passed: 2399 (11.0.1 rc1: 2399)
  Failed:3 (11.0.1 rc1:3)


Main results on i386-freebsd11:

  Unsupported:  3513 (11.0.1 rc1:  3513)
  Passed : 66675 (11.0.1 rc1: 66654)
  Expectedly Failed  :   231 (11.0.1 rc1:   230)
  Timed Out  : 7 (11.0.1 rc1: 7)
  Failed :   317 (11.0.1 rc1:   319)
  Unexpectedly Passed: 1 (11.0.1 rc1: 1)


Main results on i386-freebsd12:

  Unsupported:  3513 (11.0.1 rc1:  3513)
  Passed : 66670 (11.0.1 rc1: 66651)
  Expectedly Failed  :   231 (11.0.1 rc1:   230)
  Timed Out  : 7 (11.0.1 rc1: 7)
  Failed :   322 (11.0.1 rc1:   322)
  Unexpectedly Passed: 1 (11.0.1 rc1: 1)


Uploaded:
SHA256 (clang+llvm-11.0.1-rc2-amd64-unknown-freebsd11.tar.xz) = 
8063ba2616492e060820b6859fe69c9f7ae9ea9b0307568635d816fbf2070722
SHA256 (clang+llvm-11.0.1-rc2-amd64-unknown-freebsd12.tar.xz) = 
f72e46f4f18e133a527fc120b78c928277b36eb60a40bf71717a6c952ec0fe11
SHA256 (clang+llvm-11.0.1-rc2-i386-unknown-freebsd11.tar.xz) = 
b4c753772180be3ba3603de3b763626d975c6e834109af759b9df2a0ecf064ff
SHA256 (clang+llvm-11.0.1-rc2-i386-unknown-freebsd12.tar.xz) = 
22513d2e02a527531d4886cc9c612f85e63bdc987e9b28aa127cb74b7ae2f37f

-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 11.0.1-rc1 has been tagged

[Dimitry Andric via lldb-dev]

On 26 Nov 2020, at 08:21, Tom Stellard via Release-testers 
 wrote:
> 
> I've tagged LLVM 11.0.1-rc1.  Testers may begin testing and uploading 
> binaries.  If you still have bugs you want fixed in LLVM 11.0.1, you have 
> until Dec. 8 to request backports.  You can make these requests by filing a 
> bug at bugs.llvm.org and putting release-11.0.1 in the 'blocks' field.

For 11.0.1 rc1, I have built and tested on both FreeBSD 11 and 12 this time. No 
additional patches were needed.


Main results on amd64-freebsd11:

  Unsupported:  5122 (11.0.0 final:  5122)
  Passed : 69779 (11.0.0 final: 69765)
  Expectedly Failed  :   245 (11.0.0 final:   245)
  Timed Out  :16 (11.0.0 final:16)
  Failed :   478 (11.0.0 final:   479)
  Unexpectedly Passed: 2 (11.0.0 final: 2)

Test suite results on amd64-freebsd11:

  Passed: 2400 (11.0.0 final: 2400)
  Failed:2 (11.0.0 final:2)


Main results on amd64-freebsd12:

  Unsupported:  5122
  Passed : 69776
  Expectedly Failed  :   245
  Timed Out  :16
  Failed :   481
  Unexpectedly Passed: 2

Test suite results on amd64-freebsd12:

  Passed: 2399
  Failed:3


Main results on i386-freebsd11:

  Unsupported:  3512
  Passed : 66597
  Expectedly Failed  :   230
  Timed Out  : 7
  Failed :   322
  Unexpectedly Passed: 1


Uploaded:
SHA256 (clang+llvm-11.0.1-rc1-amd64-unknown-freebsd11.tar.xz) = 
92d956dbe14176c8defeb32c03449ed61a42eb0ba0b500784fff6f8a62b00f01
SHA256 (clang+llvm-11.0.1-rc1-amd64-unknown-freebsd12.tar.xz) = 
7d38dcbe47d62da3dd16ed31e5749edb952163e9c66cc3b12926a78e8f88
SHA256 (clang+llvm-11.0.1-rc1-i386-unknown-freebsd11.tar.xz) = 
2e80d8d6c7178374696c67e2fea6a7d9cadf68bca08e07238b814d46cea09fa3
SHA256 (clang+llvm-11.0.1-rc1-i386-unknown-freebsd12.tar.xz) = 
b3d4ca7539f3e29a47b8f724503223051e6a62157b966afa6a4aba9a89400ef7

-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] [11.0.0 Release] Release Candidate 6 is here

[Dimitry Andric via lldb-dev]

On 7 Oct 2020, at 16:40, Hans Wennborg via Release-testers 
 wrote:
> 
> A few more issues appeared, so here is yet another release candidate:
> llvmorg-11.0.0-rc6 was just tagged.

I've built rc6, and again this did not need any patches.

Main results on amd64-freebsd11:

  Unsupported:  5122 (rc4:  5122)
  Passed : 69762 (rc4: 69761)
  Expectedly Failed  :   245 (rc4:   245)
  Timed Out  :16 (rc4:16)
  Failed :   482 (rc4:   481)
  Unexpectedly Passed: 2 (rc4: 2)

Test suite results on amd64-freebsd11:

  Passed: 2399 (rc5: 2399)
  Failed:3 (rc5:3)

Main results on i386-freebsd11:

  Unsupported:  3513 (rc4:  3513)
  Passed : 66638 (rc4: 66637)
  Expectedly Failed  :   230 (rc4:   230)
  Timed Out  : 7 (rc4: 7)
  Failed :   322 (rc4:   321)
  Unexpectedly Passed: 1 (rc4: 1)

Uploaded:
SHA256 (clang+llvm-11.0.0-rc6-amd64-unknown-freebsd11.tar.xz) = 
c2c9840e7329d77d9655f5b576bc441db254622ea9c1845d3f3846b75f7220f6
SHA256 (clang+llvm-11.0.0-rc6-i386-unknown-freebsd11.tar.xz) = 
aa949a4978f6aa33b678b0887c74bfaf954080b8d0b210b458759599fb108903

-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] [11.0.0 Release] Release Candidate 5 is here

[Dimitry Andric via lldb-dev]

On 30 Sep 2020, at 20:07, Hans Wennborg via Release-testers 
 wrote:
> 
> We had to pick up another bug fix, so here is another release
> candidate: llvmorg-11.0.0-rc5 tag was just created.

I've built both rc4 and rc5, and again these did not need any patches.

Main results on amd64-freebsd11:

  Unsupported:  5122 (rc4:  5122, rc3:  5122)
  Passed : 69761 (rc4: 69761, rc3: 69761)
  Expectedly Failed  :   245 (rc4:   245, rc3:   245)
  Timed Out  :16 (rc4:16, rc3:16)
  Failed :   481 (rc4:   481, rc3:   480)
  Unexpectedly Passed: 2 (rc4: 2, rc3: 2)

Test suite results on amd64-freebsd11:

  Passed: 2399 (rc4: 2399, rc3: 2399)
  Failed:3 (rc4:3, rc3:3)

Main results on i386-freebsd11:

  Unsupported:   3513 (rc4:  3513, rc3:  3513)
  Passed :  66637 (rc4: 66637, rc3: 66636)
  Expectedly Failed  :230 (rc4:   230, rc3:   230)
  Timed Out  :  7 (rc4: 7, rc3: 7)
  Failed :321 (rc4:   321, rc3:   321)
  Unexpectedly Passed:  1 (rc4: 1, rc3: 1)

Uploaded:
SHA256 (clang+llvm-11.0.0-rc4-amd64-unknown-freebsd11.tar.xz) = 
b95c237df671ee507c607e8d36245126c5ea5241389aae0b20e3e4fce4f3df37
SHA256 (clang+llvm-11.0.0-rc4-i386-unknown-freebsd11.tar.xz) = 
60755863b49155d23c9fef9571aa09ca46425a9bd830d9ef498fe9855e741d11
SHA256 (clang+llvm-11.0.0-rc5-amd64-unknown-freebsd11.tar.xz) = 
712401cade6996bb7042cdd659b41ee4411cdd9cc34cbdd21e7a4cafe75ac267
SHA256 (clang+llvm-11.0.0-rc5-i386-unknown-freebsd11.tar.xz) = 
956bd26d28602f375853593631c1f413a869ba6087c51f7ef5405fa31263d06c

-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] [11.0.0 Release] Release Candidate 3 is here

[Dimitry Andric via lldb-dev]

On 22 Sep 2020, at 17:12, Hans Wennborg via Release-testers 
 wrote:
> 
> After some delay, the llvmorg-11.0.0-rc3 tag was just created.

This rc3, like rc2, I could finally build and test without adding any
patches! :)

Main results on amd64-freebsd11:

  Unsupported:  5122 (rc2:  5121)
  Passed : 69761 (rc2: 69739)
  Expectedly Failed  :   245 (rc2:   245)
  Timed Out  :16 (rc2:16)
  Failed :   480 (rc2:   481)
  Unexpectedly Passed: 2 (rc2: 2)

Test suite results on amd64-freebsd11:

  Passed: 2399 (rc2: 2399)
  Failed:3 (rc2:3)

Main results on i386-freebsd11:

  Unsupported:  3513 (rc2:  3512)
  Passed : 66636 (rc2: 66614)
  Expectedly Failed  :   230 (rc2:   230)
  Timed Out  : 7 (rc2: 7)
  Failed :   321 (rc2:   322)
  Unexpectedly Passed: 1 (rc2: 1)

Uploaded:
SHA256 (clang+llvm-11.0.0-rc3-amd64-unknown-freebsd11.tar.xz) = 
8ef0c820ff9865d54c2d2b79abc0aae3ca584218a3f90a31487590a90f398a26
SHA256 (clang+llvm-11.0.0-rc3-i386-unknown-freebsd11.tar.xz) = 
17e9f4bafbd34de102f0e8530ca154a57fa205cd183f402b366f873f3607f55b

-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] [11.0.0 Release] Release Candidate 2 is here

[Dimitry Andric via lldb-dev]

On 20 Aug 2020, at 22:34, Hans Wennborg via Release-testers 
 wrote:
> 
> The llvmorg-11.0.0-rc2 tag was just created.

This rc2, I could finally build and test without adding any patches! :)

Main results on amd64-freebsd11:

  Unsupported:  5121 (rc1:  5121)
  Passed : 69739 (rc1: 69722)
  Expectedly Failed  :   245 (rc1:   245)
  Timed Out  :16 (rc1:12)
  Failed :   481 (rc1:   485)
  Unexpectedly Passed: 2 (rc1: 2)

Test suite results on amd64-freebsd11:

  Passed: 2399 (rc1: 2399)
  Failed:3 (rc1:3)

Main results on i386-freebsd11:

  Unsupported:  3512 (rc1:  3512)
  Passed : 66614 (rc1: 66597)
  Expectedly Failed  :   230 (rc1:   230)
  Timed Out  : 7 (rc1: 7)
  Failed :   322 (rc1:   322)
  Unexpectedly Passed: 1 (rc1: 1)

Uploaded:
SHA256 (clang+llvm-11.0.0-rc2-amd64-unknown-freebsd11.tar.xz) = 
6d6733f3b996c90621d7712ad08c7722ca4d8f5ec75357ee3755ec9e2f337906
SHA256 (clang+llvm-11.0.0-rc2-i386-unknown-freebsd11.tar.xz) = 
4ccba28c955ba0fce5de11c0d772d2304d7e7053a71b1042e11dc86c7fdab5c0

-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] [11.0.0 Release] Release Candidate 1 is here

[Dimitry Andric via lldb-dev]

On 28 Jul 2020, at 19:49, Hans Wennborg via Release-testers 
 wrote:
> 
> We're a little bit behind schedule, but RC1 is now here. It was tagged
> earlier today as llvmorg-11.0.0-rc1.

For this rc1, I used two patches, which are attached. (Yes, I am
slowly, very slowly, working on getting these into the tree. :)

Main results on amd64-freebsd11:

  Unsupported:  5121
  Passed : 69722
  Expectedly Failed  :   245
  Timed Out  :12
  Failed :   485
  Unexpectedly Passed: 2

Test suite results on amd64-freebsd11:

  Passed: 2399
  Failed:3

Main results on i386-freebsd11:

  Unsupported:  3512
  Passed : 66597
  Expectedly Failed  :   230
  Timed Out  : 7
  Failed :   322
  Unexpectedly Passed: 1

Uploaded:
SHA256 (clang+llvm-11.0.0-rc1-amd64-unknown-freebsd11.tar.xz) = 
06c763ddea9e02a5542afb1b4e6a31954e7e025bdeab71c2cd750a124566aaa7
SHA256 (clang+llvm-11.0.0-rc1-i386-unknown-freebsd11.tar.xz) = 
447755a057e222181bc3747ca63a9d36d3bad38b8fce9ac40c84feeaabd245d6

-Dimitry



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.1-rc4 tagged

[Dimitry Andric via lldb-dev]

On 8 Jul 2020, at 06:08, Tom Stellard via Release-testers 
 wrote:
> I've tagged 10.0.1-rc4, please test and report the results.

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

Main results on amd64-freebsd11:

  Expected Passes: 67554
  Passes With Retry  : 1
  Expected Failures  : 265
  Unsupported Tests  : 5114
  Unexpected Passes  : 2
  Unexpected Failures: 513
  Individual Timeouts: 11

Test suite results on amd64-freebsd11:

  Expected Passes: 2398
  Unexpected Failures: 3

Main results on i386-freebsd11:

  Expected Passes: 64619
  Passes With Retry  : 1
  Expected Failures  : 248
  Unsupported Tests  : 3541
  Unexpected Passes  : 1
  Unexpected Failures: 192
  Individual Timeouts: 7

Uploaded:
SHA256 (clang+llvm-10.0.1-rc4-amd64-unknown-freebsd11.tar.xz) = 
26b4d7554bee13386978766a4c3efb1a71569dd885c5c79673a3e69c16478286
SHA256 (clang+llvm-10.0.1-rc4-i386-unknown-freebsd11.tar.xz) = 
b4640a5efd146899f1daaa34ab33994d3f9600fbcb3593aad203102a2175925e

-Dimitry


fix-clang-1.diff
Description: Binary data


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


fix-libcxx-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.1-rc2 release has been tagged

[Dimitry Andric via lldb-dev]

On 27 Jun 2020, at 02:44, Tom Stellard via Release-testers 
 wrote:
> 
> I've tagged the 10.0.1-rc2 release, please test the release and report any 
> issues.

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

Main results on amd64-freebsd11:

  Expected Passes: 68020
  Passes With Retry  : 1
  Expected Failures  : 265
  Unsupported Tests  : 4654
  Unresolved Tests   : 1
  Unexpected Passes  : 6
  Unexpected Failures: 542
  Individual Timeouts: 13

Test suite results on amd64-freebsd11:

  Expected Passes: 2398
  Unexpected Failures: 3

Main results on i386-freebsd11:

  Expected Passes: 65077
  Passes With Retry  : 2
  Expected Failures  : 248
  Unsupported Tests  : 3083
  Unexpected Passes  : 6
  Unexpected Failures: 225
  Individual Timeouts: 10

Uploaded:
SHA256 (clang+llvm-10.0.1-rc2-amd64-unknown-freebsd11.tar.xz) = 
e81a26433c45b3a477686a8a361c9fb2dc5772f91b0841ebedeb01e9bebecac9
SHA256 (clang+llvm-10.0.1-rc2-i386-unknown-freebsd11.tar.xz) = 
3ad9341b2548f9a48536e4068823c36af9ff32dc13c09f07493bd862ac4c79ba

-Dimitry



fix-clang-1.diff
Description: Binary data


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


fix-libcxx-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.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

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] 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] [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] [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 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 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] [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 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] [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(, {, 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(, {, 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 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.

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] 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 :: 

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

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 :: 

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
  

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
  

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
  

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 :: 

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
  

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++ :: 

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++ :: 

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
  

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] 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] [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] 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] [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 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] 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] [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] [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] 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] [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] 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] 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 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] 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] 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.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] [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] 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] 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 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 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] 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 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] [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 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] [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:
> 
> 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] [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] [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] [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] [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] [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 :: 

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] [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] [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] [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: 

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,
> 
> 

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] [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] [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] [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] [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] [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] 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 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 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] [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
 

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