sorry about the breakage... thanks for testing on real hardware!

In D86321#2229537, @vvereschaka wrote:

The test got failed again. I got the following output:

ubuntu@jetson8:~$ ./t.tmp.exe
Testing 29715 symbols.
1ILeeeEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE -> <-0x1.cecececececececececececececep+11983L
Got instead: <-0x1.cecececececececececececececep+11983L>
t.tmp.exe: C:/buildbot/temp/llvm-project/libcxxabi/test/test_demangle.pass.cpp:30001: void testFPLiterals(): Assertion `false' failed.
Aborted (core dumped)

looks like it does not expect trailing >.

Address vvereschaka's comment.

In D77924#2229360, @vvereschaka wrote:

I ran the test directly on our aarch64 board.

In D77924#2228309, @RKSimon wrote:

@enh This is causing a test failure on the windows/aarch64 cross compile bot, please can you take a look:

http://lab.llvm.org:8011/builders/llvm-clang-win-x-aarch64/builds/2267
http://lab.llvm.org:8011/builders/llvm-clang-win-x-aarch64/builds/2267/steps/test-libc%2B%2Babi/logs/FAIL%3A%20libc%2B%2Babi%3A%3A%20test_demangle.pass.cpp

(sorry, didn't see these comments until after i'd git pushed. i've failed to set up gmail filters so i see the mail i need to see without drowning in thousands of mails i don't need to see :-( )

clang-format the new test (but leave the other 30kloc).

In D77924#2089802, @ldionne wrote:

In D77924#2088349, @enh wrote:

In D77924#1977737, @ldionne wrote:

Is it possible to add a test to always trigger this bug?

only if you run with hwasan.

Do the current tests fail under hwasan? If not, please add a test case that fails under hwasan, it's better than nothing.

Add test.

Use actual upper bound.

In D77924#1977737, @ldionne wrote:

Is it possible to add a test to always trigger this bug?

actually, it looks like clang is inlining the code for all the is*_l
functions anyway. you're paying for the indirection on
strcoll_l/strxfrm_l/wcscoll_l/wcsxfrm_l, but no one should be using
those anyway.

honestly, if it was me, i'd keep all these inlines even for current releases: inlining a call to the underlying function saves you a layer of useless cruft at runtime. (the Android "implementations" are just one-liners that drop the extra argument and call the underlying function, just like these inlines.)

i assume the idea here is "all libc++ mutexes are covered by RAII anyway, so there's no value to the error checking"?

yeah, we always used the low numbers internally.

not really though --- i think you're getting that from libgcc. so
although short term you don't need to add this stuff to compiler-rt to
test, it will be necessary for anyone not using libgcc. (like us, at
some point in the future.)