On 19 March 2014 17:18, Venkataramanan Kumar
wrote:
> I used the existing dg-require-effective-target check,
> "stack_protector" and added it in a separate line.
>
> ChangeLog.
>
> 2014-03-19 Venkataramanan Kumar
> * g++.dg/fstack-protector-strong.C: Add effetive target check for
>
On 19 March 2014 17:11, Venkataramanan Kumar
wrote:
> I have incorporated your review comments and split the patch into two.
>
> The first patch attached here contains Aarch64 machine descriptions
> for the stack protect patterns.
>
> ChangeLog.
>
> 2014-03-19 Venkataramanan Kumar
> * c
Hi Marcus,
On 14 March 2014 19:42, Marcus Shawcroft wrote:
> Hi Venkat
>
> On 5 February 2014 10:29, Venkataramanan Kumar
> wrote:
>> Hi Marcus,
>>
>>> + "ldr\\t%x2, %1\;str\\t%x2, %0\;mov\t%x2,0"
>>> + [(set_attr "length" "12")])
>>>
>>> This pattern emits an opaque sequence of instructions t
Hi Marcus,
On 14 March 2014 19:42, Marcus Shawcroft wrote:
>>>
>>> Do we need a new effective target test, why is the existing
>>> "fstack_protector" not appropriate?
>>
>> "stack_protector" does a run time test. It failed in cross compilation
>> environment and these are compile only tests.
>
>
Hi Venkat
On 5 February 2014 10:29, Venkataramanan Kumar
wrote:
> Hi Marcus,
>
>> + "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 individua
On Fri, Mar 14, 2014 at 4:05 AM, Andrew Pinski wrote:
> On Wed, Feb 5, 2014 at 2:29 AM, Venkataramanan Kumar
> wrote:
>> Hi Marcus,
>>
>>> + "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
On Wed, Feb 5, 2014 at 2:29 AM, Venkataramanan Kumar
wrote:
> Hi Marcus,
>
>> + "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
>>
Hi Marcus,
> + "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 ?
Almost all the ports emits a templat
Hi Venkat,
On 22 January 2014 16:57, Venkataramanan Kumar
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, s
Can someone review this please.
regards,
Venkat.
On 22 January 2014 22:27, Venkataramanan Kumar
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
ping.
On 22 January 2014 22:27, Venkataramanan Kumar
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,
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
12 matches
Mail list logo
