Shuenhoy/vtk-m
1
0
Fork 0
mirror of https://gitlab.kitware.com/vtk/vtk-m synced 2024-09-19 18:45:43 +00:00
Code Issues 2 Actions Packages Projects Releases Wiki Activity
5a72275ed8
vtk-m/vtkm/testing/UnitTestArrayPortalValueReference.cxx

329 lines
10 KiB
C++
Raw Normal View History

Implement ArrayHandleGroupVecVariable This is a fancy array handle that can group entries in another array by arbitrary amounts. This allows us to implement input and output arrays with a different sized Vec for each instance. This is necessary for generating new topologies with cells of different types.
2016-10-28 03:14:29 +00:00
//============================================================================
// Copyright (c) Kitware, Inc.
// All rights reserved.
// See LICENSE.txt for details.
conslidate the license statement
2019-04-15 23:24:21 +00:00
//
Implement ArrayHandleGroupVecVariable This is a fancy array handle that can group entries in another array by arbitrary amounts. This allows us to implement input and output arrays with a different sized Vec for each instance. This is necessary for generating new topologies with cells of different types.
2016-10-28 03:14:29 +00:00
// This software is distributed WITHOUT ANY WARRANTY; without even
// the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
// PURPOSE. See the above copyright notice for more information.
//============================================================================
For VTK-m libs all includes of DeviceAdapterTagCuda happen from cuda files It is very easy to cause ODR violations with DeviceAdapterTagCuda. If you include that header from a C++ file and a CUDA file inside the same program we an ODR violation. The reasons is that the C++ versions will say the tag is invalid, and the CUDA will say the tag is valid. The solution to this is that any compilation unit that includes DeviceAdapterTagCuda from a version of VTK-m that has CUDA enabled must be invoked by the cuda compiler.
2019-04-17 17:59:49 +00:00
#include <vtkm/testing/Testing.h>
Implement ArrayHandleGroupVecVariable This is a fancy array handle that can group entries in another array by arbitrary amounts. This allows us to implement input and output arrays with a different sized Vec for each instance. This is necessary for generating new topologies with cells of different types.
2016-10-28 03:14:29 +00:00
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
#include <vtkm/TypeTraits.h>
For VTK-m libs all includes of DeviceAdapterTagCuda happen from cuda files It is very easy to cause ODR violations with DeviceAdapterTagCuda. If you include that header from a C++ file and a CUDA file inside the same program we an ODR violation. The reasons is that the C++ versions will say the tag is invalid, and the CUDA will say the tag is valid. The solution to this is that any compilation unit that includes DeviceAdapterTagCuda from a version of VTK-m that has CUDA enabled must be invoked by the cuda compiler.
2019-04-17 17:59:49 +00:00
#include <vtkm/cont/ArrayHandle.h>
#include <vtkm/internal/ArrayPortalValueReference.h>
Implement ArrayHandleGroupVecVariable This is a fancy array handle that can group entries in another array by arbitrary amounts. This allows us to implement input and output arrays with a different sized Vec for each instance. This is necessary for generating new topologies with cells of different types.
2016-10-28 03:14:29 +00:00
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
namespace
{
Implement ArrayHandleGroupVecVariable This is a fancy array handle that can group entries in another array by arbitrary amounts. This allows us to implement input and output arrays with a different sized Vec for each instance. This is necessary for generating new topologies with cells of different types.
2016-10-28 03:14:29 +00:00
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
static constexpr vtkm::Id ARRAY_SIZE = 10;
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
template <typename ArrayPortalType>
void SetReference(vtkm::Id index, vtkm::internal::ArrayPortalValueReference<ArrayPortalType> ref)
Implement ArrayHandleGroupVecVariable This is a fancy array handle that can group entries in another array by arbitrary amounts. This allows us to implement input and output arrays with a different sized Vec for each instance. This is necessary for generating new topologies with cells of different types.
2016-10-28 03:14:29 +00:00
{
using ValueType = typename ArrayPortalType::ValueType;
ref = TestValue(index, ValueType());
}
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
template <typename ArrayPortalType>
void CheckReference(vtkm::Id index, vtkm::internal::ArrayPortalValueReference<ArrayPortalType> ref)
Implement ArrayHandleGroupVecVariable This is a fancy array handle that can group entries in another array by arbitrary amounts. This allows us to implement input and output arrays with a different sized Vec for each instance. This is necessary for generating new topologies with cells of different types.
2016-10-28 03:14:29 +00:00
{
using ValueType = typename ArrayPortalType::ValueType;
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
VTKM_TEST_ASSERT(test_equal(ref, TestValue(index, ValueType())), "Got bad value from reference.");
Implement ArrayHandleGroupVecVariable This is a fancy array handle that can group entries in another array by arbitrary amounts. This allows us to implement input and output arrays with a different sized Vec for each instance. This is necessary for generating new topologies with cells of different types.
2016-10-28 03:14:29 +00:00
}
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
template <typename ArrayPortalType>
void TryOperatorsNoVec(vtkm::Id index,
vtkm::internal::ArrayPortalValueReference<ArrayPortalType> ref,
vtkm::TypeTraitsScalarTag)
{
using ValueType = typename ArrayPortalType::ValueType;
ValueType expected = TestValue(index, ValueType());
VTKM_TEST_ASSERT(ref.Get() == expected, "Reference did not start out as expected.");
VTKM_TEST_ASSERT(!(ref < ref));
VTKM_TEST_ASSERT(ref < ValueType(expected + ValueType(1)));
VTKM_TEST_ASSERT(ValueType(expected - ValueType(1)) < ref);
VTKM_TEST_ASSERT(!(ref > ref));
VTKM_TEST_ASSERT(ref > ValueType(expected - ValueType(1)));
VTKM_TEST_ASSERT(ValueType(expected + ValueType(1)) > ref);
VTKM_TEST_ASSERT(ref <= ref);
VTKM_TEST_ASSERT(ref <= ValueType(expected + ValueType(1)));
VTKM_TEST_ASSERT(ValueType(expected - ValueType(1)) <= ref);
VTKM_TEST_ASSERT(ref >= ref);
VTKM_TEST_ASSERT(ref >= ValueType(expected - ValueType(1)));
VTKM_TEST_ASSERT(ValueType(expected + ValueType(1)) >= ref);
}
template <typename ArrayPortalType>
void TryOperatorsNoVec(vtkm::Id,
vtkm::internal::ArrayPortalValueReference<ArrayPortalType>,
vtkm::TypeTraitsVectorTag)
{
}
template <typename ArrayPortalType>
void TryOperatorsInt(vtkm::Id index,
vtkm::internal::ArrayPortalValueReference<ArrayPortalType> ref,
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
vtkm::internal::ArrayPortalValueReference<ArrayPortalType> scratch,
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
vtkm::TypeTraitsScalarTag,
vtkm::TypeTraitsIntegerTag)
{
using ValueType = typename ArrayPortalType::ValueType;
ValueType expected = TestValue(index, ValueType());
VTKM_TEST_ASSERT(ref.Get() == expected, "Reference did not start out as expected.");
VTKM_TEST_ASSERT((ref % ref) == (expected % expected));
VTKM_TEST_ASSERT((ref % expected) == (expected % expected));
VTKM_TEST_ASSERT((expected % ref) == (expected % expected));
VTKM_TEST_ASSERT((ref ^ ref) == (expected ^ expected));
VTKM_TEST_ASSERT((ref ^ expected) == (expected ^ expected));
VTKM_TEST_ASSERT((expected ^ ref) == (expected ^ expected));
VTKM_TEST_ASSERT((ref | ref) == (expected | expected));
VTKM_TEST_ASSERT((ref | expected) == (expected | expected));
VTKM_TEST_ASSERT((expected | ref) == (expected | expected));
VTKM_TEST_ASSERT((ref & ref) == (expected & expected));
VTKM_TEST_ASSERT((ref & expected) == (expected & expected));
VTKM_TEST_ASSERT((expected & ref) == (expected & expected));
VTKM_TEST_ASSERT((ref << ref) == (expected << expected));
VTKM_TEST_ASSERT((ref << expected) == (expected << expected));
VTKM_TEST_ASSERT((expected << ref) == (expected << expected));
VTKM_TEST_ASSERT((ref << ref) == (expected << expected));
VTKM_TEST_ASSERT((ref << expected) == (expected << expected));
VTKM_TEST_ASSERT((expected << ref) == (expected << expected));
VTKM_TEST_ASSERT(~ref == ~expected);
VTKM_TEST_ASSERT(!(!ref));
VTKM_TEST_ASSERT(ref && ref);
VTKM_TEST_ASSERT(ref && expected);
VTKM_TEST_ASSERT(expected && ref);
VTKM_TEST_ASSERT(ref || ref);
VTKM_TEST_ASSERT(ref || expected);
VTKM_TEST_ASSERT(expected || ref);
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
scratch = ValueType(7);
const ValueType operand = ValueType(7);
clang-format: reformat the repository with clang-format-9
2020-08-17 14:18:24 +00:00
#define RESET \
ref = TestValue(index, ValueType()); \
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
expected = TestValue(index, ValueType());
Fix warnings found when cuda is the cuda host compiler
2019-04-05 12:31:34 +00:00
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
RESET;
ref &= scratch;
expected &= operand;
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
VTKM_TEST_ASSERT(ref == expected);
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
RESET;
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
ref &= operand;
expected &= operand;
VTKM_TEST_ASSERT(ref == expected);
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
RESET;
ref |= scratch;
expected |= operand;
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
VTKM_TEST_ASSERT(ref == expected);
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
RESET;
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
ref |= operand;
expected |= operand;
VTKM_TEST_ASSERT(ref == expected);
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
RESET;
ref >>= scratch;
expected >>= operand;
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
VTKM_TEST_ASSERT(ref == expected);
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
RESET;
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
ref >>= operand;
expected >>= operand;
VTKM_TEST_ASSERT(ref == expected);
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
RESET;
ref <<= scratch;
expected <<= operand;
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
VTKM_TEST_ASSERT(ref == expected);
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
RESET;
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
ref <<= operand;
expected <<= operand;
VTKM_TEST_ASSERT(ref == expected);
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
RESET;
ref ^= scratch;
expected ^= operand;
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
VTKM_TEST_ASSERT(ref == expected);
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
RESET;
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
ref ^= operand;
expected ^= operand;
VTKM_TEST_ASSERT(ref == expected);
Fix warnings found when cuda is the cuda host compiler
2019-04-05 12:31:34 +00:00
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
#undef RESET
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
}
template <typename ArrayPortalType, typename DimTag, typename NumericTag>
void TryOperatorsInt(vtkm::Id,
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
vtkm::internal::ArrayPortalValueReference<ArrayPortalType>,
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
vtkm::internal::ArrayPortalValueReference<ArrayPortalType>,
DimTag,
NumericTag)
{
}
template <typename ArrayPortalType>
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
void TryOperators(vtkm::Id index,
vtkm::internal::ArrayPortalValueReference<ArrayPortalType> ref,
vtkm::internal::ArrayPortalValueReference<ArrayPortalType> scratch)
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
{
using ValueType = typename ArrayPortalType::ValueType;
ValueType expected = TestValue(index, ValueType());
VTKM_TEST_ASSERT(ref.Get() == expected, "Reference did not start out as expected.");
// Test comparison operators.
VTKM_TEST_ASSERT(ref == ref);
VTKM_TEST_ASSERT(ref == expected);
VTKM_TEST_ASSERT(expected == ref);
VTKM_TEST_ASSERT(!(ref != ref));
VTKM_TEST_ASSERT(!(ref != expected));
VTKM_TEST_ASSERT(!(expected != ref));
TryOperatorsNoVec(index, ref, typename vtkm::TypeTraits<ValueType>::DimensionalityTag());
VTKM_TEST_ASSERT((ref + ref) == (expected + expected));
VTKM_TEST_ASSERT((ref + expected) == (expected + expected));
VTKM_TEST_ASSERT((expected + ref) == (expected + expected));
VTKM_TEST_ASSERT((ref - ref) == (expected - expected));
VTKM_TEST_ASSERT((ref - expected) == (expected - expected));
VTKM_TEST_ASSERT((expected - ref) == (expected - expected));
VTKM_TEST_ASSERT((ref * ref) == (expected * expected));
VTKM_TEST_ASSERT((ref * expected) == (expected * expected));
VTKM_TEST_ASSERT((expected * ref) == (expected * expected));
VTKM_TEST_ASSERT((ref / ref) == (expected / expected));
VTKM_TEST_ASSERT((ref / expected) == (expected / expected));
VTKM_TEST_ASSERT((expected / ref) == (expected / expected));
Suppress more self-assign-overloaded warnings found by clang
2019-04-09 18:09:54 +00:00
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
scratch = ValueType(7);
const ValueType operand = ValueType(7);
clang-format: reformat the repository with clang-format-9
2020-08-17 14:18:24 +00:00
#define RESET \
ref = TestValue(index, ValueType()); \
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
expected = TestValue(index, ValueType());
Suppress more self-assign-overloaded warnings found by clang
2019-04-09 18:09:54 +00:00
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
RESET;
ref += scratch;
expected += operand;
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
VTKM_TEST_ASSERT(ref == expected);
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
RESET;
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
ref += operand;
expected += operand;
VTKM_TEST_ASSERT(ref == expected);
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
RESET;
ref -= scratch;
expected -= operand;
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
VTKM_TEST_ASSERT(ref == expected);
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
RESET;
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
ref -= operand;
expected -= operand;
VTKM_TEST_ASSERT(ref == expected);
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
RESET;
ref *= scratch;
expected *= operand;
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
VTKM_TEST_ASSERT(ref == expected);
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
RESET;
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
ref *= operand;
expected *= operand;
VTKM_TEST_ASSERT(ref == expected);
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
RESET;
ref /= scratch;
expected /= operand;
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
VTKM_TEST_ASSERT(ref == expected);
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
RESET;
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
ref /= operand;
expected /= operand;
VTKM_TEST_ASSERT(ref == expected);
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
RESET;
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
TryOperatorsInt(index,
ref,
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
scratch,
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
typename vtkm::TypeTraits<ValueType>::DimensionalityTag(),
typename vtkm::TypeTraits<ValueType>::NumericTag());
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
#undef RESET
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
}
Implement ArrayHandleGroupVecVariable This is a fancy array handle that can group entries in another array by arbitrary amounts. This allows us to implement input and output arrays with a different sized Vec for each instance. This is necessary for generating new topologies with cells of different types.
2016-10-28 03:14:29 +00:00
struct DoTestForType
{
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
template <typename ValueType>
VTKM_CONT void operator()(const ValueType&) const
Implement ArrayHandleGroupVecVariable This is a fancy array handle that can group entries in another array by arbitrary amounts. This allows us to implement input and output arrays with a different sized Vec for each instance. This is necessary for generating new topologies with cells of different types.
2016-10-28 03:14:29 +00:00
{
vtkm::cont::ArrayHandle<ValueType> array;
array.Allocate(ARRAY_SIZE);
std::cout << "Set array using reference" << std::endl;
Use new ways to get array portal in control environment Also fix deadlocks that occur when portals are not destroyed in time.
2020-01-28 19:14:32 +00:00
using PortalType = typename vtkm::cont::ArrayHandle<ValueType>::WritePortalType;
PortalType portal = array.WritePortal();
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
for (vtkm::Id index = 0; index < ARRAY_SIZE; ++index)
Implement ArrayHandleGroupVecVariable This is a fancy array handle that can group entries in another array by arbitrary amounts. This allows us to implement input and output arrays with a different sized Vec for each instance. This is necessary for generating new topologies with cells of different types.
2016-10-28 03:14:29 +00:00
{
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
SetReference(index, vtkm::internal::ArrayPortalValueReference<PortalType>(portal, index));
Implement ArrayHandleGroupVecVariable This is a fancy array handle that can group entries in another array by arbitrary amounts. This allows us to implement input and output arrays with a different sized Vec for each instance. This is necessary for generating new topologies with cells of different types.
2016-10-28 03:14:29 +00:00
}
std::cout << "Check values" << std::endl;
CheckPortal(portal);
std::cout << "Check references in set array." << std::endl;
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
for (vtkm::Id index = 0; index < ARRAY_SIZE; ++index)
Implement ArrayHandleGroupVecVariable This is a fancy array handle that can group entries in another array by arbitrary amounts. This allows us to implement input and output arrays with a different sized Vec for each instance. This is necessary for generating new topologies with cells of different types.
2016-10-28 03:14:29 +00:00
{
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
CheckReference(index, vtkm::internal::ArrayPortalValueReference<PortalType>(portal, index));
Implement ArrayHandleGroupVecVariable This is a fancy array handle that can group entries in another array by arbitrary amounts. This allows us to implement input and output arrays with a different sized Vec for each instance. This is necessary for generating new topologies with cells of different types.
2016-10-28 03:14:29 +00:00
}
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
std::cout << "Make a scratch buffer for ref-ref operations." << std::endl;
vtkm::cont::ArrayHandle<ValueType> scratchArray;
scratchArray.Allocate(1);
PortalType scratchPortal = scratchArray.WritePortal();
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
std::cout << "Check that operators work." << std::endl;
// Start at 1 to avoid issues with 0.
for (vtkm::Id index = 1; index < ARRAY_SIZE; ++index)
{
Fix UnitTestArrayPortalValueReference A recent change to the continuous integration setup has caused `UnitTestArrayPortalValueReference` to fail on one platform. The problem was that the test was doing two unsafe things with the right-shift assignment operator. The first unsafe thing was using itself as the operand. ```cpp ref >>= ref; ``` This causes clang to give a "self assign overload" warning. Using a variable as its own operand for a compute assign operation isn't great style, but for some operations it can cause weird errors. The reason for the warning is that for a true integer shift operation, the compiler will recognize that the result should be 0. So, when using this on base integer types, you will get 0. But overloads can give you something different, so that might lead to unexpected results. Because we _are_ using an overload (for the `ArrayPortalValueReference` class), the compiler tells us we can get potentially unexpected results. OK. That seems like something we can safely ignore (and were ignoring for some time). After all, the whole point of the `ArrayPortalValueReference` operators is to behave exactly the same as the values they wrap. That brings us to the second unsafe thing the test was doing: using an invalid value as the right hand operation. And this is where things get weird. The test was specifically failing when being run on `Int32`. It was setting the underlying value for `ref` to be `1000` to start with. So the expression `ref >>= ref` was trying to right shift `ref` by 1000 bits. Logically, this should of course give you 0. However, shifting a number by more bits than exist causes undefined behavior (c.f. https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+not+shift+an+expression+by+a+negative+number+of+bits+or+by+greater+than+or+equal+to+the+number+of+bits+that+exist+in+the+operand). You might not get back the expected value, and this is exactly what was happening. What I think happened was that the compiler determined that any valid shift would be contained in 5 bits, so it truncated the value (1000) to the least signifcant 5 bits (which happens to be 8). It then shifted 1000 by 8 and got the value 3 instead of 0. The fix picks an operand number that is sure to be valid.
2020-07-14 22:10:06 +00:00
TryOperators(index,
vtkm::internal::ArrayPortalValueReference<PortalType>(portal, index),
vtkm::internal::ArrayPortalValueReference<PortalType>(scratchPortal, 0));
Add specialized operators for ArrayPortalValueReference The ArrayPortalValueReference is supposed to behave just like the value it encapsulates and does so by automatically converting to the base type when necessary. However, when it is possible to convert that to something else, it is possible to get errors about ambiguous overloads. To avoid these, add specialized versions of the operators to specify which ones should be used. Also consolidated the CUDA version of an ArrayPortalValueReference to the standard one. The two implementations were equivalent and we would like changes to apply to both.
2019-02-09 23:49:17 +00:00
}
Implement ArrayHandleGroupVecVariable This is a fancy array handle that can group entries in another array by arbitrary amounts. This allows us to implement input and output arrays with a different sized Vec for each instance. This is necessary for generating new topologies with cells of different types.
2016-10-28 03:14:29 +00:00
}
};
void DoTest()
{
Fix problem with imprecise float comparison
2022-07-08 14:31:37 +00:00
// We are not testing on the default (exemplar) types because we want to test operators, and
// many basic C types could fail on basic operations. Small integer types (such as unsigned
// bytes) get automatically promoted to larger types, so doing somthing like a += operation
// causes annoying compiler warnings. Float types are also problematic because comparison
// operations like == can fail even when you expect the values to be the same.
Update lists in TypeListTag.h 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`.
2019-12-05 17:55:57 +00:00
vtkm::testing::Testing::TryTypes(DoTestForType(),
Fix problem with imprecise float comparison
2022-07-08 14:31:37 +00:00
vtkm::List<vtkm::Int32, vtkm::UInt64, vtkm::Id3>());
Implement ArrayHandleGroupVecVariable This is a fancy array handle that can group entries in another array by arbitrary amounts. This allows us to implement input and output arrays with a different sized Vec for each instance. This is necessary for generating new topologies with cells of different types.
2016-10-28 03:14:29 +00:00
}
} // anonymous namespace
Testing run methods now take argc/argv to init logging/runtime device `vtkm::cont::testing` now initializes with logging enabled and support for device being passed on the command line, `vtkm::testing` only enables logging.
2019-01-01 22:19:02 +00:00
int UnitTestArrayPortalValueReference(int argc, char* argv[])
Implement ArrayHandleGroupVecVariable This is a fancy array handle that can group entries in another array by arbitrary amounts. This allows us to implement input and output arrays with a different sized Vec for each instance. This is necessary for generating new topologies with cells of different types.
2016-10-28 03:14:29 +00:00
{
For VTK-m libs all includes of DeviceAdapterTagCuda happen from cuda files It is very easy to cause ODR violations with DeviceAdapterTagCuda. If you include that header from a C++ file and a CUDA file inside the same program we an ODR violation. The reasons is that the C++ versions will say the tag is invalid, and the CUDA will say the tag is valid. The solution to this is that any compilation unit that includes DeviceAdapterTagCuda from a version of VTK-m that has CUDA enabled must be invoked by the cuda compiler.
2019-04-17 17:59:49 +00:00
return vtkm::testing::Testing::Run(DoTest, argc, argv);
Implement ArrayHandleGroupVecVariable This is a fancy array handle that can group entries in another array by arbitrary amounts. This allows us to implement input and output arrays with a different sized Vec for each instance. This is necessary for generating new topologies with cells of different types.
2016-10-28 03:14:29 +00:00
}
Reference in New Issue Copy Permalink