What is the if( ... ) below good for ?

template<bit_cursor_iterator BitIt>
constexpr uint64_t bit_cursor<BitIt>::dRead( uint64_t const &data ) noexcept
{ #if defined(__GNUC__) || defined(__llvm__)
if( (size_t)&data % 8 )
__builtin_unreachable();
#endif
uint64_t value;
memcpy( &value, &data, sizeof(uint64_t) );
return value;
}

On 2023-06-13 at 20:31, Bonita Montero wrote:
> What is the if( ... ) below good for ?
>
> template<bit_cursor_iterator BitIt>
> constexpr uint64_t bit_cursor<BitIt>::dRead( uint64_t const &data )
> noexcept
> {
> #if defined(__GNUC__) || defined(__llvm__)
>     if( (size_t)&data % 8 )
>         __builtin_unreachable();
> #endif
>     uint64_t value;
>     memcpy( &value, &data, sizeof(uint64_t) );
>     return value;
> }

It tells the compiler that the data is properly aligned. Possibly saves
a potential call to library memcpy to sort out unaligned bytes.

On 2023-06-13 8:36 PM, Bo Persson wrote:
> On 2023-06-13 at 20:31, Bonita Montero wrote:
>> What is the if( ... ) below good for ?
>>
>> template<bit_cursor_iterator BitIt>
>> constexpr uint64_t bit_cursor<BitIt>::dRead( uint64_t const &data )
>> noexcept
>> {
>> #if defined(__GNUC__) || defined(__llvm__)
>>      if( (size_t)&data % 8 )
>>          __builtin_unreachable();
>> #endif
>>      uint64_t value;
>>      memcpy( &value, &data, sizeof(uint64_t) );
>>      return value;
>> }
>
> It tells the compiler that the data is properly aligned. Possibly saves
> a potential call to library memcpy to sort out unaligned bytes.

But the function is nonsense, copying an `uint64_t` to `uint64_t`.

And with that in mind it doesn't matter that proper alignment is already
guaranteed via the types, i.e. that the alignment hint is nonsense
embedded in nonsense.

At a guess, the whole thing is probably wrapped in some nonsense at the
level where it's called, to make it Churchill-esque: nonsense containing
some nonsense wrapped in nonsense.

---

More constructively, the compiler-specific `__builtin_unreachable();`
can possibly be replaced with portable `for(;;){}`, which is formally UB
and thus tells the compiler to assume it will never be reached.

And the nonsensical `memcpy` can be replaced with safer assignment, `=`.

And the assignment can be replaced with initialization.

---

But then, the whole nonsensical shebang can be replaced with nothing,
and I guess that's worth keeping in mind in general.

- Alf

Am 14.06.2023 um 05:11 schrieb Alf P. Steinbach:

> But the function is nonsense, copying an `uint64_t` to `uint64_t`.

No, it isn't because the uint64_t is an aliased content.

On 2023-06-14 6:05 AM, Bonita Montero wrote:
> Am 14.06.2023 um 05:11 schrieb Alf P. Steinbach:
>
>> But the function is nonsense, copying an `uint64_t` to `uint64_t`.
>
> No, it isn't because the uint64_t is an aliased content.

It's copying an `uint64_t` that is known to be correctly aliased, to an
`uint64_t`; that's nonsense.

It's using `memcpy` instead of `=` for the copying; that's some nested
nonsense.

Maybe I should state this more clearly: it's retarded code.

- Alf

On 2023-06-14 7:52 AM, Alf P. Steinbach wrote:
> On 2023-06-14 6:05 AM, Bonita Montero wrote:
>> Am 14.06.2023 um 05:11 schrieb Alf P. Steinbach:
>>
>>> But the function is nonsense, copying an `uint64_t` to `uint64_t`.
>>
>> No, it isn't because the uint64_t is an aliased content.
>
> It's copying an `uint64_t` that is known to be correctly aliased, to an
> `uint64_t`; that's nonsense.

aligned, aligned. sry.

>
> It's using `memcpy` instead of `=` for the copying; that's some nested
> nonsense.
>
> Maybe I should state this more clearly: it's retarded code.
>
>
> - Alf
>

