Unexpected failing test pbump2gig.pass.cpp in libc++ for 6.0-rc2

[llvmbot]

Bugzilla Link	36373
Resolution	FIXED
Resolved on	Feb 15, 2018 00:22
Version	6.0
OS	Linux
Blocks	#35152
Reporter	LLVM Bugzilla Contributor
CC	@zmodem,@mclow

Extended Description

On a big endian mips64 system, the test-release.sh reports a failure in pbump2gig.pass.cpp. This test failure did not occur on a little endian mips64 system. In both cases the binaries were compiled for mips32(el) as appropriate.

Reported test output:

Compiled With: ['/home/sdardis/releases/6.0.0/release/rc2/Phase2/Release/llvmCore-6.0.0-rc2.install/usr/local/bin/clang++', '-o', '/home/sdardis/releases/6.0.0/release/rc2/Phase3/Release/llvmCore-6.0.0-rc2.obj/projects/libcxx/test/std/input.output/stream.buffers/streambuf/streambuf.protected/streambuf.put.area/Output/pbump2gig.pass.cpp.o', '-x', 'c++', '/home/sdardis/releases/6.0.0/release/rc2/llvm.src/projects/libcxx/test/std/input.output/stream.buffers/streambuf/streambuf.protected/streambuf.put.area/pbump2gig.pass.cpp', '-c', '-v', '-D_LIBCPP_DISABLE_AVAILABILITY', '-ftemplate-depth=270', '-Werror=thread-safety', '-std=c++2a', '-include', '/home/sdardis/releases/6.0.0/release/rc2/llvm.src/projects/libcxx/test/support/nasty_macros.hpp', '-nostdinc++', '-I/home/sdardis/releases/6.0.0/release/rc2/llvm.src/projects/libcxx/include', '-I/home/sdardis/releases/6.0.0/release/rc2/Phase3/Release/llvmCore-6.0.0-rc2.obj/projects/libcxx/include/c++build', '-D__STDC_FORMAT_MACROS', '-D__STDC_LIMIT_MACROS', '-D__STDC_CONSTANT_MACROS', '-I/home/sdardis/releases/6.0.0/release/rc2/llvm.src/projects/libcxx/test/support', '-DLIBCXX_FILESYSTEM_STATIC_TEST_ROOT="/home/sdardis/releases/6.0.0/release/rc2/llvm.src/projects/libcxx/test/std/experimental/filesystem/Inputs/static_test_env"', '-DLIBCXX_FILESYSTEM_DYNAMIC_TEST_ROOT="/home/sdardis/releases/6.0.0/release/rc2/Phase3/Release/llvmCore-6.0.0-rc2.obj/projects/libcxx/test/filesystem/Output/dynamic_env"', '-DLIBCXX_FILESYSTEM_DYNAMIC_TEST_HELPER="/usr/bin/python2.7 /home/sdardis/releases/6.0.0/release/rc2/llvm.src/projects/libcxx/test/support/filesystem_dynamic_test_helper.py"', '-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', '-c', '&&', '/home/sdardis/releases/6.0.0/release/rc2/Phase2/Release/llvmCore-6.0.0-rc2.install/usr/local/bin/clang++', '-o', '/home/sdardis/releases/6.0.0/release/rc2/Phase3/Release/llvmCore-6.0.0-rc2.obj/projects/libcxx/test/std/input.output/stream.buffers/streambuf/streambuf.protected/streambuf.put.area/Output/pbump2gig.pass.cpp.exe', '/home/sdardis/releases/6.0.0/release/rc2/Phase3/Release/llvmCore-6.0.0-rc2.obj/projects/libcxx/test/std/input.output/stream.buffers/streambuf/streambuf.protected/streambuf.put.area/Output/pbump2gig.pass.cpp.o', '-v', '-D_LIBCPP_DISABLE_AVAILABILITY', '-ftemplate-depth=270', '-L/home/sdardis/releases/6.0.0/release/rc2/Phase3/Release/llvmCore-6.0.0-rc2.obj/./lib', '-Wl,-rpath,/home/sdardis/releases/6.0.0/release/rc2/Phase3/Release/llvmCore-6.0.0-rc2.obj/./lib', '-nodefaultlibs', '-lc++experimental', '-lc++', '-lm', '-lgcc_s', '-lgcc', '-lpthread', '-lc', '-lgcc_s', '-lgcc']
Command: ['/home/sdardis/releases/6.0.0/release/rc2/Phase3/Release/llvmCore-6.0.0-rc2.obj/projects/libcxx/test/std/input.output/stream.buffers/streambuf/streambuf.protected/streambuf.put.area/Output/pbump2gig.pass.cpp.exe']
Exit Code: -6
Standard Error:

