* Roll external/effcee/ 66edefd2b..77a53ba53 (1 commit)
66edefd2bb...77a53ba53b
$ git log 66edefd2b..77a53ba53 --date=short --no-merges --format='%ad %ae %s'
2023-05-26 dneto Add Abseil dependency, via RE2
Created with:
roll-dep external/effcee
* Roll external/re2/ c9cba7606..03da4fc08 (18 commits)
c9cba76063...03da4fc085
$ git log c9cba7606..03da4fc08 --date=short --no-merges --format='%ad %ae %s'
2023-05-26 junyer Use `--enable_platform_specific_config` in `.bazelrc`.
2023-05-24 junyer Call `find_package()` conditionally.
2023-05-19 junyer Install CMake in the `gcc:13` container.
2023-05-19 junyer Sigh. I forgot to omit `sudo` because running under Docker.
2023-05-19 junyer Fix the CMake build on Ubuntu.
2023-05-19 junyer Try building the testing for RE2 with CMake again.
2023-05-18 junyer Uhh. Fix `LDABSL` for sure this time.
2023-05-18 junyer Try one more time to fix the GNU make build with GCC on Ubuntu.
2023-05-18 junyer For now, stop building the testing for RE2 with CMake.
2023-05-18 junyer Revert "Try `x64-windows-static` for CMake on Windows."
2023-05-18 junyer Try `x64-windows-static` for CMake on Windows.
2023-05-18 junyer Try again to fix the CI workflows.
2023-05-17 junyer Try to fix the CMake CI workflow.
2023-05-17 junyer Try to fix the GNU make CI workflow.
2023-05-17 junyer Fix the GNU make and CMake configurations and CI workflows.
2023-05-17 junyer Copy over the `re2/` and `util/` subdirectories.
2023-05-15 junyer Copy over the Bazel configuration and the workflow for Python releases.
2023-05-15 junyer Copy over the `app/` and `python/` subdirectories.
Created with:
roll-dep external/re2
* Update WORKSPACE to work with the new RE2.
* Do not build tests with VS2017
RE2 no longer supports VS2017, so we cannot build the tests anymore. We
will continue to make sure the everything else still builds with vs2017.
---------
Co-authored-by: GitHub Actions[bot] <>
Co-authored-by: Steven Perron <stevenperron@google.com>
If the build fails, the artifacts must still be chowned
so the CI can pick them up. If they are not, the CI tooling
will fail and go into 'aborted' state, which blocks the logs.
Signed-off-by: Nathan Gauër <brioche@google.com>
Before, we did set cxx version to c++17 using COPTS in our bazel files.
This was wrong, and part of the dependencies were then built with the
default standard version. This was not an issue until we moved to c++17.
Then, we decided to use the bazel --cxxopt=-std=c++17, but this was only
valid for nix platforms.
The last option left is to ask the user to specify the standard
when building using bazel.
Kokoro clones repos with a different user used to run the build steps,
meaning if some git command must be run at build time, they will fail
because of this dubious ownership issue.
Running some git commands makes only sense with history, so changing
checkout depth so we can run them and get the true result.
This is a known Kororo issue.
Fixing this is required to generate the version file using git history.
Signed-off-by: Nathan Gauër <brioche@google.com>
Signed-off-by: Nathan Gauër <brioche@google.com>
Kokoro clones repos with a different user used to run the build steps,
meaning if some git command must be run at build time, they will fail
because of this dubious ownership issue.
Running some git commands makes only sense with history, so changing
checkout depth so we can run them and get the true result.
This is a known Kororo issue.
Fixing this is required to generate the version file using git history.
Signed-off-by: Nathan Gauër <brioche@google.com>
* Kokoro CI bots use git-sync-deps to get sources
Update git-sync-deps to reduce the amount of data downloaded on a first
checkout, while being able to checkout the specific commit specified in
the DEPS file.
Previously the CI bots would only clone --depth=1. But that's not
enough to check out a specific commit. So clone either blobless
or treeless. For a CI bot, treeless is preferable, because it
downloads the least data. For interactive use, blobless is better
because it prevents redundant downloads of tree data.
See
https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/Fixes: #5028
* --treeless decays to blob:none when git is too old
* Pin googletest to an older version, to make bazel build work
* Use bazel 5 for Linux bazel builds.
* Download bazel 5.0.0 for macos and windows bazel builds.
* Modify the readme to mention bazel 5.0.0 as the version to use.
With a change in the VM, the kokoro asan run is failing because it does
not have the correct permissions. Adding the ptrace capability will
hopefully fix that.
A test has been removed which depends on casting to spv_target_env from a value
outside the range of that enum. This is an undefined behaviour, thus the
test is invalid.
* Work around GCC-9 warning treated as error
```
../source/opt/instruction.h:101:23: error: '*((void*)& operand +32)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
101 | uint64_t result = uint64_t(words[0]);
```
* Migrate all Kokoro build scripts over to use the docker VM image
Required updating the NDK SDK and build scripts, as well as the check_copyright for handling 2021.
This change improves spirv-fuzz CMake code to be more compatible with other projects that might want to include spirv-fuzz as a sub-project.
* Add a CMake option for building spirv-fuzz.
* We now check if protobuf targets are already available.
* We no longer specify `-DGOOGLE_PROTOBUF_NO_RTTI -DGOOGLE_PROTOBUF_USE_UNALIGNED=0`; a newer version of protobuf does not require this. Note that we probably should have specified this for protobuf targets as well, but this is no longer needed.
* Updated protobuf version in Kokoro scripts and README.md.
When moving blocks around, we ended up with a nullptr for a basic block,
and it was left in the list for a little bit. However, in that time, it
would end up being dereferenced while traversing the function.
To fix this, we delete it right away. This was found in an asan build
that runs our current tests. No new tests are needed, but I did add
extra check asan checks for our asan bot.
The option "SPIRV_USE_SANITIZER=address" does not work as stated in our
documentation because the link step fails for the tools. We have to add
-fsanitize to the link flags so the correct libraries are added on the
link step.
Fixes https://github.com/KhronosGroup/SPIRV-Tools/issues/2482.
Updated script to work with python3 and python2.
Added required tools.
We added a section to the readme to mention the tools that are needed to
build and test spirv-tools. For the compiler, the compilers used by the
bots are mentioned.
The bots have been changed. The windows bots will not use python 3.6 for testing. The other bots will still use python 2.7. Both Python2 and Python3 will be tested.
Fixes#2407.
Fixes#1856.
