Does clang erase your UB code if you access a badly-aligned uintN_t?

[celest condor]

Title.
A.k.a., can we just say "well, our system requirements are to use only modern CPUs that allow missaligned access, this is fine"?

[tacit trench]

When your question is answered use !solved to mark the question as resolved.

Remember to ask specific questions, provide necessary details, and reduce your question to its simplest form. For tips on how to ask a good question use !howto ask.

[turbid ember]

!tias

[tacit trench]

https://tryitands.ee/

[celest condor]

nah, trial and error is a fool's game

(like how for 20 years people though "yeah, vloatile bools are thread safe, don't worry guys" when they are in fact, not)

[turbid ember]

Your question is about a specific implementation, the way to answer it is to look at how the specific implementation behaves.

(If only there was some website that let you easily do this)

[celest condor]

we do know that when UB is involved, the compiler is allowed to burn your house down

so dismissing misalligned access sounds very suspicious

unless, some C++26 standard updated this behavior

[tropic moth]

"is the compiler allowed to delete your code?" is a very different question from "will clang 17.0.1 delete this particular code in this particular example under those particular circumstances with these particular flags?"

the compiler is absolutely allowed to delete your code if your code invokes UB.

and just because the current version of a particular compiler doesn't doesn't mean the next version won't.

¯_(ツ)_/¯

[celest condor]

so the answer is yes

!solved

[tacit trench]

Thank you and let us know if you have any more questions!

This thread is now set to auto-hide after an hour of inactivity

[tropic moth]

the answer is: maybe, it depends

[turbid ember]

Again: If only there was a site you could use to figure this out

[zealous dome]

memcpy

If it can be optimized out to an unaligned read, it probably will be?

[celest condor]

I know the safe way to force correct alignment with a memcpy, or the wrapper around memcpy called std::bit_cast (since C++20, allowed only for std::is_trivial<T>::value types)

[celest condor]

so the code is not erased still

[zealous dome]

I don't see how you could use bit_cast for this

[zealous dome]

You mean you tried and it didn't get optimzied out?

[celest condor]

you extract uint32_t from some void* address

[celest condor]

havent tried

[zealous dome]

I don't see how

What are you gonna pass as a parameter

[celest condor]

uint32_t num = bit_cast<uint32_t>(*((uint32_t*)someRawAddress));

[tropic moth]

that'd be UB

[zealous dome]

This is equivalent to just uint32_t num = *((uint32_t*)someRawAddress);

[celest condor]

oh, right, cause reinterpret_cast is UB for non-chars

kay, then the memcpy is the only legit way

[tropic moth]

bit_cast takes a pointer to the object whose bits you want to cast

[celest condor]

it takes a const lvalue reference

[tropic moth]

sry, reference, yes

you could copy the bytes into a byte array and then bit_cast that

but memcpy is potentially simpler in that case

[celest condor]

unless you memcpy into some STL container and corrupt all the bytes

[tropic moth]

😛

[celest condor]

so, std::is_trivial<T>::value is used

[turbid ember]

std::is_trivial is deprecated

[turbid ember]

uint32_t num = bit_cast<uint32_t>(*((char(*)[4])someRawAddress)); should be ok

[zealous dome]

Looks UBey to me 😛

[turbid ember]

I don't think so

[zealous dome]

If there is no char[4] at that location, isn't this a SA violation like any other?

[turbid ember]

I would have to double check. Chars are special, they alias with everything

In practice this is always fine

[tropic moth]

pretty sure that's UB

[zealous dome]

True

[zealous dome]

This isn't char though, it's an array of them

[turbid ember]

eh, big char 😛

[tropic moth]

lol

[zealous dome]

A conspiracy by big char to push for more SA violations? 😛

[celest condor]

yes

reinterpret_cast docs:

Type aliasing
Type accessibility

If a type T_ref is similar to any of the following types,

Similar types

Informally, two types are similar if, ignoring top-level cv-qualification:

    they are the same type; or
    they are both pointers, and the pointed-to types are similar; or
    they are both pointers to member of the same class, and the types of the pointed-to members are similar; or
    they are both arrays and the array element types are similar. 

so, fixed length N-dimensional arrays can be used for well defined reinterpret_cast

[zealous dome]

I don't see what leads you to this conclusion

[turbid ember]

There's no question about whether a reinterpret_cast here is ok

Reinterpret casts in general are never UB. It's how you use the result that can be.

[celest condor]

recently in C++26 they tried to make infinite loops without side effects well defined, but I haven't heard anything for the misaligned access

[turbid ember]

(well, function pointers might be the one case)

[zealous dome]

?

I mean you posted this quote and said that it makes the cast (and the subsequent dereference I assume) well-defined

I don't see how the quote proves that

[celest condor]

yes, but due to laziness or lack of C++20, many people just run a missaligned access from a raw pointer, and this may be a hidden catastrophic bug, because the compiler said, lmao, nope, get rid of that code