intel
info::device::atomic64 is deprecated
- A separate .def file was created for deprecated features that are not part of SYCL 2020 spec
- info::device::atomic64 was deprecated
- Test for info::device::atomic64 deprecated was added into separate file due to -Wno-deprecated-declarations flag in warnings.cpp tests file.
Test for info::device::atomic64 deprecated was added into separate file due to -Wno-deprecated-declarations flag in warnings.cpp tests file.
Just curious - did you try warnings.cpp actually? Not sure, but I think I tried it sometime ago and there was no need for a separate test.
UPD. I've likely tried another test - test/warnings/sycl_2020_deprecations.cpp. You can try updating it instead of creating a separate one. I'd also suggest to update our code, so we don't use this deprecated query.
Just curious - did you try warnings.cpp actually? Not sure, but I think I tried it sometime ago and there was no need for a separate test.
warnings.cpp is focused on sycl.hpp being warning-free on its own, it is not for checking that right diagnostics are emitted
UPD. I've likely tried another test - test/warnings/sycl_2020_deprecations.cpp. You can try updating it instead of creating a separate one.
That is not a SYCL 2020 deprecation, that deprecation does not depend on the language version, so I think that a separate test is better.
I'd also suggest to update our code, so we don't use this deprecated query.
That's a good point! warnings.cpp should be updated to fail unless this is fixed to ensure that we also cover this use case. I suppose that not all code paths may produce warnings, simply because we don't instantiate those templates in the test.
I'd also suggest to update our code, so we don't use this deprecated query.
That's a good point!
warnings.cppshould be updated to fail unless this is fixed to ensure that we also cover this use case. I suppose that not all code paths may produce warnings, simply because we don't instantiate those templates in the test.
I've realized the the call we perform happens within the library, so it doesn't affect public headers and can't be checked by warnings.cpp. I agree with Nikita that we should address it (most likely our -Werror build in post-commit will fail otherwise), but please disregard the comment about updating warnings.cpp
@cperkinsintel, @intel/llvm-reviewers-runtime, could you please take a look?