Test/hlsl.inf.vert tests parsing and some constant math on
infinities, including (-1.#INF * 0.0).
By IEEE 754 rules, that result is a NaN, but its sign is not significant.
The test output assumes a negative-NaN is in the generated SPIR-V.
However, the math library on some platforms (like macOS 14, a.k.a.
Sonoma) will produce a positive NaN instead.
This PR adjusts the test so it takes the absolute value of the NaN,
to ensure we the emitted SPIR-V has the NaN with a 0 for it sign bit.
Even for a double precision float, the largest valid exponent is 308, so
clamp exponents to 500 when parsing to avoid overflow of the parsed
exponent value if the exponent is too big.
This function is used to import SPIR-V extended instruction set. It
mistakenly treated the name of SPIR-V extended instruction set as the
name of SPIR-V extension. For example, when we have such code
getExtBuiltins("NonSemantic.DebugBreak")
'NonSemantic.DebugBreak' is added to SPIR-V extension. Rather, the
SPIR-V extension name should be 'SPV_KHR_non_semantics_info'. Therefore,
we must avoid this since the name of SPIR-V extended instruction set is
not necessarily equal to that of relevant SPIR-V extension. Adding a
SPIR-V extension must be done by calling addExtension() explicitly
outside this function.
This change also fixes disassembly issues of debugBreak().
coopmat<> type definition allows type parameters. To make it accept
types defined by spirv_type directive, we add spirvType info to the type
parameters. This change is to support this case. And a test is added to
show the missing usage.
Fix#3538.
Visual Studio 2022 added a new warning to detect when enumerators can
not be represented within the given bit field width. This warning is
disabled by default but can be enabled using the flag /w15249. This PR
increases the width by one to accommodate the signed maximum value of
EvqLast, which is currently 32.
Perhaps a future improvement would be to use scoped enums; however,
that is more work as the typing is more strict and would require more
changes.
The actual support has been available with GL_EXT_control_flow_attributes.
This change set is to handle
"#extension GL_EXT_control_flow_attributes2 : <val>"
The file and source text was not being set correctly in the test output.
This change makes the test fixture consistent with the command line
behavior, "-gVS", which was my original intent when I added these tests.
Add support for GL_ARB_shading_language_include. Usage is identical to
the way GL_GOOGLE_include_directive currently works glslang (since
GL_ARB_shading_language_include is inherently a runtime feature and
glslang is an offline compiler).
Users can simulate their runtime environment by using a custom
glslang::TShader::Includer or using filenames that match their GL
runtime names.
Closes#249.
Since assert(0) compiles to nothing on release builds, it's not
sufficient to silence a fallthrough warning. Instead, some switch
statements are changed into if/else and others have the assert(0)
replaced with "return 0".
This is intended so that downstream projects consuming glslang with FetchContent or similar means can use `-Wimplicit-fallthrough` without getting warning spam.
I've used my best judgement to determine whether the implicit fallthrough was desired, or was simply unreachable code.
`std::unreachable` is unavailable until C++23, but I saw places where `default: assert(0);` was used, so copied that.
There were a few places where some code might actually have been reachable and intended to return a value that represented an error, so someone should double check that kind of thing.
Like with the last few PRs from me, it fixes a warning that's commonly enabled in downstream projects that might want to consume glslang via FetchContent or equivalent.
It doesn't actually enable the warning, but that might be desirable.
I think I found a bug in the Spv.FromFile.cpp tests that would have been prevented had this warning been enabled all along.
I had to guess the value for the missing field, so went for the most common one in the list.
The only test case that used a different value before had an RWTexture1D, so if baseImageBinding is meaning the same kind of image as image load store in OpenGL, it would make sense that that would be the only one to need a non-zero value for the binding.
I'm a little concerned that the test wasn't previously failing with the incorrectly-assigned fields as it implies they don't make any difference, so the test might be too permissive.
