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.
This is only set while compiling device code, and is useful
for code that needs different implementations on devices (e.g.
they call CUDA device intrinsics, etc).
Sandia National Laboratories recently changed management from the
Sandia Corporation to the National Technology & Engineering Solutions
of Sandia, LLC (NTESS). The copyright statements need to be updated
accordingly.
VTKM_PASS_COMMAS(...) will pass it's arguments verbatim into another
macro, even if they contain commas. This is helpful when using templated
classes, e.g.
#define SOME_MACRO(arg) ...
SOME_MACRO(vtkm::cont::ArrayHandle<float, StorageTag>)
won't compile, because the comma in the template parameters is assumed
to be separating macro arguments. Adding extra parenthesis,
SOME_MACRO((vtkm::cont::ArrayHandle<float, StorageTag>))
helps in some cases, but not others (e.g. the macro declares a variable).
SOME_MACRO(VTKM_PASS_COMMAS(vtkm::cont::ArrayHandle<float, StorageTag>))
will always* work.
windows.h was only being included for MSVC, while in UnitTestTimer.cxx, the
Windows function Sleep was being called after check for _WIN32. This was
causing compilation failure in MINGW.
Fixes#122
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.
In VTK-m libraries, we are typically exporting (with declspec) classes rather
than the independent methods within the class. When you are exporting to a
dll in MSVC and the class contains a field that is not similarly exported,
then you get a warning. This is generally not an issue for our use since we
are really only using classes from the standard library and distributed with
VTK-m itself. The only sane way to fix the issue is to just disable the
warning.
a6609311 Silence auto_ptr deprecation warnings with older boosts ( < 1.61 )
6d38f44d Update ListTag and DispatcherBase to leverage C++11 features.
ea0d84a8 Remove VTK-m Variadic defines and replace them with a single CXX11 define
77121d18 Add support to VTK-m to build with C++11
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !475
Add pragmas to disable warnings 4244 and 4800 on Visual Studio when
compiling third party libraries. This gets around some warnings inside
the thrust library.
MSVC has a warning for using "unsafe" algorithms such as fill_n that can
easily overrun the end of unchecked pointers. The problem is that there
are lots of valid uses of these algorithms, and the signal that this is
a valid use is MSVC-specific. Even less fortunate is the fact that if
another header violates the warning, it is impossible to suppress it
because it happens in a system header file (xutility), which was included
far before the actual offending code occured. Even less fortunate than
that, a boost header we (indirectly) use sets off this warning, cannot
be suppressed, and is not going to be fixed
(https://svn.boost.org/trac/boost/ticket/11426). The best solution is to
turn off this problematic warning for everybody.
We are disabling the entire vectorization hints for ICC as it generates
both bad code, and dramatically decreases compile time.
The compiler does not check for aliasing or dependencies that might cause
incorrect results after vectorization, and it does not protect against illegal
memory references. #pragma ivdep overrides potential dependencies, but the
compiler still performs a dependency analysis, and will not vectorize if it
finds a proven dependency that would affect results. With #pragma simd, the
compiler does no such analysis, and tries to vectorize regardless.
86bb45b9 Simplify the ifdef conditions used for vector pragma definitions
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !310
f5f9939f Update all of vtkm to understand it can only identify as one compiler.
c706c826 Configure.h can only state a machine is a one compiler.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !307
It used to be possible for vtk-m to say it was multiple compilers, for example
it could be both GCC and PGI, Clang and MSVC ( yes possible ), or Intel and
Clang.
This logical restructure now makes that impossible, and instead prefers a system
where we choose the most specialized version of the compiler over the most
general, where general is GCC / Clang.
