[PATCH 2/3] alpha: enable -fstack-protector

FRAME_GROWS_DOWNWARD was left commented out in alpha.h, so it defaulted
to 0 and -fstack-protector was rejected outright:

    cc1: warning: '-fstack-protector' not supported for this target

The stack protector needs a downward-growing frame.  cfgexpand allocates
the canary slot before it reorders the local arrays, so with an
upward-growing frame the canary would land below the buffers it is meant
to guard.  Define FRAME_GROWS_DOWNWARD when the stack protector is in
use, as rs6000 and xtensa do, and resolve the soft frame pointer to the
high end of the local variables in that case.

Default code generation is unaffected: FRAME_GROWS_DOWNWARD is zero
whenever flag_stack_protect is zero.  Compiling gcc.c-torture/compile
with and without this change at -O0 and at -O2 gives byte-identical
assembly for all 1625 files.

glibc already provides everything the generic expansion needs on Alpha:
__stack_chk_guard from ld.so and __stack_chk_fail from libc, both since
GLIBC_2.4.  There is no TCB stack guard on Alpha, so no
-mstack-protector-guard= option is added.

The OpenVMS elimination offsets get the same treatment for consistency,
but that path is untested.

gcc/ChangeLog:

	* config/alpha/alpha.h (FRAME_GROWS_DOWNWARD): Define.
	* config/alpha/alpha.cc (alpha_initial_elimination_offset): Resolve
	FRAME_POINTER_REGNUM to the high end of the local variables when
	FRAME_GROWS_DOWNWARD.
	(alpha_vms_initial_elimination_offset): Likewise.

gcc/testsuite/ChangeLog:

	* gcc.dg/fstack-protector-strong.c: Run on alpha*-*-*.  Expect
	twice as many stack_chk_fail matches there, since Alpha names the
	callee once for !literal and once for !lituse_jsr.