Am 16.06.2023 um 23:16 schrieb james...@alumni.caltech.edu:

> ... The memcpy() would only be reasonable if it were possible
> for "data' to be a misaligned pointer; otherwise simple assignment
> would be simpler and equally safe.

I'm aliasing a char-array.

On 2023-06-17 7:57 PM, David Brown wrote:
> On 17/06/2023 00:17, Alf P. Steinbach wrote:
>> On 2023-06-16 11:16 PM, james...@alumni.caltech.edu wrote:
>>> On Friday, June 16, 2023 at 2:48:24 AM UTC-4, Alf P. Steinbach wrote:
>>>> On 2023-06-15 12:27 AM, James Kuyper wrote:
>>>>> On 6/14/23 15:46, Alf P. Steinbach wrote:
>>> ...
>>>>> 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<>.
>>>> Yes, but irrelevant for the case discussed, because the values are
>>>> guaranteed correctly aligned.
>>>
>>> You said nothing about what p_bytes was when you asked
>>>
>>> "how is the compiler to know that it's generally called with a
>>> `*reinterpret_cast<uint64_t*>( p_bytes )` as argument?"
>>>
>>> In particular, you said nothing about p_bytes that would guarantee
>>> that it was
>>> correctly aligned.
>>
>> That was known from the optimization attempt in the original posting's
>> code (I'm not the OP):
>>
>>      #if defined(__GNUC__) || defined(__llvm__)
>>          if( (size_t)&data % 8 )
>>              __builtin_unreachable();
>>      #endif
>>
>>
>>> The memcpy() would only be reasonable if it were possible
>>> for "data' to be a misaligned pointer; otherwise simple assignment
>>> would be
>>> simpler and equally safe.
>>
>> On that we agree. :)
>
> If we knew that the original pointer pointed to a uint64_t, then we
> could /all/ agree that a plain assignment would be simpler, clearer, and
> as efficient as possible.
>
> But as far as I know, no such guarantee exists.  My guess, from how
> functions like this are sometimes used, is that the original data is in
> an array of unsigned char - perhaps a buffer for a received network
> packet or a file that has been read.
>
> And if the data does not start as a uint64_t (or compatible type), then
> reading it through a uint64_t glvalue is /not/ safe, even if alignment
> is guaranteed.
>
>>
>>
>>>> [snip]
>>>>> If p_bytes is correctly aligned, simple assignment will work just as
>>>>> well as memcpy().
>>>> Yes.
>>>>>> 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 is what this `reinterpret_cast` does.
>>>
>>> This reinterpret_cast converts p_bytes, which presumably points to the
>>> first element of an array of character type, into a pointer to
>>> uint64_t*. In
>>> other words, an array of char is being aliased as a uint64_t. Are you
>>> claiming that uint64_t is a character type?
>>
>> It may be that my English isn't good enough to understand a one-way
>> nature of the GCC docs' wording.
>>
>
> The "cppreference" site is often clearer than the standards language:
>
> <https://en.cppreference.com/w/cpp/language/reinterpret_cast#Type_aliasing>
>
> The key point is that a reinterpret_cast (or equivalent via a C-style
> cast) does not let you access incompatible types.  It does not, in gcc
> parlance, side-step the strict aliasing rules.
>
> Like a C cast, reinterpret_cast is a way to tell the compiler that you
> think it is safe to change the type of an object (usually a pointer).
> But it does not /make/ it safe.  And if the compiler can see that the
> actual object type is not compatible with the way you are accessing it,
> then you have a conflict - you are lying to the compiler, and no good
> will come of it.  A reinterpret_cast will not change that situation.
> (And separate compilation will only hide the problem.)
>
>
>> Perhaps.
>>
>> The way I think, aliasing is of interest to the compiler because where
>> it can assume that a T value is never changed via a U* pointer, and
>> that the value that the U* points to is never changed by a change to
>> the T value, it can optimize, e.g. not reload that value from memory
>> when it's already in a register. If T = float and U* = int*, then it
>> can make this assumption. Similarly if T = int and U* = float*, it can
>> assume this.
>>
>
> Yes.
>
>> But if T = char-type, such as the first char in an array, and U* is a
>> double*, then it can not reasonably make this assumption, and as I
>> read the docs quote g++ doesn't make this assumption for T = char-type.
>>
>
> No.  You can use a char-type pointer to access a non-char object, but
> you cannot use a non-char pointer to access a char (array) object.

Assuming no padding bits, which for clarity is not checked (AFAIK there
is no extant compiler that introduces padding bits):

#include <new>
#include <assert.h>
#include <stdio.h>

auto main() -> int
{
alignas( int ) char chars[sizeof( int )] = {};
int* const p = std::launder( new( (void*) chars ) int );
assert( *p == 0 );
chars[0] = 42;
printf( "This system is %s-endian.\n", (*p == 42)? "little" :
"big" );
}

One possible way to reconcile that working example with your assertion
"cannot" is that in your view the `*p` expressions do not access the
character array but the `double` object that resides there.

If that is the case then the assertion is meaningless nonsense,
consistent with your sequence of self-contradictions in this thread.

[snip]

- Alf

