Re: GSOC 2018 - Textual LTO dump tool project

2018-03-02 Thread Hrishikesh Kulkarni
Hello everyone, Thanks for your suggestions and engaging response. Based on the feedback I think that the scope of this project comprises of following three indicative actions: 1. Creating separate driver i.e. separate dump tool that uses lto object API for reading the lto file. 2. Extending L

Re: GSOC 2018 - Textual LTO dump tool project

2018-03-02 Thread Richard Biener
On Fri, Mar 2, 2018 at 10:24 AM, Hrishikesh Kulkarni wrote: > Hello everyone, > > > Thanks for your suggestions and engaging response. > > Based on the feedback I think that the scope of this project comprises of > following three indicative actions: > > > 1. Creating separate driver i.e. separate

Further for GSoC.

2018-03-02 Thread Tejas Joshi
> > > The above Project Idea is made available on 'Summer of Code' wiki of > > GNU GCC Website. I wanted to have some more details about above idea > > regarding to what is expected for implementation and expected output > > for the same. I've been having interest in this idea I already asked abo

Re: GSOC 2018 - Textual LTO dump tool project

2018-03-02 Thread Jan Hubicka
Hello, > On Fri, Mar 2, 2018 at 10:24 AM, Hrishikesh Kulkarni > wrote: > > Hello everyone, > > > > > > Thanks for your suggestions and engaging response. > > > > Based on the feedback I think that the scope of this project comprises of > > following three indicative actions: > > > > > > 1. Creatin

Re: Further for GSoC.

2018-03-02 Thread Joseph Myers
On Fri, 2 Mar 2018, Tejas Joshi wrote: > I have some university level experience of working and programming assembly > language under Intel 80386DX architecture. I think it may help for > implementing supports for other architectures. Just for start, you > mentioned roundeven function as a guide f

Why does IRA force all pseudos live across a setjmp call to be spilled?

2018-03-02 Thread Peter Bergner
While debugging the PR84264 ICE caused by the following test case: void _setjmp (); void a (unsigned long *); void b () { for (;;) { _setjmp (); unsigned long args[9]{}; a (args); } } I noticed that IRA is spilling all pseudos that are live acro

Re: Why does IRA force all pseudos live across a setjmp call to be spilled?

2018-03-02 Thread Alexander Monakov
On Fri, 2 Mar 2018, Peter Bergner wrote: > But currently ira-lives.c:process_bb_node_lives() has: > > /* Don't allocate allocnos that cross setjmps or any > call, if this function receives a nonlocal > goto. */ > if (cfun->has_nonlocal_label > || find_reg_note (insn, REG_SETJ

Re: Why does IRA force all pseudos live across a setjmp call to be spilled?

2018-03-02 Thread Jeff Law
On 03/02/2018 12:45 PM, Peter Bergner wrote: > While debugging the PR84264 ICE caused by the following test case: > > void _setjmp (); > void a (unsigned long *); > void > b () > { > for (;;) > { > _setjmp (); > unsigned long args[9]{}; > a (args); > } >

Re: gdb 8.x - g++ 7.x compatibility

2018-03-02 Thread Roman Popov
Ok, sounds reasonable. In case of debugger we are indeed "linking" RTTI name with name in debuginfo. I've checked LLVM docs, they generate Debuginfo from LLVM "Metadata", and metadata for types already contains mangled names in "identifier" field: https://llvm.org/docs/LangRef.html#dicompositetype

Re: Why does IRA force all pseudos live across a setjmp call to be spilled?

2018-03-02 Thread Vladimir Makarov
On 03/02/2018 02:45 PM, Peter Bergner wrote: While debugging the PR84264 ICE caused by the following test case: void _setjmp (); void a (unsigned long *); void b () { for (;;) { _setjmp (); unsigned long args[9]{}; a (args); } } I n

Re: Why does IRA force all pseudos live across a setjmp call to be spilled?

2018-03-02 Thread Peter Bergner
On 3/2/18 3:26 PM, Jeff Law wrote: > On 03/02/2018 12:45 PM, Peter Bergner wrote: >> ...which forces us to spill everything live across the setjmp by forcing >> the pseudos to interfere all hardregs. That can't be good for performance. >> What am I missing? > > You might want to hold off a bit. I

Re: gdb 8.x - g++ 7.x compatibility

2018-03-02 Thread Roman Popov
I've experimented with adding DW_AT_linkage_name for composite types in LLVM. Here is impact on binary sizes (compiled with debuginfo): Original size with DW_AT_linkage_name for composites % increase clang-7.01926574256 1952846192 1.4% clang-tidy 12209

Security alert for your linked Google Account

2018-03-02 Thread Google via gcc
chandramohananbs mohananbs Your account gcc@gcc.gnu.org is listed as the recovery email for chandramohan...@gmail.com. Don't recognize this account? Click here