https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945
--- Comment #8 from npl at chello dot at ---
@Andrew Pinski: The code in question was compiled for arm4t.
The toolchain is not configured for arm7, but has a multilib-configuration for
arm4/armv5te/thumb. No defaults where touched in any way, correct unaligned
load/stores are generated otherwise and __ARM_FEATURE_UNALIGNED is NOT defined.
Further I tested the code below and the gcc will generate a per-byte-copy:
-----------------------------
#pragma pack(1)
struct CPacked
{
unsigned char m_EvilEpsilon;
unsigned m_Data;
};
void testaligned(CPacked *pPacked)
{
pPacked->m_Data = 0;
}
-----------------------------
I tested almost the same thing with nullptr, also results in a per-byte-copy:
-----------------------------
struct CNullpointer
{
unsigned char m_EvilEpsilon;
decltype(nullptr) m_Data;
};
void testnull(CNullpointer *pPacked)
{
pPacked->m_Data = 0;
}
-----------------------------
To me that raises the following points:
*) nullptr_t in an struct will generate the correct code (per-byte-copy)
*) nullptr_t when flushed to the stackframe will write a word without adhering
to alignment restrictions.
Since I doubt there is special handling for nullptr_t for flushing to the
stackframe, this seems like a lingering issue that is hard to reproduce. Even
more so since development and testing nowadays seems focused on platforms which
will allow or emulate unaligned accesses.
maybe if you create a struct of 4 chars with a constexpr constructor that takes
an int you will run in the same issue. fixing nullptr_t alignment might just
hide the issue