On 17/06/2023 20:37, Alf P. Steinbach wrote:
> On 2023-06-17 7:57 PM, David Brown wrote:

>> No.  You can use a char-type pointer to access a non-char object, but
>> you cannot use a non-char pointer to access a char (array) object.
>
> Assuming no padding bits, which for clarity is not checked (AFAIK there
> is no extant compiler that introduces padding bits):
>
>     #include <new>
>     #include <assert.h>
>     #include <stdio.h>
>
>     auto main() -> int
>     {
>         alignas( int ) char chars[sizeof( int )] = {};
>         int* const p = std::launder( new( (void*) chars ) int );
>         assert( *p == 0 );
>         chars[0] = 42;
>         printf( "This system is %s-endian.\n", (*p == 42)? "little" :
> "big" );
>     }
>
> One possible way to reconcile that working example with your assertion
> "cannot" is that in your view the `*p` expressions do not access the
> character array but the `double` object that resides there.

It is an int, in your example, not a double, but otherwise that is
/exactly/ what happens. *p is accessing the int object, not a char array.

Then "chars[0] = 42;" is using a character pointer to access the memory
used for storing an int.

<https://en.cppreference.com/w/cpp/utility/launder>

>
> If that is the case then the assertion is meaningless nonsense,
> consistent with your sequence of self-contradictions in this thread.
>

I haven't contradicted myself - I have only contradicted you.

On 16/06/2023 19:27, Alf P. Steinbach wrote:
> On 2023-06-16 6:32 PM, David Brown wrote:
> [snip]
>>>>
>>>> A "uint64_t" has a guaranteed fully-defined format and no padding bits.
> [snip]
>> The C++ standards change their numbering regularly.  These numbers are
>> from the C++20 draft N4860 - I don't believe the contents change much
>> between versions.
>>
>> 6.8.1p3 .. p5 describes the representation of unsigned types as
>> collections of bits representing powers of 2.  For unsigned integer
>> types in general, there may be padding bits, but there are no padding
>> bits in char, signed char, unsigned char and char8_t.
>
> [snip]
>
>> The ball is in your court.
>
> In the above you contradict yourself:

Your English is better than most native speakers - but you have to /try/
to read and understand posts. It is your comprehension that is at
fault, and I suspect also your assumptions about C and C++. (To be
fair, many of your assumptions are true in all realistic implementations
in the modern world.)

>
> * First you claim that there are no padding bits for `uint64_t`.

Correct. That's what the C standard says, and that's what the C++
standard says by delegation to the C standard.

> * Then you paraphrase the standard that "there may be padding bits".

You asked for references - I gave them. Look them up. You will see
that in general, unsigned integer types (other than unsigned char) may
have padding bits. Only specific types such as the size-specific types
in <stdint.h> are guaranteed not to have padding bits - /if/ they exist.
An implementation might not support these non-padded types at all. It
might support them as extended integer types, and have padding bits in
the standard integer types. It might have lots of unsigned types - some
with padding, some without.

But uint64_t and the other size-specific unsigned types are guaranteed
not to have padding.

>
> I elected now to not quote or respond to the rest which likewise
> involved some self-contradictions.
>

On 2023-06-18 12:30 AM, David Brown wrote:
> On 17/06/2023 20:37, Alf P. Steinbach wrote:
>> On 2023-06-17 7:57 PM, David Brown wrote:
>
>>> No.  You can use a char-type pointer to access a non-char object, but
>>> you cannot use a non-char pointer to access a char (array) object.
>>
>> Assuming no padding bits, which for clarity is not checked (AFAIK
>> there is no extant compiler that introduces padding bits):
>>
>>      #include <new>
>>      #include <assert.h>
>>      #include <stdio.h>
>>
>>      auto main() -> int
>>      {
>>          alignas( int ) char chars[sizeof( int )] = {};
>>          int* const p = std::launder( new( (void*) chars ) int );
>>          assert( *p == 0 );
>>          chars[0] = 42;
>>          printf( "This system is %s-endian.\n", (*p == 42)? "little" :
>> "big" );
>>      }
>>
>> One possible way to reconcile that working example with your assertion
>> "cannot" is that in your view the `*p` expressions do not access the
>> character array but the `double` object that resides there.
>
> It is an int, in your example, not a double, but otherwise that is
> /exactly/ what happens.  *p is accessing the int object, not a char array.
>
> Then "chars[0] = 42;" is using a character pointer to access the memory
> used for storing an int.
>
> <https://en.cppreference.com/w/cpp/utility/launder>
>
>>
>> If that is the case then the assertion is meaningless nonsense,
>> consistent with your sequence of self-contradictions in this thread.
>>
>
> I haven't contradicted myself - I have only contradicted you.

Well I give up, as usual when I encounter strong religious beliefs with
argumentation consisting of self-contradictions, denials and advice.

- Alf

