Was getting the following error:
vtkm/List.h(284): error C2210: 'T' : pack expansions cannot be used as
arguments to non-packed parameters in alias templates
This is probably an issue with the compiler not resolving templated
aliases correctly.
This cleans up the code a bit by removing duplication. More importantly,
it makes sure that the old ListTag functions work with both the new
`List` and old `ListTagBase`.
Previously, the `VTKM_ALWAYS_EXPORT` and `VTKM_NEVER_EXPORT` macros
used the gnu-specific `__attribute__` keyword. This change instead
uses the C++11 standard method of using `[[ ]]` as attributes.
Specifically, `__attribute(visibility("---"))` is changed to
`[[gnu::visibility("--")]]`.
The main impetus for this change is that `__attribute__` does not
seem to work with `[[deprecated]]` on GCC compilers. (For sure on
GCC 6. I didn't check all compiler versions.) This change was
recommended from
https://stackoverflow.com/questions/40886628/deprecated-attribute-visibility-default-in-gcc-6-2
This creates a minor backward incompatibility. We have always meant
for these macros to be used before the return type when used with
a function. However, GCC accepted placing `__attribute__` after
the return type. The C++11 `[[ ]]` cannot be placed there, so
some macros might have to be moved. Still, this was a broken
use that happened to work.
A new header named TypeList.h and the type lists have been redefined in
this new file. All the types have been renamed from `TypeListTag*` to
`TypeList*`. TypeListTag.h has been gutted to provide deprecated
versions of the old type list names.
There were also some other type lists that were changed from using the
old `ListTagBase` to the new `List`.
The newer List operations should still work on the old ListTags, so make
those changes first to ensure that everything still works as expected if
given an old ListTag.
Next step is to deprecate ListTagBase itself and move all the lists to
the new types.
Instead of incrementally building a new Invocation object
for each modified parameter, we construct a single new type
with all the new parameters.
GCC 9.2, Release, Contour Filter:
Master: 1:08.96min, max memory: 1762644 KB
This: 1:04.56min, max memory: 1730376 KB
`vtkm::List` is meant to replace `vtkm::ListTag`. Rather than
subclassing a base class with a variadic template, all lists expose the
list of types.
`vtkm::ListTag` was originally created before we required C++11 so
supporting variadic templates was problematic. To hide the issue we had,
we made list tags subclass other lists rather than be the list
themselves. It makes for nicer types in the compiler, but hides
important details about what is actually in the type. It also creates
lots of unnecessary new types.
The new `vtkm::List` is in some ways simpler. All lists have to be a
`vtkm::List`. Subclasses are not supported (or rather, they will not
work as expected). All manipulations (such as `vtkm::ListAppend`)
resolve directly back to a `vtkm::List`. Although the types reported by
the compiler will be longer, they will be more specific to the types
being used. Also, the new implimentation should ultimately use fewer
types.
Yet more ways that we can reduce the complexity of `FunctionInterface`.
This is another step in figuring out what set of features the replacement
for `FunctionInterface` needs to have.
Using GCC 9.2 the pre change vtkm::filter::Threshold would
take 31.84sec to compile and use 1.1GB of memory. After
these changes the filter takes 24.16sec to compile and
uses 885MB of memory.
CMake 3.16 includes support for unity builds which merge multiple
translation units together automatically for faster builds.
A couple of translation units in VTK-m already require lots of
system memory, and merging them actually decreases compile performance
When it was originally created, it was assumed that the ArrayHandle
class would be used by a single thread. As the use of VTK-m expands,
that is no longer a safe assumption. To ensure that operations on
ArrayHandle happen correctly, add a mutex to the Internals of
ArrayHandle and require all operations on the Internals lock that mutex.
There is some behavior of GCC compilers before GCC 9.0 that is
incompatible with the specification of OpenMP 4.0. The workaround was
using the workaround any time a GCC compiler >= 9.0 was used. The proper
behavior is to only use the workaround when the GCC compiler is being
used and the version of the compiler is less than 9.0.
Also, switch to using VTKM_GCC to check for the GCC compiler instead of
__GNUC__. The problem with using __GNUC__ is that many other compilers
pretend to be GCC by defining this macro, but in cases like compiler
workarounds it is not accurate.
Older GCC compilers were giving warnings in the operator of the
GeneratePoints worklets for tubes because they could not completely
determine that variables were being properly initialized in the first
loop iteration (and therefore initialized for every subsequent
iteration). Fixed that by moving the initialization for the first
iteration outside of the loop.
Previously we relied on CMake's compiler detection module to build the
macros for using the deprecated attribute. However, CMake created macros
for pre-C++14 versions of the feature, which do not work in all cases.
Also, we have the need to be able to suppress deprecation warnings when
we are implementing a deprecated thing. Since we have to query compilers
ourself, we might as well figure out if the deprecated attribute we want
is supported.
Worst case is that we won't support deprecation warnings everywhere we
could. That will not create incorrect code and we can always add that
later.
Previously, Configure.h.in used a pragma to disable warning 4996 is all
VTK-m code and anything that used it. The reason for this was that the
warning was given for any use of std algorithms such as fill_n that the
Visual Studio team deemed unsafe. Although we could fix it in our code,
it was impossible to work around warnings in other headers as the actual
warning comes from a system header file (xutility) that we have very
little control over. At the time we disabled this warning, we were
getting the warning from a bost header file, and the warning was never
to be fixed (https://svn.boost.org/trac/boost/ticket/11426).
Unfortunately, disabling warning 4996 also disables all warnings about
deprecated items. We want to support warnings for things deprecated in
VTK-m itself, so turning off this warning means we cannot correctly
support VTK-m deprecation.
Fortunately, a lot has changed since then. We no longer boost at all, so
the issue there is no longer our problem. We can thus re-enable the
warning (by removing the pragma). We've managed to avoid using these
"unsafe" functions anyway, so we should be able to cleanly build with
this warning on.
The `VTKM_DEPRECATED` macro allows us to remove (and usually replace)
features from VTK-m in minor releases while still following the conventions
of semantic versioning. The idea is that when we want to remove or replace
a feature, we first mark the old feature as deprecated. The old feature
will continue to work, but compilers that support it will start to issue a
warning that the use is deprecated and should stop being used. The
deprecated features should remain viable until at least the next major
version. At the next major version, deprecated features from the previous
version may be removed.
Previously when ApplyPolicyFieldOfType was used in cases where not all
of the types matched not all of the storages, those invalid arrays were
replaced with an ArrayHandleDiscard. This unnecessarily increased the
length of the type names used for the resulting ArrayHandleMultiplexer.
Now, ListTagRemoveIf is used to remove any invalid arrays so that the
resulting ArrayHandleMultiplexer only includes the valid arrays.
Although GCC 4.8 and 4.9 claim to be C++11 compliant, there are a few
C++11 features they do not support. One of these features is
std::is_trivially_copyable. So on these platforms, do not attempt to use
it. Instead, treat nothing as trivially copyable.
The code from the previous commit was causing one of the dashboards,
which is using gcc-7, to produce the following warning:
In file included from ../testing/UnitTestVariant.cxx:11:0:
../Variant.h: In function 'void {anonymous}::TestCopyDestroy()':
../Variant.h:269:5: warning: '<anonymous>' may be used uninitialized in this function [-Wmaybe-uninitialized]
this->Storage = std::move(rhs.Storage);
^~~~
At best, this warning is not helpful as it does not seem to point to
anything that could be used uninitialized. At worst, it might be a
compiler bug. A Google search finds a few similar bugs although none I
can assert with any confidence of this issue. However, many reported
bugs and issues point to the use of anonymous namespaces. So, I'm going
to attempt to fix the problem by removing anonymous namespaces.
Hopefully it will fix the warning or at least point me to something
concrete that I can fix.
The Variant template can hold any type. If it is holding a type that is
non-copyable, then it has to make sure that appropriate constructors,
copiers, movers, and destructors are called.
Previously, these were called even the Variant was holding a trivially
copyable class because no harm no foul. If you were holding a trivially
copyable class and did a memcpy, that work work, which should make it
possible to copy between host and device, right?
In theory yes, but in practice no. The problem is that Cuda is
outsmarting the code. It is checking that Variant is not trivially-
copyable by C++ semantics and refusing to push it.
So, change Variant to check to see if all its supported classes are
trivially copyable. If they are, then it use the default constructors,
destructors, movers, and copiers so that C++ recognizes it as trivially
copyable.
79f7f8275 Fix UnitTestError failure
901711bff Fix test failure due to floating point issues
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1896
This file was using the Matrix class but not including Matrix.h. When I
tried to use the MeshQuality filter in an example that did not include
Matrix.h on its own, I got a compile error.
If a worklet doesn't explicitly state an ExecutionSignature, VTK-m
assumes the worklet has no return value, and each ControlSignature
argument is passed to the worklet in the same order.
For example if we had this worklet:
```cxx
struct DotProduct : public vtkm::worklet::WorkletMapField
{
using ControlSignature = void(FieldIn, FieldIn, FieldOut);
using ExecutionSignature = void(_1, _2, _3);
template <typename T, vtkm::IdComponent Size>
VTKM_EXEC void operator()(const vtkm::Vec<T, Size>& v1,
const vtkm::Vec<T, Size>& v2,
T& outValue) const
{
outValue = vtkm::Dot(v1, v2);
}
};
```
It can be simplified to be:
```cxx
struct DotProduct : public vtkm::worklet::WorkletMapField
{
using ControlSignature = void(FieldIn, FieldIn, FieldOut);
template <typename T, vtkm::IdComponent Size>
VTKM_EXEC void operator()(const vtkm::Vec<T, Size>& v1,
const vtkm::Vec<T, Size>& v2,
T& outValue) const
{
outValue = vtkm::Dot(v1, v2);
}
};
The older Xcode 9 compiler has troubles with ArrayHandleDecorator that
are similar to those of earlier Microsoft and Cuda compilers.
Note that the logic behind the changed compiler check has a lot of
guesswork involved. I noticed this problem on a laptop with Xcode 9
installed. However, even though Xcode uses the clang compiler, it
notoriously does not return the actual clang version. Instead, it
returns some toolchain version that has nothing to do with it. I'm
pretty sure Xcode 9 is using clang version 4 under the covers, but
__clang_major__ reports 9. Oddly, Xcode 10 reports __clang_major__ as 8,
so that's not too much help. So instead, we check for
__apple_build_version__, which returns the Xcode version (sort of) and
that seems a reasonable comparison.
Although I have not tried it, I'm willing to bet that the older clang
outside of Xcode will also have issues. Here is where the real guesswork
takes place since I don't have handy compilers to try. Like I said, I
think the internet claims that Xcode 9 is using clang 4, so also add to
the check any compiler that reports itself clang 4 or below.
973878b8b Improve the performance of the Image and Graph Connectivity algorithms
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !1873
The collection of connectivity algorithms had a couple of inefficiencies.
By moving to using WorkId we can remove a couple of arrays of the same size
as the input domain. In addition by moving to using atomics we can remove
an bool output array with a size equivalent to the input domain and
a call to reduce.