Am 14.06.2023 um 07:52 schrieb Alf P. Steinbach:

> It's copying an `uint64_t` that is known to be correctly aliased, to an
> `uint64_t`; that's nonsense.

The reference intitially supplied by the caller is casted from a char
-array. memcpy() is the only legal way in C++ to alias that content.

Am 13.06.2023 um 20:36 schrieb Bo Persson:

> On 2023-06-13 at 20:31, Bonita Montero wrote:

>> What is the if( ... ) below good for ?
>>
>> template<bit_cursor_iterator BitIt>
>> constexpr uint64_t bit_cursor<BitIt>::dRead( uint64_t const &data )
>> noexcept
>> {
>> #if defined(__GNUC__) || defined(__llvm__)
>>      if( (size_t)&data % 8 )
>>          __builtin_unreachable();
>> #endif
>>      uint64_t value;
>>      memcpy( &value, &data, sizeof(uint64_t) );
>>      return value;
>> }

> It tells the compiler that the data is properly aligned. Possibly
> saves a potential call to library memcpy to sort out unaligned bytes.

memcpy() is a partitially intrsinic function. I.e. if you want to copy
a static small amount of memory the compiler uses some moves; or even
copies the content directly to a register.
My bit_cursor is for having bit_field acess in a char-sized array. The
compiler can't guess that the address supplied to memcpy() is aligned,
so I give it a hint with the above code. Accoding to godbolt this works
with current clang++, but unfortunately not with g++ when you compile
code for RISC-V (unaligned acesses RISC-V are optional with RISC-V).

On 14/06/2023 07:56, Bonita Montero wrote:
> Am 14.06.2023 um 07:52 schrieb Alf P. Steinbach:
>
>> It's copying an `uint64_t` that is known to be correctly aliased, to
>> an `uint64_t`; that's nonsense.
>
> The reference intitially supplied by the caller is casted from a char
> -array. memcpy() is the only legal way in C++ to alias that content.
>

Well, you can also use std::byte as an alternative to memcpy. But
memcpy works for all standards.

On 14/06/2023 09:22, Bonita Montero wrote:
> Am 13.06.2023 um 20:36 schrieb Bo Persson:
>
>> On 2023-06-13 at 20:31, Bonita Montero wrote:
>
>>> What is the if( ... ) below good for ?
>>>
>>> template<bit_cursor_iterator BitIt>
>>> constexpr uint64_t bit_cursor<BitIt>::dRead( uint64_t const &data )
>>> noexcept
>>> {
>>> #if defined(__GNUC__) || defined(__llvm__)
>>>      if( (size_t)&data % 8 )
>>>          __builtin_unreachable();
>>> #endif
>>>      uint64_t value;
>>>      memcpy( &value, &data, sizeof(uint64_t) );
>>>      return value;
>>> }
>
>> It tells the compiler that the data is properly aligned. Possibly
>> saves a potential call to library memcpy to sort out unaligned bytes.
>
> memcpy() is a partitially intrsinic function. I.e. if you want to copy
> a static small amount of memory the compiler uses some moves;  or even
> copies the content directly to a register.

Note that this applies only to specific implementations of memcpy().
The function itself is a standard library function, and can be
implemented with whatever magic the compiler provides, but there is
absolutely no requirement for a given implementation to handle it as
inline or with any special optimisations.

Most decent compilers will, however, optimise memcpy() as inline when
given a small constant size for the number of bytes, and even omit it
entirely if it doesn't need to do anything in the generated code. (It
can still be useful for accessing data in ways that might be contrary to
the "strict aliasing" rules or alignment requirements, even when no code
is generated - as in this case.)

> My bit_cursor is for having bit_field acess in a char-sized array. The
> compiler can't guess that the address supplied to memcpy() is aligned,
> so I give it a hint with the above code. Accoding to godbolt this works
> with current clang++, but unfortunately not with g++ when you compile
> code for RISC-V (unaligned acesses RISC-V are optional with RISC-V).
>

I can understand the attempt, but it doesn't actually work. Look at the
generated code with godbolt.org.

First, it's worth noting that the use of "constexpr" here is wrong. Use
of uninitialised variables, memcpy and pointer casts are all naughty in
constexpr functions (later C++ standards are a little laxer than earlier
ones).