On 6/16/23 18:17, Alf P. Steinbach wrote:
> On 2023-06-16 11:16 PM, james...@alumni.caltech.edu wrote:
>> On Friday, June 16, 2023 at 2:48:24 AM UTC-4, Alf P. Steinbach wrote:
>>> On 2023-06-15 12:27 AM, James Kuyper wrote:
>>>> On 6/14/23 15:46, Alf P. Steinbach wrote:
>> ...
>>>> 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<>.
>>> Yes, but irrelevant for the case discussed, because the values are
>>> guaranteed correctly aligned.
>>
>> You said nothing about what p_bytes was when you asked
>>
>> "how is the compiler to know that it's generally called with a
>> `*reinterpret_cast<uint64_t*>( p_bytes )` as argument?"
>>
>> In particular, you said nothing about p_bytes that would guarantee
>> that it was
>> correctly aligned.
>
> That was known from the optimization attempt in the original posting's
> code (I'm not the OP):
>
> #if defined(__GNUC__) || defined(__llvm__)
> if( (size_t)&data % 8 )
> __builtin_unreachable();
> #endif

How is that supposed to help? On platforms where misaligned access
doesn't just cause inefficiency, but actually is a serious problem, the
unspecified result of the reinterpret_cast<> of a mis-aligned pointer
can be, and often is, a correctly aligned pointer which, therefore,
necessarily points at a different location in memory. It is quite
frequently one of the two nearest correctly aligned pointers. The result
of such a conversion would pass that test, and as a result it would
memcpy() from the wrong location.

>>> [snip]
>>>> If p_bytes is correctly aligned, simple assignment will work just as
>>>> well as memcpy().
>>> Yes.
>>>>> 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 is what this `reinterpret_cast` does.
>>
>> This reinterpret_cast converts p_bytes, which presumably points to the
>> first element of an array of character type, into a pointer to
>> uint64_t*. In
>> other words, an array of char is being aliased as a uint64_t. Are you
>> claiming that uint64_t is a character type?
>
> It may be that my English isn't good enough to understand a one-way
> nature of the GCC docs' wording.

I was responding to a statement about both the C and the C++ standards.
The GCC docs merely reword the relevant clauses of the standards.
Insofar as gcc claims standard conformance, the wording of those
standards is more authoritative than GCC's docs.

The C standard's wording is quite explicitly asymmetrical. It
distinguishes between the effective type of an object, and of the lvalue
that is used to access it. The effective type of the object, in this
case, is an array of character type. The lvalue is uint64_t. There is a
special case that allows the lvalue to have a character type regardless
of the effective type; there is no special case that allows the
effective type to be an array of character when the lvalue's type isn't
also an array of character.

The relevant section of the C++ standard is 7.2.1p11 (in n4860.pdf). It
uses the term "dynamic type" instead of "effective type", and "glvalue"
rather than "lvalue", and is assymetrical in the same way: it has an
exception that allows the glvalue to be "char, unsigned char, or
std::byte" regardless of the dynamic type. It has no exception that
allows the dynamic type be an array of one of those types unless the
glvalue is also such an array.

....
> The way I think, aliasing is of interest to the compiler because where
> it can assume that a T value is never changed via a U* pointer, and
> that the value that the U* points to is never changed by a change to
> the T value, it can optimize, e.g. not reload that value from memory
> when it's already in a register. If T = float and U* = int*, then it
> can make this assumption. Similarly if T = int and U* = float*, it can
> assume this.

That is one relevant issue, but it ignores the alignment issue, which is
also a barrier to aliasing, and an inherently asymmetric one.

On 16/06/2023 20:06, Keith Thompson wrote:
> "Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes:
>> On 2023-06-16 10:55 AM, David Brown wrote:
>>> On 16/06/2023 08:59, Alf P. Steinbach wrote:
>>>>
>>>> `memcpy` is not the safest tool around. It's rather the opposite,
>>>> something to avoid /if possible/. `memcpy` is the "weak tool" here.
>>>>
>>> I don't know how the function here is supposed to be used.  We know
>>> that the pointer (it is syntactically a reference, but effectively a
>>> pointer) is properly aligned for a uint64_t, but we don't know if it
>>> actually points to a uint64_t.  Perhaps it points to a double, or
>>> some other 64-bit type.
>>
>> In the case you sketch where the bits do not represent a valid
>> `uint64_t`, the `memcpy` does not make the behavior well-defined:
>> that's a (dangerous) misconception.
>
> I think David was suggesting, not the bits are not a valid
> representation for an object of type uint64_t, but that for example the
> pointer point to an object whose type is, say, double. (I haven't
> followed the discussion closely enough to have an opinion on whether
> that matters.)
>

All I am saying, is that if you have a double in memory somewhere, and
you have a pointer-to-uint64_t that happens to contain the address of
the double, you can't use that pointer to access the double without
invoking undefined behaviour. Alignment is not the main problem here
(it is not a problem at all if the double has a valid alignment for a
uint64_t). It is the effective type (C), dynamic type (C++) or strict
aliasing rules (gcc) that are the problem.

Moving parts of the code to separate compilation, as Alf suggested, does
not help. reinterpret_cast<> does not help. std::launder, another of
Alf's suggestions, does not help either if you want to read the double
as an uint64_t. (You can use std::launder to create a new uint64_t in
the space the double occupied, but not to let you read the existing
data. I believe that std::launder was so rarely used appropriately, and
so often used incorrectly, that there are plans to remove it from C++.)

memcpy(), on the other hand, /will/ let you access the memory safely and
with well-defined behaviour. This is why the OP's original code will
work correctly. It was merely the optimisation in that code that was
not as good as it could easily have been.

On 18/06/2023 01:11, Alf P. Steinbach wrote:
> On 2023-06-18 12:30 AM, David Brown wrote:

>> I haven't contradicted myself - I have only contradicted you.
>
> Well I give up, as usual when I encounter strong religious beliefs with
> argumentation consisting of self-contradictions, denials and advice.
>

I strongly resent the accusation of "religious" beliefs here. I put
considerable effort into trying to understand the details of the C and
C++ languages, both the theoretical aspects from the standards, and the
practical aspects of how the languages are implemented in practice. If
my understanding is incorrect, I like to be told, and learn from that.
I have done so many, many times over the years in this group (and c.l.c.).

I still have no idea what you are talking about when you say I am
contradicting myself. None. Not a clue. If you told me - I have asked
you to do so - then we might make progress. But no, you would rather
repeat your claims without proof or explanation - /that/ is
religious-style posting.

On 13/06/2023 19:36, 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.
>
Coming in late to this, but having read the thread through -
It tells the compiler the data is aligned on an 8 word boundary.

I say word, because while almost all computers have byte addressing it
is not 100% (the first one I learned assembler on had 36-bit addressing
- and I didn't use C on it).

And even when it is 8-bit addressing this could be an excessive check,
for example on a machine with a 32 bit native word size.

Andy

Vir Campestris <vir.campestris@invalid.invalid> writes:
> On 13/06/2023 19:36, 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.
>>
> Coming in late to this, but having read the thread through -
> It tells the compiler the data is aligned on an 8 word boundary.
>
> I say word, because while almost all computers have byte addressing it
> is not 100% (the first one I learned assembler on had 36-bit
> addressing - and I didn't use C on it).

C++, as far as I know, doesn't define what a "word" is, and
doesn't use that term. It does define a "byte" to be CHAR_BIT
bits, where CHAR_BIT >= 8. An implementation for a system with
36-bit addressing might either define CHAR_BIT==36 or CHAR_BIT==9
with byte level accesses implemented in software. (And such an
implementation would not define uint64_t.)

sizeof (uint64_t) is most likely 8, but it could be 4, 2, or 1.

> And even when it is 8-bit addressing this could be an excessive check,
> for example on a machine with a 32 bit native word size.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 2023-06-18 7:10 AM, james...@alumni.caltech.edu wrote:
> On 6/16/23 18:17, Alf P. Steinbach wrote:
>> On 2023-06-16 11:16 PM, james...@alumni.caltech.edu wrote:
>>> On Friday, June 16, 2023 at 2:48:24 AM UTC-4, Alf P. Steinbach wrote:
>>>> On 2023-06-15 12:27 AM, James Kuyper wrote:
>>>>> On 6/14/23 15:46, Alf P. Steinbach wrote:
>>> ...
>>>>> 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<>.
>>>> Yes, but irrelevant for the case discussed, because the values are
>>>> guaranteed correctly aligned.
>>>
>>> You said nothing about what p_bytes was when you asked
>>>
>>> "how is the compiler to know that it's generally called with a
>>> `*reinterpret_cast<uint64_t*>( p_bytes )` as argument?"
>>>
>>> In particular, you said nothing about p_bytes that would guarantee
>>> that it was
>>> correctly aligned.
>>
>> That was known from the optimization attempt in the original posting's
>> code (I'm not the OP):
>>
>> #if defined(__GNUC__) || defined(__llvm__)
>> if( (size_t)&data % 8 )
>> __builtin_unreachable();
>> #endif
>
> How is that supposed to help?

Regarding the cast to `size_t` you'd have to ask the original coder,
which is not necessarily even the original poster, which isn't me.

However, presumably you're asking how that quote is meant to help you
understand that there is an assumption of correct alignment.

That's because with incorrect alignment execution (with GCC and clang)
reaches `__builtin_unreachable`, which is UB by definition. This allows
the compiler to optimize /as if/ correct alignment is guaranteed. Thus
the quoted code explicitly expresses that assumption.

> On platforms where misaligned access
> doesn't just cause inefficiency, but actually is a serious problem, the
> unspecified result of the reinterpret_cast<> of a mis-aligned pointer
> can be, and often is, a correctly aligned pointer which, therefore,
> necessarily points at a different location in memory. It is quite
> frequently one of the two nearest correctly aligned pointers. The result
> of such a conversion would pass that test, and as a result it would
> memcpy() from the wrong location.

Yes that's trivially true: breaking an assumption can have dire
consequences.

However, /mentioning/ that indicates some relevance to something.

And AFAICS there is no relevance to anything.

[snip]

- Alf

On 6/19/23 10:43, Alf P. Steinbach wrote:
> On 2023-06-18 7:10 AM, james...@alumni.caltech.edu wrote:
>> On 6/16/23 18:17, Alf P. Steinbach wrote:
>>> On 2023-06-16 11:16 PM, james...@alumni.caltech.edu wrote:
>>>> On Friday, June 16, 2023 at 2:48:24 AM UTC-4, Alf P. Steinbach wrote:
>>>>> On 2023-06-15 12:27 AM, James Kuyper wrote:
>>>>>> On 6/14/23 15:46, Alf P. Steinbach wrote:
>>>> ...
>>>>>> 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<>.
>>>>> Yes, but irrelevant for the case discussed, because the values are
>>>>> guaranteed correctly aligned.
>>>>
>>>> You said nothing about what p_bytes was when you asked
>>>>
>>>> "how is the compiler to know that it's generally called with a
>>>> `*reinterpret_cast<uint64_t*>( p_bytes )` as argument?"
>>>>
>>>> In particular, you said nothing about p_bytes that would guarantee
>>>> that it was
>>>> correctly aligned.
>>>
>>> That was known from the optimization attempt in the original posting's
>>> code (I'm not the OP):
>>>
>>> #if defined(__GNUC__) || defined(__llvm__)
>>> if( (size_t)&data % 8 )
>>> __builtin_unreachable();
>>> #endif
>>
>> How is that supposed to help?
>
> Regarding the cast to `size_t` you'd have to ask the original coder,
> which is not necessarily even the original poster, which isn't me.

That is not the point I was discussing, which you might reasonably have
concluded from the fact that I didn't even mention size_t or [u]intptr_t.

I agree that it is the wrong type, but other people have already
addressed that issue more than adequately. I don't normally respond to
the original poster, for reasons that should be abundantly clear by
looking at how she responded to discussions of that issue. Keep in mind
that she's apparently not the person who wrote the code, she just ran
into it and is trying to figure it out.

> However, presumably you're asking how that quote is meant to help you
> understand that there is an assumption of correct alignment.

Nope. I'm not how I'm supposed to figure out that that assumption was
made. That's trivial. I'm asking why you think the assumption is
guaranteed to be true. See above, where you say "the values are
guaranteed correctly aligned".

> That's because with incorrect alignment execution (with GCC and clang)
> reaches `__builtin_unreachable`, which is UB by definition. This allows
> the compiler to optimize /as if/ correct alignment is guaranteed. Thus
> the quoted code explicitly expresses that assumption.

So, this is designed to make the compiler generate code that is
optimized for correctly aligned pointers, which is valuable on a
platform where mis-aligned access is merely slower than correctly
aligned access. It doesn't do anything useful on a platform where
mis-aligned pointers simply cannot be safely dereferenced. Nor does it
do any good on platforms where uint64_t* is incapable of representing an
address that is mis-aligned, so the reinterpret_cast<> is guaranteed to
produce a pointer that points at a different location in memory.

The fact that you don't work on such platforms doesn't change the fact
that such platforms exist, and it doesn't negate the C and C++
committees' decisions to write the two standards in such a way as to
allow fully conforming implementations on such platforms.

....
> Yes that's trivially true: breaking an assumption can have dire
> consequences.

You said that this code has "UB that can't happen unless one informs a
really perverse compiler that it's there." You've just admitted that if
you compile for a platform where that assumption is not valid, the
consequences are dire. That's precisely what the UB specified by the
standard is intended to cover. That the code can also be used on
platforms where it isn't a problem doesn't make it any less appropriate
for the standard to say that has UB.

Am 19.06.2023 um 20:25 schrieb James Kuyper:

> I agree that it is the wrong type, but other people have already
> addressed that issue more than adequately. I don't normally respond to
> the original poster, for reasons that should be abundantly clear by
> looking at how she responded to discussions of that issue. Keep in mind
> that she's apparently not the person who wrote the code, she just ran
> into it and is trying to figure it out.

I've written the code and I don't think that I'll ever run
into problems with that; I'm simply not that compulsive.

On 2023-06-19 8:25 PM, James Kuyper wrote:
> On 6/19/23 10:43, Alf P. Steinbach wrote:
>> On 2023-06-18 7:10 AM, james...@alumni.caltech.edu wrote:
>>> On 6/16/23 18:17, Alf P. Steinbach wrote:
>>>> On 2023-06-16 11:16 PM, james...@alumni.caltech.edu wrote:
>>>>> On Friday, June 16, 2023 at 2:48:24 AM UTC-4, Alf P. Steinbach wrote:
>>>>>> On 2023-06-15 12:27 AM, James Kuyper wrote:
>>>>>>> On 6/14/23 15:46, Alf P. Steinbach wrote:
>>>>> ...
>>>>>>> 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<>.
>>>>>> Yes, but irrelevant for the case discussed, because the values are
>>>>>> guaranteed correctly aligned.
>>>>>
>>>>> You said nothing about what p_bytes was when you asked
>>>>>
>>>>> "how is the compiler to know that it's generally called with a
>>>>> `*reinterpret_cast<uint64_t*>( p_bytes )` as argument?"
>>>>>
>>>>> In particular, you said nothing about p_bytes that would guarantee
>>>>> that it was
>>>>> correctly aligned.
>>>>
>>>> That was known from the optimization attempt in the original posting's
>>>> code (I'm not the OP):
>>>>
>>>> #if defined(__GNUC__) || defined(__llvm__)
>>>> if( (size_t)&data % 8 )
>>>> __builtin_unreachable();
>>>> #endif
>>>
>>> How is that supposed to help?
>>
>> Regarding the cast to `size_t` you'd have to ask the original coder,
>> which is not necessarily even the original poster, which isn't me.
>
> That is not the point I was discussing, which you might reasonably have
> concluded from the fact that I didn't even mention size_t or [u]intptr_t.
>
> I agree that it is the wrong type, but other people have already
> addressed that issue more than adequately. I don't normally respond to
> the original poster, for reasons that should be abundantly clear by
> looking at how she responded to discussions of that issue. Keep in mind
> that she's apparently not the person who wrote the code, she just ran
> into it and is trying to figure it out.
>
>> However, presumably you're asking how that quote is meant to help you
>> understand that there is an assumption of correct alignment.
>
> Nope. I'm not how I'm supposed to figure out that that assumption was
> made. That's trivial. I'm asking why you think the assumption is
> guaranteed to be true. See above, where you say "the values are
> guaranteed correctly aligned".
>
>> That's because with incorrect alignment execution (with GCC and clang)
>> reaches `__builtin_unreachable`, which is UB by definition. This allows
>> the compiler to optimize /as if/ correct alignment is guaranteed. Thus
>> the quoted code explicitly expresses that assumption.
>
> So, this is designed to make the compiler generate code that is
> optimized for correctly aligned pointers, which is valuable on a
> platform where mis-aligned access is merely slower than correctly
> aligned access. It doesn't do anything useful on a platform where
> mis-aligned pointers simply cannot be safely dereferenced.

Not sure I'm buying that evaluation; it assumes too much about
compiler's code generation and knowledge of calling context.

> Nor does it
> do any good on platforms where uint64_t* is incapable of representing an
> address that is mis-aligned, so the reinterpret_cast<> is guaranteed to
> produce a pointer that points at a different location in memory.
>
> The fact that you don't work on such platforms doesn't change the fact
> that such platforms exist, and it doesn't negate the C and C++
> committees' decisions to write the two standards in such a way as to
> allow fully conforming implementations on such platforms.
>
> ...
>> Yes that's trivially true: breaking an assumption can have dire
>> consequences.
>
> You said that this code has "UB that can't happen unless one informs a
> really perverse compiler that it's there." You've just admitted that if
> you compile for a platform where that assumption is not valid, the
> consequences are dire.

No, the assumption that was made in the code was not about the platform.

The assumption made was that it's guaranteed that the function is called
with a correctly aligned argument.

The platform has nothing to do with it.

> That's precisely what the UB specified by the
> standard is intended to cover. That the code can also be used on
> platforms where it isn't a problem doesn't make it any less appropriate
> for the standard to say that has UB.

These errors of reasoning follow from the one about platform-specificity.

- Alf

"Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes:
> On 2023-06-19 8:25 PM, James Kuyper wrote:
>> On 6/19/23 10:43, Alf P. Steinbach wrote:
>>> On 2023-06-18 7:10 AM, james...@alumni.caltech.edu wrote:
>>>> On 6/16/23 18:17, Alf P. Steinbach wrote:
>>>>> On 2023-06-16 11:16 PM, james...@alumni.caltech.edu wrote:
>>>>>> On Friday, June 16, 2023 at 2:48:24 AM UTC-4, Alf P. Steinbach wrote:
>>>>>>> On 2023-06-15 12:27 AM, James Kuyper wrote:
>>>>>>>> On 6/14/23 15:46, Alf P. Steinbach wrote:
>>>>>> ...
>>>>>>>> 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<>.
>>>>>>> Yes, but irrelevant for the case discussed, because the values are
>>>>>>> guaranteed correctly aligned.
>>>>>>
>>>>>> You said nothing about what p_bytes was when you asked
>>>>>>
>>>>>> "how is the compiler to know that it's generally called with a
>>>>>> `*reinterpret_cast<uint64_t*>( p_bytes )` as argument?"
>>>>>>
>>>>>> In particular, you said nothing about p_bytes that would guarantee
>>>>>> that it was
>>>>>> correctly aligned.
>>>>>
>>>>> That was known from the optimization attempt in the original posting's
>>>>> code (I'm not the OP):
>>>>>
>>>>> #if defined(__GNUC__) || defined(__llvm__)
>>>>> if( (size_t)&data % 8 )
>>>>> __builtin_unreachable();
>>>>> #endif
>>>>
>>>> How is that supposed to help?
>>>
>>> Regarding the cast to `size_t` you'd have to ask the original coder,
>>> which is not necessarily even the original poster, which isn't me.
>> That is not the point I was discussing, which you might reasonably
>> have
>> concluded from the fact that I didn't even mention size_t or [u]intptr_t.
>> I agree that it is the wrong type, but other people have already
>> addressed that issue more than adequately. I don't normally respond to
>> the original poster, for reasons that should be abundantly clear by
>> looking at how she responded to discussions of that issue. Keep in mind
>> that she's apparently not the person who wrote the code, she just ran
>> into it and is trying to figure it out.
>>
>>> However, presumably you're asking how that quote is meant to help you
>>> understand that there is an assumption of correct alignment.
>> Nope. I'm not how I'm supposed to figure out that that assumption
>> was
>> made. That's trivial. I'm asking why you think the assumption is
>> guaranteed to be true. See above, where you say "the values are
>> guaranteed correctly aligned".
>>
>>> That's because with incorrect alignment execution (with GCC and clang)
>>> reaches `__builtin_unreachable`, which is UB by definition. This allows
>>> the compiler to optimize /as if/ correct alignment is guaranteed. Thus
>>> the quoted code explicitly expresses that assumption.
>> So, this is designed to make the compiler generate code that is
>> optimized for correctly aligned pointers, which is valuable on a
>> platform where mis-aligned access is merely slower than correctly
>> aligned access. It doesn't do anything useful on a platform where
>> mis-aligned pointers simply cannot be safely dereferenced.
>
> Not sure I'm buying that evaluation; it assumes too much about
> compiler's code generation and knowledge of calling context.
>
>
>> Nor does it
>> do any good on platforms where uint64_t* is incapable of representing an
>> address that is mis-aligned, so the reinterpret_cast<> is guaranteed to
>> produce a pointer that points at a different location in memory.
>> The fact that you don't work on such platforms doesn't change the
>> fact
>> that such platforms exist, and it doesn't negate the C and C++
>> committees' decisions to write the two standards in such a way as to
>> allow fully conforming implementations on such platforms.
>> ...
>>> Yes that's trivially true: breaking an assumption can have dire
>>> consequences.
>> You said that this code has "UB that can't happen unless one informs
>> a
>> really perverse compiler that it's there." You've just admitted that if
>> you compile for a platform where that assumption is not valid, the
>> consequences are dire.
>
> No, the assumption that was made in the code was not about the platform.
>
> The assumption made was that it's guaranteed that the function is
> called with a correctly aligned argument.
>
> The platform has nothing to do with it.

I haven't followed this thread closely enough to be sure that nobody has
raised this point:

Nothing in the language standard guarantees that converting a pointer
value to an integer type and checking the low-order bits of the result
tells you anything about the alignment of the memory the pointer points
to. The assuption is likely to be valid on any platform supported by
gcc and/or llvm (clang), but I have no idea whether either of those
compilers would be clever enough to recognize what the code is trying to
assert and perform the desired optimization.

I've worked on systems where a pointer value with a representation
ending in binary 000 might be byte-aligned, or a pointer ending in
non-zero bits might be word-aligned. (Cray vector machines, where the
hardware can only address 64-bit words and a byte offset was stored in
the high-order 4 bits and managed in software.)

>> That's precisely what the UB specified by the
>> standard is intended to cover. That the code can also be used on
>> platforms where it isn't a problem doesn't make it any less appropriate
>> for the standard to say that has UB.
>
> These errors of reasoning follow from the one about platform-specificity.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 2023-06-20 2:37 AM, Keith Thompson wrote:
[snip]
> Nothing in the language standard guarantees that converting a pointer
> value to an integer type and checking the low-order bits of the result
> tells you anything about the alignment of the memory the pointer points
> to. The assuption is likely to be valid on any platform supported by
> gcc and/or llvm (clang), but I have no idea whether either of those
> compilers would be clever enough to recognize what the code is trying to
> assert and perform the desired optimization.

From a portability POV the example given in the original posting is
even worse:

* Your point that checking the low order bits is not guaranteed.
Apparently the standard library has no simple way to query the
alignment of an arbitrary address, only the alignment of a type. In
principle one could check the alignment by generating a corresponding
well aligned address via `std::align`, and comparing, but that may be
too convoluted to help the compiler understand an assertion about the
alignment. However, at the point where one is dealing with a byte array,
if one has ensured that the array itself is properly aligned it's
trivial to check/ensure that any part of it has some given alignment.

* The `% 8` in the code.
Should be `% alignof( Type )`. E.g. byte size /can/ be 8 octets.

* The cast to `size_t`.
Should be a cast to `uintptr_t`. `size_t` may be too small.

And I've remarked elsewhere that portable `for(;;){}` UB would probably
communicate the "can't get here" just as well as the non-portable GCC
intrinsic.

Plus, that

* The parameter type `uint64_t const &` /already/ expresses the
alignment assumption.

It's only with machine code inlining that the compiler might at all
consider that `void foo( int& )` might receive a non-aligned parameter.

Proper alignment is a tacit assumption of all C++ code.

> I've worked on systems where a pointer value with a representation
> ending in binary 000 might be byte-aligned, or a pointer ending in
> non-zero bits might be word-aligned. (Cray vector machines, where the
> hardware can only address 64-bit words and a byte offset was stored in
> the high-order 4 bits and managed in software.)

Gah. :-(

But that raises the question of which platforms modern C++ really cover
/in practice/. I.e. which platforms have C++20 compilers.

It's counter-productive with modern C++ rules that ensure portability of
some construct where that portability is only an issue for systems that
don't have modern C++ compilers, so maybe the standard should be fixed.

[snip]

- Alf

On 20/06/2023 08:32, Alf P. Steinbach wrote:
> On 2023-06-20 2:37 AM, Keith Thompson wrote:
> [snip]
>> Nothing in the language standard guarantees that converting a pointer
>> value to an integer type and checking the low-order bits of the result
>> tells you anything about the alignment of the memory the pointer points
>> to.  The assuption is likely to be valid on any platform supported by
>> gcc and/or llvm (clang), but I have no idea whether either of those
>> compilers would be clever enough to recognize what the code is trying to
>> assert and perform the desired optimization.

That assumption /is/ true for all gcc targets. (I am less familiar with
clang.) And gcc will /sometimes/ use the explicit undefined behaviour
to optimise the access as aligned. Sometimes, however, that information
appears to get lost before later optimisation passes. (On RISC-V, gcc
generates fast aligned code at -O1, but slow unaligned code at -O2.)
gcc has a better solution to this - __builtin_assume_aligned() - which
could also work if gcc ever targeted systems like the Cray you
mentioned. (The OP, being Bonita, decided that the original poorer code
was better than listening to anyone else.)

>
> From a portability POV the example given in the original posting is
> even worse:
>
> * Your point that checking the low order bits is not guaranteed.
>   Apparently the standard library has no simple way to query the
> alignment of an arbitrary address, only the alignment of a type.

C++20 has std::assume_aligned, which is basically a less flexible
standardisation of the gcc builtin. It does not let you query the
alignment, but it /does/ let you tell the compiler about it, which is
what you need for optimising code like the original post.

> In
> principle one could check the alignment by generating a corresponding
> well aligned address via `std::align`, and comparing, but that may be
> too convoluted to help the compiler understand an assertion about the
> alignment. However, at the point where one is dealing with a byte array,
> if one has ensured that the array itself is properly aligned it's
> trivial to check/ensure that any part of it has some given alignment.
>
> * The `% 8` in the code.
>   Should be `% alignof( Type )`. E.g. byte size /can/ be 8 octets.
>

Yes.

> * The cast to `size_t`.
>   Should be a cast to `uintptr_t`. `size_t` may be too small.
>

There's also the possibility that the target does not have an integer
type that is suitable for conversion of all data pointer types. If that
is the case, no "uintptr_t" type will exist for the platform - but
"size_t" will always exist. So if you have such a target, a cast to
"uintptr_t" will give a compile-time error, which is vastly preferable
to the silently dangerous compile you'd get with "size_t".

And of course, "uintptr_t" is better than "size_t" simply because you
would be using the correctly specified type for the purpose.

> And I've remarked elsewhere that portable `for(;;){}` UB would probably
> communicate the "can't get here" just as well as the non-portable GCC
> intrinsic.
>

In theory, perhaps. In practice, no. In some kinds of coding, infinite
loops like that can be exactly what you want, and compilers generally do
not assume that it is an error or undefined behaviour. (I am not at all
convinced that an infinite loop is undefined behaviour.)

If you are happy with C++23, then std::unreachable() would of course be
a better choice than a gcc extension.

On 6/19/23 18:47, Alf P. Steinbach wrote:
> On 2023-06-19 8:25 PM, James Kuyper wrote:
>> On 6/19/23 10:43, Alf P. Steinbach wrote:
....
>>> That's because with incorrect alignment execution (with GCC and clang)
>>> reaches `__builtin_unreachable`, which is UB by definition. This allows
>>> the compiler to optimize /as if/ correct alignment is guaranteed. Thus
>>> the quoted code explicitly expresses that assumption.
>>
>> So, this is designed to make the compiler generate code that is
>> optimized for correctly aligned pointers, which is valuable on a
>> platform where mis-aligned access is merely slower than correctly
>> aligned access. It doesn't do anything useful on a platform where
>> mis-aligned pointers simply cannot be safely dereferenced.
>
> Not sure I'm buying that evaluation; it assumes too much about
> compiler's code generation and knowledge of calling context.

I'm merely trying to guess at plausible reasons why someone might
consider it desireable to instruct the compiler to generate code that
can't deal safely with misaligned pointers. Obviously, those reasons
will be platform-specific.

....
>>> Yes that's trivially true: breaking an assumption can have dire
>>> consequences.
>>
>> You said that this code has "UB that can't happen unless one informs a
>> really perverse compiler that it's there." You've just admitted that if
>> you compile for a platform where that assumption is not valid, the
>> consequences are dire.
>
>
> No, the assumption that was made in the code was not about the platform.
>
> The assumption made was that it's guaranteed that the function is
> called with a correctly aligned argument.

Nothing is more normal than writing code that has pre-conditions that
must be met for the code to work properly. However, I find it quite
bizarre that you describe such a practice by claiming that it is
guaranteed that the pre-conditions will be met, and that, as a result,
the corresponding UB can't happen. And you reiterate those claims after
admitting that "breaking an assumption can have dire consequences".
You're twisting the meaning of basic words in the English language such
as "guarantee", "assume", and "can't happen" in ways I hadn't considered
plausible. I'll keep that in mind for future conversations with you.

,,,
> The platform has nothing to do with it.

The platform's characteristics determine whether or not alignment even
matters, and in particular whether misaligned access is even an issue,
and if it is, whether it is merely inefficient, or positively dangerous.

Hello, David.

Nice to see You around, man.

Seems line noone wants to post anymore to comp.programming.

Even Amine not.

You too moved out of there, like it is visible ?

On Thursday, June 15, 2023 at 11:02:30 AM UTC+3, David Brown wrote:
> 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.