[Bug c++/50518] [C++0x] repeated c++11 opaque enum declarations are invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50518 fabien at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW CC||fabien at gcc dot gnu.org Assignee|fabien at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #4 from fabien at gcc dot gnu.org --- Hi paolo, not for the foreseeable future unfortunately.
[Bug c++/60894] [4.8/4.9/5 Regression] Use of redundant struct keyword in function prototype combined with using statement causes compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60894 --- Comment #11 from fabien at gcc dot gnu.org --- I posted a patch here: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02190.html
[Bug c++/60894] [4.8/4.9/5 Regression] Use of redundant struct keyword in function prototype combined with using statement causes compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60894 --- Comment #9 from fabien at gcc dot gnu.org --- (In reply to Jason Merrill from comment #8) (In reply to fabien from comment #6) I looked into it but did not manage to get it fixed. I will have another try this week. Thanks for the reminder. Ping? I have a patch for it, but not perfect as it triggers a minor diagnostic regression about class-type redefinition in presence of using decl at class scope. The using decl is no longer mentioned in the diagnostic... I'll try to make it work, otherwise I would ask you some help...
[Bug c++/60894] [4.7/4.8/4.9/4.10 Regression] Use of redundant struct keyword in virtual function prototype combined with using statement causes compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60894 --- Comment #6 from fabien at gcc dot gnu.org --- (In reply to Jason Merrill from comment #5) Any news? I looked into it but did not manage to get it fixed. I will have another try this week. Thanks for the reminder.
[Bug c++/60894] [4.7/4.8/4.9/4.10 Regression] Use of redundant struct keyword in virtual function prototype combined with using statement causes compilation error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60894 fabien at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |fabien at gcc dot gnu.org --- Comment #4 from fabien at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #2) The regression was caused by r181359 Fabien, could you take a look please? I think the code is valid. Thanks, I will look into it.
[Bug c++/52369] Const-qualified non-class base member and defaulted default constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52369 fabien at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.3 --- Comment #4 from fabien at gcc dot gnu.org --- Fixed.
[Bug c++/52369] Const-qualified non-class base member and defaulted default constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52369 --- Comment #3 from fabien at gcc dot gnu.org --- Author: fabien Date: Wed Mar 26 21:33:28 2014 New Revision: 208854 URL: http://gcc.gnu.org/viewcvs?rev=208854root=gccview=rev Log: 2014-03-26 Fabien Chene fab...@gcc.gnu.org PR c++/52369 * cp/method.c (walk_field_subobs): improve the diagnostic locations for both REFERENCE_TYPEs and non-static const members. * cp/init.c (diagnose_uninitialized_cst_or_ref_member): use %q#D instead of %qD to be consistent with the c++11 diagnostic. 2014-03-26 Fabien Chene fab...@gcc.gnu.org PR c++/52369 * g++.dg/init/const10.C: New. * g++.dg/init/const11.C: New. * g++.dg/init/pr25811.C: Adjust. * g++.dg/init/pr29043.C: Likewise. * g++.dg/init/pr43719.C: Likewise. * g++.dg/init/pr44086.C: Likewise. * g++.dg/init/ctor8.C: Likewise. * g++.dg/init/uninitialized1.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/init/const10.C trunk/gcc/testsuite/g++.dg/init/const11.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/cp/method.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/init/ctor8.C trunk/gcc/testsuite/g++.dg/init/pr25811.C trunk/gcc/testsuite/g++.dg/init/pr29043.C trunk/gcc/testsuite/g++.dg/init/pr43719.C trunk/gcc/testsuite/g++.dg/init/pr44086.C trunk/gcc/testsuite/g++.dg/init/uninitialized1.C
[Bug c++/32039] Using declaration accepts non-visible members from base classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32039 --- Comment #2 from fabien at gcc dot gnu.org --- (In reply to Andrew Stubbs from comment #0) The problem should be that B::foo hides A::foo from class C. Clause 7.3.3/14 of the C++ standard says the using declaration should not work, in this case - class A is not a direct base class of class C. However, GCC 4.1.1 accepts it with no diagnostic. 7.3.3/14 says ...The base class members mentioned by a using-declaration shall be visible in the scope of at least one of the direct base classes of the class where the using-declaration is specified... In the example above, A (from using A::foo) is visible from its direct base class B. Consequently, it is valid. Adding 'using A::foo' within B does not change anything to that. without 'using A::foo': 'int B::foo(long)' hides int A::foo(int) in B and 'using A::foo' brings 'int A::foo(int)' into C and hides 'int B::foo(long)'. with 'using A::foo': two overloads of 'foo' are present in B: 'int B::foo(long)' and 'int A::foo(int)' (brought into B scope by the using-declaration). and 'using A::foo' brings 'int A::foo(int)' into C and hides 'int B::foo(long)' (and 'using A::foo)
[Bug c++/32039] Using declaration accepts non-visible members from base classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32039 --- Comment #3 from fabien at gcc dot gnu.org --- (In reply to Eelis from comment #1) Still accepted by 4.4. Comeau concurs with reporter, and rejects saying: line 15: error: class member designated by a using-declaration must be visible in a direct base class Which seems wrong according to the standard quoted above. From Clang results and the analysis done in bug 19377, I am inclined to close this bug as invalid.
[Bug c++/32039] Using declaration accepts non-visible members from base classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32039 fabien at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID --- Comment #4 from fabien at gcc dot gnu.org --- Closed as invalid.
[Bug c++/32039] Using declaration accepts non-visible members from base classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32039 fabien at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|INVALID |--- --- Comment #6 from fabien at gcc dot gnu.org --- (In reply to Harald van Dijk from comment #5) [...] Your comment (the In the example above, A (from using A::foo) is visible bit) suggests that you read the standard as requiring that the base class be visible, rather than the base class member. Obviously should read members of A are visible... Anyway thanks for the clarification.
[Bug c++/37140] type inherited from base class not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37140 --- Comment #16 from fabien at gcc dot gnu.org --- Author: fabien Date: Wed Feb 26 21:16:15 2014 New Revision: 208182 URL: http://gcc.gnu.org/viewcvs?rev=208182root=gccview=rev Log: 2014-02-26 Fabien Chene fab...@gcc.gnu.org PR c++/37140 * parser.c (cp_parser_nonclass_name): Call strip_using_decl and move the code handling dependent USING_DECLs... * name-lookup.c (strip_using_decl): ...Here. 2014-02-26 Fabien Chene fab...@gcc.gnu.org PR c++/37140 * g++.dg/template/using27.C: New. * g++.dg/template/using28.C: New. * g++.dg/template/using29.C: New. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/template/using27.C branches/gcc-4_7-branch/gcc/testsuite/g++.dg/template/using28.C branches/gcc-4_7-branch/gcc/testsuite/g++.dg/template/using29.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/name-lookup.c branches/gcc-4_7-branch/gcc/cp/parser.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug c++/37140] type inherited from base class not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37140 --- Comment #15 from fabien at gcc dot gnu.org --- Author: fabien Date: Mon Feb 24 20:27:34 2014 New Revision: 208093 URL: http://gcc.gnu.org/viewcvs?rev=208093root=gccview=rev Log: 2014-02-24 Fabien Chene fab...@gcc.gnu.org PR c++/37140 * parser.c (cp_parser_nonclass_name): Call strip_using_decl and move the code handling dependent USING_DECLs... * name-lookup.c (strip_using_decl): ...Here. 2014-02-24 Fabien Chene fab...@gcc.gnu.org PR c++/37140 * g++.dg/template/using27.C: New. * g++.dg/template/using28.C: New. * g++.dg/template/using29.C: New. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/template/using27.C branches/gcc-4_8-branch/gcc/testsuite/g++.dg/template/using28.C branches/gcc-4_8-branch/gcc/testsuite/g++.dg/template/using29.C Modified: branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/name-lookup.c branches/gcc-4_8-branch/gcc/cp/parser.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug c++/19377] Using declaration in private part causes protected diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19377
--- Comment #10 from fabien at gcc dot gnu.org ---
(In reply to Andrey Belevantsev from comment #9)
Another test case of the same issue (both clang and icc compile this fine):
It is not the same issue as the protected keyword is not involved. (And Clang
and ICC should be fixed instead, see below).
namespace ns {
class Base {
public:
int i;
};
class Derived : public Base {
using Base::i;
};
}
class DerivedDerived : public ns::Derived {
using ns::Base::i;
};
we get
/tmp/ns.C:4:9: error: ‘int ns::Base::i’ is inaccessible
/tmp/ns.C:10:7: error: within this context
It is indeed rejects-valid but I cannot claim this is a regression as I
can't find the version that did that correctly.
The testcase is not valid, as a using declaration shall refer to a direct base
class, which is not the case in 'using ns::Base::i' (the namespace ns does not
seem to be relevant here). It is invalid for a second reason, 'using Base::i'
is declared (implicitly) in a private section, so inaccessible in
DerivedDerived.
It's 9 years of the
original bugreport, maybe rise a priority?..
Raising the priority would not make me fix this bug more quickly. This bug is
not a regression, and not a high priority in my opinion. Thought, it is in my
TODO list. I gave it a try two years ago, and it was not obvious to fix. Feel
free to take over if you have more free time than I have.
[Bug c++/37140] type inherited from base class not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37140 --- Comment #11 from fabien at gcc dot gnu.org --- Author: fabien Date: Sun Feb 2 19:58:06 2014 New Revision: 207407 URL: http://gcc.gnu.org/viewcvs?rev=207407root=gccview=rev Log: 2014-02-02 Fabien Chene fab...@gcc.gnu.org PR c++/37140 * parser.c (cp_parser_nonclass_name): Call strip_using_decl and move the code handling dependent USING_DECLs... * name-lookup.c (strip_using_decl): ...Here. 2014-02-02 Fabien Chene fab...@gcc.gnu.org PR c++/37140 * g++.dg/template/using27.C: New. * g++.dg/template/using28.C: New. * g++.dg/template/using29.C: New. Modified: trunk/gcc/cp/name-lookup.c
[Bug c++/37140] type inherited from base class not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37140 --- Comment #12 from fabien at gcc dot gnu.org --- Author: fabien Date: Sun Feb 2 20:02:37 2014 New Revision: 207408 URL: http://gcc.gnu.org/viewcvs?rev=207408root=gccview=rev Log: 2014-02-02 Fabien Chene fab...@gcc.gnu.org PR c++/37140 * parser.c (cp_parser_nonclass_name): Call strip_using_decl and move the code handling dependent USING_DECLs... * name-lookup.c (strip_using_decl): ...Here. 2014-02-02 Fabien Chene fab...@gcc.gnu.org PR c++/37140 * g++.dg/template/using27.C: New. * g++.dg/template/using28.C: New. * g++.dg/template/using29.C: New. Added: trunk/gcc/testsuite/g++.dg/template/using27.C trunk/gcc/testsuite/g++.dg/template/using28.C trunk/gcc/testsuite/g++.dg/template/using29.C Modified: trunk/gcc/cp/parser.c
[Bug c++/37140] type inherited from base class not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37140 fabien at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from fabien at gcc dot gnu.org --- Fixed in 4.9. I will backport it to 4.8 and 4.7 if everething goes well.
[Bug c++/37140] type inherited from base class not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37140 fabien at gcc dot gnu.org changed: What|Removed |Added CC||roshan.shariff at gmail dot com --- Comment #14 from fabien at gcc dot gnu.org --- *** Bug 58047 has been marked as a duplicate of this bug. ***
[Bug c++/58047] parse error with typedef introduced from base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58047 fabien at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from fabien at gcc dot gnu.org --- marked as duplicate *** This bug has been marked as a duplicate of bug 37140 ***
[Bug c++/37140] type inherited from base class not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37140 fabien at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #10 from fabien at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #9) Fabien, any news on this - now that we are in Stage 3? I have successfuly tested a patch, but wait a moment, I need to refine it a bit.
[Bug c++/14258] typename in a using declaration not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14258 --- Comment #20 from fabien at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #19) Fabien, the fix doesn't seem to work with nested-name-specifiers, do you remember if there's another bug report about that case? Yes, it's probably PR58047.
[Bug c++/58047] parse error with typedef introduced from base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58047 fabien at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |fabien at gcc dot gnu.org --- Comment #4 from fabien at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #3) Seems closely related to PR37140. Can be a dup indeed, but let it open. This way, I will not forget to check this tescase when I work on PR37140 -- which I generally don't for duplicates.
[Bug c++/54537] undiagnosed using-declaration conflicting with used function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54537 --- Comment #3 from fabien at gcc dot gnu.org --- (In reply to Peter Bergner from comment #1) Given the OK by Paolo, I retested the patch from: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01166.html It needed a small change to the expected error message from using9.C, but otherwise bootstrapped and regtested with no errors. Committed to mainline as revision 201414. Thank you very much. I have also asked about the appropriateness of backporting it to the FSF 4.8 branch. It is not a regression, so I think you would need an approval. Just ask it on gcc-patches.
[Bug c++/37140] type inherited from base class not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37140 --- Comment #8 from fabien at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #7) Any news on this? Sorry Paolo, no news. I will look into it after I resurrect some stage one 1 material patches on using decls (comming after c++/54537). I think this one can be tackled in stage 3.
[Bug c++/58040] Cannot take address-of public using-declaration of member from protected base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58040 fabien at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-08-02 Assignee|unassigned at gcc dot gnu.org |fabien at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from fabien at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #2) Fabien, are you interested in this? Yes, let's put it on my TODO list. Might be related to PR c++/19377.
[Bug c++/37140] type inherited from base class not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37140 fabien at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |fabien at gcc dot gnu.org --- Comment #5 from fabien at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #4) PR14258 is fixed and this is still rejected. Maybe Fabien wants to have a look?!? Sure, I'll have a look. Thank you Paolo!
[Bug c++/56243] [4.8 regression] ICE in tree check: expected field_decl, have identifier_node in fixed_type_or_null, at cp/class.c:6645
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56243
--- Comment #7 from fabien at gcc dot gnu.org 2013-02-25 20:56:42 UTC ---
(In reply to comment #6)
(In reply to comment #4)
[...]
If so, this corrected test case still triggers ICE:
Good point. Further reduced:
struct A
{
virtual int String ();
};
class F: public A { };
struct G
{
F value;
};
class D
{
template int
void Verify()
{
G x;
F name = x.value;
name.String();
}
};
I restarted the analysis from the beginning. My fix for c++/11750 was basically
to restrict the cases where the unsafe front-end de-virtualization was done. It
wouldn't help to refine that change because anyway, it would still be possible
to find a testcase that shows the same ICE.
My attempts to fix the problem on the constexpr side failed probably because it
is correct.
The problem is more related to the COMPONENT_REF 'G'. Probably because
D::Verify is not instantiated yet, the field 'value' of G is still an
IDENTIFIER_NODE instead of being a FIELD_DECL, which leads to a crash while
calling DECL_FIELD_IS_BASE.
Hence, I can only see two solutions:
1) make 'value' a FIELD_DECL before or during the
fold_non_dependent_expr_sfinae call. Not sure it is simple.
2) check that the first operand of a COMPONENT_REF is actually a FIELD_DECL
before calling DECL_FIELD_IS_BASE on it.
Upcoming patch for the solution 2 on gcc-patch...
[Bug c++/56243] [4.8 regression] ICE in tree check: expected field_decl, have identifier_node in fixed_type_or_null, at cp/class.c:6645
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56243 --- Comment #8 from fabien at gcc dot gnu.org 2013-02-25 21:04:59 UTC --- (In reply to comment #6) [...] 2) check that the first operand of a COMPONENT_REF is actually a FIELD_DECL before calling DECL_FIELD_IS_BASE on it. As a consequency, while processing fold_non_dependent_expr_sfinae, fixed_type_or_null returns NULL_TREE on 'x.value' the and build_vtbl_ref_1 has not chance to call unshare_expr. Jason, is that a big deal ?
[Bug c++/56243] [4.8 regression] ICE in tree check: expected field_decl, have identifier_node in fixed_type_or_null, at cp/class.c:6645
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56243 --- Comment #3 from fabien at gcc dot gnu.org 2013-02-23 10:42:55 UTC --- (In reply to comment #2) Any news on this bug? It's one of only a few P1 regressions left. This bug triggers with --enable-checking on the constexpr stuff. I was looking at it yesterday, and tried to fix it in the same way than you fixed PR53816. It did work, but it caused a regression on constexpr-static10.C which I didn't manage to resolve yet. If I fail to find out what goes wrong this week-end, I will probably have to defer to someone more involved than me on the constexpr stuff. I didn't check if it was a regression wrt 4.7 with --enable-checking
[Bug c++/56243] [4.8 regression] ICE in tree check: expected field_decl, have identifier_node in fixed_type_or_null, at cp/class.c:6645
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56243 --- Comment #4 from fabien at gcc dot gnu.org 2013-02-23 22:00:44 UTC --- I think the testcase is invalid Shouldn't the below line be diagnosed, even if it is in a template ? F name = x-value; We fail to return early, and the compiler is confused because of this error.
[Bug c++/56243] [4.8 regression] ICE in tree check: expected field_decl, have identifier_node in fixed_type_or_null, at cp/class.c:6645
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56243
--- Comment #5 from fabien at gcc dot gnu.org 2013-02-23 22:02:16 UTC ---
reduced testcase:
class A
{
virtual int String ();
};
class F: public A { };
template typename V class G
{
V value;
};
class D
{
template int N void Verify() {
GA* x = 0;
F name = x-value;
name.String();
}
};
[Bug c++/56243] [4.8 regression] ICE in tree check: expected field_decl, have identifier_node in fixed_type_or_null, at cp/class.c:6645
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56243 fabien at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |fabien at gcc dot gnu.org |gnu.org |
[Bug c++/11750] class scope using-declaration lookup not implemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11750 --- Comment #9 from fabien at gcc dot gnu.org 2012-11-14 20:12:56 UTC --- Author: fabien Date: Wed Nov 14 20:12:47 2012 New Revision: 193504 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193504 Log: gcc/testsuite/ChangeLog 2012-11-14 Fabien Chêne fab...@gcc.gnu.org PR c++/11750 * g++.dg/inherit/vitual9.C: New. gcc/cp/ChangeLog 2012-11-14 Fabien Chêne fab...@gcc.gnu.org PR c++/11750 * call.c (build_new_method_call_1): Check that the instance type and the function context are the same before setting the flag LOOKUP_NONVIRTUAL. Added: trunk/gcc/testsuite/g++.dg/inherit/virtual9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog
[Bug c++/11750] class scope using-declaration lookup not implemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11750 fabien at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #10 from fabien at gcc dot gnu.org 2012-11-14 20:20:21 UTC --- Fixed in 4.8.
[Bug c++/54537] New: undiagnosed using-declaration conflicting with used function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54537
Bug #: 54537
Summary: undiagnosed using-declaration conflicting with used
function
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fab...@gcc.gnu.org
Noticed while working on DR39, the below is wrongly accepted. A diagnostic is
issued if the function f is not used.
namespace a
{
void f(int);
}
namespace b
{
void f(int);
void g()
{
f (3);
}
using a::f; // { dg-error already declared }
}
I have a patch for it.
[Bug c++/54537] undiagnosed using-declaration conflicting with used function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54537 fabien at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-09-09 AssignedTo|unassigned at gcc dot |fabien at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 Known to fail||4.6.3, 4.8.0
[Bug c++/46687] Class member lookup ambiguity w/ overloaded static members and using declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46687 fabien at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-09-02 Ever Confirmed|0 |1
[Bug c++/50921] GCC cannot find dependent conversion-function-id even if there's a using declaration for it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50921 fabien at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-08-31 Ever Confirmed|0 |1 Known to fail||4.6.3, 4.7.0, 4.8.0 --- Comment #3 from fabien at gcc dot gnu.org 2012-08-31 20:04:41 UTC --- (In reply to comment #2) Fabien, you may be interested in this one. Indeed! Thanks for notifying me.
[Bug c++/51214] [4.7 Regression] [C++11] name lookup issue with c++11 enums
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51214 --- Comment #6 from fabien at gcc dot gnu.org 2012-06-27 17:36:56 UTC --- Author: fabien Date: Wed Jun 27 17:36:50 2012 New Revision: 189021 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189021 Log: gcc/testsuite/ChangeLog 2012-06-27 Fabien Chêne fab...@gcc.gnu.org PR c++/51214 * g++.dg/cpp0x/forw_enum11.C: New. gcc/cp/ChangeLog 2012-06-27 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. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/cpp0x/forw_enum11.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/class.c branches/gcc-4_7-branch/gcc/cp/cp-tree.h branches/gcc-4_7-branch/gcc/cp/decl.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug c++/51214] [4.7 Regression] [C++11] name lookup issue with c++11 enums
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51214 fabien at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from fabien at gcc dot gnu.org 2012-06-27 17:53:11 UTC --- Fixed in 4.7.
[Bug c++/53549] [4.7/4.8 Regression] g++ and armadillo 3.2.0, operator() is inaccessible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53549 fabien at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |fabien at gcc dot gnu.org |gnu.org |
[Bug c++/51214] [4.7/4.8 Regression] [C++11] name lookup issue with c++11 enums
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51214 --- Comment #3 from fabien at gcc dot gnu.org 2012-06-07 05:36:23 UTC --- Author: fabien Date: Thu Jun 7 05:36:18 2012 New Revision: 188294 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188294 Log: gcc/testsuite/ChangeLog 2012-06-07 Fabien Chêne fab...@gcc.gnu.org PR c++/51214 * g++.dg/cpp0x/forw_enum11.C: New. gcc/cp/ChangeLog 2012-06-07 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. Added: trunk/gcc/testsuite/g++.dg/cpp0x/forw_enum11.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug c++/53247] [regression, c++11] can't use a function from a base class of the same name in a different namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53247 fabien at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from fabien at gcc dot gnu.org 2012-05-05 17:57:27 UTC --- (In reply to comment #1) Fabien, is this a dup of one of the other using regressions? Definitely, this is a duplicate, thanks. *** This bug has been marked as a duplicate of bug 52841 ***
[Bug c++/52841] [4.7/4.8 Regression] error: type 'Solvable' is not a base type for type 'Resolvable'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52841 fabien at gcc dot gnu.org changed: What|Removed |Added CC||b.r.longbons at gmail dot ||com --- Comment #12 from fabien at gcc dot gnu.org 2012-05-05 17:57:27 UTC --- *** Bug 53247 has been marked as a duplicate of this bug. ***
[Bug c++/53236] using declaration and base function template overloading
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53236 fabien at gcc dot gnu.org changed: What|Removed |Added CC||fabien at gcc dot gnu.org --- Comment #2 from fabien at gcc dot gnu.org 2012-05-05 18:04:26 UTC --- The testcase does not seem to be reduced at the minimum. Would you mind reducing it?
[Bug c++/52841] [4.7/4.8 Regression] error: type 'Solvable' is not a base type for type 'Resolvable'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52841 fabien at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|WAITING AssignedTo|fabien at gcc dot gnu.org |unassigned at gcc dot ||gnu.org --- Comment #10 from fabien at gcc dot gnu.org 2012-05-04 19:45:46 UTC --- I no longer work on it, so it is more honest to set this bug as unassigned. The patch I attached here fixes the problem, because it bypasses a deeper issues. Returning the earliest possible in cp_parser_alias_declaration makes sense to me because there are probably much more using-declarations than alias-declarations to parse at the moment. However, I do not want to submit it because I think we should fix the real issue as well. I had a look on non-matching parse_tentatively/definitely, without finding anything suspect. If one needs some details about what goes wrong -- if I was unclear here and in previous comments --, do not hesitate to ask me.
[Bug c++/52841] [4.7/4.8 Regression] error: type 'Solvable' is not a base type for type 'Resolvable'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52841 --- Comment #7 from fabien at gcc dot gnu.org 2012-04-17 21:06:52 UTC --- Created attachment 27180 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27180 return earlier in cp_parser_alias_declaration
[Bug c++/52841] [4.7/4.8 Regression] error: type 'Solvable' is not a base type for type 'Resolvable'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52841 --- Comment #8 from fabien at gcc dot gnu.org 2012-04-17 21:08:13 UTC --- It is related to alias declarations. It seems that we do not recover properly from a failure in cp_parser_alias_declaration, in the block introduced by this check: if (!(flags CP_PARSER_FLAGS_NO_USER_DEFINED_TYPES)), around here: #0 cp_parser_simple_type_specifier (parser=0x7571b738, decl_specs=0x7fffdd00, flags=1) at ../../gcc/gcc/cp/parser.c:13651 #1 0x006be5e0 in cp_parser_type_specifier (parser=0x7571b738, flags=1, decl_specs=0x7fffdd00, is_declaration=0 '\000', declares_class_or_enum=0x0, is_cv_qualifier=0x7fffdcde ) at ../../gcc/gcc/cp/parser.c:13434 #2 0x006c5c96 in cp_parser_type_specifier_seq (parser=0x7571b738, is_declaration=0 '\000', is_trailing_return=0 '\000', type_specifier_seq=0x7fffdd00) at ../../gcc/gcc/cp/parser.c:16887 #3 0x006c5a63 in cp_parser_type_id_1 (parser=0x7571b738, is_template_arg=0 '\000', is_trailing_return=0 '\000') at ../../gcc/gcc/cp/parser.c:16771 #4 0x006c5b57 in cp_parser_type_id (parser=0x7571b738) at ../../gcc/gcc/cp/parser.c:16810 #5 0x006c1987 in cp_parser_alias_declaration (parser=0x7571b738) at ../../gcc/gcc/cp/parser.c:15101 I can't find what goes wrong there. The good news is that it seems to work if we return earlier in cp_parser_alias_declaration -- which I think is better --, like in the attached patch. Perhaps Dodji (or Jason) can take a closer look ?
[Bug c++/19377] Using declaration in private part causes protected diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19377 --- Comment #8 from fabien at gcc dot gnu.org 2012-04-15 18:24:08 UTC --- (In reply to comment #7) (In reply to comment #6) (In reply to comment #5) You should write to Jason directly, as he is probably the only person in the world that understands the C++ FE well enough to answer this. (And am I the only one who thinks this is REALLY bad for the future of g++?) I don't think it is he is only person who understands the C++ front-end, but rather he is one of the few who understands the C++ language fully and understands the interaction between different items of the C++ language. So please stop spreading the false hope about G++. I am not spreading false hopes, that sounds like I am hoping that G++ will fail or some such. If I wanted that, why would I be contributing my free time to G++? The question above is not about C++, but about the C++ FE specifically. So, please, tell us, who else may know the answer besides Jason AND have the time or interest to answer? Please add them to the CC, so Fabien can fix this bug. Thanks for your interest manuel, Indeed I've asked Jason via private emails, he answers the best he can, but unfortunately, it was too late for me to solve it for 4.7. I'm targeting 4.8...
[Bug c++/52465] [4.7 Regression] g++ rejects valid code with in-class using declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52465 --- Comment #8 from fabien at gcc dot gnu.org 2012-04-15 20:22:47 UTC --- Author: fabien Date: Sun Apr 15 20:22:44 2012 New Revision: 186473 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186473 Log: 2012-04-15 Fabien Chêne fab...@gcc.gnu.org PR c++/52465 * g++.dg/lookup/using52.C: New. gcc/cp/ChangeLog 2012-04-15 Fabien Chêne fab...@gcc.gnu.org PR c++/52465 * parser.c (cp_parser_class_name): Call strip_using_decl and return the target decl. * name-lookup.c (strip_using_decl): Returns NULL_TREE if the decl to be stripped is NULL_TREE. (qualify_lookup): Call strip_using_decl and perform some checks on the target decl. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/lookup/using52.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/name-lookup.c branches/gcc-4_7-branch/gcc/cp/parser.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug c++/52465] [4.7 Regression] g++ rejects valid code with in-class using declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52465 fabien at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from fabien at gcc dot gnu.org 2012-04-15 20:25:23 UTC --- Fixed in 4.7.1 and on trunk.
[Bug c++/52841] [4.7/4.8 Regression] error: type 'Solvable' is not a base type for type 'Resolvable'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52841 --- Comment #6 from fabien at gcc dot gnu.org 2012-04-12 12:50:31 UTC --- (In reply to comment #5) Ping? I haven't yet finished the investigation. Something is broken in c++11 mode, the parsing of Solvable in using sat::Solvable::bool_type; is failing in c++11 mode, debug_tree() is crashing while debugging it.
[Bug c++/52465] [4.7/4.8 regression] g++ rejects valid code with in-class using declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52465 --- Comment #6 from fabien at gcc dot gnu.org 2012-04-11 20:40:58 UTC --- Author: fabien Date: Wed Apr 11 20:40:51 2012 New Revision: 186355 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186355 Log: gcc/testsuite/ChangeLog 2012-04-09 Fabien Chêne fab...@gcc.gnu.org PR c++/52465 * g++.dg/lookup/using52.C: New. gcc/cp/ChangeLog 2012-04-09 Fabien Chêne fab...@gcc.gnu.org PR c++/52465 * parser.c (cp_parser_class_name): Call strip_using_decl and return the target decl. * name-lookup.c (strip_using_decl): Returns NULL_TREE if the decl to be stripped is NULL_TREE. (qualify_lookup): Call strip_using_decl and perform some checks on the target decl. Added: trunk/gcc/testsuite/g++.dg/lookup/using52.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/52841] [4.7/4.8 Regression] error: type 'Solvable' is not a base type for type 'Resolvable'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52841 fabien at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |fabien at gcc dot gnu.org |gnu.org | --- Comment #3 from fabien at gcc dot gnu.org 2012-04-03 20:06:54 UTC --- I'm busy this week, but I will look into it next week.
[Bug c++/52465] [4.7 regression] g++ rejects valid code with in-class using declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52465 fabien at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |fabien at gcc dot gnu.org |gnu.org | --- Comment #5 from fabien at gcc dot gnu.org 2012-03-08 20:41:06 UTC --- (In reply to comment #4) This is because some USING_DECLs are stored in IDENTIDIER_BINDINGs. Jason, do you agree that cxx_binding-value and cxx_binding-type should not be USING_DECLs ? Nonsense, it cannot works. I am testing a patch...
[Bug c++/52465] [4.7 regression] g++ rejects valid code with in-class using declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52465 fabien at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from fabien at gcc dot gnu.org 2012-03-04 18:42:28 UTC --- (In reply to comment #2) Yes, that's valid. Fabien, can you take a look? Yes, of course.
[Bug c++/52465] [4.7 regression] g++ rejects valid code with in-class using declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52465 --- Comment #4 from fabien at gcc dot gnu.org 2012-03-04 21:52:15 UTC --- This is because some USING_DECLs are stored in IDENTIDIER_BINDINGs. Jason, do you agree that cxx_binding-value and cxx_binding-type should not be USING_DECLs ?
[Bug c++/51214] [4.7 Regression] [C++11] name lookup issue with c++11 enums
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51214
fabien at gcc dot gnu.org changed:
What|Removed |Added
Summary|[C++11] name lookup issue |[4.7 Regression] [C++11]
|with c++11 enums|name lookup issue with
||c++11 enums
--- Comment #2 from fabien at gcc dot gnu.org 2012-02-28 20:19:23 UTC ---
We can manage to mark this bug as a 4.7 Regression, evidence below (to be
compiled with -std=c++11 obviously).
struct Base
{
int b1, b2, b3;
};
struct T : Base
{
int t1, t2, t3;
using Base::b1;
using Base::b2;
using Base::b3;
enum E2 : int;
};
enum T::E2 : int { A1 = 23 };
int i = T::A1;
I have a patch for it.
[Bug c++/52369] Const-qualified non-class base member and defaulted default constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52369 fabien at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-02-24 CC||fabien at gcc dot gnu.org AssignedTo|unassigned at gcc dot |fabien at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 Known to fail||4.1.2, 4.2.4, 4.3.6, 4.5.3, ||4.7.0 --- Comment #1 from fabien at gcc dot gnu.org 2012-02-24 14:05:19 UTC --- Confirmed. Can someone please test it on 4.6.0 and 4.6.2 ? Thanks.
[Bug c++/52126] [4.7 Regression] compilation error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52126 --- Comment #6 from fabien at gcc dot gnu.org 2012-02-16 09:57:20 UTC --- (In reply to comment #5) (In reply to comment #2) Further investigation shows that the issue appears only when inheritance from the template class (class B : private AT) is provided explicitly. According to the standard a nested class defined inside a class template is implicitly template as well. I don't think that's relevant. The point is that the injected-class-name 'A' and 'AT' both refer to the class template, and should work equivalently. Yes, they should. The first bug is that 'A' does not behave like 'AT' -- I have fixed it. The second bug is that 'AT' as a base for a nested class does not currently work if A is also an enclosing class. I have tested a patch, but it is not quite ready.
[Bug c++/52126] [4.7 Regression] compilation error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52126 --- Comment #7 from fabien at gcc dot gnu.org 2012-02-17 07:49:43 UTC --- Author: fabien Date: Fri Feb 17 07:49:35 2012 New Revision: 184328 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184328 Log: gcc/testsuite/ChangeLog 2012-02-16 Fabien Chene fab...@gcc.gnu.org PR c++/52126 * g++.dg/template/using21.C: New. * g++.dg/template/using22.C: Likewise. gcc/cp/ChangeLog 2012-02-16 Fabien Chene fab...@gcc.gnu.org PR c++/52126 * decl.c (xref_basetypes): call dependent_scope_p instead of dependent_type_p. Added: trunk/gcc/testsuite/g++.dg/template/using21.C trunk/gcc/testsuite/g++.dg/template/using22.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug c++/52126] [4.7 Regression] compilation error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52126 fabien at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from fabien at gcc dot gnu.org 2012-02-17 07:51:44 UTC --- Fixed in 4.7.
[Bug c++/52126] [4.7 Regression] compilation error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52126 fabien at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |fabien at gcc dot gnu.org |gnu.org |
[Bug c++/52126] [4.7 Regression] compilation error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52126 --- Comment #3 from fabien at gcc dot gnu.org 2012-02-06 21:31:30 UTC --- I'll be assigning myself to this bug when I come back from vacation next monday.
[Bug c++/14258] typename in a using declaration not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14258 fabien at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug c++/26256] ignores using declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26256 fabien at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug c++/23211] using dec in nested class doesn't import name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23211 fabien at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug c++/30195] Using declaration doesn't work in template.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30195 fabien at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug c++/6936] member using binds wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6936 fabien at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug c++/25994] Using declarations and base function overloading
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25994 fabien at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug c++/51214] [C++11] name lookup issue with c++11 enums
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51214
--- Comment #1 from fabien at gcc dot gnu.org 2011-12-29 20:02:15 UTC ---
Here is a correct testcase for this bug.
// { dg-do compile }
// { dg-options -std=c++0x }
enum { A = 1 };
struct T
{
int i1, i2, i3, i4, i5, i6, i7;
enum E2 : int;
};
enum T::E2 : int { A1 = A };
int i = T::A1;
[Bug c++/23211] using dec in nested class doesn't import name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23211 --- Comment #15 from fabien at gcc dot gnu.org 2011-12-28 19:53:19 UTC --- Author: fabien Date: Wed Dec 28 19:53:14 2011 New Revision: 182711 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182711 Log: gcc/testsuite/ChangeLog 2011-12-28 Fabien Chene fab...@gcc.gnu.org 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.C: Likewise. gcc/cp/ChangeLog 2011-12-28 Fabien Chene fab...@gcc.gnu.org PR c++/23211 * name-lookup.c (do_class_using_decl): Use dependent_scope_p instead of dependent_type_p, to check that a non-dependent nested-name-specifier of a class-scope using declaration refers to a base, even if the current scope is dependent. * parser.c (cp_parser_using_declaration): Set USING_DECL_TYPENAME_P to 1 if the DECL is not null. Re-indent a 'else' close to the prior modification. Added: trunk/gcc/testsuite/g++.dg/template/using18.C trunk/gcc/testsuite/g++.dg/template/using19.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/crash13.C trunk/gcc/testsuite/g++.dg/template/nested3.C
[Bug c++/23211] using dec in nested class doesn't import name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23211 fabien at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #16 from fabien at gcc dot gnu.org 2011-12-28 20:04:25 UTC --- Fixed.
[Bug c++/50518] [C++0x] repeated c++11 opaque enum declarations are invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50518 --- Comment #2 from fabien at gcc dot gnu.org 2011-12-20 13:29:26 UTC --- (In reply to comment #1) Any news on this? No, sorry, I'll try to work on it before the end of stage 3.
[Bug c++/14258] typename in a using declaration not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14258 --- Comment #15 from fabien at gcc dot gnu.org 2011-12-13 18:47:04 UTC --- Author: fabien Date: Tue Dec 13 18:46:58 2011 New Revision: 182292 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182292 Log: gcc/testsuite/ChangeLog 2011-12-11 Fabien Chene fab...@gcc.gnu.org PR c++/14258 * g++.dg/template/using16.C: New. * g++.dg/template/using17.C: New. gcc/cp/ChangeLog 2011-12-11 Fabien Chene fab...@gcc.gnu.org PR c++/14258 * cp-tree.h (USING_DECL_TYPENAME_P): New macro. * parser.c (cp_parser_nonclass_name): Handle using declarations that refer to a dependent type. (cp_parser_using_declaration): Set USING_DECL_TYPENAME_P to 1 if the using declaration refers to a dependent type. Added: trunk/gcc/testsuite/g++.dg/template/using16.C trunk/gcc/testsuite/g++.dg/template/using17.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/14258] typename in a using declaration not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14258 fabien at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Known to fail|| --- Comment #16 from fabien at gcc dot gnu.org 2011-12-13 19:29:26 UTC --- Fixed.
[Bug c++/51319] [4.7 Regression] Eigen3 enums not accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51319 --- Comment #3 from fabien at gcc dot gnu.org 2011-12-05 22:04:45 UTC --- Author: fabien Date: Mon Dec 5 22:04:40 2011 New Revision: 182029 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182029 Log: gcc/testsuite/ChangeLog 2011-12-05 Fabien Chene fab...@gcc.gnu.org PR c++/51319 * g++.dg/lookup/using50.C: New. * g++.dg/lookup/using51.C: New. gcc/cp/ChangeLog 2011-12-05 Fabien Chene fab...@gcc.gnu.org PR c++/51319 * semantics.c (finish_id_expression): Strip using declarations early in the function. Added: trunk/gcc/testsuite/g++.dg/lookup/using50.C trunk/gcc/testsuite/g++.dg/lookup/using51.C Modified: trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/51382] Incorrect diagnostic cannot appear in a constant-expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51382 fabien at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from fabien at gcc dot gnu.org 2011-12-05 22:13:19 UTC --- Fixed in r182029.
[Bug c++/51319] [4.7 Regression] Eigen3 enums not accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51319 fabien at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||fabien at gcc dot gnu.org Resolution||DUPLICATE --- Comment #2 from fabien at gcc dot gnu.org 2011-12-04 22:07:45 UTC --- (In reply to comment #0) This is likely related to Bug 51312 and/or Bug 51305 Most likely Bug 51382 ;-) *** This bug has been marked as a duplicate of bug 51382 ***
[Bug c++/51382] Incorrect diagnostic cannot appear in a constant-expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51382 fabien at gcc dot gnu.org changed: What|Removed |Added CC||marc.glisse at normalesup ||dot org --- Comment #8 from fabien at gcc dot gnu.org 2011-12-04 22:07:45 UTC --- *** Bug 51319 has been marked as a duplicate of this bug. ***
[Bug c++/51382] Incorrect diagnostic cannot appear in a constant-expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51382 fabien at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-12-01 CC||fabien at gcc dot gnu.org AssignedTo|unassigned at gcc dot |fabien at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #5 from fabien at gcc dot gnu.org 2011-12-01 23:43:15 UTC --- I am testing a fix. Paolo, thanks for retrieving the duplicate. Diego, this is the one I was talking about (off list).
[Bug c++/51382] Incorrect diagnostic cannot appear in a constant-expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51382 --- Comment #6 from fabien at gcc dot gnu.org 2011-12-02 07:34:52 UTC --- (In reply to comment #4) About the garbled error message - the second issue - the fix should be rather trivial, just matter of handling USING_DECL in dump_expr together with the other *_DECL and forwarding to dump_decl. Although that seems quite simple, I think we'd need an invalid testcase showing that this change is necessary. In this PR, the testcase is a valid code.
[Bug debug/51276] ICE: in force_decl_die, at dwarf2out.c:19261
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51276 fabien at gcc dot gnu.org changed: What|Removed |Added CC||fabien at gcc dot gnu.org --- Comment #2 from fabien at gcc dot gnu.org 2011-11-29 16:16:53 UTC --- Marc, This is surely a duplicate of Bug 51189, I must have missed it ...
[Bug c++/19377] Using declaration in private part causes protected diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19377
fabien at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #4 from fabien at gcc dot gnu.org 2011-11-27 21:13:49 UTC ---
(In reply to comment #0)
Given this code:
class A {
protected:
int i;
};
class B : public A {
private:
using A::i;
};
class C : public B {
public:
void f() { A::i = 0; }
};
As 'i' is referenced through 'this' and is qualified with a nested name
specifier (A), I think we should perform the access lookup directly in A.
The problem seems to be that we do not have the information that 'i' is
referenced through 'this' when checking the access in accessible_p, unless I'm
missing something.
Any idea where to find this information ?
[Bug c++/11750] class scope using-declaration lookup not implemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11750 fabien at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Last reconfirmed|2005-12-18 20:22:49 |2011-11-21 20:22:49
[Bug c++/32039] Using declaration accepts non-visible members from base classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32039 fabien at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-11-22 Ever Confirmed|0 |1
[Bug c++/51141] [4.7 regression] rev181359 causes Chromium build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51141 --- Comment #4 from fabien at gcc dot gnu.org 2011-11-18 18:44:25 UTC --- Author: fabien Date: Fri Nov 18 18:44:23 2011 New Revision: 181490 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181490 Log: gcc/testsuite/ChangeLog 2011-11-18 Fabien Chene fab...@gcc.gnu.org PR c++/51141 * g++.dg/lookup/using46.C: New. * g++.dg/lookup/using47.C: New. * g++.dg/lookup/using48.C: New. * g++.dg/lookup/using49.C: New. * g++.dg/lookup/using50.C: New. gcc/cp/ChangeLog 2011-11-18 Fabien Chene fab...@gcc.gnu.org PR c++/51141 * search.c (lookup_field_1): Handle USING_DECLs for the storted case. Added: trunk/gcc/testsuite/g++.dg/debug/using6.C trunk/gcc/testsuite/g++.dg/lookup/using46.C trunk/gcc/testsuite/g++.dg/lookup/using47.C trunk/gcc/testsuite/g++.dg/lookup/using48.C trunk/gcc/testsuite/g++.dg/lookup/using49.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/search.c trunk/gcc/testsuite/ChangeLog
[Bug c++/51214] New: [C++11] name lookup issue with c++11 enums
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51214
Bug #: 51214
Summary: [C++11] name lookup issue with c++11 enums
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fab...@gcc.gnu.org
Noticed while working on PR c++/51188, I have launched the c++ testsuite with
the patch below:
Index: class.c
===
--- class.c(revision 181491)
+++ class.c(working copy)
@@ -6007,7 +6007,7 @@ finish_struct_1 (tree t)
hierarchy), and we want this failure to occur quickly. */
n_fields = count_fields (TYPE_FIELDS (t));
- if (n_fields 7)
+ if (n_fields 0)
And it has raised two errors related to c++11 enums: forw_enum5.C and
forw_enum9.C. Thus, here is a reproducer, comming from forw_enum5.C:
// { dg-do compile }
// { dg-options -std=c++0x }
namespace one
{
struct S
{
enum { A = 1, B = 2 };
struct T
{
int i1, i2, i3, i4, i5, i6, i7;
enum { B = 102 };
enum class E1;
enum E2 : int;
};
};
static_assert(int(S::T::A1) == 1, error);
static_assert(int(S::T::B1) == 102, error);
static_assert(int(S::T::C1) == 103, error);
}
The following errors are issued:
error: 'A1' is not a member of 'one::S::T'
error: 'B1' is not a member of 'one::S::T'
error: 'C1' is not a member of 'one::S::T'
Most likely an issue in the sorted case of lookup_field_1. Mine.
[Bug c++/51214] [C++11] name lookup issue with c++11 enums
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51214 fabien at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-11-18 AssignedTo|unassigned at gcc dot |fabien at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug c++/51188] invalid static_cast from type 'XBase' to type 'int'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51188 --- Comment #14 from fabien at gcc dot gnu.org 2011-11-18 20:32:08 UTC --- Author: fabien Date: Fri Nov 18 20:32:04 2011 New Revision: 181492 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181492 Log: gcc/testsuite/ChangeLog 2011-11-18 Fabien Chene fab...@gcc.gnu.org PR c++/51188 * g++.dg/lookup/using46.C: New. * g++.dg/lookup/using47.C: New. * g++.dg/lookup/using48.C: New. * g++.dg/lookup/using49.C: New. * g++.dg/lookup/using50.C: New. gcc/cp/ChangeLog 2011-11-18 Fabien Chene fab...@gcc.gnu.org PR c++/51188 * search.c (lookup_field_1): Handle USING_DECLs for the storted case. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/testsuite/ChangeLog
[Bug c++/51188] invalid static_cast from type 'XBase' to type 'int'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51188 fabien at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #15 from fabien at gcc dot gnu.org 2011-11-18 20:36:54 UTC --- Fixed by rev 181490, not 181492.
[Bug c++/51188] invalid static_cast from type 'XBase' to type 'int'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51188 --- Comment #1 from fabien at gcc dot gnu.org 2011-11-17 09:25:55 UTC --- Yet another bug caused by my recent changes with using declarations.
[Bug c++/51188] invalid static_cast from type 'XBase' to type 'int'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51188 fabien at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-11-17 CC||jason at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from fabien at gcc dot gnu.org 2011-11-17 09:52:40 UTC --- (In reply to comment #0) [...] if I remove any of the superfluous statements in x.cpp it works fine! There is a strange thing here, if we reach 7 members in a class, things are done differently in the compiler. Jason, I'd like to run the testsuite without this 7 member rule, how could I do that ? Thanks.
[Bug c++/51188] invalid static_cast from type 'XBase' to type 'int'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51188 --- Comment #3 from fabien at gcc dot gnu.org 2011-11-17 10:21:30 UTC --- (In reply to comment #2) (In reply to comment #0) [...] Jason, I'd like to run the testsuite without this 7 member rule, how could I do that ? To clarify, I mean 0 instead of 7.
[Bug c++/51189] [4.7 Regression] ICE in force_decl_die, at dwarf2out.c:19261
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51189 fabien at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-11-17 CC||fabien at gcc dot gnu.org AssignedTo|unassigned at gcc dot |fabien at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug c++/51190] [4.7 Regression] 'using' causing trouble
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51190 fabien at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-11-17 CC||fabien at gcc dot gnu.org AssignedTo|unassigned at gcc dot |fabien at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug c++/51188] invalid static_cast from type 'XBase' to type 'int'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51188
--- Comment #6 from fabien at gcc dot gnu.org 2011-11-17 20:24:56 UTC ---
(In reply to comment #5)
It looks like the sorted fields code in lookup_field_1 needs to handle
using_decl like the unsorted fields code does. I think this will also fix
PR51141 (instead of the patch you already posted).
Thanks, I'm current testing the below patch:
Index: class.c
===
--- class.c(revision 181436)
+++ class.c(working copy)
@@ -6000,7 +6000,7 @@ finish_struct_1 (tree t)
hierarchy), and we want this failure to occur quickly. */
n_fields = count_fields (TYPE_FIELDS (t));
- if (n_fields 7)
+ if (n_fields 0)
{
struct sorted_fields_type *field_vec = sorted_fields_type_new
(n_fields);
add_fields_to_record_type (TYPE_FIELDS (t), field_vec, 0);
Index: search.c
===
--- search.c(revision 181436)
+++ search.c(working copy)
@@ -424,8 +424,9 @@ lookup_field_1 (tree type, tree name, bo
if (want_type)
{
do
-field = fields[i--];
+field = strip_using_decl (fields[i--]);
while (i = lo DECL_NAME (fields[i]) == name);
+
if (TREE_CODE (field) != TYPE_DECL
!DECL_TYPE_TEMPLATE_P (field))
field = NULL_TREE;
@@ -433,7 +434,7 @@ lookup_field_1 (tree type, tree name, bo
else
{
do
-field = fields[i++];
+field = strip_using_decl (fields[i++]);
while (i hi DECL_NAME (fields[i]) == name);
}
return field;
[Bug c++/51188] invalid static_cast from type 'XBase' to type 'int'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51188 --- Comment #7 from fabien at gcc dot gnu.org 2011-11-17 20:57:16 UTC --- FYI, it fixes the following PRs: c++/51190, c++/51189, c++/51188, c++/51152, c++/51141.
[Bug c++/51190] [4.7 Regression] 'using' causing trouble
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51190 fabien at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE --- Comment #1 from fabien at gcc dot gnu.org 2011-11-17 20:58:46 UTC --- Marked as duplicate. *** This bug has been marked as a duplicate of bug 51188 ***
[Bug c++/51188] invalid static_cast from type 'XBase' to type 'int'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51188 fabien at gcc dot gnu.org changed: What|Removed |Added CC||reichelt at gcc dot gnu.org --- Comment #8 from fabien at gcc dot gnu.org 2011-11-17 20:58:46 UTC --- *** Bug 51190 has been marked as a duplicate of this bug. ***
