On Thu, 14 Jul 2016, Eric Botcazou wrote:
> > Boostrap / regtest on strict-alignment platforms welcome.
>
> Bootstrap/regtest on SPARC/Solaris is OK, modulo:
>
> XPASS: gcc.dg/memmove-4.c scan-tree-dump-not optimized "memmove"
> FAIL: gcc.dg/strlenopt-8.c scan-tree-dump-times strlen "strlen \\\\(" 0
> FAIL: gcc.dg/strlenopt-8.c scan-tree-dump-times strlen "memcpy \\\\(" 4
>
> for both 32-bit and 64-bit.
>
> > Unless I hear some positives I'll let the patch sit here as I
> > don't really care too much about those pesky targets (and
> > targets can choose to opt-in by providing movmisalign optabs
> > anyway so they don't go the store/extract_bit_field path).
>
> The patch is a step forward but it doesn't fully solve the problem:
>
> #include <stdint.h>
> #include <string.h>
>
> uint32_t foo_noalign(const uint32_t *s) {
> uint32_t v;
> memcpy(&v, s, sizeof(v));
> return v;
> }
>
> uint32_t foo(const uint32_t *s) {
> uint32_t v;
> memcpy(&v, __builtin_assume_aligned(s, 4), sizeof(v));
> return v;
> }
>
> As discussed in the audit trail, the compiler ought to generate again
> the same code on strict-alignment targets in both cases, as Clang
> apparently and as GCC itself during most of its existence (until GCC 4.5
> to be precise).
The patch wasn't supposed to address this issue. It was supposed
to address the fact that the memcpy call is not optimized away
on strict-align targets
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50417#c16).
I've commented on the original issue in that PR extensively (on what
is possible and what not within the constraints of the middle-end).
Iff alignment according to the pointer type passed to memory
functions is important the FEs need to extract said information
before it gets lost (and before casting it to the prototypes argument
type).
Richard.
