Re: Default arguments and FUNCTION_TYPEs
Nathan Sidwell [EMAIL PROTECTED] writes: | Gabriel Dos Reis wrote: | | Assuming the extension was gone, do you see a reason we not move the | default arguments to FUNCTION_DECLs and have FUNCTION_TYPEs use | TREE_VEC instead of TREE_LIST to hold the parameter-type list? | | you could probably use a VEC(tree), which I think would be even better :) Thanks! -- Gaby
Re: Default arguments and FUNCTION_TYPEs
Nathan Sidwell [EMAIL PROTECTED] wrote: In the C++ front end, default arguments are recorded in FUNCTION_TYPEs intead of being part of the FUNCTION_DECLs. What are the reasons for that? There used to be an extension that allowed default arguments on function pointer types. We agreed to kill it, although I don't know if it was actually removed. If that's been done, there's no longer any reason. I took it out the back and shot it. The obvious place is on the DECL_INITIAL of the PARM_DECLs, but I don't think they exist until the function is defined. I heard once that there was some long-term project of storing function declarations (without corresponding definitions) in a more memory-efficient memory representation. Moving default parameters within PARM_DECL seems a little backward in this respect. And if your memory is right, requiring to build PARM_DECLs just to store default arguments would be even worse. I understand this has to be done in a separate pass: I was just bringing up the issue so that, if possibile, we could find some place which does not conflict with that project. Giovanni Bajo
Re: Default arguments and FUNCTION_TYPEs
Giovanni Bajo [EMAIL PROTECTED] writes: | Nathan Sidwell [EMAIL PROTECTED] wrote: | | In the C++ front end, default arguments are recorded in | FUNCTION_TYPEs intead of being part of the FUNCTION_DECLs. What are | the reasons for that? | | | There used to be an extension that allowed default arguments on | function pointer types. We agreed to kill it, although I don't know | if it was actually removed. If that's been done, there's no longer | any reason. | | I took it out the back and shot it. | | The obvious place is on the DECL_INITIAL of the PARM_DECLs, but I | don't think they exist until the function is defined. | | | I heard once that there was some long-term project of storing function | declarations (without corresponding definitions) in a more memory-efficient | memory representation. Moving default parameters within PARM_DECL seems a | little backward in this respect. And if your memory is right, requiring to | build PARM_DECLs just to store default arguments would be even worse. I don't see why, it is backward -- we still need to build the PARM_DECLs default arguments or not. Anyway, I'm in the middle of coding that suggestion, so I would appreciate a better concrete representation. -- Gaby
Re: Default arguments and FUNCTION_TYPEs
Gabriel Dos Reis [EMAIL PROTECTED] writes: [...] | | The obvious place is on the DECL_INITIAL of the PARM_DECLs, but I | | don't think they exist until the function is defined. | | | | | | I heard once that there was some long-term project of storing function | | declarations (without corresponding definitions) in a more memory-efficient | | memory representation. Moving default parameters within PARM_DECL seems a | | little backward in this respect. And if your memory is right, requiring to | | build PARM_DECLs just to store default arguments would be even worse. | | I don't see why, it is backward -- we still need to build the | PARM_DECLs default arguments or not. Consider PR c++/17395. My guess is that is partly because we do not build the PARM_DECLs (and their associated scope) early enough. -- Gaby
Re: Default arguments and FUNCTION_TYPEs
Gabriel Dos Reis [EMAIL PROTECTED] wrote:
templateint struct X { };
void fu(int a, Xsizeof(a)) { } // #1
I gave a look to PR 17395 and you are probably right. This testcase requires
us to build PARM_DECLs even for function declarations. That's really too
bad.
You should though measure memory usage for large C++ testcases when building
PARM_DECLs immediately. If they raise too much, that's a serious regression.
--
Giovanni Bajo
Re: Default arguments and FUNCTION_TYPEs
Giovanni Bajo [EMAIL PROTECTED] writes:
| Gabriel Dos Reis [EMAIL PROTECTED] wrote:
|
| templateint struct X { };
|
| void fu(int a, Xsizeof(a)) { } // #1
|
| I gave a look to PR 17395 and you are probably right. This testcase requires
| us to build PARM_DECLs even for function declarations. That's really too
| bad.
I guess we don't need to implement the language, we can be very fast :-)
|
| You should though measure memory usage for large C++ testcases when building
| PARM_DECLs immediately. If they raise too much, that's a serious regression.
Once I'm finished, I'll post the patch and I would probably ask you
help in the testing department and suggest better concrete
solution. That PR needs to be fixed.
-- Gaby
Re: Default arguments and FUNCTION_TYPEs
Gabriel Dos Reis [EMAIL PROTECTED] wrote: Once I'm finished, I'll post the patch and I would probably ask you help in the testing department and suggest better concrete solution. That PR needs to be fixed. Fixing a PR introducing a regression is not a proper fix for any bug, *especially* for a bug which is not a regression itself. Given that it never worked before, there are no GCC users depending on it. Of course, it'd be good to fix it, but must be done in the proper way. I'm glad to help with testing if I have time. -- Giovanni Bajo
Re: Default arguments and FUNCTION_TYPEs
Giovanni Bajo [EMAIL PROTECTED] writes: | Gabriel Dos Reis [EMAIL PROTECTED] wrote: | | Once I'm finished, I'll post the patch and I would probably ask you | help in the testing department and suggest better concrete | solution. That PR needs to be fixed. | | | Fixing a PR introducing a regression is not a proper fix for any bug, | *especially* for a bug which is not a regression itself. Thanks for the lecture. Not just because this is not a regression does not mean it does not need fixing. | Given that it never | worked before, there are no GCC users depending on it. The reporter of the PR is a GCC user who is trying to move working codes from other compilers to GCC. | Of course, it'd be | good to fix it, but must be done in the proper way. | | I'm glad to help with testing if I have time. Indeed. I see. -- Gaby
Re: Default arguments and FUNCTION_TYPEs
Giovanni Bajo [EMAIL PROTECTED] writes: | Gabriel Dos Reis [EMAIL PROTECTED] wrote: | | Fixing a PR introducing a regression is not a proper fix for any bug, | *especially* for a bug which is not a regression itself. | | Thanks for the lecture. | | Not just because this is not a regression does not mean it does not | need fixing. | | I just warned you that finding a proper fix might be harder than you had | expected. I think I anticipated that. What I do not quite understand is your apparant insisting of not fixing the bug (that people did run inito), inventing reason that no GCC user could have faced it. | But I should just shut up and let you waste your time. you wasted more of my time than I'm wasting on this PR. Did you suggest any *concrete* representation, you would have made less noise. -- Gaby
Default arguments and FUNCTION_TYPEs
Hi, In the C++ front end, default arguments are recorded in FUNCTION_TYPEs intead of being part of the FUNCTION_DECLs. What are the reasons for that? -- Gaby
Re: Default arguments and FUNCTION_TYPEs
Gabriel Dos Reis wrote: Hi, In the C++ front end, default arguments are recorded in FUNCTION_TYPEs intead of being part of the FUNCTION_DECLs. What are the reasons for that? There used to be an extension that allowed default arguments on function pointer types. We agreed to kill it, although I don't know if it was actually removed. If that's been done, there's no longer any reason. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Default arguments and FUNCTION_TYPEs
Mark Mitchell [EMAIL PROTECTED] writes: | Gabriel Dos Reis wrote: | Hi, | |In the C++ front end, default arguments are recorded in | FUNCTION_TYPEs intead of being part of the FUNCTION_DECLs. What are | the reasons for that? | | There used to be an extension that allowed default arguments on function | pointer types. We agreed to kill it, although I don't know if it was | actually removed. If that's been done, there's no longer any reason. Great! I seem to remember it was killed (and I would say you killed it but I may be wrong.) I'll investigate. Assuming the extension was gone, do you see a reason we not move the default arguments to FUNCTION_DECLs and have FUNCTION_TYPEs use TREE_VEC instead of TREE_LIST to hold the parameter-type list? -- Gaby
Re: Default arguments and FUNCTION_TYPEs
Gabriel Dos Reis wrote: Assuming the extension was gone, do you see a reason we not move the default arguments to FUNCTION_DECLs and have FUNCTION_TYPEs use TREE_VEC instead of TREE_LIST to hold the parameter-type list? Both things sound OK to me. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Default arguments and FUNCTION_TYPEs
Gabriel Dos Reis wrote: Assuming the extension was gone, do you see a reason we not move the default arguments to FUNCTION_DECLs and have FUNCTION_TYPEs use TREE_VEC instead of TREE_LIST to hold the parameter-type list? you could probably use a VEC(tree), which I think would be even better :) nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
