Looks good; I fixed a few whitespace and formatting issues and checked
in the patch. Thanks a lot!
Jason
2011/11/11 Jason Merrill :
> On 11/11/2011 04:42 AM, Dodji Seketeli wrote:
>>
>> Fabien Chêne a écrit:
>>
>>> Are the other debugging backends not interested at all in USING_DECLs ?
>>
>> The way debug info is generated for USING_DECLs is that
>> handle_using_decl (via cp_emit_debug_info_for_using
On 11/11/2011 04:42 AM, Dodji Seketeli wrote:
Fabien Chêne a écrit:
Are the other debugging backends not interested at all in USING_DECLs ?
The way debug info is generated for USING_DECLs is that
handle_using_decl (via cp_emit_debug_info_for_using) asks the backend to
generate debug info for
Fabien Chêne a écrit:
> Are the other debugging backends not interested at all in USING_DECLs ?
The way debug info is generated for USING_DECLs is that
handle_using_decl (via cp_emit_debug_info_for_using) asks the backend to
generate debug info for the DECLs the USING_DECL resolves to, basically
2011/11/10 Dodji Seketeli :
> Fabien Chêne a écrit:
>
>> Index: gcc/dbxout.c
>> ===
>> --- gcc/dbxout.c (revision 178088)
>> +++ gcc/dbxout.c (working copy)
>> @@ -1518,6 +1518,8 @@ dbxout_type_fields (tree type)
>> i
Fabien Chêne a écrit:
> Index: gcc/dbxout.c
> ===
> --- gcc/dbxout.c (revision 178088)
> +++ gcc/dbxout.c (working copy)
> @@ -1518,6 +1518,8 @@ dbxout_type_fields (tree type)
>if (TREE_CODE (tem) == TYPE_DECL
>
On 11/09/2011 03:58 PM, Fabien Chêne wrote:
Well, here it is. I've added a very simple function in order to guess
if a name is a declaration or a definition.
This seems unnecessary; a definition is also a declaration, so it's
always correct to talk about a previous declaration.
+ if
On 11/02/2011 05:04 PM, Fabien Chêne wrote:
Consequently, I think the current patch is not good enough without
that. Would you be OK with the changes suggested above ?
Sounds good.
Jason
2011/10/27 Jason Merrill :
[...]
>> 3) seems complicated: in finish_member_declaration, we must put away
>> the decl into TYPE_FIELDS or TYPE_METHODS, but we would like to put
>> the target_decl into TYPE_METHODS (and call add_method), and at the
>> same time put its using decl into TYPE_FIELDS...
On 10/24/2011 05:53 PM, Fabien Chêne wrote:
After looking into it a bit more, I now see things differently. The
target_decl is in fact put into the CLASSTYPE_METHOD_VEC at
instantiation time, via handle_using_decl, with the correct access.
Great.
The problem is that while parsing the template
Hi,
2011/10/12 Jason Merrill :
>>> Copying the decl is unlikely to do what we want, I think. Does putting
>>> the
>>> target decl directly into the method vec work?
>>
>> Unfortunately not, it ends up with the same error: undefined
>> reference.
>
> Hunh, that's surprising.
>
>> Furthermore, I do
On 10/16/2011 05:01 PM, Fabien Chêne wrote:
[...]
Does the attached testcase checked what you mention ?
... with the testcase attached.
Yes, that's what I had in mind.
Jason
[...]
> Does the attached testcase checked what you mention ?
... with the testcase attached.
--
Fabien
// { dg-do run }
template
struct A
{
int f() { return 1; }
};
template
struct B : A
{
int f() { return 2; }
using A::f;
void g()
{
if (A::f() != 1 )
__builtin_a
2011/10/12 Jason Merrill :
>>> Copying the decl is unlikely to do what we want, I think. Does putting
>>> the
>>> target decl directly into the method vec work?
>>
>> Unfortunately not, it ends up with the same error: undefined
>> reference.
>
> Hunh, that's surprising.
I have found it quite surp
Copying the decl is unlikely to do what we want, I think. Does putting the
target decl directly into the method vec work?
Unfortunately not, it ends up with the same error: undefined
reference.
Hunh, that's surprising.
Furthermore, I don't think it is the right approach since
the access may
e
PR c++/6936
PR c++/25994
PR c++/26256
PR c++/30195
* dbxout.c (dbxout_type_fields): Ignore using declarations.
gcc/testsuite/ChangeLog
2011-10-11 Fabien Chêne
PR c++/6936
PR c++/25994
PR c++/26256
PR c++/30195
On 10/10/2011 03:56 PM, Fabien Chêne wrote:
It tried to add the target declaration of a USING_DECL in the
method_vec of the class where the USING_DECL is declared. Thus, I
copied the target decl, adjusted its access, and then called
add_method with the target decl.
Copying the decl is unlikely
e're in
>>> lookup_field_1, which isn't interested in functions, so I guess we do
>>> want
>>> to ignore function using-declarations here.
>>
>> That's strange because if we do return FUNCTION_DECL, PR c++/30195 seems
>> solved.
>
>
18 matches
Mail list logo
