When emitting SPIR-V code for frexp, avoid access
beyond the end of the operands vector. When constructing
the OpExtInst, construct a new arguments vector instead of
modifying the existing operands vector. In the case of OpFrexp,
well need that last operand later on to generate the store.
Fixes https://github.com/KhronosGroup/glslang/issues/110
Change-Id: Ibc380fadf5e600ac491932e9ecef7afe2d72fd7f
* This also moves bison generated files into the source tree, so that
include of glslang_tab.cpp.h and includes from glslang_tab.cpp work
the same way.
Depending on specific optimization settings VS2013 will sometimes
execute the operands to
new Instruction(builder.getUniqueId(), builder.makeBoolType(), OpPhi)
left-to-right, and sometimes right-to-left. Since makeBoolType can
also call getUniqueId(), the IDs to the OpPhi can sometimes be swapped.
This guarantees an explicit ordering of the Ids so that tests work
reliably.
Structured control-flow rules allow leaving the middle of a construct through
a return, but not through a jump to a block that does a return.
Addresses issue #58.
This generally simplifies access chain generation, with far fewer type conversions.
It is particularly important to future SPIR-V changes where there is less aggregate
type uniqueness due to carrying different layout information with the type.
If this breaks your AST consumer, best is to modify it to test
against the enum values instead of doing string comparisons on
built-in function names. This is the reason the change was made.
If you need the old behavior, you should be able to get it back by changing
PureOperatorBuiltins to be false instead of true. This path will work for
a while, but is marked deprecated.
Also, the old behavior is tagged as release 2.4.
Previously if a non-void function implictly returned, a dummy variable
was created as return value. Now instead it returns the result of the
OpUndef instruction. This better conveys the presence of undefined
behavior to SPIR-V consuming tools (and humans).
It also saves one ID per occurrence...
There will be subsequent commits to refine semantics, esp. version-specific semantics,
as well as I/O functionality and restrictions.
Note: I'm getting white-space differences in the preprocessor test results,
which I'm not checking in. I think they need to be tagged as binary or something.
