This 4.1 regression is going to break one of the proposed benchmarks in spec2005. I believe that we have established that this code ----------------------------- template <class T> void f (T &, void (T::*)() ); template <class T> void f (const T &, void (T::*)() const); struct X { void g() const; }; const X *x; int main () { f (*x, &X::g); } -------------------------------- is valid because the pointer to the constant member &X::g can't match the first template (it wants a non-const pointer-to-member). The code is accepted by all previous gcc versions, but with present mainline I get this: spec/src> c++ -c x.cc x.cc: In function ‘int main()’: x.cc:11: error: call of overloaded ‘f(const X&, void (X::*)()const)’ is ambiguous x.cc:1: note: candidates are: void f(T&, void (T::*)()) [with T = const X] x.cc:2: note: void f(const T&, void (T::*)()const) [with T = X] Too bad... W.
Confirmed, I noticed that we accept the code if we get rid of the second template function (see PR 21801) so in GCC's mind it is ambiguous.
The PR Andrew cites is essentially a duplicate of PR 8271, which has been around for 2 1/2 years already. It is about the fact that gcc accepts a pointer to a constant member function for an argument that does not have the const specifier. However, up to now this didn't lead to an ambiguity: somehow gcc "knew" that the declaration with the 'const' specifier was a better match, but this was lost recently, as it appears. W.
I think this is a dup of bug 21066.
*** Bug 21066 has been marked as a duplicate of this bug. ***
Since this PR prevents me from running my nightly tests for more than 2 months now, could someone try to run the regression finder on the small testcase to find out who broke this and when? The duplicate of this PR indicates that this was before 2005-04-18, but I don't know how long before that... Thanks Wolfgang
Does my patch for 8271 fix this bug? If so, whatever caused this might just have exposed the problem, and fixing 8271 would fix this as well.
I also see this problem on the 4.0 branch now, with gcc version 4.0.1 20050531 (prerelease) I am pretty sure that it wasn't there in 4.0.0, but don't know for sure any more... W.
Giovanni, I can confirm that your patch for PR 8271 also fixes the problem in this PR. I would be extremely grateful if it would move somewhere... Cheers Wolfgang
Confirmed in 4.0.1 20050610 also. Hmm.
I think this was exposed by the patch for PR 19203 (aka DR 214), could you double check that, that patch makes sense if it exposes this bug.
I don't have the time to check it today, but could try tomorrow. It certainly sounds plausible. Nathan, could you comment on this problem? Thanks Wolfgang
Subject: Re: [4.0/4.1 regression] Spurious ambiguity with pointers to members > I think this was exposed by the patch for PR 19203 (aka DR 214), could you > double check that, that patch makes sense if it exposes this bug. It has become impossible to take out Nathan's patch from mainline, because the code has been worked over again in the meantime. A run through the regression tester may be the best chance to determine which patch broke this. W. ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@ices.utexas.edu www: http://www.ices.utexas.edu/~bangerth/
Subject: Re: [4.0/4.1 regression] Spurious ambiguity with pointers to members On Jun 21, 2005, at 4:43 PM, bangerth at ices dot utexas dot edu wrote: > > ------- Additional Comments From bangerth at ices dot utexas dot edu > 2005-06-21 20:43 ------- > Subject: Re: [4.0/4.1 regression] Spurious ambiguity with pointers to > members > > >> I think this was exposed by the patch for PR 19203 (aka DR 214), >> could you >> double check that, that patch makes sense if it exposes this bug. > > It has become impossible to take out Nathan's patch from mainline, > because the > code has been worked over again in the meantime. A run through the > regression > tester may be the best chance to determine which patch broke this. It might be easier to try to take it out on the 4.0 branch and easier to run the regression tester there, I don't have time to either because I am looking into the other bug you filed, the seg fault one. -- Pinski
Good idea. So I tried it, and indeed this patch 2005-05-10 Nathan Sidwell <nathan@codesourcery.com> PR c++/20723 * pt.c (more_specialized_fn): Member functions are unordered wrt non-members. Conversion operators are unordered wrt other functions. PR c++/19203, implement DR 214 * call.c (joust): Use more_specialized_fn. * cp-tree.h (DEDUCE_ORDER): Remove. (more_specialized): Replace with ... (more_specialized_fn): ... this. * pt.c (maybe_adjust_types_for_deduction): Remove DEDUCE_ORDER case. (type_unification_real): Remove DEDUCE_ORDER case. (more_specialized): Replace with ... (more_specialized_fn): ... this. Implement DR 214. (most_specialized_instantiation): Use get_bindings_real directly. to the 4.0 branch has caused the problem. It may be conjectured that the corresponding patch broke the same thing on mainline. That's bad -- we now have a regression between 4.0.0 and 4.0.1 :-( W.
For mainline, my patch has to be reworked as suggested by Jason in the review. It is not a difficult work, but I am working on another couple of big patches so don't hold your breath. As for the release branches, my patch might be acceptable there if and only if we decide that Nathan's patch can't be backed up. In which case, Nathan can probably both decide what to do with his patch, and re-review my patch for PR 8271 just for the 4.0 release branch.
Mark, since you are looking for bugs to be fixed in 4.0.1 again, would this regression between 4.0.0 and the present state of 4.0.1 interest you? This is code that also appears in boost... W.
Subject: Re: [4.0/4.1 regression] Spurious ambiguity with pointers to members bangerth at dealii dot org wrote: > ------- Additional Comments From bangerth at dealii dot org 2005-06-23 14:51 ------- > Mark, since you are looking for bugs to be fixed in 4.0.1 again, would > this regression between 4.0.0 and the present state of 4.0.1 interest > you? This is code that also appears in boost... Definitely a serious bug, but I'm not sure I want to try to fix it before 4.0.1. I'm really trying to confine myself to wrong-code bugs on primary platforms...
Subject: Re: [4.0/4.1 regression] Spurious ambiguity with pointers to members > Definitely a serious bug, but I'm not sure I want to try to fix it > before 4.0.1. I'm really trying to confine myself to wrong-code bugs on > primary platforms... It could be fixed by backing out Nathan's patch (that, to the best of my knowledge didn't fix a regression). But your statement is fair enough, thanks for the feedback! W. ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@ices.utexas.edu www: http://www.ices.utexas.edu/~bangerth/
Subject: Re: [4.0/4.1 regression] Spurious ambiguity with pointers to members bangerth at ices dot utexas dot edu wrote: > ------- Additional Comments From bangerth at ices dot utexas dot edu 2005-06-23 15:08 ------- > Subject: Re: [4.0/4.1 regression] Spurious ambiguity with > pointers to members > > > >>Definitely a serious bug, but I'm not sure I want to try to fix it >>before 4.0.1. I'm really trying to confine myself to wrong-code bugs on >>primary platforms... > > > It could be fixed by backing out Nathan's patch (that, to the best of my > knowledge didn't fix a regression). I've CC'd nathan -- but he's on a plane over the Atlantic right now, so I'm not sure we'll get a quick response. In any case, I think we can live with this until 4.0.2. Thanks,
> > It could be fixed by backing out Nathan's patch (that, to the best of my > > knowledge didn't fix a regression). it did not fix a regression, but was something we wanted added (as I beleive things like Boost were having problems). I waited a while after applying to mainline to see if there were any problem ... > > I've CC'd nathan -- but he's on a plane over the Atlantic right now, so > I'm not sure we'll get a quick response. In any case, I think we can > live with this until 4.0.2. I'll have a look and see if the fix is 'trivial'. My inclination is that if it is not, then we should do nothing for 4.0.1
looking carefully, this is exposing an existing bug that we deduce 'const X' against template <class T> void f (T &, void (T::*)() ); this should not happen. Previously we must have been deducing both and then selecting the second one as more specialized. Although I have not developed a patch, any patch will (more than likely) be non-trivial. I'll work on a fix, but don't think we should hold up 4.0.1 for it. Does 4.0.0 compile spec2005? If it does, then I don't think we expect any performance difference between 4.0.0 and 4.0.1 anyway. If it doesn't, are all of those failures fixed in 4.0.1? If they are not, I don't think this one change matters in that regard.
Subject: Re: [4.0/4.1 regression] Spurious ambiguity with pointers to members > Although I have not developed a patch, any patch will (more than likely) be > non-trivial. I'll work on a fix, but don't think we should hold up 4.0.1 > for it. Does 4.0.0 compile spec2005? I believe it does compile at least the one benchmark this affects. > If it does, then I don't think we > expect any performance difference between 4.0.0 and 4.0.1 anyway. If it > doesn't, are all of those failures fixed in 4.0.1? If they are not, I > don't think this one change matters in that regard. This PR will is about the that 4.0.1 won't be able to compile this one benchmark. However, given that SPEC 2005 isn't released yet, that's not such a big deal if the problem gets fixed in 4.0.2. I personally would like to see it fixed sooner rather than later, but I don't care too much if that is before or after 4.0.1 is released -- for me, the annoyance is just that if my nightly builds fail regularly, I don't catch other regressions that pop up over time, and things are only discovered at a later time... Cheers Wolfgang ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@ices.utexas.edu www: http://www.ices.utexas.edu/~bangerth/
Subject: Re: [4.0/4.1 regression] Spurious ambiguity with pointers to members (Sleep deprivation during the week leads to such marvels on Fridays...) > This PR will is about the that 4.0.1 won't This should read: "This PR is about the fact that 4.0.1 won't..."
Subject: Re: [4.0/4.1 regression] Spurious ambiguity with pointers to members bangerth at ices dot utexas dot edu wrote: > ------- Additional Comments From bangerth at ices dot utexas dot edu 2005-06-24 16:14 ------- > Subject: Re: [4.0/4.1 regression] Spurious ambiguity with pointers to members > > > (Sleep deprivation during the week leads to such marvels on Fridays...) > > >>This PR will is about the that 4.0.1 won't > > > This should read: "This PR is about the fact that 4.0.1 won't..." Given Nathan's analysis, we should definitely wait until 4.0.2 to fix this PR.
Postponed until 4.0.2.
Subject: Bug 21799 CVSROOT: /cvs/gcc Module name: gcc Changes by: nathan@gcc.gnu.org 2005-07-08 11:05:52 Modified files: gcc/cp : ChangeLog pt.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: unify8.C unify9.C Log message: cp: PR c++/21799 * pt.c (type_unification_real): Add is_method argument. Use it for this pointer unification. (fn_type_unification): Adjust type_unification_real call. (unify): Likewise. testsuite: PR c++/21799 * g++.dg/template/unify8.C: New. * g++.dg/template/unify9.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4814&r2=1.4815 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.1012&r2=1.1013 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5741&r2=1.5742 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/unify8.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/unify9.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
Fixed mainline 2005-07-08 Nathan Sidwell <nathan@codesourcery.com> PR c++/21799 * pt.c (type_unification_real): Add is_method argument. Use it for this pointer unification. (fn_type_unification): Adjust type_unification_real call. (unify): Likewise.
Subject: Bug 21799 CVSROOT: /cvs/gcc Module name: gcc Changes by: nathan@gcc.gnu.org 2005-08-12 09:23:54 Modified files: gcc/cp : ChangeLog pt.c Log message: cp: PR c++/21799 PR c++/8271 * pt.c (unify) <METHOD_TYPE>: Check this-pointer cv-qualifiers explicitly. PR c++/21799 Revert my 2005-07-08 patch * pt.c (type_unification_real): Remove is_method_argument and assoicated checks. (fn_type_unification, unify): Adjust type_unification_real calls. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4848&r2=1.4849 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.1021&r2=1.1022
Fixed mainline & 4.0 2005-08-12 Giovanni Bajo <giovannibajo@libero.it> Nathan Sidwell <nathan@codesourcery.com> PR c++/21799 PR c++/8271 * pt.c (unify) <METHOD_TYPE>: Check this-pointer cv-qualifiers explicitly. 2005-08-12 Nathan Sidwell <nathan@codesourcery.com> PR c++/21799 Revert my 2005-07-08 patch * pt.c (type_unification_real): Remove is_method_argument and assoicated checks. (fn_type_unification, unify): Adjust type_unification_real calls.
Subject: Bug 21799 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-4_0-branch Changes by: nathan@gcc.gnu.org 2005-08-12 09:40:35 Modified files: gcc/cp : pt.c ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: unify8.C unify9.C unify10.C Log message: cp: PR c++/21799 PR c++/8271 * pt.c (unify) <METHOD_TYPE>: Check this-pointer cv-qualifiers explicitly. testsuite: * g++.dg/template/unify8.C: New. * g++.dg/template/unify9.C: New. * g++.dg/template/unify10.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.978.2.15&r2=1.978.2.16 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.76&r2=1.4648.2.77 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/unify8.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.16.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/unify9.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.16.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/unify10.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.331&r2=1.5084.2.332