Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX

2013-10-07 Thread Ilya Enkovich
2013/10/2 Ilya Enkovich : > 2013/10/1 Jakub Jelinek : >> On Tue, Oct 01, 2013 at 04:15:53PM +0400, Ilya Enkovich wrote: >>> I'd like to restart discussion on this topic. I see two viable options >>> in this thread for PLT entry for MPX. >>> >>> The first one is to use new relocation for calls requi

Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX

2013-10-07 Thread Jakub Jelinek
On Mon, Oct 07, 2013 at 01:31:29PM +0400, Ilya Enkovich wrote: > Seems assembler may not always detect MPX relocation. For simple calls > it may check for 'bnd' prefix, but for indirect call we need to > generate MPX relocation for 'mov' instruction storing address of the > called function. This in

Re: Update the c++1y/c++14 support page

2013-10-07 Thread Paolo Carlini
On 10/06/2013 03:19 PM, Morwenn Ed wrote: Ok, no problem then, here is the patch. And the changelog. I hope they are ok, I have never properly submitted anything before. Patch looks great to me, thanks. I'm applying it. Thanks, Paolo.

Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX

2013-10-07 Thread Ilya Enkovich
2013/10/7 Jakub Jelinek : > On Mon, Oct 07, 2013 at 01:31:29PM +0400, Ilya Enkovich wrote: >> Seems assembler may not always detect MPX relocation. For simple calls >> it may check for 'bnd' prefix, but for indirect call we need to >> generate MPX relocation for 'mov' instruction storing address of

Re: Update the c++1y/c++14 support page

2013-10-07 Thread Richard Kenner
> This has nothing to do with Oracle v. Google, but with GCC policy of not > requiring a copyright assignment for small patches from the first-time > contributors (which Paolo knows as a long-time GCC hacker). I think it's a valid reminder that that policy needs to be interpreted carefully and