Clang produces a warning when a method that overrides another is
not marked with the override keyword. Adding the keyword has no
effect on overridden functions, but it is good practice to mark
all methods intended to override as such because if they fail to
do so, the keyword will produce an error.
Fixes 78 Clang warnings.
There is the possibility of a few variables being used without
initialization, which causes some warnings.
Fixes 2 clang warnings
GCC worries that assigning a variable to the result of an
assignment of that same variable may be undefined. It's a silly
thing to do anyway. So it's removed.
Fixes 1 gcc warning.
GCC is quite sure that Interp is too small to hold values of up
to 9 with only 4 bits. Perhaps because the RHS is a variable of
8 bits.
Fixes 47 gcc warnings
Terminating classes may create a muscle memory for typing a
semicolon after a left-justified closed brace. Whatever the reason
to GCC's chagrine there were many functions ended with unnecessary
semicolons. Each one caused a warning. This removes them.
Fixes 285 GCC warnings
GCC has what seems to me to be a bug where it disapproves of the members
of a member struct of class OP having the same name as a type imported
by "using". It's the only compiler with the issue and I don't see any real
conflict, but it's easier to placate it than to fix GCC. GCC
claims its ambiguous. Making the member variables lowercase fixes
this neatly.
Removed some PointerStatus:: prefixes from references within the
class itself which upsets GCC.
HLSL changes excluded Transforms/Instrumentation directory entirely
including BoundsChecking. However it didn't excluder one reference
to a function declared there in BackendUtil that fails to link on GCC.
The function that references the missing BoundsChecking function
is static and not used anywhere with current settings. So it's not
considered a symbol to be linked by MSVC or clang, but GCC insists.
This CL makes changes to CMake files in order to:
1- disable things that are not supported on non-Windows platforms.
2- make cross-platform compilation possible.
It also brings back LLVM's config.guess (mirrors:
https://github.com/llvm-mirror/llvm/blob/master/cmake/config.guess)
InterlockedIncrement and InterlockedDecrement are atomic operations to
increment or decrement the value pointed to by the pointer parameter and
return the same.
There are already platform abstractions available to LLVM in Atomics.h.
This change leverages them to implement the same functionality in a
platform-agnostic way. Mostly it's just a matter of swapping
InterlockedIncrement for AtomicIncrement.
GCC5 has a few limitations that later versions do not. The
most pervasive issue is the confusion of scoped operators on enum
names when the name of the enum is shared with a local variable.
The only other issue concerns intialization of a union containing
structs and how many curly braces is enough.
DiagnosticPrinter doesn't support io manipulators like std::hex,
in spite of that, they were included in some invocations of it. MSVC
seemed to allow this because it interpretted std::hex as a void
pointer, which is supported.
This adds support of std::hex and similar manipulators by adding an
overloaded operator<< that takes the type of std::hex and its friends
and sets a base number which is used when the base is not 10 to print
numbers in the specified base, which can only be 8 or 16 according to
what is passed in.
Also while I was changing things in raw_ostream.h I added a
missing override keyword that produced a lot of warnings on clang.
Just a few warning conditions in a handful of common headers
was producing pages and pages of warning messages. By fixing them,
the output spew is reduced significantly.
Static variables in a header produce a separate variable for every
file that includes it. In many of these, these variables were unused.
Instead, variables used in multiple files should be defined only
once in a source file and declared as extern in the header.
Many unsigned variables were checked to be greater than zero and less
than 3 in HlslTypes.h. If they were somehow assigned a negative
value, it would appear as much greater than 3 in unsigned form.
So we can just check that they are less than or equal to 3.
In Type.h, parammods_begin() was casting its return value to the
proper pointer, but without const, producing an error. The best
part is that the function returned a const pointer. The cast was
just wrong. Adding const silences the warning.
When calling functions with arguments that references local
variables as a whole and annotated with out/inout, we don't
need to create temporary variables for them again. Just pass
the pointers to the original local variables.
Suddenly the CompileWhenNoMemThenOOM test started to fail
on Appveyor even for a pull request that is trivial and does not
touch the source code. And we cannot reproduce this failure locally.
It's likely an Appveyor infrastructure issue; they updated a few things
yesterday.
I temporary disabled this test on Appveyor CI for now to unblock
other work. A following up PR to try to revert this PR and fix the issue.
Using SV_RenderTargetArrayIndex (translated into Layer builtin)
and SV_ViewportArrayIndex (translated into ViewportIndex builtin)
in VS and DS output requires the SPV_EXT_shader_viewport_index_layer
extension.
Added -Wno-vk-ignored-features to suppress warnings on features
that are ignored because of no Vulkan support. Examples include
cbuffer member initializer.
Using an enum class as the key of an unordered_set is supported starting
C++14.
The two possible solutions are: a) provide a hash function b) cast to
unsigned. Given the usage here, it latter is a simpler fix.
1. Change llvm.dbg.contents into dx.source.contents.
2. Fix crash when SemanticIndexVec is empty.
3. Fix case Utf8StringVector is reallocated in MainArgs::operator=(const MainArgs &other).
Use llvm::make_unique instead of std::make_unique. This fixes some
compiler errors on linux and makes the code more consistent with the
rest of the code base.
There are a few error-handling goto operators that cross
initialization of variables involved in the standard correct
operation. This introduces the risk of undefined behavior should
the code at the label jumped to use those uninitialized variables.
Templated iterators often have a dependent scope, which annoys
some compilers because they can't tell if the typename evaluates
to a type or a variable name. This adds typename keywords to
remove the ambiguity in removeResources.
Additionally, the std toupper function can't be found for the sake
of the templated call to std::transform in ValidateSignature
function. By adding :: to clarify it, the template can be evaluated.
A few ternary operators took different types in the second and
third position, which some compilers refuse to resolve. By casting
the second operand to the type of the assigned variable and make
it match the third operand which was already cast.
2 means no indication as to whether this is a depth or non-depth
image.
Reverted "Hack OpSampledImage for depth-comparison sampling".
This reverts commit 0f165c6483.
MSVC is very forgiving of crimes committed in templated functions
and methods of templated classes that never actually get instantiated.
Consequently, the fact that the public variant of Find in SpanAllocator
referenced an unknown variable, seemingly as a copy paste error
was left unnoted. Other compilers are not so magnanimous.
The call to the private version of Find() takes an iterator. The
public Find() searches through the known spans to find the one just
past the range requested by the current pos and size. If it reaches
the end, then the span can be placed at the end safely. If it
fits before some other span, overlap needs to be checked. If the
new span would overlap it's neighbor, another location is needed.
It makes sense to start looking for that location after the end
of the neighbor whose span you just treaded on. So passing the
next iterator into the private Find() makes sense.
Replaces -i64 suffixes with -LL which are said to be equivalent by
MSDN. Both should result in 64 bit behavior.
Additionally, I dropped a superfluous repetition of the class name
on the CheckVectorConditional method of HLSLExternalSource. By all
rights, it should be its own change, but it gets lonely so it came
along for the ride. The repeated class name made some compilers
unhappy and losing it doesn't bother anyone.
Several #included files were capitalized incorrectly in the case of
files pertaining to the project, or inconsistently in the case of
Windows headers which are typically only relevant where capitalization
doesn't matter. In spite of that, consistent capitalization can be
useful for cross platform stubbing purposes.
This corrects capitalization of a few Dxil* headers and forces
capitalization of Windows-specific headers to be consistent with
the overwhelming majority of other cases.
No functional change, just cross-platform facilitation
The DxilSigPoint.inl file depends on an esoteric distinction in how
different preprocessors expand macros included as parameters to
other macros.
When a macro receives another macro as its argument, different
preprocessors expand these parameter macros differently. MSVC
defers expanding the macro until the macros taking parameters
have been completely expanded. GCC and others expand the parameter
macro just as soon as it can.
At issue is the expansion of the three _## macros: _41, _50, and
_61 which expand to ,#,# respectively. These macros can be passed
into an initial macro that plugs them directly into a function that
takes multiple parameters without issue with any preprocessor.
Regardless of when the _## macro is expanded, it will be interpretted
correctly as passing multiple arguments to the function.
If the _## macro is passed into a parameterized macro that passes
it to another such parameterized macro that takes a single argument,
preprocessor inconsistencies come into play. If the preprocessor
expands the _## macro immediately, instead of passing the parameter
macro directly into the second paramaterized macro, the expansion
of the parameter macro will be passed in, which will be
interpretted as passing multiple arguments to a single-parameter
macro and an error will reseult. If the _## macro is not expanded
until the end, then it is expanded only for the final multi-
parameter function call as the author expected.
The simplest example of this is something like this:
define AB 1,2
define SEC(args) (args)
define FIRST(args) SEC(args)
FIRST(_AB);
A preprocessor that delays expansion of _AB will expand thus:
FIRST(_AB) => SEC(_AB) => (_AB) => (1,2)
whereas an early expanding preprocessor will expand thus:
FIRST(_AB) => SEC(_AB) => SEC(1,2) => ERROR! SEC only takes 1 arg!
Some of the details of the example might be slightly off, but the
important thing is that the parameter gets expanded at different
times.
The solution to this is to complicate this already long macro.
The middle macro that introduces the opportunity for the _##
macros to be expanded early is DO_ROW, which doesn't do much
except allow for the larger data entry macro, DO_INTERPRETATION_TABLE
to be a bit shorter and simpler. By eliminating DO_ROW and
shortening the DO macro to D, the large table specifying behaviors
is only a little wider and harder to read and it no longer depends
on this inconsistent element of preprocessor behavior.
(I really hope that made sense. I wish I could come up with a
simpler explanation or solution. If any have suggestions for
either, I would be happy to adopt either. Feel free to email me.)
No functional change. Inching further toward cross-platform.
Some compilers require function prototypes and bodies to match with
throw() attributes. This corrects them.
Additionally, it replaces thrown std::exceptions with a string
parameter with runtime_errors, which can take a string on any
system.
Finally, I moved GetPosition in FileIOHelper.cpp to its proper
place with the rest of the AbstractMemoryStream implementation
instead of grouping it with the IDxcBlob implementation
Nonfunctional change. Just inching toward cross platform compatibility
It's actually a spec reading issue that it seems we cannot
have stand-alone variables for Position, PointSize, ClipDistance,
or CullDistance in HS/DS/GS.
Removed all code regarding Position and PointSize from GlPerVertex.
We still need to keep GlPerVertex aroudn to handle ClipDistance
and CullDistance though.
Greg Roth
Ehsan
Vishal Sharma
Lei Zhang
Tex Riddell
Xiang Li
Greg Roth
John Porto
Marcelo Lopez Ruiz