Hi Venkat, On 22 January 2014 16:57, Venkataramanan Kumar <venkataramanan.ku...@linaro.org> wrote: > Hi Marcus, > > After we changed the frame growing direction (downwards) in Aarch64, > the back-end now generates stack smashing set and test based on > generic code available in GCC. > > But most of the ports (i386, spu, rs6000, s390, sh, sparc, tilepro and > tilegx) define machine descriptions using standard pattern names > 'stack_protect_set' and 'stack_protect_test'. This is done for both > TLS model as well as global variable based stack guard model.
+ "" + "ldr\\t%x2, %1\;str\\t%x2, %0\;mov\t%x2,0" + [(set_attr "length" "12")]) This pattern emits an opaque sequence of instructions that cannot be scheduled, is that necessary? Can we not expand individual instructions or at least split ? + "ldr\t%x3, %x1\;ldr\t%x0, %x2\;eor\t%x0, %x3, %x0" + [(set_attr "length" "12")]) Likewise. -/* { dg-do compile { target i?86-*-* x86_64-*-* rs6000-*-* s390x-*-* } } */ +/* { dg-do compile { target stack_protection } } */ /* { dg-options "-O2 -fstack-protector-strong" } */ Do we need a new effective target test, why is the existing "fstack_protector" not appropriate? Cheers /Marcus