Re: [C++ Patch] for c++/51214
2012/6/7 Fabien Chêne fabien.ch...@gmail.com: [...] ... committed as rev 188294. I will backport it to 4.7 when it unfreezes. ... Eventually backported as rev 189021. -- Fabien
Re: [C++ Patch] for c++/51214
2012/6/3 Fabien Chêne fabien.ch...@gmail.com: 2012/6/3 Jason Merrill ja...@redhat.com: On 05/24/2012 09:18 AM, Jason Merrill wrote: OK, thanks. I notice you haven't checked the patch in yet, is there a problem? Not at all, just lack of time, so many problems/holidays to tackle at the moment... That is May month in France ;-) I'll be checking in it the next few days. ... committed as rev 188294. I will backport it to 4.7 when it unfreezes. -- Fabien
Re: [C++ Patch] for c++/51214
2012/6/3 Gabriel Dos Reis g...@integrable-solutions.net: On Sun, Jun 3, 2012 at 10:56 AM, Fabien Chêne fabien.ch...@gmail.com wrote: 2012/6/3 Jason Merrill ja...@redhat.com: On 05/24/2012 09:18 AM, Jason Merrill wrote: OK, thanks. I notice you haven't checked the patch in yet, is there a problem? Not at all, just lack of time, so many problems/holidays to tackle at the moment... That is May month in France ;-) It must be distressing to make up for those 35 hours ;-p Provided we do not respond as an ideal gas (P = nRT/V), it should be fine ;-) -- Fabien
Re: [C++ Patch] for c++/51214
2012/6/3 Jason Merrill ja...@redhat.com: On 05/24/2012 09:18 AM, Jason Merrill wrote: OK, thanks. I notice you haven't checked the patch in yet, is there a problem? Not at all, just lack of time, so many problems/holidays to tackle at the moment... That is May month in France ;-) I'll be checking in it the next few days. -- Fabien
Re: [C++ Patch] for c++/51214
On Sun, Jun 3, 2012 at 10:56 AM, Fabien Chêne fabien.ch...@gmail.com wrote: 2012/6/3 Jason Merrill ja...@redhat.com: On 05/24/2012 09:18 AM, Jason Merrill wrote: OK, thanks. I notice you haven't checked the patch in yet, is there a problem? Not at all, just lack of time, so many problems/holidays to tackle at the moment... That is May month in France ;-) It must be distressing to make up for those 35 hours ;-p -- Gaby
Re: [C++ Patch] for c++/51214
On 05/24/2012 09:18 AM, Jason Merrill wrote: OK, thanks. I notice you haven't checked the patch in yet, is there a problem? Jason
Re: [C++ Patch] for c++/51214
OK, thanks. Jason
Re: [C++ Patch] for c++/51214
2012/5/7 Jason Merrill ja...@redhat.com: On 05/06/2012 04:06 PM, Fabien Chêne wrote: + if (late_enum_values) + VEC_safe_push (tree, gc, late_enum_values, decl); I would think you could walk the TYPE_VALUES list directly, rather than copy it into a temporary VEC. Indeed, let's use good old tree lists. Tested x86_64-unknown-linux-gnu, OK for trunk and 4.7 ? gcc/testsuite/ChangeLog 2012-05-23 Fabien Chêne fab...@gcc.gnu.org PR c++/51214 * g++.dg/cpp0x/forw_enum11.C: New. gcc/cp/ChangeLog 2012-05-23 Fabien Chêne fab...@gcc.gnu.org PR c++/51214 * cp-tree.h (insert_late_enum_def_into_classtype_sorted_fields): Declare. * class.c (insert_into_classtype_sorted_fields): New. (add_enum_fields_to_record_type): New. (count_fields): Adjust the comment. (add_fields_to_record_type): Likewise. (finish_struct_1): Move the code that inserts the fields for the sorted case, into insert_into_classtype_sorted_fields, and call it. (insert_late_enum_def_into_classtype_sorted_fields): Define. * decl.c (finish_enum_value_list): Call insert_late_enum_def_into_classtype_sorted_fields if a late enum definition is encountered. -- Fabien 51214.patch Description: Binary data
Re: [C++ Patch] for c++/51214
On 05/06/2012 04:06 PM, Fabien Chêne wrote: + if (late_enum_values) + VEC_safe_push (tree, gc, late_enum_values, decl); I would think you could walk the TYPE_VALUES list directly, rather than copy it into a temporary VEC. Jason
Re: [C++ Patch] for c++/51214
2012/2/29 Jason Merrill ja...@redhat.com: On 02/28/2012 05:06 PM, Fabien Chêne wrote: I agree, this is not efficient but I didn't find a better place. perhaps in cp_parser_enumerator_list, that would require adding an additional parameter to keep track of all the enum DECLs. Is it what you have in mind ? I was thinking of finish_enum_value_list. OK great. I have tried to reuse the existing infrastructure to extend the CLASSTYPE_SORTED_FIELDS, unfortunately, it does not seem possible because the code uses a tree chain (chained with DECL_CHAIN), and this field is already used for enum values to store the enum type. Among various possibilities, in the end, I think it is clearer to handle the lately defined enum case separately. That is what I have done in the attached patch. Unqualified lookup works because when the type is not complete, the lookup uses the non sorted case, which always works. OK, just make sure we have a test for that. I have added a check in forw_enum11.C for that. Boostrapped and tested on x86_64-unknown-linux-gnu, OK to commit ? gcc/testsuite/ChangeLog 2012-05-06 Fabien Chêne fab...@gcc.gnu.org PR c++/51214 * g++.dg/cpp0x/forw_enum11.C: New. gcc/cp/ChangeLog 2012-05-06 Fabien Chêne fab...@gcc.gnu.org PR c++/51214 * cp-tree.h (insert_late_enum_def_into_classtype_sorted_fields): Declare. * class.c (insert_into_classtype_sorted_fields): New. (add_enum_fields_to_record_type): New. (count_fields): Adjust the comment. (add_fields_to_record_type): Likewise. (finish_struct_1): Move the code that inserts the fields for the sorted case, into insert_into_classtype_sorted_fields, and call it. (insert_late_enum_def_into_classtype_sorted_fields): Define. * decl.c (finish_enum_value_list): Call insert_late_enum_def_into_classtype_sorted_fields if a late enum definition is encountered. -- Fabien pr51214.patch Description: Binary data
Re: [C++ Patch] for c++/51214
On 02/28/2012 05:06 PM, Fabien Chêne wrote: I agree, this is not efficient but I didn't find a better place. perhaps in cp_parser_enumerator_list, that would require adding an additional parameter to keep track of all the enum DECLs. Is it what you have in mind ? I was thinking of finish_enum_value_list. Unqualified lookup works because when the type is not complete, the lookup uses the non sorted case, which always works. OK, just make sure we have a test for that. Jason
[C++ Patch] for c++/51214
Hi, The problem in this PR is that the CLASSTYPE_SORTED_FIELDS is created too early (in finish_struct_1) to handle those late unscoped enum definitions. Consequently, I propose to lately add those names in CLASSTYPE_SORTED_FIELDS when they are encountered, in build_enumerator. Tested x86_64-unknown-linux-gnu, OK for 4.7 ? gcc/testsuite/ChangeLog 2012-02-27 Fabien Chêne fab...@gcc.gnu.org * g++.dg/cpp0x/forw_enum11.C: New. gcc/cp/ChangeLog 2012-02-27 Fabien Chêne fab...@gcc.gnu.org * cp-tree.h (insert_into_classtype_sorted_fields): Declare. * class.c (finish_struct_1): Move the code into insert_into_classtype_sorted_fields, and call it. (insert_into_classtype_sorted_fields): Define. * decl.c (build_enumerator): Call insert_into_classtype_sorted_fields if an enumerator-definition referring to a class scope opaque enum has been encountered. -- Fabien 51214.patch Description: Binary data
Re: [C++ Patch] for c++/51214
Minor nit: the correct spelling is threshold, not threashold. Thanks, Paolo.
Re: [C++ Patch] for c++/51214
On 02/28/2012 03:36 PM, Fabien Chêne wrote: * decl.c (build_enumerator): Call insert_into_classtype_sorted_fields if an enumerator-definition referring to a class scope opaque enum has been encountered. This will insert and sort the vector again for each enumerator; we should wait and sort after we've seen all of them. Will unqualified lookup work because we're in the enumeration scope, or do we need to make lookup in the class work? + equal to THREASHOLD or greater than THREASHOLD. */ No 'a' in threshold. Jason
Re: [C++ Patch] for c++/51214
2012/2/28 Jason Merrill ja...@redhat.com: On 02/28/2012 03:36 PM, Fabien Chêne wrote: * decl.c (build_enumerator): Call insert_into_classtype_sorted_fields if an enumerator-definition referring to a class scope opaque enum has been encountered. This will insert and sort the vector again for each enumerator; we should wait and sort after we've seen all of them. I agree, this is not efficient but I didn't find a better place. perhaps in cp_parser_enumerator_list, that would require adding an additional parameter to keep track of all the enum DECLs. Is it what you have in mind ? Will unqualified lookup work because we're in the enumeration scope, or do we need to make lookup in the class work? Sorry, could you specify what you mean ? -- Fabien
Re: [C++ Patch] for c++/51214
2012/2/28 Fabien Chêne fabien.ch...@gmail.com: 2012/2/28 Jason Merrill ja...@redhat.com: On 02/28/2012 03:36 PM, Fabien Chêne wrote: [...] Will unqualified lookup work because we're in the enumeration scope, or do we need to make lookup in the class work? Unqualified lookup works because when the type is not complete, the lookup uses the non sorted case, which always works. -- Fabien
