There were two implementations of isInf() and isNan(), in Constant.cpp
and in intermOut.cpp. The former only works on little-endian systems,
the latter is a wrapper for library functions and works regardless of
endianness. Move the second version into Common.h and adopt it in both
places. Thereby avoid the duplication and fix for big-endian systems.
On s390x, this fixes the test case
Glsl/CompileToAstTest.FromFile/constFold_frag.
Fixes#2802
Otherwise this can race with other threads for access to the fields it's
supposed to be initializing/finalizing.
For example, imagine another thread is calling ShInitialize() while the
first thread is calling ShFinalize() - the finalize function would
destroy the state at the same time as the initialize function is trying
to initialize it.
Holding on to the global lock for the entire function prevents all of
these failure modes.
Currently, ShInitialize() and friends call glslang::InitGlobalLock()
which *overwrites* the global mutex. As such, even though it ostensibly
takes a mutex, this function is actually completely thread-unsafe.
Fix it by using pthread_once to ensure the mutex is only initialized
once, and then never again.
Per SPIR-V spec, a string literal's UTF-8 octets are encoded packed into
words with little-endian convention. Explicitly perform that encoding
instead of assuming that the host system is little-endian.
Note that this change requires corresponding fixes in SPIRV-Tools.
Fixes#202
Fix#2760.
Implement the optional function select_on_container_copy_contruction to
return a default-contructed allocator for containers that are
copy-constructed. This gives copy-constructed containers a pool
allocator for the current thead.
There may be a similar problem with the copy contructor which takes
allocators of type "Other" but, in practice, there is only one place
where this is being used and the allocators are always the same. (i.e.
executing from the same thread)
1. spirv_execution_mode_id and spirv_decorate_id could support
specialization constants. The original implementation always
assume only normal frontend constants are valid. It is not true.
2. spirv_type donesn't support type_specifier as an option of
spirv_type_parameter. At present, only constant_expression is the
valid option.
it's a little strange how the resolver takes an arbitrary intermediate
in it's constructor. Really this should be an 'options' object that
holds the various resolve/remapping options which are read from this
intermediate.
At least for now rename it so it's more clear it's used differently from
other intermediates that are accessed in the resolver (such as the per
stage ones).
* add ability to upgrade uniform block to push constants assuming it fits within the size limit imposed by the caller
* allow selecting the packing for the auto push constants
* check the size using the potential layout packing of the push constants
