This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, PR c++/41503] Make function_parameter_expanded_from_pack_p() return false if DECL_ARTIFICIAL (param_decl)
- From: Martin Jambor <mjambor at suse dot cz>
- To: Dodji Seketeli <dodji at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 30 Sep 2009 17:32:51 +0200
- Subject: Re: [PATCH, PR c++/41503] Make function_parameter_expanded_from_pack_p() return false if DECL_ARTIFICIAL (param_decl)
- References: <20090929165059.GA13517@virgil.suse.cz> <4AC34EDF.4060205@redhat.com>
Hi,
On Wed, Sep 30, 2009 at 02:28:15PM +0200, Dodji Seketeli wrote:
> Hello Martin,
>
> I not a maintainer so please take my comments with a grain of salt :)
>
> Le 29/09/2009 18:51, Martin Jambor a Ãcrit :
>> Hi,
>>
>> the patch below fixes a number of segmentation faults in the libstdc++
>> testsuite when IPA-SRA is turned on. Somehow IPA-SRA created
>> PARM_DECLs get passed to function_parameter_expanded_from_pack_p()
>> through dwrf2out and early inlining nowadays. These don't have
>> language specific info and so access to it segfaults.
>
> Okay, I guess you mean DECL_LANG_SPECIFIC is not set for the PARM_DECLs at
> this point then.
>
>>
>> This patch fixes the problem by not trying to go to this info if
>> DECL_ARTIFICIAL is set on the parm_decl. At least I hope that is the
>> correct approach.
>
> Why not testing if DECL_LANG_SPECIFIC is set instead ? I mean, who knows if
> in the future there couldn't be a compiler generated PARM_DECL
> (DECL_ARTIFICIAL would then be set) that is expanded from a parameter pack
That might be a good point. However, as I do not know about ther
conventions in this part of the compiler, I will do whichever of the
two possibilities that a C++ maintainer approves.
Thanks,
Martin