In a Chromium build environment on Windows git is supplied by
depot_tools as git.bat. This was causing build errors on Windows that
are most easily reproduced with this command:
gn gen out\default && gn clean out\default && ninja -C out\default spirv-as
The errors included:
[12:55:40][ERROR ] Failed to run "['git', 'tag', '--sort=-v:refname']" in "C:\src\chromium\src\third_party\vulkan-deps\spirv-tools\src": [WinError 2] The system cannot find the file specified
[12:55:40][WARNING ] Could not deduce latest release version from history.
This is because 'git' does not resolve to git.bat unless shell=True is
passed to subprocess.Popen. This change passes shell=True but only on
Windows which resolves these errors.
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.
Adding a new type instruction required making the same change in two
places.
Also remove IsCompileTimeConstantInst that was used in a single place
and replace its use by an expression that better conveys the intent.
Change-Id: I49330b74bd34a35db6369c438c053224805c18e0
Signed-off-by: Kevin Petit <kevin.petit@arm.com>
This commit adds a C++ wrapper above the current spvBinaryParse
function. I tried to match it 1:1, except for 2 things:
- std::function<>& are used. No more function pointers, allowing
context capture.
- spv_result_t replaced with a boolean, to match other C++ apis.
Callbacks still return a spv_result_t because the underlying implem
relies on that. The convertion from spv_result_t to boolean is only done
at the boundary.
Signed-off-by: Nathan Gauër <brioche@google.com>
2f2e72bae9...3d568bdda5
$ git log 2f2e72bae..3d568bdda --date=short --no-merges --format='%ad %ae %s'
2023-02-06 absl-team Add support for the alternative base64 encoding in RFC 4648 section 5 to `WhenBase64Unescaped`.
Created with:
roll-dep external/googletest
Co-authored-by: GitHub Actions[bot] <>
* Update fuzz tests to not use invalid combinations of LoopMerge + BranchConditional
New IDs were selected to make clear the transformation being done here, instead
of reordering all IDs in between or refactoring the SPIR-V in the test.
* spirv-val: Conditional Branch without an exit is invalid in loop header
From 2.16.2, for CFG:
Selections must be structured. That is, an OpSelectionMerge
instruction is required to precede:
- an OpSwitch instruction
- an OpBranchConditional instruction that has different True Label
and False Label operands where neither are declared merge blocks
or Continue Targets.
When the build is done on a shallow repo, or on a non-git copy,
the version script failed. We should not hard fail, but generate
a "version" (unknown).
Sample outputs:
with git history:
`"v2023.2-dev", "SPIRV-Tools v2023.2-dev v2022.4-87-g53541064"`
with shallow clone:
`"unknown_version", "SPIRV-Tools unknown_version d8759a140bc65811332d5f91f3b08febadd5a21d"`
not a git repo:
`"unknown_version", "SPIRV-Tools unknown_version unknown_hash, 2023-02-02T16:25:48.077995"`
* Fix null pointer in FoldInsertWithConstants.
Struct types are not supported in constant folding yet.
* Added 'Test case 16' to fold_test.
Tests OpCompositeInsert not to be folded on a struct type.
Contributes to https://github.com/KhronosGroup/glslang/issues/2439
* When OpTypeStruct is used in Vulkan env and its last member
is a RuntimeArray, check if the struct is decorated with
Block or BufferBlock, as required by VUID-...-04680.
-Make more use of InstructionBuilder instruction helper methods
-Use MakeUnique<>() rather than new
-Add InstrumentPass::GenReadFunctionCall() which optimizes function
calls in a loop with constant arguments and no side effects.
This is a prepatory change for future work on the instrumentation
code which will add more generated functions.
This commit changes the way bazel chooses which version to build.
Before, we had a COPT set to -std=c++17, which is analogous to the cmake
way.
However, googletest decided to follow abseil, meaning this is *not*
recommended at all, and causes a mixed-standard build.
From https://github.com/abseil/abseil-cpp/blob/master/FAQ.md#how-to-i-set-the-c-dialect-used-to-build-abseil
we have 3 options to define the standard. Using a bazelrc is what I
believe to be the simplest, as it "fixes" the repo standard.
Signed-off-by: Nathan Gauër <brioche@google.com>
The CHANGES file was an alternative source of truth that was trying
to duplicate/replace the git history truth.
This allow us to change the way we handle releases so we don't have to make
sure our CHANGES PR are linked to the tag and tested PR, simplifying the
process.
This should help with avoiding mistakes such as the one that happened under #4958.
Signed-off-by: Kevin Petit <kevin.petit@arm.com>
Change-Id: I922f02e25c507f3412e0e7a99f525fb617b2d426
Signed-off-by: Kevin Petit <kevin.petit@arm.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>
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>
* build: move from c++11 to c++17
Moving from cpp 11 to cpp 17 will allow us to use modern features like
filesystem support, optional, any, execution policies and improved
templates.
Signed-off-by: Nathan Gauër <brioche@google.com>
The bazel build are set up to run any time there is a push to any branch. This
cause the same workflow to be run twice when a PR is updated.
I'm changing the workflow to trigger on there is a push to "main", for the
continuous test, and leaving the pull_request trigger for the presubmit test.
The current bot is having trouble with the CLA. I checked with the Khronos
admin, and this was his reply:
> We already safe list *[bot] which should account for all GitHub bots. If you
have manually named the GitHub Actions bot to GitHub Actions bot, it should be
renamed to GitHub Actions[bot]. This should resolve the issue.
Trying that to see if it works.
Adding a github action to open a PR when the DEPS can be updated.
It will run once a day or it can be manually triggered.
I updated roll_deps.sh so that it will not return an error if there were no new
commits for a repository.