The following testcase shows that GCC trunk mishandles DSE of __*_chk
calls.  Tail trimming of the calls is fine, we want to just decrease the
third argument and keep the first two and last arguments unmodified.
But for head trimming, we currently increment the two by head_trim and
decrease the third by head_trim, so
  __builtin___memcpy_chk (&a, b_2(D), 48, 32);
  __builtin_memset (&a, 32, 16);
into:
  _5 = b_2(D) + 16;
  __builtin___memcpy_chk (&MEM <char> [(void *)&a + 16B], _5, 32, 32);
  __builtin_memset (&a, 32, 16);
This is wrong, because the 32 was the determined (maximum) size of the
destination (char a[32]), but &a[16] has maximum size of 16, not 32.
The __builtin___memcpy_chk (&MEM <char> [(void *)&a + 16B], _5, 32, 32);
call is just folded later into
__builtin_memcpy (&MEM <char> [(void *)&a + 16B], _5, 32);
because it says that it copies as many bytes into destination as the
destination has.  We need:
  __builtin___memcpy_chk (&MEM <char> [(void *)&a + 16B], _5, 32, 16);
instead, which will terminate the program instead of letting it silently
overflow the buffer.
The patch just punts if we'd need to decrease the last argument below 0.

Fortunately, release branches are unaffected.
P.S. it was quite hard to make the runtime test working, in builtins.exp
neither dg-options nor dg-additional-options work and builtins.exp adds
-fno-tree-dse among several other -fno-* options.  Fortunately optimize
attribute works.

2020-01-15  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/93262
	* tree-ssa-dse.c (maybe_trim_memstar_call): For *_chk builtins,
	perform head trimming only if the last argument is constant,
	either all ones, or larger or equal to head trim, in the latter
	case decrease the last argument by head_trim.

	* gcc.c-torture/execute/builtins/pr93262-chk.c: New test.
	* gcc.c-torture/execute/builtins/pr93262-chk-lib.c: New file.
	* gcc.c-torture/execute/builtins/pr93262-chk.x: New file.