For chromebooks, we need a new build variant whose target arch is
goldmont, but without SHA and XSAVES support (b/314243939#comment21)
Bug: 314243939
Test: Build an image with TARGET_ARCH_VARIANT:=goldmont-without-sha-xsaves
Change-Id: If73660b515b443d5c138ca367fa3d1c6f18485b5
No-one ever fixes unused-* or deprecated-* warnings in external/ (nor should they!).
-Wno-deprecated-enum-enum-conversion should probably have been added
next to -Wno-deprecated-anon-enum-enum-conversion when it was added,
since it's a major spam contributor, and equally unlikely that anyone
will clean them up.
-Wno-deprecated-dynamic-exception-spec is a weird special case because
it should be irrelevant after our next libc++ update, but in the
meantime -- because libc++ is used everywhere -- this is a massive spam
contributor that no-one on Android cares about because we don't use
exceptions (and the people seeing this can't fix libc++ anyway).
Test: local clean builds
Change-Id: I098202337e9e5026c4c5215dbf5a2abf1fbbdca8
The previous patch was insufficient. Craig Topper explains:
-fno-vectorize only disables the loop vectorizer
-fno-slp-vectorize only disables the SLP vectorizer
The backend can also use vector instructions for memcpy/memset or
combining multiple scalar loads and/or stores. That is independent
of -fno-vectorize.
-mllvm -vector-bits-min=0 will disable any use of fixed vectors. And
will make attribute(vector_size) get scalarized.
-mno-implicit-float will disable both vectorizers and
prevent the backend for using vectors for memcpy/memset
oor multiple scalar loads/stores. It will not affect
attribute(vector_size). -mno-implicit-float also prevents scalar
floating point instructions from being used for anything that didn’t
use float/double/_Float16/etc. type in source, but I don’t think that
happens on RISC-V today. 32-bit X86 can use a 64-bit x87 FP load as an
atomic load for uint64_t, for example. Basically -mno-implicit-float
is supposed to prevent the compiler from using FP or vectors when the
source doesn’t explicitly use FP or vectors.
So -mno-implicit-float was what we were actually looking for here. I've
done a clean build with this change, and see only the expected
(hand-written assembler) vector code in bionic, and the ART
ClassLinker::LoadClass() issue is gone too. As far as I can tell, the
remaining vector code is all deliberate in that sense.
We may still end up back here again, to change "gcv" to "gc", but that
still requires some code changes just to build, and still makes it less
obvious that this is just a temporary workaround for a qemu bug
(specifically https://gitlab.com/qemu-project/qemu/-/issues/1976).
Bug: http://b/320416684
Test: objdump
Change-Id: Ibd104e4289d6d1aaf441efa0440fedc90e3da29a
* changes:
Add script to run Soong tests with go tools
Disable TestVariantSingletonModule when go test -short is used
Fix data race in propagateRROEnforcementMutator
Fix data race in finder_test.go
Fix data race in dex_bootjars
Fix race CommonGlobalCflags when running tests in parallel.
Fix data race in snapshot singletons when running parallel tests
Until https://gitlab.com/qemu-project/qemu/-/issues/1976 is fixed, this
is just causing too much confusion and wasted time.
Removing V from the architecture string has the same effect, but
requires some code changes (to be able to compile code that's
_explicitly_ using V), and makes it less obvious that this is just a
temporary workaround for a qemu bug.
Bug: http://b/320416684
Test: objdump
Change-Id: Iec7d63ab227b31f82f530dabbdc4f3aa54277f04
Clone the commonGlobalCflags global variable when modifying it so that
it gets a unique object per context.
Test: go test -race ./...
Change-Id: Ia4b91c40939d4b4d338bd11e4d4f523521874548
Its target arch is goldmont, but without xsaves support.
This ensures efficient execution on a broad range of Intel/AMD CPUs used
in Chromebooks, including those lacking xsaves support.
(e.g. Kaby Lake, Gemini Lake, Alder Lake and AMD Zen series)
Bug: 314243939
Test: Build an image with TARGET_ARCH_VARIANT:=goldmont-without-xsaves
Change-Id: I9963cc3356394815f068fc998a9708bdb30c8266
Remove the ConvertWithBp2build implementations from all the module
types, along with the related code.
Bug: 315353489
Test: m blueprint_tests
Change-Id: I212672286686a318893bc7348ddd5a5ec51e77a7
This is part of a larger change to update the flag
PRODUCT_PAGE_SIZE_AGNOSTIC to PRODUCT_NO_BIONIC_PAGE_SIZE_MACRO.
This is to help clarify that this flag doesn't mean the device
will actually work end-to-end with any page size.
Bug: 312541564
Test:
```
source build/envsetup.sh
lunch aosp_cf_arm64_phone_pgagnostic-trunk-userdebug
m
cat out/soong/build.aosp_cf_arm64_phone_pgagnostic.ninja | grep __BIONIC_NO_PAGE_SIZE_MACRO
```
Change-Id: I33033876d0d4a276d1bb962d40315b71a3968c66
By default clang assumes that on riscv64 jumps are really expensive.
That's probably not true for the kind of SoCs we're dealing with, but
more importantly (see the bug) it causes clang to do loads from the
right hand side of a `&&` before the left hand side has been evaluated.
This found one latent bug in libcore, and it doesn't seem like the best
use of anyone's time to have to chase similar issues if they're going
to be similarly latent for riscv64 when we get clang's default fixed.
Bug: https://github.com/google/android-riscv64/issues/124
Test: treehugger
Change-Id: I640f1b43ea3d2452366ab86e97a9189fa9f5326c
We should update gnu++2a to gnu++2b too, but not in this CL.
Bug: 311052584
Test: treehugger
Test: m checkbuild
Change-Id: I3637444d74868b3a29b425fd749ecbbe1a45fbf7
To simulate 16k page size in x86-64 cuttefish, it is necessary
to compile the shared libraries and binaries with max-page-size greater
than 4096.
Bug: 309816695
Test: source build/envsetup.sh
lunch aosp_cf_x86_64_phone_pgagnostic-trunk-userdebug
m
Change-Id: I32670ef2c25fdcefec11bd07ba41cd0ea96c92bd
To simulate 16k page size in x86-64 cuttefish, it is necessary
to compile the shared libraries and binaries with max-page-size greater
than 4096.
Bug: 309816695
Test: source build/envsetup.sh
lunch aosp_cf_x86_64_phone_pgagnostic-trunk-userdebug
m
readelf -l out/target/product/vsoc_x86_64_only/system/bin/toybox
Change-Id: I38e4449a7826a2eca0c1a1cccc916af21f0b3a93
The MLGO model we embed in the Android Clang is trained on ARM64
ThinLTO artefacts. Applying the model across architectures does not
necessarily translate to performance improvement. Therefore only enable
the optimisation on ARM64 ThinLTO for now.
Test: presubmit
Bug: 293827654
Change-Id: Ie64a65c11191cf700a463637a0746c8470d3aa3c
Also add -Wno-everything as suggested by Pirama
Bug: b/308179696
Follow up: https://b.corp.google.com/issues/308179380
Change-Id: Iaa73f2b52363562b2391346d8b2e5dc73bab4f2d
This warning is triggered even when initializers don't have any
side effects, so it very rarely surfaces actual bugs/mistakes.
99% of the time it complains about a purely cosmetic issue.
Disable it by default in commonGlobalCFlags, which still allows
individual modules to opt into it.
Bug: 145210666
Test: presubmit
Change-Id: I671b5c457ee3d92b9cc37f020ba54e01e1a04f59
We can save a significant amount of disk space by compressing
debug info in `lld` cc builds. This change configures a build
flag to instruct lld to compress debug info when building cc
libraries. Rather than adding a global config we add this to
each target individually to avoid linker failures on windows
cross build targets.
Test: m
Bug: 305277519
Change-Id: I4ab3d47fb0de7e31a39fb671cccde1acee3a2018
We can save a significant amount of disk space by compressing
debug info in `clang` builds. This change configures a build
flag to instruct clang to compress debug info.
Test: m
Bug: 305277519
Change-Id: Ieeaa655452d847e83ebc6bec0864e47c46f4c6fb
This reverts commit 4e28d0eda2.
Reason for revert: Reverting now that we should have sufficient data from Crystalball https://b.corp.google.com/issues/306023954
Change-Id: I9f92c203eda309956ec192432ba0063eb11f59e2
This reverts commit 07c362bf7f.
Reason for revert: DroidMonitor: Potential culprit for Bug 304839693 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.”.
Change-Id: Iafb894510c48af2dd8b015d7264a031ff9348884
