Open iarspider opened 8 months ago
assign heterogeneous
New categories assigned: heterogeneous
@fwyzard,@makortel you have been requested to review this Pull request/Issue and eventually sign? Thanks
cms-bot internal usage
A new Issue was created by @iarspider.
@makortel, @smuzaffar, @rappoccio, @sextonkennedy, @antoniovilela, @Dr15Jones can you please review it and eventually sign/assign? Thanks.
cms-bot commands are listed here
There seems to be some issue with signed/unsigned sizes and conversions:
.../gcc/12.3.1-40d504be6370b5a30e3947a6e575ca28/include/c++/12.3.1/bits/char_traits.h:435:57: warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)' accessing 9223372036854775810 or more bytes at offsets [2, 9223372036854775807] and 1 may overlap up to 9223372036854775813 bytes at offset -3 [-Wrestrict]
9223372036854775807
is 0x7FFFFFFFFFFFFFFF
,
9223372036854775810
is 0x8000000000000002
,
9223372036854775813
is 0x8000000000000005
I don't think we have such large buffers...
The line gcc complains about in the first error is
rtCheck<TApi, TThrow>(error, ("'" + std::string(cmd) + "' returned error ").c_str(), file, line);
What is wrong with it ?
The std
function in question is (I added a comment to highlight the line 435)
template<>
struct char_traits<char>
{
// ...
static _GLIBCXX20_CONSTEXPR char_type*
copy(char_type* __s1, const char_type* __s2, size_t __n)
{
if (__n == 0)
return __s1;
#if __cplusplus >= 202002L
if (std::__is_constant_evaluated())
return __gnu_cxx::char_traits<char_type>::copy(__s1, __s2, __n);
#endif
return static_cast<char_type*>(__builtin_memcpy(__s1, __s2, __n)); // <------ line 435
}
Given the large numbers, smells like a compiler bug.
See https://github.com/alpaka-group/alpaka/pull/2295 should soon be resolved in latest develop branch.
The line gcc complains about in the first error is
rtCheck<TApi, TThrow>(error, ("'" + std::string(cmd) + "' returned error ").c_str(), file, line);
What is wrong with it ?
Looking at it again: is the temporary returned by c_str()
guaranteed to be valid in this case ?
Answering myself: yes, it should be fine.
(just came across the warnings in a local area) Would it be worth for us to cherry-pick https://github.com/alpaka-group/alpaka/pull/2295? Or we wait for the Alpaka 1.2 and upgrade there in 14_2_X? (although that would leave the warnings in 14_1_X build logs)
We can cherry pick it, I think we are already using a dedicated branch anyway.
During compilation of HeterogeneousCore/AlpakaInterface module in CPP20 IBs log, the gcc emits the following warnings: