[Bug c++/44320] New: ADL names are looked up in namespaces that are only referenced by template arguments
I believe that the following is a bug. it is accepted by MSVC and comeau.
GCC seems to ADL-lookup names in namespaces that are only used in the template
arguments of the function arguments, for example:
Aotherns::type a;
adl_func(a); //otherns::adl_func is called
this can cause unintended conflicts with non-function names in otherns, e.g.
if the ADL function is called apply and the argument type happens to be a
template instantiated with a type from namespace boost::mpl, only the fact that
a header containing the type boost::mpl::apply is included can cause a compile
error.
here's a simplified test case that causes a conflict:
namespace mpl{
class apply{};
class vector{};
}
templateclass T
void apply(T const ){}
templateclass T
class A{};
int main(){
Ampl::vector a;
apply(a);
}
--
Summary: ADL names are looked up in namespaces that are only
referenced by template arguments
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sstrasser at systemhaus-gruppe dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44320
[Bug c++/44320] ADL names are looked up in namespaces that are only referenced by template arguments
--- Comment #1 from sstrasser at systemhaus-gruppe dot de 2010-05-29 07:45 --- a workaround (other than renaming the ADL function) would be appreciated -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44320
[Bug libstdc++/41975] unordered_set::erase performs worse when nearly empty
--- Comment #9 from sstrasser at systemhaus-gruppe dot de 2009-11-29 02:29 --- (In reply to comment #7) An implementation is probably expected to shrink bucket_count when size shrinks, so the complexity should still be O(size). That would be good for memory use anyway, so why's that not done? shrinking invalidates iterators, doesn't it? erase() is specified not to invalidate iterators. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41975
[Bug c++/42071] New: ICE on trying to use a typedef as a nested class
templateclass T struct A{
typedef int *B;
};
templateclass T
void AT::B::C(){}
test.cpp:6: internal compiler error: in is_ancestor, at cp/name-lookup.c:2292
--
Summary: ICE on trying to use a typedef as a nested class
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sstrasser at systemhaus-gruppe dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42071
[Bug c++/19073] cp_binding_level::names not returning all decls
--- Additional Comments From sstrasser at systemhaus-gruppe dot de 2005-05-15 16:17 --- (In reply to comment #9) only if it may be needed there in the future. Perhaps a solution would be adding every name there when -fdump-translation-unit is given (at the expense of some extra memory consumption, slower compilation). in case you plan to to this: the above mentioned case seems to be the only one. I've fixed this in my project MetaC++ by just commenting out the 4 lines above. which probably introduces other bugs and so is no solution for -fdump..., but what I'm trying to say is that this is the only case where GCC does not add a name to cp_binding_level::names -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19073
[Bug c++/21555] New: name lookup / friend function
from c.l.c.moderated by Maxim Yegorushkin:
#include algorithm
namespace N {
#ifdef SHOW_BUG
struct A
{
};
int swap(A, A);
#else
struct A
{
friend int swap(A, A);
};
#endif
struct B : A
{
};
void swap(B x, B y)
{
using std::swap;
typedef char a[sizeof(swap(static_castA(x), static_castA(y))) ?
1 : -1] ; // compiles only if int swap(A, A) is found
}
}
--
Summary: name lookup / friend function
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sstrasser at systemhaus-gruppe dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21555
[Bug c++/21425] New: typeof with parens rejected
one might argue that this isn't a bug because it isn't in std but it looks inconsistent, so I let you decide: int a; // ok int (b); // ok typeof(a) c; // ok typeof(a) (d) // error -- Summary: typeof with parens rejected Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sstrasser at systemhaus-gruppe dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21425
[Bug c++/21084] New: parse error on valid dependent default argument
template typename _Key,typename _Val,typename _KeyOfValue,typename
_Compare,typename _Alloc class _Rb_tree;
template typename _Key,typename _Compare,typename _Alloc class multiset{
multiset(_Compare const __comp,
typename _Rb_tree_Key,_Key,_Key ,_Compare,_Alloc ::allocator_type const
__a=_Rb_tree_Key,_Key,_Key ,_Compare,_Alloc ::allocator_type());
};
accepted if the allocator_type is typedef'ed and the default argument is
constructed through the typedef name.
gcc version 4.0.0 20050415 (prerelease)
gcc-Version 3.4.4 20050314 (prerelease) (Debian 3.4.3-12)
--
Summary: parse error on valid dependent default argument
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sstrasser at systemhaus-gruppe dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21084
[Bug c++/21084] parse error on valid dependent default argument
--- Additional Comments From sstrasser at systemhaus-gruppe dot de
2005-04-18 12:04 ---
here's another, simpler, testcase:
template typename T1,typename T2 class A; //it works with only 1 parameter
class B{
templatetypename U
void hoh(typename AU,U::depname a=AU,U::depname());
};
I'd appreciate a simple workaround for this one, because you can't typedef the
dependent type like in the original testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21084
[Bug c++/20240] [3.3 Regression] invalid using-redeclaration accepted
--- Additional Comments From sstrasser at systemhaus-gruppe dot de 2005-04-18 12:08 --- fixed -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20240
[Bug c++/21087] New: ICE in do_nonmember_using_decl
out.cpp:17279: internal compiler error: in do_nonmember_using_decl, at cp/name-lookup.c:2072 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. I think the code is valid, though I'm not sure since I don't know what's the cause for this, the line reported, 17279, definitly is valid. attaching source. ICE with: gcc version 4.0.0 20050418 (prerelease) works with: gcc-Version 3.4.4 20050314 (prerelease) (Debian 3.4.3-12) -- Summary: ICE in do_nonmember_using_decl Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sstrasser at systemhaus-gruppe dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21087
[Bug c++/21087] ICE in do_nonmember_using_decl
--- Additional Comments From sstrasser at systemhaus-gruppe dot de 2005-04-18 14:51 --- Created an attachment (id=8676) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8676action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21087
[Bug c++/20173] [3.3/3.4/4.0/4.1 regression] gcc accepts invalid partial specialization attempt of member function
--- Additional Comments From sstrasser at systemhaus-gruppe dot de 2005-04-09 10:59 --- is still accepted by 4.0 although 20157 is fixed now -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20173
[Bug c++/20240] [3.3 Regression] invalid using-redeclaration accepted
--- Additional Comments From sstrasser at systemhaus-gruppe dot de 2005-04-09 11:00 --- any reason why this bug is still NEW? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20240
[Bug c++/20734] [4.0/4.1 Regression] rejects valid pointer to member
--- Additional Comments From sstrasser at systemhaus-gruppe dot de 2005-04-06 06:28 --- the file which has led to the test case above compiles ok, too -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20734
[Bug c++/20733] New: performance regression 3.4 = 4.0
characteristics of the file: - complex inheritance hierarchy with virtual inheritance. this definitely is the reason for long compile times, though I don't know if it's the reason for the regression. - usage of boost::mpl, but I've almost disabled it for this test file AMD Athlon(TM) MP 2000+ i686-pc-linux-gnu gcc-Version 3.3.5 (Debian 1:3.3.5-8) mem 426 mb user2m10.870s sys 0m2.250s gcc-Version 3.4.4 20041218 (prerelease) (Debian 3.4.3-6) mem 387 mb user1m4.920s sys 0m1.210s gcc-Version 4.0.0 20041218 (experimental) mem 581 mb user2m0.800s sys 0m2.720s -- Summary: performance regression 3.4 = 4.0 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sstrasser at systemhaus-gruppe dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20733
[Bug c++/20733] compile time/memory usage regression 3.4 = 4.0
--- Additional Comments From sstrasser at systemhaus-gruppe dot de 2005-04-02 23:05 --- Created an attachment (id=8520) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8520action=view) Preprocessed source preprocessed with gcc 3.4(could matter because of boost) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20733
[Bug c++/20733] compile time/memory usage regression 3.4 = 4.0
--- Additional Comments From sstrasser at systemhaus-gruppe dot de 2005-04-02 23:15 --- fergot gcc arguments: -O0 -S comment #2: I'm downloading mainline to fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20733
[Bug c++/20734] New: rejects valid pointer to member
error: cannot convert 'int*' to 'int A::*' for argument '1' to 'void blah(int
A::*)'
struct A;
void blah(int A::*);
struct A{
int a;
};
templatetypename T //remove this line to make it work
void hoho(){
blah(A::a);
}
compiles on gcc up to early 4.0, icc and comeau
--
Summary: rejects valid pointer to member
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P1
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sstrasser at systemhaus-gruppe dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20734
[Bug c++/20733] compile time/memory usage regression 3.4 = 4.0
--- Additional Comments From sstrasser at systemhaus-gruppe dot de 2005-04-03 00:59 --- it's actually a performance _improvement_ between 3.4 and current 4.0 branch: gcc-Version 3.4.4 20041218 (prerelease) (Debian 3.4.3-6) user0m57.250s sys 0m1.050s gcc-Version 4.0.0 20050402 (prerelease) user0m40.290s sys 0m1.070s memory about the same. I'm quite sure though that the error message in comment #2 is a bug and filed 20734(with convenient test case) it also fails on 4.0 branch. (the numbers above are from a slightly different file which performs as bad on the outdated 4.0 I've used before). -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20733
[Bug c++/20691] New: accept-invalid template template argument
Ioannis Vranos [EMAIL PROTECTED] wrote...
#include vector
template templateclass class ContainerTemplate, class ValueType
inline void test(const ValueType val)
{
ContainerTemplateValueType container(val);
}
int main()
{
using namespace std;
testvector(10);
}
No, this is not valid for a simple reason that std::vector is a template
that has more than one argument. Your 'ContainerTemplate' template
template argument has only one argument itself.
--
Summary: accept-invalid template template argument
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sstrasser at systemhaus-gruppe dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20691
[Bug c++/20658] New: warning on minimum integer values
long long a=-9223372036854775808ll; int b=-2147483648; test2.cpp:1:14: warning: integer constant is so large that it is unsigned it is not. test2.cpp:1: warning: this decimal constant is unsigned only in ISO C90 test2.cpp:2: warning: this decimal constant is unsigned only in ISO C90 huh? unsigned? example with sizeof(int) == 4 sizeof(long long) == 8 -- Summary: warning on minimum integer values Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sstrasser at systemhaus-gruppe dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20658
[Bug c++/20207] null constructor not needed in multiple inheritance
--- Additional Comments From sstrasser at systemhaus-gruppe dot de 2005-03-01 05:38 --- it is invalid to use A0 in the base constructor list of D, because A0 is not a virtual base for D. .it doesn't matter that the inheritance A-A0 is declared virtual, 2 trees which both inherit A0 must join at D to use it in base constructor list) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20207
[Bug c++/20240] New: invalid using-redeclaration accepted
sorry if this is a dupe, I've checked the summaries, but there are too many
about using to read each in detail.
I think this is a bug:
namespace A{int a;};
namespace C{
int a;
using A::a;
}
accepted.
if not, then this is one:
namespace A{int a;};
namespace C{
double a;
using A::a;
}
error: `a' is already declared in this scope
--
Summary: invalid using-redeclaration accepted
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sstrasser at systemhaus-gruppe dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20240
[Bug c++/20157] [4.0 Regression] Internal compiler error on invalid code
--- Additional Comments From sstrasser at systemhaus-gruppe dot de 2005-02-24 14:24 --- (In reply to comment #2) I think it is a minor regression. 3.3/3.4 treats the code correctly if the specialization(unlike above) is a definition. 4.0 does not. no regression with exactly this testcase though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20157
[Bug c++/20173] New: Wrong template function specialization chosen
attaching testcase. result should be '1', but is '2', an int is matched to a pointer. (and the pointer has the value of the integer in the function) is known to fail for 3.3.5 and 3.4.4. I can't test with 4.0 atm but I think it also fails because I came across this by a strange internal tree generated by 4.0. -- Summary: Wrong template function specialization chosen Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sstrasser at systemhaus-gruppe dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20173
[Bug c++/20173] Wrong template function specialization chosen
--- Additional Comments From sstrasser at systemhaus-gruppe dot de 2005-02-23 17:16 --- Created an attachment (id=8266) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8266action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20173
[Bug c++/20173] Wrong template function specialization chosen
--- Additional Comments From sstrasser at systemhaus-gruppe dot de 2005-02-23 17:19 --- Comeau C++ thinks this code is invalid. If it's right, this bug might be related to #20157 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20173
[Bug c++/20174] New: rejects valid partial template function specialization
...and I have another one, this is gcc bug finding day.
it's again related to partial template function specializations, but I open a
new report because this time it is rejects-valid:
(at least I think so)
templatetypename AT
struct A{
templatetypename T
void function(){}
};
template
templatetypename TTT
void Aint::functionTTT(){}
error: partial specialization `functionTTT' of function template
that's right, but why is this an error?
if function has a parameter of type T, so you can specialize it without
explicitly giving a template parameter, it works.
(...::function(TTT){})
Comeau accepts both.
--
Summary: rejects valid partial template function specialization
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sstrasser at systemhaus-gruppe dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20174
[Bug c++/20157] New: Internal compiler error on invalid code
4.0.0 outputs internal compiler error on the following invalid code.
3.3/3.4 silently ignores it.
if the invalid template function specialization is a definition 3.3/3.4
correctly reports it, 4.0.0 still outputs an internal compiler error.
templatetypename AT
struct A{
templatetypename T
void function(T);
};
template
templatetypename ABC,typename DEF
void Aint::function(ABC);
--
Summary: Internal compiler error on invalid code
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sstrasser at systemhaus-gruppe dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20157
[Bug c++/19809] New: Multiple definitions of friend functions in template classes
This report is based on [EMAIL PROTECTED]
given this testcase:
#include iostream
templateint i
struct n{
friend void foo(){
std::cerr i std::endl;;
}
};
int main(){
n1 n1;
n2 n2;
n3 n3;
foo();
}
there must be a bug here, though I'm not sure what exactly it is.
a) it could be a multiple definition of foo, which is reported by version 3.3.4,
but not by 4.0.0 and 3.4.3.
b) std note 14.5.3.3 could mean that it's not a multiple definition:
3 When a function is defined in a friend function declaration in a class
template, the function is defined when the class template is first instantiated.
The function is defined even if it is never used.
so if it's _only_ defined on the first instantiation this is not a multiple
definition - but then I don't think it is legal to use the template arguments of
struct n in the function definition
c) even if b) is wrong and usage of template arguments is allowed, there's still
a bug, because the result of the testcase above is 3, so the _last_
instantiation is used.
comeau C++ chooses a), so does 3.3.4.
--
Summary: Multiple definitions of friend functions in template
classes
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sstrasser at systemhaus-gruppe dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19809
[Bug c++/19772] New: crash on invalid template friend decl
I spent some time looking for a dupe of this bug because it has been around at
least since version 3.3.5, and also is in 4.0.0 CVS, but I haven't found one:
I think this is illegal code, though I haven't checked, I put the parts to make
it work in comments:
templatetypename AT
class A{
templatetypename BT
class B;
};
templatetypename AT
templatetypename BT
class AAT::B{
templatetypename BT2
friend class /*AAT::*/B;
};
segfaults on versions:
4.0.0 20041218 (experimental)
3.4.4 20041218 (prerelease) (Debian 3.4.3-6)
3.3.5 (Debian 1:3.3.5-5)
--
Summary: crash on invalid template friend decl
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sstrasser at systemhaus-gruppe dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19772
[Bug c++/19772] crash on invalid template friend decl
--- Additional Comments From sstrasser at systemhaus-gruppe dot de 2005-02-03 03:39 --- one additional note, I wrote above that the code works with the commented code. it only does on 3.3.5, not on the other 2 versions: error: no type named `B' in `class AAT' it even crashes on 4.0.0, but that could be due to changes I've made, I don't have a clean version atm. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19772
[Bug c++/19474] wrong tree for extern C variables
--- Additional Comments From sstrasser at systemhaus-gruppe dot de
2005-01-31 07:48 ---
I think I was wrong, this is a bug _and_ has effects on compilation:
in example2(see above) int a is not extern C in the tree, AND it is C++
mangled in compiler output!
std 7.5.7 states that a once declared extern C function is extern C even if
defined without linkage specification. I can't find the same for variables, but
since this is a redeclaration that must be the true:
extern C{ extern int a; }
int a;
extern C{ int a; }
I've attached a simple test case. link it and you'll get an undefined reference
to a.
--
What|Removed |Added
Severity|minor |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19474
[Bug c++/19474] wrong linkage of extern C variables
-- What|Removed |Added Summary|wrong tree for extern C |wrong linkage of extern C |variables |variables http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19474
[Bug c++/19474] wrong linkage of extern C variables
--- Additional Comments From sstrasser at systemhaus-gruppe dot de 2005-01-31 07:52 --- Created an attachment (id=8111) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8111action=view) reference to a in c.c shouldn't be undefined -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19474
[Bug c++/19474] New: wrong tree for extern C variables
I don't know if this ever has an effect on an output of gcc(are C variable names
ever different from C++ ones?), but there are two different trees which should
be equal:
example1:
extern C{ extern int a; }
extern C{ int a; }
example2:
extern C{ extern int a; }
int a;
those should be equal I think, but a is not DECL_EXTERN_C_P for example2.
if a is a function it is DECL_EXTERN_C_P in both examples.
--
Summary: wrong tree for extern C variables
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sstrasser at systemhaus-gruppe dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19474
[Bug c++/19474] wrong tree for extern C variables
--- Additional Comments From sstrasser at systemhaus-gruppe dot de 2005-01-16 23:55 --- I totally agree that this is not important. I just don't know gcc good enough to forecast the possible effects of that minor bug so I thought it'd be interesting. please close the bug if you are sure it doesn't have any effects on compilation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19474
[Bug c++/19073] cp_binding_level::names not returning all decls
--- Additional Comments From sstrasser at systemhaus-gruppe dot de 2004-12-20 03:42 --- ok, I took a closer look at this. we all agree that type_decls(even c++ implicit ones) should be in cp_binding_level::names, don't we? decls get added to this list by name-lookup.c add_decl_to_level(), which gets called by name-lookup.c:pushdecl() pushdecl() checks if there is already a binding for the decl(via namespace_binding()). if there is(which is the case for the implicit type decls in current version), it only calls add_decl_to_level() under certain circumstances, one of these is: not being a TYPE_DECL. in gcc version 3.3.4(which doesn't have this problem) namespace_binding() returns 0, there is no binding, in current CVS there is. so, why is this? because of these lines in name-lookup.c:set_identifier_type_value_with_scope: if (binding-value) supplement_binding (binding, decl); else binding-value = decl; I understand what they're doing but I don't understand why they are at this point and were introduced in decl.c version 1.1114. the cvs log message doesn't contain anything that's useful to me either. why are these lines there? before this there was no assignment to binding-value at all. Thanks for your help -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19073
[Bug c++/19073] New: cp_namespace_decl not returning all decls
I'm not sure if the bug is the behaviour of the function or the documentation,
but they differ:
cp_namespace_decl(tree) is documented to return all decls of a
namespace(documented in cp/name-lookup.c and in gcc internals documentation),
but it leaves out a lot of decls, e.g. c++ classes and enums.
this is true for current CVS version(12-19-04) and for the current
release(3.4.3).
but in version 3.3.4 it correctly returns at least the type_decl nodes for
enums(classes not tested).
you can easily check this with -fdump-translation-unit, which uses
cp_namespace_decl:
code: class Abc{};
Abc does not appear in the output of current versions. in 3.3.4 it does.
--
Summary: cp_namespace_decl not returning all decls
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sstrasser at systemhaus-gruppe dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19073
[Bug c++/19073] cp_namespace_decl not returning all decls
--- Additional Comments From sstrasser at systemhaus-gruppe dot de 2004-12-19 01:04 --- The struct cp_binding_level contains all the decls. that seems to be the same thing. cp_namespace_decls uses NAMESPACE_LEVEL macro which brings you to a cp_binding_level structure. maybe the summary of this bug shouldn't be about cp_namespace_decls but I don't see why this is expected behaviour. the behaviour is not specific to this function. and then again, because everybody is telling me I shouldn't use -fdump-translation-unit: I don't. I just proposed it as a way to check this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19073
[Bug c++/19073] cp_binding_level::names not returning all decls
-- What|Removed |Added Summary|cp_namespace_decl not |cp_binding_level::names not |returning all decls |returning all decls http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19073
[Bug c++/19073] cp_binding_level
-- What|Removed |Added Summary|cp_binding_level::names not |cp_binding_level |returning all decls | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19073
[Bug c++/19073] cp_binding_level::names not returning all decls
-- What|Removed |Added Summary|cp_binding_level|cp_binding_level::names not ||returning all decls http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19073
