Hi,

this is a regression present on the mainline for the ARM in the form of an 
assertion failure at -O2 in the back-end, which rightfully refuses to generate 
a load from an unaligned memory location (the ARM target is strict-alignment).

It comes from a __builtin_memcpy generating:

MEM <unsigned char[8]> [(char * {ref-all})&b] = MEM <unsigned char[8]> [(char 
* {ref-all})a.0_1];

in the .optimized dump, where b is a small union.  As a result, store_field is 
invoked with:

(gdb) p debug_rtx(target)
(reg/v:DI 113 [ b ])

and sends:

(gdb) p debug_rtx(temp)
(mem:BLK (reg/f:SI 115) [0 MEM <unsigned char[8]> [(char * {ref-all})a.0_1]+0 
S8 A8])

to store_bit_field with 64 bits and BLKmode.  The unaligned memory reference 
is then generated by store_integral_bit_field, which does:

rtx value_word = operand_subword_force (value, wordnum, value_mode);

thus creating an unaligned word mode (SImode) load.

store_integral_bit_field is ready to handle BLKmode fields, there is even a 
subtlety with their handling on big-endian targets, see PR middle-end/50325, 
but not if they are unaligned, so the fix is simply to call extract_bit_field 
for them in order to generate an unaligned load.  As a bonus, this subsumes 
the big-endian specific path that was added under PR middle-end/50325.

Bootstrapped/regtested on x86-64/Linux and SPARC/Solaris, OK for mainline?


2019-03-13  Eric Botcazou  <ebotcazou@adacore.com>

	PR middle-end/92071
	* expmed.c (store_integral_bit_field): For fields larger than a word,
	call extract_bit_field on the value if the mode is BLKmode.  Remove
 	specific path for big-endian targets and tidy things up a little bit.


2019-03-13  Eric Botcazou  <ebotcazou@adacore.com>

	* gcc.c-torture/compile/20200313-1.c: New test.

-- 
Eric Botcazou