There was a static assert in a templated function that was never
supposed to be used. Some compilers were fine as long as there was no
use of the templated function, but others errored out anyway. Change the
implementation to use the =delete keyword instead.
This won't have as nice of an error message, but you would have to jump
through some hoops to get to this point anyway. If this still does not
work, we could just probably remove the invalid templated function. The
compiler error would get even more obfuscated, but again I don't expect
anyone to actually run into it.
The implementation was calling PrepareForOutput on the delegate arrays
rather than PrepareForInPlace, do when used with CUDA you did not get
the data on the device.
Also added a regression test to check this.
The CellSetExplicit and CellSetSingleType classes have an ivar that
marks the number of points. There were several instances of code
creating cell sets without specifying the number of points. This can be
very bad if subsequent code needs that information.
f23ff9fa Fix warnings about assignment operators not being generated
7ec8c034 Remove warning about constant conditional in VTKM_ASSUME
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !657
For some reason when VTK-m was being compiled as an accelerator in VTK,
Visual Studio 2013 gave a bunch of warnings about not being able to generate
assignment operators for many classes. This happened for classes with a
const ivar that could not be automatically set. (Automatic copy constructors
are fine on this count.) I'm not sure why these warnings did not happen
when just compiling VTK-m, nor am I sure why they were generated at all as
no code actually used the copy constructors.
This commit fixes the problems by adding a private declaration for assignment
operators that cannot be automatically created. No implementation is
provided, nor should any be needed.
It is common practice to swallow a semicolon in a macro using a do/
while(false) loop that only executes once. However, the Visual Studio
2013 compiler was stupidly warning about having a constant expression
for the loop. Get around the problem by creating our own swallow
semicolon macros that disable this warning as necessary.
This will expose bugs inside the tbb backend. We had to use heap allocations
for test arrays, instead of stack as the new array increases started to
cause stack overflow on windows.
a339f3ac Had to rewrite tbb reduce to correct all the problems.
0120157e Correct tbb reduction algorithm to be correct when using multiple threads.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !654
When using Types or Matrix with the nvcc compiler with Wunused-value
enabled you would get the following warning:
(__builtin_expect(!(rowIndex < (this,NUM_ROWS)), 0)) ?
__assert_rtn(__func__, "vtkm/Matrix.h", 86, "rowIndex < this->NUM_ROWS") :
((void)0);
This is solved by changing this->NUM_ROWS to just NUM_ROWS.
c27bb01f Introduces ListTagUniversal which represents a list of everything.
9eb28841 vtkm::filter now deduces the subset of valid field types.
49c5e822 vtkm can now find the intersection of two ListTags.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !649
Previously the ApplyPolicy logic was to use the filters
field set, and ignore the policy field set.
But this caused problems, as a filter couldn't express that
it was able to work on all valid types. This caused
certain complex types Vec of Vec's to fail to work properly,
and would cause compile use code paths that would never
be valid for a given policy.
