instead of just detecting Bazel's default "compiler" string.
When Bazel auto-configures GCC, it sets the compiler string to
"compiler", probably for backwards compatibility. Some users manually
set the string to "gcc".
This should address the backwards compatibility issues described in
https://github.com/bazelbuild/bazel/issues/12707 and hopefully fix
https://github.com/abseil/abseil-cpp/issues/1263
PiperOrigin-RevId: 473069817
Change-Id: I8a24721f63f9d61447b22b3b05b06a9dde7d34d8
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 tests.)
Bug: chromium:1292951
PiperOrigin-RevId: 473055916
Change-Id: I40cdd6c87ba9d0a5fb2db5746cff04f14ee829c2
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 miscellaneous non-test source files.)
Bug: chromium:1292951
PiperOrigin-RevId: 473054605
Change-Id: Ifd7b24966613ca915511a3a607095508068200b8
internal/stacktrace_x86-inl.inc includes internal/raw_logging.h and therefore needs
a direct dependency to satisfy Bazel layering_check (Clang -fmodules-strict-decluse).
Clang before https://reviews.llvm.org/D132779 does not report the issue becasue:
* internal/stacktrace_x86-inl.inc is an .inc file and is not checked as a main file
* internal/stacktrace_x86-inl.inc is a textual header and older Clang incorrectly
considers there is no requesting module and suppresses the error.
PiperOrigin-RevId: 472795469
Change-Id: Ia4ad667ea80b2590cef1adfd22af025c8df826ac
In some cases we can do a bit better by using
std::min(std::numeric_limits<size_type>::max() / 2, allocator<T>::max_size())
They may help in some cases, particularly on 32-bit platforms.
PiperOrigin-RevId: 471846886
Change-Id: I5bd63de5dd8aec3de6530a33d8904dd6e9bd015e
In the time since pcg_engine.h was written, absl::uint128 was fixed to
generate identical code to __uint128_t
PiperOrigin-RevId: 471789541
Change-Id: Ibd1afc3e5e6d57af27cdd6a21171c96ea333161c
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
Corrects the computation of max_size(), so that it accounts for the
size of the objects.
PiperOrigin-RevId: 471343778
Change-Id: I68e222cefaa0295b8d8c38d00308a29df4165e81
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
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
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
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
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
Derek Mauro
Abseil Team
Evan Brown
Gennadiy Rozental
Andy Getzendanner
Jonathan Conder
Kim Hyun
Saleem Abdulrasool
Thomas Köppe