terminating with uncaught exception of type std::length_error: basic_string

[llvmbot]

assigned to @mclow

[zmodem]

This seems serious if it indicates there's an endianness problem in the code.

[llvmbot]

It occurred in RC1 but was lost in the sea of -Wtautological-comparison failures.

[llvmbot]

Little endian:

Dump of assembler code for function _ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEjc:
0x77f80c0c <+0>: lui v0,0x5
0x77f80c10 <+4>: addiu v0,v0,-29516
0x77f80c14 <+8>: addiu sp,sp,-48
0x77f80c18 <+12>: sw ra,44(sp)
0x77f80c1c <+16>: sw s5,40(sp)
0x77f80c20 <+20>: sw s4,36(sp)
0x77f80c24 <+24>: sw s3,32(sp)
0x77f80c28 <+28>: sw s2,28(sp)
0x77f80c2c <+32>: sw s1,24(sp)
0x77f80c30 <+36>: sw s0,20(sp)
0x77f80c34 <+40>: move s0,a1
0x77f80c38 <+44>: addu s1,v0,t9
0x77f80c3c <+48>: move s2,a2
=> 0x77f80c40 <+52>: sltiu at,s0,-16
0x77f80c44 <+56>: beqz at,0x77f80ce4 <_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEjc+216>
0x77f80c48 <+60>: move s3,a0
0x77f80c4c <+64>: sltiu at,s0,11

Big endian:

Dump of assembler code for function _ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEjc:
0x77f0b8f4 <+0>: lui v0,0xc
0x77f0b8f8 <+4>: addiu v0,v0,-6964
0x77f0b8fc <+8>: addiu sp,sp,-48
0x77f0b900 <+12>: sw ra,44(sp)
0x77f0b904 <+16>: sw s5,40(sp)
0x77f0b908 <+20>: sw s4,36(sp)
0x77f0b90c <+24>: sw s3,32(sp)
0x77f0b910 <+28>: sw s2,28(sp)
0x77f0b914 <+32>: sw s1,24(sp)
0x77f0b918 <+36>: sw s0,20(sp)
1=> 0x77f0b91c <+40>: lui at,0x7fff
0x77f0b920 <+44>: move s0,a1
0x77f0b924 <+48>: addu s1,v0,t9
0x77f0b928 <+52>: move s2,a2
2=> 0x77f0b92c <+56>: ori at,at,0xfff0
3=> 0x77f0b930 <+60>: sltu at,s0,at
0x77f0b934 <+64>: beqz at,0x77f0b9d4 <_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEjc+224>

The problem that is occurring that we've miscompiled the comparison (1 vs. 1,2,3). The big endian version should be the same as the little endian version. For some reason we're materializing 0x7ffffff0 and comparing that against the parameter (0x80000000).

[mclow]

This failure is caused by the size being > max_size() and throwing std::length_error in basic_string.

There's definitely big-endian specific code in max_size().
Investigating.

Are there any other failing tests in test/std/strings?

[llvmbot]

No, that was the only failing test. If you don't have access to a big endian machine to test a fix, I can do for you. Thanks.

[mclow]

I think the problem is in the test, not the compiler or basic_string. More as I find out.

[mclow]

Committed r325147 to fix the test.
Please let me know if the test still fails.

Note: Its not really "fixing" any problem, but rather catching the length_error, because in big-endian mode we steal a bit from the capacity to mark the SSO state.
This means that the max size of a basic_string on a 32-bit big endian system is just less than 2 GB, and so the test throws a length_error.

[llvmbot]

That commit on top of the release branch fixes the failing test. Thanks.

[zmodem]

Merged in r325219. Thanks!