There is no need to test for "__llvm__" here when you test for
"__GNUC__", as clang/llvm also defines "__GNUC__". Your cast should be
to "uintptr_t", not "size_t". And if you want to be /really/ portable,
or at least consistent, you should use sizeof(uint64_t) instead of 8.
(All of gcc's targets have 8-bit char, so it is also not unreasonable to
use 8 everywhere instead of sizeof(uint64_t).)

Regarding the optimisation hint, you have a problem.
"__builtin_unreachable()" can /sometimes/ be used as an optimisation
hint, but it is not really the purpose of the builtin, and sometimes it
does not work as you expect. In particular, different passes of the
optimiser can make things work in different ways. So if you look at
32-bit ARM or 64-bit RISC-V, your code gives optimal results for -O1.
However, at -O2 the compiler is eliminating the unreachable part earlier
and losing that information, leading to slow unaligned load code.

The correct way to handle this kind of thing is __builtin_assume_unaligned :

uint64_t dRead2(const uint64_t &data) {
#if defined(__GNUC__) || defined(__llvm__)
uint64_t value;
const uint64_t * p = (const uint64_t * )
__builtin_assume_aligned (&data, sizeof(uint64_t);
memcpy( &value, p, sizeof(uint64_t) );
return value;
#else
uint64_t value;
memcpy( &value, &data, sizeof(uint64_t) );
return value;
#endif
}

<https://godbolt.org/z/P3oj1fzs9>

Still, it would be nice if your code was also optimised the way you
want, so I filed a missed-optimisation issue for gcc.

<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110249>

Am 14.06.2023 um 13:06 schrieb David Brown:

> Note that this applies only to specific implementations of memcpy(). ...

memcpy() is the only way to reliably alias something in C++ and
therefore it's safe to assume that it is partitially intrinsic.

> I can understand the attempt, but it doesn't actually work.
> Look at the generated code with godbolt.org.

I checked it for clang++ and RISC_V and the trick worked; without
it does eight loads to eight registers followes by eight stores
to an aligned entitity on the stack and a single load from the
stack. But this currently doesn't work with g++ and RISC-V.

> There is no need to test for "__llvm__" here when you test for
> "__GNUC__", as clang/llvm also defines "__GNUC__".  Your cast
> should be to "uintptr_t", not "size_t".

I use size_t because that's a safe assumption with flat memory.

> Regarding the optimisation hint, you have a problem.
> "__builtin_unreachable()" can /sometimes/ be used as
> an optimisation hint, ...

Check godbolt and RISC-V clang++.

On 14/06/2023 15:31, Bonita Montero wrote:
> Am 14.06.2023 um 13:06 schrieb David Brown:
>
>> Note that this applies only to specific implementations of memcpy(). ...
>
> memcpy() is the only way to reliably alias something in C++ and
> therefore it's safe to assume that it is partitially intrinsic.

That's not what "intrinsic" means. An "intrinsic" is basically a
wrapper function around a cpu-specific feature or instruction. So if
you want to use advanced SIMD instructions, you are likely to include a
header with macros (they are often macros, for use in C as much as C++)
defining these for a particular CPU family.

It is not long since memcpy() on MSVC was always implemented as a call
to an external library function in a DLL, which was a huge overhead for
such a simple feature.

And no, "memcpy" is /not/ the only way to access aliased data or access
data through pointers of non-compatible types. You can use any
character pointer, with pointers to unsigned char being particularly
useful. (This is precisely how "memcpy" is able to work.) std::byte is
a more modern C++ replacement for using unsigned char in such contexts.

I agree that memcpy is often the right choice here, and I agree that
most decent compilers will optimise it very well. But /some/ compilers
do a bad job of handling it.

>
>> I can understand the attempt, but it doesn't actually work.
>> Look at the generated code with godbolt.org.
>
> I checked it for clang++ and RISC_V and the trick worked; without
> it does eight loads to eight registers followes by eight stores
> to an aligned entitity on the stack and a single load from the
>  stack. But this currently doesn't work with g++ and RISC-V.
>

You did not check gcc.

You might have looked at the results for "-O1" optimisation, but you did
not look at the results for "-O2" optimisation.

I spend quite a bit of effort on the post I made to you, because I
thought it was an interesting case. I would appreciate it if you
actually read the post.

>> There is no need to test for "__llvm__" here when you test for
>> "__GNUC__", as clang/llvm also defines "__GNUC__".  Your cast
>> should be  to "uintptr_t", not "size_t".
>
> I use size_t because that's a safe assumption with flat memory.
>

It is still not the appropriate type. "uintptr_t" is the type for such
use-cases (even though it will almost certainly be implemented with the
same underlying integer type as size_t). The flatness of the memory is
irrelevant.

>> Regarding the optimisation hint, you have a problem.
>> "__builtin_unreachable()" can /sometimes/ be used as
>> an optimisation hint, ...
>
> Check godbolt and RISC-V clang++.
>

You did not look at gcc.

Writing code with a specific conditional compilation that explicitly
targets gcc, and then not testing properly for gcc, is just silly.

Did you try the godbolt link I sent?

Am 14.06.2023 um 16:36 schrieb David Brown:

> On 14/06/2023 15:31, Bonita Montero wrote:

>> memcpy() is the only way to reliably alias something in C++ and
>> therefore it's safe to assume that it is partitially intrinsic.

> That's not what "intrinsic" means. <rest unread>

For me it's partitially intrinsic.

> It is not long since memcpy() on MSVC was always implemented as a call
> to an external library function in a DLL, which was a huge overhead for
> such a simple feature.

Since it's the only way to have safe aliasing in C++ you can silently
rely on that.

> And no, "memcpy" is /not/ the only way to access aliased data or access
> data through pointers of non-compatible types.  You can use any
> character pointer, ...

In C you can alias anything as a char-array and vise versa,
but not in C++.

> You did not check gcc.

I checked it and this trick doesn't work with g++ / RISC-V
_with_ -O2 but I hope this will change, so I check for __GNUC__.

> It is still not the appropriate type. ...

For me it is because I use systems with flat memory. And in this case
I could even use a char since I only check for the three lower bits to
be zero.

David Brown <david.brown@hesbynett.no> writes:
>On 14/06/2023 15:31, Bonita Montero wrote:
>> Am 14.06.2023 um 13:06 schrieb David Brown:
>>
>>> Note that this applies only to specific implementations of memcpy(). ...
>>
>> memcpy() is the only way to reliably alias something in C++ and
>> therefore it's safe to assume that it is partitially intrinsic.
>
>That's not what "intrinsic" means. An "intrinsic" is basically a
>wrapper function around a cpu-specific feature or instruction.

FWIW, the HP-3000 MPE operating system interfaces (system calls) were called
"intrinsics".

Am 14.06.2023 um 17:14 schrieb Scott Lurndal:

> FWIW, the HP-3000 MPE operating system interfaces (system calls) were called
> "intrinsics".

An intrinsic is a function that directly maps to a processor instruc-
tion. That's holds true for memcpy() with small static sizes because
memcpy() is too important to be mapped to a library call for that.
Because if you're pedantic memcpy() is the only safe way to have
aliasing in C++.
In C you can alias anything as a char array and a char array as
anything so it would be safe to alias anything as anything with
double-casting (I guess that's correctly supported by the compilers).

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 14.06.2023 um 17:14 schrieb Scott Lurndal:
>
>> FWIW, the HP-3000 MPE operating system interfaces (system calls) were called
>> "intrinsics".
>
>An intrinsic is a function that directly maps to a processor instruc-
>tion.

You don't get to unilateraly determine anything, much less what an
"intrinsic" is.

On 2023-06-14 7:56 AM, Bonita Montero wrote:
> Am 14.06.2023 um 07:52 schrieb Alf P. Steinbach:
>
>> It's copying an `uint64_t` that is known to be correctly aliased, to
>> an `uint64_t`; that's nonsense.
>
> The reference intitially supplied by the caller is casted from a char
> -array. memcpy() is the only legal way in C++ to alias that content.

When that function is separately compiled in a different translation
unit, how is the compiler to know when compiling calling code that the
function uses `memcpy` internally,

and when compiling the function, how is the compiler to know that it's
generally called with a `*reinterpret_cast<uint64_t*>( p_bytes )` as
argument?

Answer: it doesn't know, in either case.

So generally (let's disregard global optimization with link time
compilation) `memcpy` versus `=` can't affect the outcome.

So for the separately compiled function it does not matter technically,
except possibly for performance, whether it uses clear, concise, safe
and guaranteed max efficient `=`, or verbose and unsafe `memcpy`.

That means that regarding this matter the common interpretation of the
standard is not technical but instead specifies a formal UB that can't
happen unless one informs a really perverse compiler that it's there.
Even g++'s documentation of `-fstrict-aliasing` says "A character type
may alias any other type.". So g++ is /not/ that perverse a compiler,
and I believe you won't find any sufficiently perverse compiler.

So in practice one can and should not accommodate the common standard
interpretation; it's nonsense, built on the assumption of magic effects.

Let the committee come up with their COBOL-inspired C++26 formal
solution. Let others waste their time trying to write then formally
correct COBOL++. I.e. just ignore all that; say no to nonsense.

- Alf

Am 14.06.2023 um 21:46 schrieb Alf P. Steinbach:

> When that function is separately compiled in a different translation
> unit, how is the compiler to know when compiling calling code that the
> function uses `memcpy` internally,

It doesn't matter if my function is inlined or not.

> So generally (let's disregard global optimization with link
> time compilation) `memcpy` versus `=` can't affect the outcome.

Thats not safe if you do aliasing.

Rest unread.

On 14/06/2023 16:46, Bonita Montero wrote:
> Am 14.06.2023 um 16:36 schrieb David Brown:
>
>> On 14/06/2023 15:31, Bonita Montero wrote:
>
>>> memcpy() is the only way to reliably alias something in C++ and
>>> therefore it's safe to assume that it is partitially intrinsic.
>
>> That's not what "intrinsic" means. <rest unread>
>
> For me it's partitially intrinsic.

Please don't use words like that in totally different ways from everyone
else.

>
>> It is not long since memcpy() on MSVC was always implemented as a call
>> to an external library function in a DLL, which was a huge overhead
>> for such a simple feature.
>
> Since it's the only way to have safe aliasing in C++ you can silently
> rely on that.
>

You said that before - you are still wrong.

>> And no, "memcpy" is /not/ the only way to access aliased data or
>> access data through pointers of non-compatible types.  You can use any
>> character pointer, ...
>
> In C you can alias anything as a char-array and vise versa,
> but not in C++.

<https://en.cppreference.com/w/cpp/language/reinterpret_cast#Type_aliasing>

<https://en.cppreference.com/w/cpp/types/byte>

Look it up in the standards if you prefer.

>
>> You did not check gcc.
>
> I checked it and this trick doesn't work with g++ / RISC-V
> _with_ -O2 but I hope this will change, so I check for __GNUC__.
>

Finally you have managed to check it, and found - as I told you at the
start - that it does not work for -O2. (Not for RISC-V, and not for any
other target that makes a distinction between aligned and unaligned
accesses.)

While I too hope this will change (that's why I registered it as a bug),
the sane thing to do is write the code properly using the correct gcc
extension for the purpose - __builtin_assume_aligned - as I suggested.

>> It is still not the appropriate type. ...
>
> For me it is because I use systems with flat memory. And in this case
> I could even use a char since I only check for the three lower bits to
> be zero.
>

No, it is still the wrong type regardless of the memory flatness.

It is really very simple. "size_t" is a type used for the size of
objects. "uintptr_t" is a type used for converting pointers to unsigned
integers. Use the correct type. You have /nothing/ to gain by using
the wrong type here other than a reputation for being stubborn in your
insistence on writing pointlessly odd code.

On 14/06/2023 17:14, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 14/06/2023 15:31, Bonita Montero wrote:
>>> Am 14.06.2023 um 13:06 schrieb David Brown:
>>>
>>>> Note that this applies only to specific implementations of memcpy(). ...
>>>
>>> memcpy() is the only way to reliably alias something in C++ and
>>> therefore it's safe to assume that it is partitially intrinsic.
>>
>> That's not what "intrinsic" means. An "intrinsic" is basically a
>> wrapper function around a cpu-specific feature or instruction.
>
> FWIW, the HP-3000 MPE operating system interfaces (system calls) were called
> "intrinsics".

It is not uncommon for system calls to be handled by embedded assembly
instructions for software interrupts. You could also argue that the
system calls are native to the target but not to the C (or C++)
language, just like assembly instructions, and can justifiably be called
"intrinsics".

"memcpy", on the other hand, is no more "intrinsic" than any other
standard library function.

On 6/14/23 15:46, Alf P. Steinbach wrote:
> On 2023-06-14 7:56 AM, Bonita Montero wrote:
>> Am 14.06.2023 um 07:52 schrieb Alf P. Steinbach:
>>
>>> It's copying an `uint64_t` that is known to be correctly aliased, to
>>> an `uint64_t`; that's nonsense.
>>
>> The reference intitially supplied by the caller is casted from a char
>> -array. memcpy() is the only legal way in C++ to alias that content.
....
> So for the separately compiled function it does not matter technically,
> except possibly for performance, whether it uses clear, concise, safe
> and guaranteed max efficient `=`, or verbose and unsafe `memcpy`.
>
> That means that regarding this matter the common interpretation of the
> standard is not technical but instead specifies a formal UB that can't
> happen unless one informs a really perverse compiler that it's there.

All you need is a platform where misaligned pointers do not merely cause
the code to be inefficient, but to actually malfunction. On such a
platform, if p_bytes is not correctly aligned to store a uint64_t, then
the code will malfunction in the reinterpret_cast<>.

"When a prvalue v of object pointer type is converted to the object
pointer type “pointer to cv T”, the result is
static_cast<cv T*>(static_cast<cv void*>(v))." (7.6.1.9p7)

"A prvalue of type “pointer to cv1 void” can be converted to a prvalue
of type “pointer to cv2 T”, where T is an object type and cv2 is the
same cv-qualification as, or greater cv-qualification than, cv1. If the
original pointer value represents the address A of a byte in memory and
A does not satisfy the alignment requirement of T, then the resulting
pointer value is unspecified." (7.6.1.8p13).

In particular, because the pointer value is unspecified, it's not
guaranteed to be dereferenceable. A common possibility is that the
result of the conversion will be a pointer to the nearest preceding or
following correctly aligned location.

If p_bytes is correctly aligned, simple assignment will work just as
well as memcpy().

> Even g++'s documentation of `-fstrict-aliasing` says "A character type
> may alias any other type.". ...

True, but that's not what this reinterpret_cast does; it aliases a
character type with uint64_t, and that a problem if pbytes is not
correctly aligned to hold a uint64_t. The anti-aliasing rules are not
symmetric.

David Brown <david.brown@hesbynett.no> writes:
>On 14/06/2023 17:14, Scott Lurndal wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 14/06/2023 15:31, Bonita Montero wrote:
>>>> Am 14.06.2023 um 13:06 schrieb David Brown:
>>>>
>>>>> Note that this applies only to specific implementations of memcpy(). ...
>>>>
>>>> memcpy() is the only way to reliably alias something in C++ and
>>>> therefore it's safe to assume that it is partitially intrinsic.
>>>
>>> That's not what "intrinsic" means. An "intrinsic" is basically a
>>> wrapper function around a cpu-specific feature or instruction.
>>
>> FWIW, the HP-3000 MPE operating system interfaces (system calls) were called
>> "intrinsics".
>
>It is not uncommon for system calls to be handled by embedded assembly
>instructions for software interrupts.

In this case, it was more generic than that, since:

1) The HP-3000 didn't have an assembler
2) Intrinsic calls were just function calls into a different segment
(a stack architecture similar to the Burroughs systems).

On 6/14/2023 3:27 PM, James Kuyper wrote:
> On 6/14/23 15:46, Alf P. Steinbach wrote:
>> On 2023-06-14 7:56 AM, Bonita Montero wrote:
>>> Am 14.06.2023 um 07:52 schrieb Alf P. Steinbach:
>>>
>>>> It's copying an `uint64_t` that is known to be correctly aliased, to
>>>> an `uint64_t`; that's nonsense.
>>>
>>> The reference intitially supplied by the caller is casted from a char
>>> -array. memcpy() is the only legal way in C++ to alias that content.
> ...
>> So for the separately compiled function it does not matter technically,
>> except possibly for performance, whether it uses clear, concise, safe
>> and guaranteed max efficient `=`, or verbose and unsafe `memcpy`.
>>
>> That means that regarding this matter the common interpretation of the
>> standard is not technical but instead specifies a formal UB that can't
>> happen unless one informs a really perverse compiler that it's there.
>
> All you need is a platform where misaligned pointers do not merely cause
> the code to be inefficient, but to actually malfunction. On such a
> platform, if p_bytes is not correctly aligned to store a uint64_t, then
> the code will malfunction in the reinterpret_cast<>.
[...]

What about some code that crosses a L2 cache line boundary and causes
the damn processor to assert a bus lock... Argh!

On 15/06/2023 00:27, James Kuyper wrote:
> On 6/14/23 15:46, Alf P. Steinbach wrote:
>> On 2023-06-14 7:56 AM, Bonita Montero wrote:
>>> Am 14.06.2023 um 07:52 schrieb Alf P. Steinbach:
>>>
>>>> It's copying an `uint64_t` that is known to be correctly aliased, to
>>>> an `uint64_t`; that's nonsense.
>>>
>>> The reference intitially supplied by the caller is casted from a char
>>> -array. memcpy() is the only legal way in C++ to alias that content.
> ...
>> So for the separately compiled function it does not matter technically,
>> except possibly for performance, whether it uses clear, concise, safe
>> and guaranteed max efficient `=`, or verbose and unsafe `memcpy`.
>>
>> That means that regarding this matter the common interpretation of the
>> standard is not technical but instead specifies a formal UB that can't
>> happen unless one informs a really perverse compiler that it's there.
>
> All you need is a platform where misaligned pointers do not merely cause
> the code to be inefficient, but to actually malfunction. On such a
> platform, if p_bytes is not correctly aligned to store a uint64_t, then
> the code will malfunction in the reinterpret_cast<>.
>
And in case anyone has doubts, such platforms do exist. I have used
embedded microcontrollers in which an unaligned access might mean access
to the address rounded down (i.e., a 16-bit store to 0x2001 actually
stores 16 bits at 0x2000). The stored data may or may not be
byte-swapped - the behaviour is undefined, and I don't think it was
consistent between different generations of the processor.

There are also big processors which will fault on unaligned accesses.
Even if there are OS services in place to simulate the access, the
process is so massively slower than normal accesses that it could be
considered a software malfunction for performance critical code.

On 14/06/2023 21:46, Alf P. Steinbach wrote:
> On 2023-06-14 7:56 AM, Bonita Montero wrote:
>> Am 14.06.2023 um 07:52 schrieb Alf P. Steinbach:
>>
>>> It's copying an `uint64_t` that is known to be correctly aliased, to
>>> an `uint64_t`; that's nonsense.
>>
>> The reference intitially supplied by the caller is casted from a char
>> -array. memcpy() is the only legal way in C++ to alias that content.
>
> When that function is separately compiled in a different translation
> unit, how is the compiler to know when compiling calling code that the
> function uses `memcpy` internally,
>
> and when compiling the function, how is the compiler to know that it's
> generally called with a `*reinterpret_cast<uint64_t*>( p_bytes )` as
> argument?
>
> Answer: it doesn't know, in either case.
>
> So generally (let's disregard global optimization with link time
> compilation) `memcpy` versus `=` can't affect the outcome.
>
> So for the separately compiled function it does not matter technically,
> except possibly for performance, whether it uses clear, concise, safe
> and guaranteed max efficient `=`, or verbose and unsafe `memcpy`.
>

Code that relies on limited optimisation or separate compilation for
correct behaviour, is an extremely bad idea - it is fragile and a hidden
bug waiting to explode in the future. Shortcuts now will cost dearly
later on. Take pride in your work, and code responsibly - do what you
can to make your code /correct/, rather than relying on weak tools!