[patch] Make memory copy functions scalar storage order barriers

[Eric Botcazou]

Hi,

this addresses the issue raised by Andrew a few weeks ago about the usage of 
memory copy functions to toggle the scalar storage order.  Recall that you 
cannot (the compiler errors out) take the address of a scalar which is stored 
in reverse order, but you can do it for the enclosing aggregate type., which 
means that you can also pass it to the memory copy functions.  In this case, 
the optimizer may rewrite the copy into a scalar copy, which is a no-no.

The patch also contains an unrelated hunk for the tree pretty printer.

Tested on x86-64/Linux, OK for the mainline?


2020-06-01  Eric Botcazou  <ebotcazou@adacore.com>

	* gimple-fold.c (gimple_fold_builtin_memory_op): Do not replace with a
	scalar copy if either type has reverse scalar storage order.
	* tree-ssa-sccvn.c (vn_reference_lookup_3): Do not propagate through a
	memory copy if either type has reverse scalar storage order.

	* tree-pretty-print.c (dump_generic_node) <ARRAY_TYPE>: Print quals.


2020-06-01  Eric Botcazou  <ebotcazou@adacore.com>

	* gcc.c-torture/execute/sso-1.c: New test.

-- 
Eric Botcazou
-------------- next part --------------
A non-text attachment was scrubbed...
Name: p.diff
Type: text/x-patch
Size: 3433 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20200601/b7bad89b/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sso-1.c
Type: text/x-csrc
Size: 1419 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20200601/b7bad89b/attachment-0001.bin>