| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
PiperOrigin-RevId: 471622229
Change-Id: I787e0da71eaa1f99cc41b7950f93a43c6cced0ed
|
|
|
|
|
|
|
| |
functions for readability purposes.
PiperOrigin-RevId: 471622216
Change-Id: Ic28ed8e26d5085ccf20290d1b9c7a5e9bc1f0fde
|
|
|
|
|
|
|
| |
better readability.
PiperOrigin-RevId: 471621696
Change-Id: I603e5707d896deef3a015c70ceac9778e360f72f
|
|
|
|
|
| |
PiperOrigin-RevId: 471600654
Change-Id: Iee722e5d736d341bc81cc10dac290383ba392f87
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
annotations.
The problem is that the underlying storage adds redzone after the actual data so from compiler's perspective it looks like a valid memory. In the outlined version the memory is returned in call.i.i with unknown size so the access check can't be removed. The workaround is to always outline the call to InitializeData for ASAN builds.
Outlined version:
%call.i.i = call noundef i32* @absl::FixedArray<int, 4ul, std::__u::allocator<int> >::Storage::InitializeData()(...), !dbg !28
store i32* %call.i.i, i32** %data_.i.i, align 8, !dbg !27
%arrayidx = getelementptr inbounds i32, i32* %call.i.i, i64 5, !dbg !29
%24 = bitcast i32* %arrayidx to i8*, !dbg !29
call void @llvm.asan.check.memaccess(i8* %24, i32 36), !dbg !29
store i32 0, i32* %arrayidx, align 4, !dbg !29
Inlined version:
%arrayidx = getelementptr inbounds %"class.absl::FixedArray", %"class.absl::FixedArray"* %7, i64 0, i32 0, i32 0, i32 1, i64 20, !dbg !40
%27 = bitcast i8* %arrayidx to i32*, !dbg !40
>>>>>>>>>>>>>>> call to @llvm.asan.check.memaccess removed <<<<<<<<<<<<<<
store i32 0, i32* %27, align 4, !dbg !40
Workaround for ASAN stack safety analysis problem with FixedArray container annotations.
PiperOrigin-RevId: 471583635
Change-Id: I0d74eed5782a1cbd340ca4aca1bce71b63b06d43
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Addresses failures with the following, in some files:
-Wshorten-64-to-32
-Wimplicit-int-conversion
-Wsign-compare
-Wsign-conversion
-Wtautological-unsigned-zero-compare
(This specific CL focuses on .cc files in */internal/.)
Bug: chromium:1292951
PiperOrigin-RevId: 471561809
Change-Id: I7abd6d83706f5ca135f1ce3458192a498a6280b9
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Addresses failures with the following, in some files:
-Wshorten-64-to-32
-Wimplicit-int-conversion
-Wsign-compare
-Wsign-conversion
-Wtautological-unsigned-zero-compare
(This specific CL focuses on .cc files in */internal/.)
Bug: chromium:1292951
PiperOrigin-RevId: 471549854
Change-Id: Id685d0e4666212926f4e001b8ef4930b6a33a4cc
|
|
|
|
|
| |
PiperOrigin-RevId: 471545981
Change-Id: I4d2c8b6d4f1e58976915bda78a77178b8bf80da8
|
|
|
|
|
|
|
|
| |
Corrects the computation of max_size(), so that it accounts for the
size of the objects.
PiperOrigin-RevId: 471343778
Change-Id: I68e222cefaa0295b8d8c38d00308a29df4165e81
|
|
|
|
|
|
|
| |
string-like types (support for other builtin types will follow in future changes). Rather than specifying %s for strings, users may specify %v and have the format specifier deduced. Notably, %v does not work for `const char*` because we cannot be certain if %s or %p was intended (nor can we be certain if the `const char*` was properly null-terminated). If you have a `const char*` you know is null-terminated and would like to work with %v, please wrap it in a `string_view` before using it.
PiperOrigin-RevId: 471321055
Change-Id: Ifbb50082d301baecc7edc277975f12e7ad3ecc8a
|
|
|
|
|
| |
PiperOrigin-RevId: 471292183
Change-Id: Ic124d671dd3b0ae819f741885abb046cbf7e1add
|
|
|
|
|
| |
PiperOrigin-RevId: 471290034
Change-Id: If5bbb990c302827c656c6437e6932221261d1319
|
|
|
|
|
| |
PiperOrigin-RevId: 471256712
Change-Id: I2a1e4846a524bccd3c935a40abab0c0218afdfc0
|
|
|
|
|
| |
PiperOrigin-RevId: 471030218
Change-Id: I727c7f8966fe9c96736283c8e1a13a76b3cdb53d
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Addresses failures with the following, in some files:
-Wshorten-64-to-32
-Wimplicit-int-conversion
-Wsign-compare
-Wsign-conversion
-Wtautological-unsigned-zero-compare
(This specific CL focuses on .cc files in debugging/internal/.)
Bug: chromium:1292951
PiperOrigin-RevId: 470812243
Change-Id: I5578030bb42ba73cb83d4df84f89e431ceac8992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Addresses failures with the following, in some files:
-Wshorten-64-to-32
-Wimplicit-int-conversion
-Wsign-compare
-Wsign-conversion
-Wtautological-unsigned-zero-compare
(This specific CL focuses on .cc files in strings/internal/.)
Bug: chromium:1292951
PiperOrigin-RevId: 470810568
Change-Id: Ibd316a7e62cc43cb198ba22daed565c9573ce235
|
|
|
|
|
| |
PiperOrigin-RevId: 470080638
Change-Id: I8d9ddfabc7704c383ed5a73abf0411f4c58a4bf7
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
initialization.
It looks to me like the language rules treat these the same for this type, but evidently GCC feels differently.
This only matters under TSAN where SpinLock has a non-trivial destructor, and under C++20 where ABSL_CONST_INIT is implemented (as constinit) by gcc.
Fixes #1253
PiperOrigin-RevId: 469806751
Change-Id: Ic01b0142101f361bc19c95f9f9474e635669c58d
|
|
|
|
|
|
|
|
| |
1. Removes unused includes
2. Replaces <stdint.h> with <cstdint>
PiperOrigin-RevId: 469705016
Change-Id: Ic32871be93d01436f5538c44321faad7bd2e4511
|
|
|
|
|
|
|
| |
"ToDoubleNanoSeconds" -> "ToDoubleNanoseconds"
PiperOrigin-RevId: 469525959
Change-Id: I43488ac8706cb857aa3890249a00fc141129dafa
|
|
|
|
|
| |
PiperOrigin-RevId: 468509663
Change-Id: I8b8d57cae59b4f44fb15ceb7a0d0c05310714921
|
|
|
|
|
|
|
|
| |
This matches std::bit_width().
Bug: chromium:1292951
PiperOrigin-RevId: 468495319
Change-Id: I0e428addb6a7353abbf2063c5c2f5820c3bae789
|
|
|
|
|
| |
PiperOrigin-RevId: 468322981
Change-Id: I61762a1a83d5b138fd2e1a93035a5087a51a4e84
|
|
|
|
|
|
|
| |
mode. They are not available in that configuration, even if the host supports them.
PiperOrigin-RevId: 468232254
Change-Id: I1cd26eda2962778b62135a31f477928c3bde1124
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Addresses failures with the following, in some files:
-Wshorten-64-to-32
-Wimplicit-int-conversion
-Wsign-compare
-Wsign-conversion
-Wtautological-unsigned-zero-compare
(This specific CL focuses on .cc files in strings/internal/.)
Bug: chromium:1292951
PiperOrigin-RevId: 468215101
Change-Id: I07fa487bcf2cf62d403489c3be7a5997cdef8987
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Addresses failures with the following, in some files:
-Wshorten-64-to-32
-Wimplicit-int-conversion
-Wsign-compare
-Wsign-conversion
-Wtautological-unsigned-zero-compare
(This specific CL focuses on .cc files in strings/, except /internal/.)
Bug: chromium:1292951
PiperOrigin-RevId: 468205572
Change-Id: Ifce3f1a7a4b2b2c359bf7700a11279bebfef8a15
|
|
|
|
|
| |
PiperOrigin-RevId: 467992681
Change-Id: I086b3da8dd95b0498d5bc118b9243052586239e6
|
|
|
|
|
| |
PiperOrigin-RevId: 467950116
Change-Id: Iccb0c80c93f1064a82a5537d4519b041609cddd6
|
|
|
|
|
|
| |
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83830.
Before GCC 7.4, __cpp_lib_has_unique_object_representations was defined
but has_unique_object_representations_v was not.
|
|
|
|
|
| |
PiperOrigin-RevId: 467004870
Change-Id: I473c1b14e9e5fe55b8a16a0e1bc4439625a947c8
|
|\
| |
| |
| |
| | |
PiperOrigin-RevId: 466946900
Change-Id: I4ebb641a46e6988dd98945226428e0a284c942b4
|
| |
| |
| | |
Delete deprecated header include
|
| |
| |
| |
| |
| | |
PiperOrigin-RevId: 466659369
Change-Id: I2bd671ef187604f12371e12a5017cac23fdad35b
|
|/ |
|
|
|
|
|
|
|
|
|
| |
The Lexan and MSVC toolchains both set _MSC_VER. The MSVC toolchain must set `ABSL_HAVE_STD_IS_TRIVIALLY_ASSIGNABLE` and `ABSL_HAVE_STD_IS_TRIVIALLY_CONSTRUCTIBLE`, in order to use Abseil workarounds in the absence of these types. This is not necessary for clang-cl.
This change excludes clang-cl from the predicate setting these variables.
PiperOrigin-RevId: 465589196
Change-Id: I0426ec4f844aabe7cdde5c60725f6a9a6b16479f
|
|
|
|
|
|
|
| |
There's no point redefining these functions if they are supported by the compiler and the version of libstdc++. Also, some of the builtins used by the absl implementation of these functions (e.g. __has_trivial_destructor) have been deprecated in Clang 15.
PiperOrigin-RevId: 465554125
Change-Id: I8674c3a5270ce3c654cdf58ae7dbd9d2bda8faa5
|
|
|
|
|
| |
PiperOrigin-RevId: 465451170
Change-Id: I5fd161b1ef156d60d7f9a6ecf493bcf802d581e8
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the case that we are unwinding with context, if the retreived frame pointer
matches the signal context, assume that the value is valid and do not perform
confidence checks. In any other case, continue to perform some validation to
avoid returning an incorrect frame pointer.
Given that the VDSO path is currently untested, remove the code to simplify the
logic in the frame walking.
PiperOrigin-RevId: 465360612
Change-Id: Iac656012182a12814bafecf20225ba68b90b4db1
|
|
|
|
|
|
|
| |
The change breaks existing code by changing the return type of absl::bit_width.
PiperOrigin-RevId: 465295951
Change-Id: Id4ce7c2ac3699ce22aa2b4851a949f9e0104a3d7
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Addresses failures with the following, in some files:
-Wshorten-64-to-32
-Wimplicit-int-conversion
-Wsign-compare
-Wsign-conversion
-Wtautological-unsigned-zero-compare
(This specific CL focuses on .cc files in dirs n-t, except string.)
Bug: chromium:1292951
PiperOrigin-RevId: 465287204
Change-Id: I0fe98ff78bf3c08d86992019eb626755f8b6803e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Addresses failures with the following, in some files:
-Wshorten-64-to-32
-Wimplicit-int-conversion
-Wsign-compare
-Wsign-conversion
-Wtautological-unsigned-zero-compare
(This specific CL focuses on .cc files in strings/, except /internal/.)
Bug: chromium:1292951
PiperOrigin-RevId: 465285043
Change-Id: I37e9d1b4c4e9aa655b720da1467927af2aba995e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Addresses failures with the following, in some files:
-Wshorten-64-to-32
-Wimplicit-int-conversion
-Wsign-compare
-Wsign-conversion
-Wtautological-unsigned-zero-compare
(This specific CL focuses on .cc files in dirs a-h.)
Bug: chromium:1292951
PiperOrigin-RevId: 464541951
Change-Id: If23b63ccea8e9b730159ff1c7288e9300a40b6bd
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The changes in d6f96eda14aca77748a439f05a567a46ce87e462 enabled handling cases
where the stack may be non-contiguous or not fully symbolicated (e.g. in cases
of alternate signal stacks). However, it did not properly honour the requests
from the caller to perform a strict unwinding where such frames are terminated
upon the discontinuity. This repairs that condition.
Hoist the alignment check since that is safe to perform early.
PiperOrigin-RevId: 464160529
Change-Id: Ic65645928ec60c2a3b4844f3abd4fed1b991edab
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Addresses failures with the following, in some files:
-Wshorten-64-to-32
-Wimplicit-int-conversion
-Wsign-compare
-Wsign-conversion
-Wtautological-unsigned-zero-compare
(This specific CL focuses on .h and win32 .inc files.)
Bug: chromium:1292951
PiperOrigin-RevId: 463835431
Change-Id: If8e5f7f651d5cd96035e23e4623bdb08a7fedabe
|
|
|
|
|
|
|
| |
use with clang's __is_trivially_relocatable and [[clang::trivial_abi]].
PiperOrigin-RevId: 463668740
Change-Id: I2d2d2f53d8184a7e4f7c848c2a5f5140c2481d72
|
|\
| |
| |
| |
| | |
PiperOrigin-RevId: 463581990
Change-Id: I47359d4d2d2fcd2365b5ff9a5c3b61b5751e4ed2
|
| |
| |
| |
| |
| |
| |
| | |
The frame pointer sanity check in NextStackFrame() was more restrictive than it is necessary. The frame pointer is used to load the saved link-register and the address for the next stack frame. So it only needs to be 8-byte aligned. The aarch64 ABI does not specify an alignment requirement for the frame point.
PiperOrigin-RevId: 463368519
Change-Id: I473e05181603288f14734fe29013900c7505e201
|
| |
| |
| |
| |
| | |
PiperOrigin-RevId: 463214218
Change-Id: I54a37fd9560b480f9eaf0454670eacf875015fe8
|
| |
| |
| |
| |
| | |
PiperOrigin-RevId: 463153060
Change-Id: I6d24915c52bfe6507864df30aad99ba4fea2ea68
|
| |
| |
| |
| |
| | |
PiperOrigin-RevId: 462681925
Change-Id: Ic5610cb4124b7f60a00817ca2f1d52674b27c168
|