2016-08-30 17:34 GMT+02:00 Prathamesh Kulkarni :
> On 30 August 2016 at 20:24, Tom de Vries wrote:
>> On 26/08/16 13:39, Prathamesh Kulkarni wrote:
>>>
>>> Hi,
>>> The following patch adds option -Wrestrict that warns when an argument
>>> is passed to a restrict qualified parameter and it aliases
2014-11-03 21:18 GMT+01:00 Fabien Chêne :
> 2014-10-09 15:34 GMT+02:00 Jason Merrill :
> [...]
>>> If the USING_DECL is returned, the code below will be rejected as
>>> expected, but the error message will not mention the line where the
>>> USING_DECL appears as th
2014-10-09 15:34 GMT+02:00 Jason Merrill :
[...]
>> If the USING_DECL is returned, the code below will be rejected as
>> expected, but the error message will not mention the line where the
>> USING_DECL appears as the previous definition, but at the target
>> declaration of the USING_DECL instead.
2014-10-07 23:13 GMT+02:00 Jason Merrill :
> On 09/24/2014 05:15 PM, Jason Merrill wrote:
>>
>> On 09/24/2014 05:06 PM, Fabien Chêne wrote:
>>>
>>> Unfortunately, just stripping the USING_DECL in lookup_and_check_tag
>>> does not really work because some
e purpose is to know if stripping USING_DECLs is
desirable. Not very exciting to fix it this way, but that is the only
solution I managed to find.
Tested x86_64 linux without regressions. OK to commit to trunk ? And
branches after some weeks of incubation ?
gcc/cp/ChangeLog
2014-09-24 Fabien Ch
Hi,
Idem than the previous patchlets, this time concerning 'pedwarn'.
Tested x86_64 linux. OK to commit ?
cp/ChangeLog
2014-04-04 Fabien Chêne
* pt.c (check_template_variable): Check for the return of pedwarn
before emitting a note.
* parser.c (cp_parser_lambda_
Hi,
next victim of the cleanup: warning_at.
Tested x86_64 linux without regressions. OK to commit ?
cp/ChangeLog
2014-04-04 Fabien Chêne
* decl.c (duplicate_decls): Check for the return of warning_at
before emitting a note.
(warn_misplaced_attr_for_class_type): Likewise
Hi,
Following the previous patchlet about conditional notes after
'permerror', same cleanup with 'warning'. Tested x86_64 linux without
regressions. OK to commit ?
cp/ChangeLog
2014-04-04 Fabien Chêne
* class.c (find_abi_tags_r): Check for the return of warning
2014-04-02 22:39 GMT+02:00 Jason Merrill :
> On 04/02/2014 04:21 PM, Fabien Chêne wrote:
>>
>> * cp/decl.c (duplicate_decls): Check for the return of
>> permerror before emitting a note.
>
>
> You don't need "cp/" within cp/ChangeLog. OK
(olddecl),
>> "previous specification in %q#D here",
>> olddecl);
>>
>> should the second permerror be a note instead ?
>
>
> Yes.
OK to commit the attached patch ?
Tested x86_64 linux, though this piece of code doe
2014-03-28 17:59 GMT+01:00 Jason Merrill :
[...]
> The inform should only happen if permerror returns true (i.e. without
> -fpermissive -w). OK with that change.
I did a little tour around the permerror uses, and found that in decl.c:
if (permerror (input_location,
"defaul
2014-03-28 17:59 GMT+01:00 Jason Merrill :
> On 03/27/2014 05:32 PM, Fabien Chêne wrote:
>>
>> + permerror (DECL_SOURCE_LOCATION (current_function_decl),
>> +"uninitialized reference member in %q#T", type);
>> +
2014-03-28 20:27 GMT+01:00 Mike Stump :
> Just a nit...
>
>> 2014-03-28 Fabien Chêne
>>
>>* cp/init.c (perform_member_init): homogeneize uninitialized
>>diagnostics.
>
> Sentences begin with an upper case letter, and spelling... Homogenize..
I will fix that, thanks.
--
Fabien
Hi,
As a followup, the following patch homogeneise some diagnostics that
relate to uninitialized const or reference members.
Tested x86_64 linux in progress, OK to commit for next stage 1 if that
succeeds ? (or trunk otherwise, I dare to mention it).
2014-03-28 Fabien Chêne
* cp/init.c
2014-03-07 22:43 GMT+01:00 Jason Merrill :
> The first patch changes the C++ testsuite to run in C++14 mode as well as
> C++98 and C++11.
As a result, specifying { target c++11 } matches c++11 and c++1y mode.
{ target c++1y } matches c++1y only, and { target c++98 } matches c++98 only.
Is that cor
Hi, sorry for the delay,
2014-03-03 2:16 GMT+01:00 Jason Merrill :
[...]
> Yes, in C++11 the point of use is the source location of the constructor,
> which is going to be different from where the constructor is called. I just
> meant use the same wording.
There we are, locating a point of use t
2014-03-21 1:33 GMT+01:00 Paul Pluzhnikov :
> Greetings,
>
> Attached patch deletes code to warn about repeated friend declaration.
Why not making this warning suppressable, instead of removing it ?
Shouldn't it fall under -W(no)-redundant-decls ?
--
Fabien
2014-02-28 22:52 GMT+01:00 Fabien Chêne :
> 2014-02-28 22:27 GMT+01:00 Jason Merrill :
>> Let's change the C++11 diagnostic to match the C++98 diagnostic. So,
>> "uninitialized const member in %q#T" + "%qD should be initialized".
>
> OK.
Hmm, sorry t
2014-02-28 22:52 GMT+01:00 Fabien Chêne :
>>> Incidentally, while moving the diagnostic concerning the uninitialized
>>> field from an error to an inform, I realized that the syntactic sugar
>>> %q#D is no longer honored an is treated as %qD, is it expected ?
>>
2014-02-28 22:27 GMT+01:00 Jason Merrill :
> Let's change the C++11 diagnostic to match the C++98 diagnostic. So,
> "uninitialized const member in %q#T" + "%qD should be initialized".
OK.
>> Incidentally, while moving the diagnostic concerning the uninitialized
>> field from an error to an infor
2014-02-27 19:25 GMT+01:00 Jason Merrill :
> On 02/23/2014 02:36 PM, Fabien Chêne wrote:
>>
>> * cp/method.c (walk_field_subobs): improve the diagnostic
>> locations for both REFERENCE_TYPEs and non-static const members.
>
>
> It's important to h
Ping (yeah boring to review!)
2014-02-23 20:36 GMT+01:00 Fabien Chêne :
> Ahem, patch resubmitted with the testsuite correctly adjusted this
> time. Tested x86_64 linux, still OK to commit ?
>
> 2014-02-23 Fabien Chene
> PR c++/52369
> * cp/method.c (walk_fiel
: Likewise.
* g++.dg/init/ctor8.C: Likewise.
* g++.dg/init/uninitialized1.C: Likewise.
--
Fabien
2014-02-06 18:04 GMT+01:00 Fabien Chêne :
> Hi,
>
> This bug seems already fixed on mainline. I have added two testcases,
> but as the C++11 one is not obvious to me, I guess this p
Hi,
This bug seems already fixed on mainline. I have added two testcases,
but as the C++11 one is not obvious to me, I guess this path does not
qualify as obvious. Incidentally, while writing the C++11 testcase, I
realized that the diagnostic was not emitted at the proper location
and fixed it.
O
2014-01-28 Jason Merrill :
> On 01/27/2014 04:28 PM, Fabien Chêne wrote:
>>
>> + if (DECL_DEPENDENT_P (decl) && USING_DECL_TYPENAME_P (decl))
>> +{
>> + /* We have found a type introduced by a using
>> +declaration at class scope th
Hi,
We fail here to create a typename_type on dependent using
declarations. In fact, facing a USING_DECLs on spotted places, either
we want to strip non-dependent USING_DECLs or we want to create a
typename_type. The attached patch simply propagates the change made to
fix c++/14258 through strip_u
Hi,
2013/5/23 Jason Merrill
>
> On 05/22/2013 04:53 PM, Fabien Chêne wrote:
>>
>> Ah, I see, it works. Then we end up with three solutions:
>> 1) remove the pow(double,double) overload
>> 2) add a specialization template <> pow(double,double)
>> 3) add a
Hi,
Again sorry for such a delay. Paolo subtly ping'ed me on DR39
(c++/13590), and I remember that this bug (c++/54537) was blocking the
patch I wrote last year for DR39.
2012/11/15 Jason Merrill :
[...]
> I was only thinking of the primary signature; putting
>
> extern "C" double pow (double, do
Hi,
Please see details on Bugzilla.
Tested x86_64-unknown-linux-gnu without regressions.
gcc/testsuite/ChangeLog
2012-02-25 Fabien Chêne
PR c++/56243
* g++.dg/cpp0x/pr56243.C: New.
gcc/cp/ChangeLog
2012-02-25 Fabien Chêne
PR c++/56243
* class.c
Hi,
2012/11/14 Jason Merrill :
> I'll just note that another solution would be to change non-template
> forwarding pows to be extern "C" declarations. But it sounds like you folks
> have this issue in hand.
I'm a bit puzzled by your suggestion, altough I have not tried it yet,
how can it work gi
legacy TR1 stuff, IMO.
Good, here is the patch then, bootstrapped and tested
x86_64-unknown-linux-gnu without regressions on a old tree.
I plan to perform an additional testing before committing anyway.
2012-11-14 Fabien Chêne
PR c++/54537
* cp-tree.h: Check OVL_US
hi,
2012/9/19 Paolo Carlini :
> Hi Fabien,
>
>
> On 09/19/2012 07:29 PM, Fabien Chêne wrote:
>>>>
>>>> But I'm afraid this is still not completely correct, because if the user
>>>> code has a using std::pow in the global namespace and then and
Jason, could you please have a look at this (rather old) one ?
Thanks.
2012/8/13 Fabien Chêne :
> Hi,
>
> Here, we were setting the LOOKUP_NONVIRTUAL flag wrongly. Actually, we
> need to check if the function context is the same than the instance
> type -- yes that might happ
Hi Paolo,
2012/9/19 Paolo Carlini :
> On 09/19/2012 01:24 AM, Paolo Carlini wrote:
>>
>> On 09/19/2012 01:12 AM, Paolo Carlini wrote:
>>>
>>> Hi again,
>>>
>>> On 09/18/2012 08:33 PM, Paolo Carlini wrote:
But I'm not surprised, frankly, I think the conflict is expected, *IF*
(please
2012/9/18 Paolo Carlini :
> I don't understand: what's wrong - exactly - with the std::tr1::pow (double,
> double) overload above? Now I can't immediately check, but do the EDG and
> CLANG front ends accept it or not?
They don't. The problem is that it conflicts with ::pow(double,double).
// i
... And the patch.
2012/9/18 Fabien Chêne :
> 2012/9/11 Fabien Chêne :
>> Oops, not sure how I test that change initially, or I must be blind,
>> because it triggers an error in tr1/cmath about pow. I'll see what I
>> can do...
>
> Well, as summarized in the cod
2012/9/11 Fabien Chêne :
> Oops, not sure how I test that change initially, or I must be blind,
> because it triggers an error in tr1/cmath about pow. I'll see what I
> can do...
Well, as summarized in the code below, the problem seems to be the
redundant overload of std::tr1::pow
Oops, not sure how I test that change initially, or I must be blind,
because it triggers an error in tr1/cmath about pow. I'll see what I
can do...
2012/9/10 Jason Merrill :
> OK.
>
> Jason
--
Fabien
-09 Fabien Chêne
PR c++/54537
* cp-tree.h: Check OVL_USED with OVERLOAD_CHECK.
* name-lookup.c (do_nonmember_using_decl): Make sure we have an
OVERLOAD before calling OVL_USED.
2012-09-09 Fabien Chêne
PR c++/54537
* g++.dg/overload/using3.C
Hi Paolo,
2012/8/23 Jason Merrill :
[...]
>> The below passes testing, anyway.
>
>
> OK.
>
> Jason
Thanks for tackling this "using" bug !
Incidentally, as you seem to be used to visiting old C++ bugs, feel
free to ping/assign me on bugs that concern using-declarations --
obviously if you do not p
y room for improvement here, though I'm not sure the C++ front
end is the better place to de-virtualize.
Tested x84_64-unknown-linux-gnu without regressions. OK to commit ?
gcc/testsuite/ChangeLog
2012-08-12 Fabien Chêne
PR c++/11750
* g++.dg/inherit/vitual9.C: New.
gcc/cp/
2012/6/7 Fabien Chêne :
[...]
> ... committed as rev 188294.
> I will backport it to 4.7 when it unfreezes.
... Eventually backported as rev 189021.
--
Fabien
2012/6/6 Jason Merrill :
[...]
> Often if we continue parsing something on the assumption that the previous
> bits are correct it leads to problems; that's all there is to this bug.
> When we see
>
> using sat::Solvable::bool_type;
>
> cp_parser_alias_declaration eats "sat" and then tries to pars
2012/6/3 Fabien Chêne :
> 2012/6/3 Jason Merrill :
>> 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 pr
2012/6/5 Jason Merrill :
> OK.
Out of curiosity, do you happen to know what kind of problem was
triggered here ?
Shouldn't we fix the underlying issue as well ? Unless that the
canonical way to solve it be to simply return earlier...
Thanks,
--
Fabien
2012/6/3 Gabriel Dos Reis :
> On Sun, Jun 3, 2012 at 10:56 AM, Fabien Chêne wrote:
>> 2012/6/3 Jason Merrill :
>>> On 05/24/2012 09:18 AM, Jason Merrill wrote:
>>>>
>>>> OK, thanks.
>>>
>>>
>>> I notice you haven't checked
2012/6/3 Jason Merrill :
> 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
2012/5/7 Jason Merrill :
> 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 tem
2012/5/21 Paolo Carlini :
> On 05/21/2012 01:45 AM, Michael Hope wrote:
>>
>> The testsuite for PR52796 uses the 'target c++11' selector which doesn't
>> exist in 4.6.
>> This patch backports the selector, clearing the 'ERROR:
>> g++.dg/cpp0x/variadic-value1.C:
>> syntax error in target selector "t
2012/2/29 Jason Merrill :
> 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 en
2012/4/11 Jason Merrill :
[...]
> Your ChangeLog needs to be adjusted. :)
I did write an updated ChangeLog, but I pasted here the wrong one...
I committed it to trunk yesterday, hopefully with the correct
ChangeLog . I'll be backporting it to 4.7 after a relaxing weekend :-)
--
Fabien
2012/4/7 Jason Merrill :
> On 04/07/2012 11:37 AM, Fabien Chêne wrote:
>>
>> Perhaps it is more correct like that, in cp_parser_set_decl_spec_type ?
>
> Even that seems late. Why not just return the target decl from
> cp_parser_class_name?
Ah yes, that's slightl
2012/3/12 Fabien Chêne :
> Salut Dodji,
>
> 2012/3/12 Dodji Seketeli :
> [...]
>>> Index: gcc/cp/decl.c
>>> ===
>>> --- gcc/cp/decl.c (revision 184891)
>>> +++ gcc/cp/
2012/3/29 Jason Merrill :
> On 03/08/2012 04:34 PM, Fabien Chêne wrote:
>>
>> * decl.c (grokdeclarator): Call strip_using_decl.
>
>
> I would think we ought to be stripping USING_DECLs at a lower level, when we
> first look up the name in the parser. They
Salut Dodji,
2012/3/12 Dodji Seketeli :
[...]
>> Index: gcc/cp/decl.c
>> ===
>> --- gcc/cp/decl.c (revision 184891)
>> +++ gcc/cp/decl.c (working copy)
>> @@ -8686,6 +8686,9 @@ grokdeclarator (const cp_declarator *dec
>>
Hi,
In the end, I think we need again to strip some USING_DECLs in a
couple of places. Tested x86_64-unknown-linux-gnu. OK to commit (for
whatever appropriate) ?
gcc/testsuite/ChangeLog
2012-03-08 Fabien Chêne
PR c++/52465
* g++.dg/lookup/using52.C: New.
gcc/cp/ChangeLog
2012/2/28 Fabien Chêne :
> 2012/2/28 Jason Merrill :
>> 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 becau
2012/2/28 Jason Merrill :
> 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
ted x86_64-unknown-linux-gnu, OK for 4.7 ?
gcc/testsuite/ChangeLog
2012-02-27 Fabien Chêne
* g++.dg/cpp0x/forw_enum11.C: New.
gcc/cp/ChangeLog
2012-02-27 Fabien Chêne
* cp-tree.h (insert_into_classtype_sorted_fields): Declare.
* class.c (finish_struct_1): Move the
2012/2/16 Jason Merrill :
> On 02/16/2012 01:47 PM, Fabien Chêne wrote:
>>
>> + tree binfo_type = TYPE_MAIN_VARIANT (BINFO_TYPE (binfo));
>
>
> BINFO_TYPE should already be its TYPE_MAIN_VARIANT. Why isn't it here?
>
>
>> For (2), the lookup was failing b
work correctly.
Tested x86_64-unknown-linux-gnu without regressions.
gcc/testsuite/ChangeLog
2012-02-16 Fabien Chêne
* g++.dg/template/using21.C: New.
* g++.dg/template/using22.C: Likewise.
gcc/cp/ChangeLog
2012-02-16 Fabien Chêne
* search.c (dfs_lookup_base):
2012/2/12 Gerald Pfeifer :
> On Fri, 27 Jan 2012, Fabien Chêne wrote:
>> I get back to you for the snippet about deprecated access
>> declarations. I would also find it sensible to advertise about the fix
>> of c++/14258, a popular bug I have hit myself many times. OK t
Ping ?
2012/1/27 Fabien Chêne :
> Hi Gerald,
>
> 2012/1/13 Fabien Chêne :
> [...]
>>> Mind suggesting a snippet for our release notes at
>>> http://gcc.gnu.org/gcc-4.7/changes.html ?
>>
>> Yes, sure, thanks for suggestion. Unfortunately, my machine is
&g
Hi Gerald,
2012/1/13 Fabien Chêne :
[...]
>> Mind suggesting a snippet for our release notes at
>> http://gcc.gnu.org/gcc-4.7/changes.html ?
>
> Yes, sure, thanks for suggestion. Unfortunately, my machine is
> currently down, I'll get back to you when it is repaired.
2012/1/19 Jason Merrill :
> When we have a class-scope using-declaration that nominates functions, we
> want to insert those functions into the derived class' CLASSTYPE_METHOD_VEC.
> In non-template code we do this in handle_using_decl, which is called from
> check_bases_and_members. But we don't
Hi,
2012/1/7 Gerald Pfeifer :
> On Thu, 29 Dec 2011, Fabien Chêne wrote:
>> As previously announced, here is a patch that deprecate access
>> declarations . I did a little tour in the GCC museum old-deja --and in
>> g++.dg as well -- to disinter and adjust those dusty tes
2011/12/30 Jason Merrill :
> Why // { dg-warning "" } deprecated on some tests, and
> // { dg-warning "deprecated" } on others? I would think all of the could
> use the second form.
I was believing that "// { dg-warning "" } deprecated" was the way to
test a warning in old-deja. If we can use the
declaration is actually valid.
Bootstrapped/Tested x86_64-unknown-linux-gnu, OK to commit ?
gcc/testsuite/ChangeLog
2011-12-28 Fabien Chêne
* g++.old-deja/g++.brendan/crash25.C: Adjust.
* g++.old-deja/g++.brendan/crash56.C: Likewise.
* g++.old-deja/g++.jason/access14.C
2011/12/27 Jason Merrill :
> On 12/27/2011 02:12 PM, Fabien Chêne wrote:
>>
>> - if (!scope_dependent_p)
>> + if (!dependent_scope_p (scope))
>
> I was thinking to change the line
>
>> scope_dependent_p = dependent_type_p (scope);
>
> to use dependent_s
ux-gnu, OK to commit ?
gcc/testsuite/ChangeLog
2011-12-27 Fabien Chêne
PR c++/23211
* g++.dg/template/using18.C: New.
* g++.dg/template/using19.C: New.
* g++.dg/template/nested3.C: Remove dg-message at instantiation.
* g++.dg/template/crash13.
to work.
Tested x86_64-unknown-linux-gnu, OK to commit ?
gcc/testsuite/ChangeLog
2011-12-20 Fabien Chêne
PR c++/23211
* g++.dg/template/using18.C: New.
* g++.dg/template/nested3.C: Remove dg-message on the
instantiation.
* g++.dg/template/crash13.C
2011/12/17 Jason Merrill :
> This testcase was aborting when we tried to check ENUM_UNDERLYING_TYPE on a
> non-enum. Fixed by checking the tree code first.
Ahem ... thank you !
--
Fabien
2011/12/13 Miles Bader :
> Jonathan Wakely writes:
> How about "...; suggest adding the using keyword"?
That sounds like the compiler is suggesting that the user suggests
doing that!
>>>
>>> It is similar to "suggest parentheses ...".
>>
>> Good point, that's not correct English
2011/12/12 Jason Merrill :
> On 12/11/2011 09:00 AM, Fabien Chêne wrote:
>>
>> Here, we weren't creating a typename_type for a dependent type
>> introduced by a using declaration. A USING_DECL was not recording the
>> fact that it refers to a dependent t
2011/12/11 Jonathan Wakely :
> On 11 December 2011 22:22, Fabien Chêne wrote:
>>
>> Consequently, I propose to deprecate them with a warning, as clang already
>> does.
>> So that you get a warning for the following code:
>>
>> struct A { int i; };
>> s
Hi,
According to § 11.3/1 from c++98, access delarations are deprecated:
The access of a member of a base class can be changed in the derived
class by mentioning its qualified-id in the derived class declaration.
Such mention is called an access declaration. The effect of an access
declaration qu
FLAG_1 for USING_DECLs), and set it appropriately in
cp_parser_using_declaration.
Tested x86_64-unkown-linux-gnu, OK to commit ?
gcc/testsuite/ChangeLog
2011-12-11 Fabien Chêne
PR c++/14258
* g++.dg/template/using16.C: New.
* g++.dg/template/using17.C: New.
gcc/cp
2011/12/5 Jason Merrill :
[...]
> Since finish_id_expression often returns something that isn't a decl at all,
> I think stripping the using here makes sense.
Good, here is an updated patch, (re)tested x86_64-unknown-linux-gnu.
OK to commit ?
--
Fabien
51319.patch
Description: Binary data
2011/12/5 Jason Merrill :
> Is there a reason not to just do
>
> decl = strip_using_decl (decl);
>
> early in finish_id_expression?
Not really, I've already tried it and it works. I wasn't sure it was
correct not to return a USING_DECL in aIl cases -- they are numerous
in this huge function. If y
ommit ?
gcc/testsuite/ChangeLog
2011-12-02 Fabien Chêne
PR c++/51319
* g++.dg/lookup/using50.C: New.
* g++.dg/lookup/using51.C: New.
gcc/cp/ChangeLog
2011-12-02 Fabien Chêne
PR c++/51319
* semantics.c (finish_id_expression): Strip using declaration
2011/11/18 Jason Merrill :
> On 11/18/2011 05:18 AM, Fabien Chêne wrote:
>>
>> +template< size_t, size_t> struct AlignedBuffer;
>> +template< size_t size> struct AlignedBuffer
>> +< size, 8> {
>> +};
>
> This testcase will break on
Hi,
As discussed in the audit trail, here is a patch that fixes this PR
and all its duplicates.
Tested x86_64-unknown-linux-gnu without regressions. OK to commit ?
gcc/testsuite/ChangeLog
2011-11-18 Fabien Chêne
PR c++/51188
* g++.dg/lookup/using46.C: New.
* g++.dg
Hi,
This patch fixes c++/51141, we simply need to strip the USING_DECL.
Tested x86_64-unknown-linux-gnu.
OK to commit ?
gcc/testsuite/ChangeLog
2011-11-15 Fabien Chêne
PR c++/51141
* g++.dg/lookup/using46.C: New.
gcc/cp/ChangeLog
2011-11-15 Fabien Chêne
PR c
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 USI
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 +151
Hi,
2011/11/9 Jason Merrill :
> On 11/09/2011 01:02 PM, Joseph S. Myers wrote:
>>
>> To confirm: what do the PASS or FAIL lines look like?
>
> For tests run in both modes, they look like
>
> PASS: g++.dg/whatever -std=c++98
> PASS: g++.dg/whatever -std=c++11
Nice, but ... is there a way to launch
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...
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
[...]
> 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
2011/10/11 Jason Merrill :
> 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 ca
Hi,
2011/9/26 Jason Merrill :
> On 09/25/2011 05:06 PM, Fabien Chêne wrote:
>>
>> + else if ((using_decl = strip_using_decl (member)) != member)
>
>> + /* If it is a using decl, use its underlying decl. */
>> + type_decl = strip_using_decl (type_decl);
&g
2011/9/23 Jason Merrill :
> On 09/22/2011 05:11 PM, Fabien Chêne wrote:
>>
>> 2011/9/22 Jason Merrill:
>
>>> I don't, it just seemed strange to handle functions differently from
>>> other
>>> decls here. But when I look more closely I see that w
2011/9/25 Paolo Carlini :
> On 09/25/2011 08:39 PM, Fabien Chêne wrote:
>>
>> And as a really minor detail, some empty constructor I added in
>> libstdc++-v3/src/future.cc, libstdc++-v3/src/system_error.cc, and
>> libstdc++-v3/testsuite/util/testsuite_error.h (
Jason,
Please ignore the previous patch, where I have introduced an
unintentional modification for PR c++/30195 in search.c, here is a new
one, sorry about that.
--
Fabien
Index: gcc/testsuite/g++.old-deja/g++.other/using1.C
===
---
2011/9/25 Paolo Carlini :
> ... nitpicking, of course, but in the testcases you have many blank trailing
> lines (and also some gratuitus, imho, blank lines in the middle)
Indeed, I've removed the blank trailing lines, and some in the middle,
not all though, I like it readable as well ;-)
--
Fa
agnosed in supplement_binding_1. Tested x86_64-unknown-linux-gnu, OK
to commit?
gcc/ChangeLog
2011-09-21 Fabien Chêne
PR c++/26256
* dbxout.c (dbxout_type_fields): Ignore using declarations.
gcc/testsuite/ChangeLog
2011-09-21 Fabien Chêne
PR c++/26256
PR c++/25994
2011/9/24 Jason Merrill :
[...]
> Tested x86_64-pc-linux-gnu, applied to trunk. I'm also considering applying
> it to 4.6 since we got more strict about the pre-253 rule in 4.6.
Great, I would be glad to see it applied to 4.6. If you do that, you
may also want to adjust the last paragraph in the
2011/9/23 Jason Merrill :
> On 09/22/2011 05:11 PM, Fabien Chêne wrote:
>>
>> 2011/9/22 Jason Merrill:
>
>>> I don't, it just seemed strange to handle functions differently from
>>> other
>>> decls here. But when I look more closely I see that w
2011/9/22 Jason Merrill :
> On 09/22/2011 04:22 AM, Fabien Chêne wrote:
>>
>> I would have thought that we want to do something with OVERLOAD here,
>> in order to get rid of PR c++/30195 and c++/25994 (removing a wrong
>> diagnostic additionaly)... But those PRs are alr
1 - 100 of 113 matches
Mail list logo
