[Bug c++/46831] New: Crash when it tries to do an invalid ICS with a conversion function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46831
Summary: Crash when it tries to do an invalid ICS with a
conversion function template
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: schaub-johan...@web.de
GCC crashes on this
struct B { };
struct D : B { };
struct A {
// [C++0x] default template argument for function template
templatetypename T = void
operator D();
};
void f(B);
int main() {
f(A());
}
This code clearly ill-formed by 13.3.3.1.2[over.ics.user] paragraph 3 . C.f.
13.3.3.1.4[ocer.ics.ref] paragraph 1.
[Bug c++/46791] New: GCC fails on for(struct { } f;;) ;, incorrectly treating it as a range-based for loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46791
Summary: GCC fails on for(struct { } f;;) ;, incorrectly
treating it as a range-based for loop
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: schaub-johan...@web.de
The following has worked correctly before, but doesn't work anymore with GCC's
range-based for-loop support enabled
void f() {
for(struct { } f;;) ;
}
error: types may not be defined in range-based for loops
Structs in the initial part of the for loop can be useful and they are broken
by that diagnostic.
[Bug c++/46731] GCC shouts cannot call member function 'void a::g()' without object if a is a dependent base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46731 --- Comment #5 from Johannes Schaub schaub-johannes at web dot de 2010-12-01 14:39:18 UTC --- (In reply to comment #3) Confirmed. EDG accepts it. But I would argue that g is bound at first stage name-lookup and thus it is not a dependent name and thus the error is correct. It is bound at first stage name lookup because it's not a dependent name. Thus, it is transformed to class-member access because g is a non-static member of some class. It being bound at first stage name lookup doesn't IMO mean that you drop any analysis that would depend on instantiation semantics, it just means you do name lookup only in the definition as opposed to be in the instantiation. In this case what will happen: g - (*this).g // found g in the definition context! - (*this).g(); So, you have an implicit object parameter of type a, and an implied object argument of lvalue of type ba, that has a dependent base class. The validity of the call depends on template arguments, so you have to delay further analysis. This further analysis doesn't have to do with name lookup but with overload resolution. The committee clarified the issue by resolving DR 515, stating their intent to support this and similar code. It may require that you internally mark constructs as instantiation dependent that formally aren't marked as type/value dependent, just because its validity depends on facts you can only know when instatiating so that you know when walking over the AST top-down what you again need to check and what not. I've no idea about those internal compiler things. Active issue #1172 looks for proper wording to capture any such constructs in a formal way.
[Bug c++/46731] New: GCC shouts cannot call member function 'void a::g()' without object if a is a dependent base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46731
Summary: GCC shouts cannot call member function 'void a::g()'
without object if a is a dependent base class
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: schaub-johan...@web.de
This code should compile just fine, but it fails with GCC
struct a {
void g() { }
templatetypename T
struct b : T { void f() { g(); } };
};
void f() {
a::ba x;
x.f();
}
[...@host2 cpp]$ LC_ALL=C g++ main1.cpp
main1.cpp: In member function 'void a::bT::f() [with T = a]':
main1.cpp:9:7: instantiated from here
main1.cpp:4:29: error: cannot call member function 'void a::g()' without object
The reason for its validity has been discussed at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21008 and
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#515 .
[Bug c++/46731] GCC shouts cannot call member function 'void a::g()' without object if a is a dependent base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46731 --- Comment #2 from Johannes Schaub schaub-johannes at web dot de 2010-11-30 19:21:57 UTC --- (In reply to comment #1) Actually it is not valid but for a different reason than what GCC gives. See PR 24163, and PR 15272 for the reasons why g() should not be found when doing the lookup. g is not found by looking into the base, but by doing unqualified lookup in the lexically enclosing nesting class scope a. This way g is still found, even though the dependent base class isn't looked into.
[Bug c++/43453] Initialization of char array with string literal fails in mem-initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43453
--- Comment #3 from Johannes Schaub schaub-johannes at web dot de 2010-10-30
09:41:36 UTC ---
(In reply to comment #2)
(In reply to comment #1)
(In reply to comment #0)
Fails to compile, but should work:
struct A {
char x[4];
A():x(bug) { }
};
Error i get is:
main.cpp:3: error: array used as initializer
Why do you think it should work?
For example, the following equivalent code is invalid as well:
char x [4] (bug);
This code is equivalent and is valid. At least, I don't see the Standard
forbidding it. GCC is the only compiler I tested (comeau/edg, clang) that
rejects it.
I'm not actually sure anymore about the validity of this code. One can make a
point about the initializer not being a mere string literal.
At least the draft n3126 makes a difference of this, in that an initializer
like ({a, b, c}) is not regarded as a braced-init-list, but rather as a
parenthesized expression-list where the initializer list is handed as one
argument. So I'm unsure whether an initializer like `(foo)` should be
regarded as a string literal or not.
I think I will send an issue report about this.
[Bug c++/46245] New: rejects function with late-specified return type as a non-type template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46245
Summary: rejects function with late-specified return type as a
non-type template parameter
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: schaub-johan...@web.de
GCC rejects the following:
templateauto f()-int struct A { };
error: parameter declared 'auto'
[Bug c++/46005] New: Don't allow auto as the simple-type-specifier of a typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46005 Summary: Don't allow auto as the simple-type-specifier of a typedef Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: schaub-johan...@web.de The following is ill-formed, but GCC allows it typedef auto autot; And it seems GCC itself can't handle it autot t = 0; // variable has incomplete type!? Neither does the Standard specify how it should be handled (it only talks about auto type specifiers, as opposed to auto being the type designated semantically. There is no semantic equivalent for auto it seems). In Standard C++, something like autot t = 0; can't occur, I think.
[Bug c++/46005] Don't allow auto as the simple-type-specifier of a typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46005 --- Comment #2 from Johannes Schaub schaub-johannes at web dot de 2010-10-13 15:28:04 UTC --- (In reply to comment #1) I'm getting 'error: ‘autot’ does not name a type' with both current trunk and 4.5. 4.4 gives error: conflicting specifiers in declaration of ‘autot’ which is the better error message (which you get also with trunk and 4.5 with typedef auto int autot;). You haven't enabled C++0x. My PR is about C++0x's auto.
[Bug c++/45657] New: Wrongly computed exception specification for destructor
This code is invalid, but is accepted by GCC:
// snip
struct Viral {
struct Dose { };
protected:
~Viral() throw (Dose) { }
};
struct Base : virtual Viral {
virtual ~Base() throw() { }
};
struct Derived : Base { };
// snap
~Derived calls ~Viral, which adds Dose to its exception spec. This yields to
a looser exception spec for ~Derived than for the overridden ~Base, which
should yield to an ill-formed program.
--
Summary: Wrongly computed exception specification for destructor
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45657
[Bug c++/45657] Wrongly computed exception specification for destructor
--- Comment #2 from schaub-johannes at web dot de 2010-09-13 17:02 --- Great(In reply to comment #1) Not a regression, and G++ 4.6 correctly rejects it: pr.cc:12:8: error: looser throw specifier for 'virtual Derived::~Derived() throw (Viral::Dose)' pr.cc:9:11: error: overriding 'virtual Base::~Base() throw ()' EDG (Comeau online) also accepts it. Great, thanks for checking on 4.6. Can we mark it as resolved? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45657
[Bug c++/43453] Initialization of char array with string literal fails in mem-initializer
--- Comment #2 from schaub-johannes at web dot de 2010-08-28 14:39 ---
(In reply to comment #1)
(In reply to comment #0)
Fails to compile, but should work:
struct A {
char x[4];
A():x(bug) { }
};
Error i get is:
main.cpp:3: error: array used as initializer
Why do you think it should work?
For example, the following equivalent code is invalid as well:
char x [4] (bug);
This code is equivalent and is valid. At least, I don't see the Standard
forbidding it. GCC is the only compiler I tested (comeau/edg, clang) that
rejects it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43453
[Bug c++/45033] New: delete does overload resolution for class operands, but shouldn't.
The Standard requires GCC to not accept this snippet. Its description of
delete does not dictate overload resolution, but requires a single conversion
function to pointer type. This was handled correctly by GCC4.4, but fails with
4.6 and 4.5 (regression?)
struct A {
operator int*() { return 0; }
operator int*() const { return 0; }
};
int main() {
A a;
int *p = a; // works
delete a; // shouldn't work, but does!
}
Expected output:
main1.cpp:9:3: error: ambiguous conversion of delete expression of type 'A' to
a pointer
delete a; // shouldn't work, but does!
^ ~
main1.cpp:2:3: note: candidate function
operator int*() { return 0; }
^
main1.cpp:3:3: note: candidate function
operator int*() const { return 0; }
^
1 error generated.
--
Summary: delete does overload resolution for class operands,
but shouldn't.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45033
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #179 from schaub-johannes at web dot de 2010-06-20 00:01 --- (In reply to comment #158) Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should rguenther at suse dot de gcc-bugzi...@gcc.gnu.org writes: [...] | Now, if I understand your argument below correctly, you are saying | that even if we fixed the union rules for C++, we may still be facing | the same problem because assignment to POD objects does not just mean | that the object was there before, but that we are actually starting a | new one. Do I understand your argument correctly? | | Yes. Then, I'm not sure I agree with that. I'll raise it as part of the union problem. I'm sorry for commenting this late, but were there any outcomes of the discussion about changing the dynamic type by assignments for non-PODs (maybe on the reflector)? The way I see it, and how Richard may see it, is by 3.8/1 which says The lifetime of an object of type T begins when - storage with the proper alignment and size for type T is obtained The lifetime of an object of type T ends when - the storage which the object occupies is reused or released. This isn't specific to unions, but it never seems to define what constitutes a reuse, but Richard seems to interpret this to include assignments and so do I, and i've always used this interpretation to explain the mechanism by which unions change their active member. -- schaub-johannes at web dot de changed: What|Removed |Added CC||schaub-johannes at web dot ||de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug c++/43282] GCC looks into dependent bases during unqualified lookup
--- Comment #8 from schaub-johannes at web dot de 2010-06-06 01:01 --- (In reply to comment #6) Dup of bug 15272. I don't know about the internals of GCC, but from a Standard point of view, the code in that bug shows a different problem than the code in my bug report. In my bug report the problem is that dependent base classes are considered during dependent name lookup. But in that other bug report, f is not a dependent name at all. It is *made* dependent by the other name in the non-dependent base (i don't know why, but maybe GCC prepends the implicit this prematurely, and then makes it dependent that way by thinking the name originally was this-f - but this is just a guess!). But in any case, my bug-report does not seem to be a duplicate of that one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43282
[Bug c++/44400] New: GCC allows declaring a function having the name of the class using a typedef
This code is accepted by GCC and compiles
typedef void F();
struct X { F X; };
Not valid according to 9.2/13bullet2. It seems that GCC thinks that F X; is a
data-member (declaring data-members with the name of the class is valid, as
long as there are no user declared constructors).
--
Summary: GCC allows declaring a function having the name of the
class using a typedef
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44400
[Bug c++/44401] New: GCC does not correctly hide injected class name
This code is valid, but GCC rejects it:
struct X { int X; };
int X::*p = X::X;
// error: taking address of constructor 'X::X'
GCC apparently seems to think that X::X looks up to the injected class name,
and thus (by 3.4.3.1/1a) would name the constructor. But the name of the
non-static data member should hide the injected class name.
--
Summary: GCC does not correctly hide injected class name
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44401
[Bug c++/44402] New: GCC does not accept friend function declarations using a typedef for function type.
This code is valid, but rejected by GCC:
struct A { void f(); };
typedef void F();
struct B { friend F A::f; };
// error: type 'A' is not derived from type 'B'
--
Summary: GCC does not accept friend function declarations using a
typedef for function type.
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44402
[Bug c++/44401] Doesn't correctly hide injected class name
--- Comment #2 from schaub-johannes at web dot de 2010-06-03 16:45 ---
The Standard allows this at 9.2/13a (In addition, if class T has a
user-declared constructor (12.1), every nonstatic data member of class T shall
have a name different from T.). In our case we don't have a user declared
constructor.
Now we have an object name, and a class-name. The object name should hide the
class name according to 3.3.7/2. You can access the class name by using an
elaborated type specifier class X::X (which is not replaced by a constructor
reference either) or if you name it in a base-specifier struct Y : X::X { };.
C++0x adds using declarations as one further context looking up the the
*constructor* specifically (not by way of injected class names). Thus the
following names the constructors of X (but inherits no constructors):
struct Y : X { using X::X; };
It does not name the data-member X, because the mapping from X::X is done
by syntactical means by the second bullet of 3.4.3.1/2. The same mapping makes
the following work in C++0x:
struct Y : X { using identityX::type::type; };
This shows it doesn't use the injected class name of X for looking up
constructors. Now, the following is valid in C++03 and C++0x:
struct Y : X { using identityX::type::X; };
In C++03 this is a normal using declaration that redeclares the member name to
be public in Y and which resolves to the data member. In C++0x,
3.4.3.1/1bullet4 (see DR #400) makes the lookup yield both the injected class
name and the data member (personally i always thought that a lookup can only
yield multiple declarations if all the declarations are function names, but i'm
always surprised again).
Anyway, if in C++0x it yields both the injected class name and the data member,
should this be the *final* result, or is that result still subject of 3.4.3.1/2
making it name only the constructor? I think this is important to clarify,
since it determines the validity of the following:
struct A { private: int A; };
struct B : A { public: using A::A; };
void f() { B b; b.A; };
If using A::A; names the injected class name and the data member of A, this
code seems to be valid, because A is public as a member of B. However if we
are subjectof 3.4.3.1/2, we will have using A::A name the constructors of A
and thus be a no-op declaration (no constructors are inherited in this case.
And since the data member lookup result was discared, no member name is
redeclared).
Any ideas? Are there issue reports about it, or am i just missing something?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44401
[Bug c++/44157] New: GCC wrongly takes a std::initializer_list argument as non-deduced context
This is well-formed, but GCC does not like it
#include initializer_list
templatetypename T
void f(T) { }
int main() {
std::initializer_listint a = { 0 };
f(a);
}
main1.cpp: In function 'int main()':
main1.cpp:8:6: warning: deducing 'T' as 'std::initializer_listint'
main1.cpp:4:6: warning: in call to 'void f(T) [with T =
std::initializer_listint]'
main1.cpp:8:6: warning: (you can disable this with -fno-deduce-init-list)
The FCD says that if the argument is an initializer list and the parameter is
a T, the parameter is a non-deduced context (14.8.2.1/1). In this code,
however, the argument is not an initializer list (if called as f({0}), it
would be). Consequently, the warning is wrong.
--
Summary: GCC wrongly takes a std::initializer_list argument as
non-deduced context
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44157
[Bug c++/41796] ambiguous subobject diagnostic given too early
--- Comment #6 from schaub-johannes at web dot de 2010-04-02 14:02 --- (In reply to comment #4) Thanks for pointing out that this has changed since C++03, though the change was to fix to something that was clearly broken. In any case, I disagree with issue 983. The point of the example is that it doesn't matter what subobject it refers to, as the type of D::i is 'int B::*'. I notified Daniel Kruegler about this, since the DR got CD2 status. He replied that you might want to consider reopening it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
[Bug c++/43559] Overloaded template functions became ambiguous
--- Comment #2 from schaub-johannes at web dot de 2010-03-28 19:33 ---
I've done some analysis for this using the argument-deduction during partial
ordering rules as clarified by
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#214:
templatetypename T, typename U
void f(U) { } // #1
templatetypename T, typename U
void f(T const) { } // #2
4 Each type from the parameter template and the corresponding type from the
argument template are used as the types of P and A.
Round 1, #1 - #2:
As: (X)// #1
Ps: (T const) // #2
Round 2, #2 - #1:
As: (X const) // #2
Ps: (T)// #1
If P is a reference type, P is replaced by the type referred to.
If A is a reference type, A is replaced by the type referred to.
=
Round 1, #1 - #2:
As: (X) // #1
Ps: (T const)// #2
Round 2, #2 - #1:
As: (X const) // #2
Ps: (T) // #1
If both P and A were reference types (before being replaced with the type
referred to above), determine which of the two types (if any) is more
cv-quali#64257;ed than the other; otherwise the types are considered to be
equally cv-quali#64257;ed for partial ordering purposes. The result of this
determination will be used below.
= * #2 more cv-qualified than #1
If P is a cv-quali#64257;ed type, P is replaced by the cv-unquali#64257;ed
version of P.
If A is a cv-quali#64257;ed type, A is replaced by the cv-unquali#64257;ed
version of A.
Round 1, #1 - #2:
As: (X) // #1
Ps: (T) // #2
Round 2, #2 - #1:
As: (X) // #2
Ps: (T) // #1
Using the resulting types P and A the deduction is then done as described in
14.9.2.5. If deduction succeeds for a given type, the type from the argument
template is considered to be at least as specialized as the type from the
parameter template.
Round 1, T - X
Round 2, T - X
#1.param1 at least as specialized as #2.param1 and vice-versa.
If, for a given type, deduction succeeds in both directions (i.e., the types
are identical after the transformations above) and if the type from the
argument template is more cv-quali#64257;ed than the type from the parameter
template (as described above) that type is considered to be more specialized
than the other.
Deduction succeeded in both rounds (types as in P/A pairs), but #2.param1
was more cv-qualified
= #2.param1 more specialized than #1.param1
If for each type being considered a given template is at least as specialized
for all types and more specialized for some set of types and the other template
is not more specialized for any types or is not at least as specialized for any
types, then the given template is more specialized than the other template.
#2 is at least as specialized for all types and more specialized for #1.param1
and #1 is not more specialized for any types, so #2 is more specialized than
#1.
So, i think GCC should choose the one with the f(T const) because that
template is more specialized. Notice that the rules also say
In most cases, all template parameters must have values in order for deduction
to succeed, but for partial ordering purposes a template parameter may remain
without a value provided it is not used in the types being used for partial
ordering.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43559
[Bug c++/43453] New: Initialization of char array with string literal fails in mem-initializer
Fails to compile, but should work:
struct A {
char x[4];
A():x(bug) { }
};
Error i get is:
main.cpp:3: error: array used as initializer
--
Summary: Initialization of char array with string literal fails
in mem-initializer
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43453
[Bug c++/43282] GCC looks into dependent bases during unqualified lookup
--- Comment #7 from schaub-johannes at web dot de 2010-03-08 23:41 ---
I've digged this up from an early draft ('96:
http://ra.dkuug.dk/JTC1/SC22/WG21/docs/wp/txt/jun96/body.txt), '98 and '03).
Each has different rules. In fact, C++98 would accept comment#3's code.
- '96pre-standard said that: if a base class is dependent, this scope is not
examined by lookup (of any kind) until the class is instantiated. However, if a
base class is a template parameter, then the names declared in it do not hide
names from an enclosing scopes. (So, if we inherit from T, we first look in
the enclosing scopes and if we found nothing, we look in dependent base
classes).
- '98 said that: if a base class is dependent and declares a name, that name
may not hide a name from the enclosing scopes. I don't think that A::foo is
considered to be in an enclosing scope of HasFoo, so C++98 would also reject my
code, i think. So C++98 just did away with the difference of inheriting a
template-parameter and the general case of dependent bases for the hiding
stuff.
- '03 says that: Unqualified namelookup will not consider dependent bases -
even not during instantiation. This was done by DR213:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#213 . John Spicer
sums it up: `What I thought the rule was is, If a base class is a dependent
type a member of that class is not found by unqualified lookup.`.
According to Erwin Unruh in that DR, unqualified lookup at the definition
context can't find members in dependent base classes because you don't know
what base class you have.. I am in the impression that since lookup for
dependent names is post-poned until the actual template arguments are known, we
will indeed be able to descend into dependent base classes when doing lookup in
the definition context, since we know the exact types of these bases by then
(and this seems to be what GCC is doing currently, actually).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43282
[Bug c++/43282] New: GCC looks into dependent bases during unqualified lookup
GCC does not accept this code, but is supposed to. foo is looked up using
unqualified name lookup, during which dependent base classes are ignored. The
fact that foo is dependent must not influence this.
templatetypename T
struct HasFoo {
void foo() { }
};
// dependent HasFooT should be ignored during
// lookup of foo
templatetypename T
struct Bar : HasFooT {
void bar() { foo(T()); }
};
namespace A {
struct Baz { };
void foo(Baz); // should be found!
}
int main() { BarA::Baz b; b.bar(); }
--
Summary: GCC looks into dependent bases during unqualified lookup
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43282
[Bug c++/43282] GCC looks into dependent bases during unqualified lookup
--- Comment #2 from schaub-johannes at web dot de 2010-03-08 00:01 --- The point is that the scope of the base class is not examined even during instantiation, so you cannot find the class member function and ADL finds A::foo instead. The Standard says at 14.6.2/3: In the definition of a class template or a member of a class template, if a base class of the class template depends on a template-parameter, the base class scope is not examined during unqualified name lookup either at the point of definition of the class template or member *or during an instantiation of the class template or member*. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43282
[Bug c++/43282] GCC looks into dependent bases during unqualified lookup
--- Comment #4 from schaub-johannes at web dot de 2010-03-08 00:26 --- Yes, this is the consequence. You have to add this- or Bar:: to use another form of lookup (qualified or class-member access) or use a using-declaration to bring the name in scope (using HasFooT::foo;). I can't say anything about the intent, but comeau rejects this code, and clang too (it's actually a well known pit-fall in C++). See my article here: http://stackoverflow.com/questions/2396019/c-templates-hides-parent-members/2398186#2398186 . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43282
[Bug c++/41796] ambiguous subobject diagnostic given too early
--- Comment #5 from schaub-johannes at web dot de 2010-02-11 15:06 --- Ah, i see now. I always thought the the member pointer would contain an offset from the nested-name-specifier of the D::i regardless of the type of the result. In fact, i see now that i'm wrong. Ambiguity checks are done for both of .* and for the implicit conversion at point of use, and the pointer will just contain offset 0 in B1 or something to that effect. I feel sad now since i'm guilty of making that issue report. Hopefully it won't make it into the IS :) Tho i wish they would make a cross reference to the section of .* (5.5) too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
[Bug c++/42490] using-directive in namespace doesn't work properly
--- Comment #2 from schaub-johannes at web dot de 2010-02-11 23:28 --- I also think the code is valid. In this case though, there is the complication that no hiding takes place: The qualified name lookup of X::m for namespace members says in 3.4.3.2/2: using-directives are ignored in any namespace, including X, directly containing one or more declarations of m. That would mean that using namespace B; is ignored, because C is declared as a namespace there. But 3.4.4/3 says: If the name is a qualified-id, the name is looked up according its qualifications, as described in 3.4.3, but ignoring any non-type names that have been declared.. That is, the declaration of the namespace is ignored, thus not preventing the consideration of the using directive. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42490
[Bug c++/42490] using-directive in namespace doesn't work properly
--- Comment #3 from schaub-johannes at web dot de 2010-02-11 23:39 --- (In reply to comment #2) I also think the code is valid. In this case though, there is the complication that no hiding takes place [...] Wasn't aware that this is also a case of hiding, but 3.3.10 about hiding actually even contains it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42490
[Bug c++/41796] ambiguous subobject diagnostic given too early
--- Comment #3 from schaub-johannes at web dot de 2010-02-11 01:08 ---
Well this is certainly not valid C++03, so i have tagged it c++0x (class member
name lookup was completely rewritten in c++0x, which made it valid and which
also added 10.2). In '03, the following should fail i think, instead of
re-declaring the member name as an alias to the declaration of a in A:
struct A { int a; };
struct B : A {};
struct C : A {};
struct D : B, C { };
struct E : D { using D::a; };
The example in 10.2/13 (n3000) is missing an ambiguity check: It's impossible
for GCC to figure out to which sub-object the member pointer address is
associated with. I think the example is wrong (see
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#983 for the issue
report about it).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
[Bug c++/42655] New: Don't qualify rvalues of non-class types
GCC applies cv-qualifiers to rvalues of non-class types. The following code is
all right, but GCC doesn't like it:
templatetypename T
void unused(T const ) { }
int main() {
volatile bool x = false;
unused(!x); // type of !x is bool
}
--
Summary: Don't qualify rvalues of non-class types
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42655
[Bug c++/42655] [4.3/4.4/4.5 Regression] ! causes the qualified types for rvalue
--- Comment #3 from schaub-johannes at web dot de 2010-01-08 03:35 --- The following are two other cases where GCC misses to drop qualifiers typedef int const intt; unused(intt()); // intt has type 'int' int const f(); unused(f()); // f() has type 'int' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42655
[Bug c++/42655] [4.3/4.4/4.5 Regression] ! causes the qualified types for rvalue
--- Comment #4 from schaub-johannes at web dot de 2010-01-08 03:40 --- (Should have mentioned i did the second set of tests with a modified unused having T as parameter type, and relying on failure of binding of non-const references to rvalues. GCC does not reject the two calls). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42655
[Bug c++/41815] New: GCC wrongly treats rvalues of non-class type cv-qualified
The issue rises up with C++0x's decltype and rvalue references:
int const f() { return 0; }
int r = f(); // binding int to int should succeed
decltype(0, f()) i; // i should get type int, not int const.
In C++, non-class type are not cv-qualified.
--
Summary: GCC wrongly treats rvalues of non-class type cv-
qualified
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41815
[Bug c++/41796] New: Extended sizeof (referring to non-static member) rises ambiguity
The following code fails for GCC:
struct A { int a; };
struct B : A {};
struct C : A {};
struct D : B, C { };
int main() { (void) sizeof(D::a); }
According to the current draft, such use is correct: Name lookup will resolve
to a single declaration, and sizeof does not make additional constraint with
regard to the subobject to refer to. It is reasonable to suspect a standard
defect - this bug report is supposed to be a reminder in that case.
--
Summary: Extended sizeof (referring to non-static member) rises
ambiguity
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
GCC host triplet: 4.4.1
GCC target triplet: 4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
[Bug c++/41796] Extended sizeof (referring to non-static member) rises ambiguity
--- Comment #1 from schaub-johannes at web dot de 2009-10-22 18:42 --- I found the same problem occurs with decltype - same diagnostic. Wasn't sure whether i should open another bug report for that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
[Bug c++/41769] New: Parameter names not restricted to identifiers
GCC compiles and runs this code correctly:
void f(void operator+()) { operator+(); }
void g() { }
int main() { f(g); }
It should reject the parameter name, because operator+ is not an identifier.
--
Summary: Parameter names not restricted to identifiers
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41769
[Bug c++/41468] New: SFINAE for expressions doesn't consider ambiguous conversion sequences
GCC 4.4 is supposed to support SFINAE for expressions - but the following
piece of code fails hard, without SFINAE
typedef void Ft(int);
struct A { operator Ft*(); };
struct B { operator Ft*(); };
struct C : A, B { };
templatetypename C decltype(C()(0)) f(int);
templatetypename C void f(...);
int main() { fC(0); }
main.cpp: In function 'int main()':
main.cpp:8: error: conversion from 'C' to 'void (*)(int)' is ambiguous
main.cpp:3: note: candidates are: B::operator void (*)(int)()
main.cpp:2: note: A::operator void (*)(int)()
The call within the decltype specifier is ill-formed - which should be a
deduction failure but shouldn't cause the program to become ill-formed.
--
Summary: SFINAE for expressions doesn't consider ambiguous
conversion sequences
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41468
[Bug c++/41431] New: main should be allowed within unevaluated operands.
The following code snippet is wrongly rejected
int main() { sizeof(main); }
---
main.cpp: In function 'int main()':
main.cpp:1: warning: ISO C++ forbids taking address of function '::main'
---
But the Standard allows that within a sizeof, because according to 3.2/2 it
does not constitute a use of main.
--
Summary: main should be allowed within unevaluated operands.
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41431
[Bug c++/40750] New: Side-effect of member function call not produced in certain circumstances
GCC mis-compiles the following code for mysterious reasons. While it should
output called, it outputs nothing at all
// snip
typedef void Fn() const;
struct Foo { Fn fn; };
void Foo::fn() const { std::cout called std::endl; }
int main() { Foo f; f.fn(); }
// snap
Any one of the following makes it show called properly:
- Adding inline function specifier in the declaration of the function at
class or namespace scope.
- Replacing Fn fn; by a declaration with a function declarator void fn()
const;
- Making the function non-const (in the typedef and in the definition of the
function).
--
Summary: Side-effect of member function call not produced in
certain circumstances
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40750
[Bug c++/40336] New: Language linkage should be part of the function type
Hello all, i discovered that the following code doesn't compile, why i expected
that it compiles fine
templatetypename, typename struct F { typedef int type; };
templatetypename A struct FA, A { };
typedef void(*fp0)();
extern C typedef void (*fp1)();
int main() { Ffp0, fp1::type i; }
// diagnostic:
main.cpp: In function 'int main()':
main.cpp:7: error: 'type' is not a member of 'Fvoid (*)(), void (*)()'
main.cpp:7: error: expected ';' before 'i'
The problem seems to be that it thinks the function pointer types are the same
- but C++ is very clear on that they are different types.
--
Summary: Language linkage should be part of the function type
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40336
[Bug c++/40239] New: Aggregate initialization requires copy constructor
GCC 4.4.0 (and earlier) requires a copy constructor for elements that are not
explicitly initialized using a non-empty aggregate initializer list. Thus the
following fails
struct B { B() { } private: B(B const); };
struct A { int a; B b; };
int main() {
A a = { 0 };
}
main.cpp: In function 'int main()':
main.cpp:1: error: 'B::B(const B)' is private
main.cpp:5: error: within this context
The Standard says any not explicitly ininitialized element is
value-initialized. In the above sample, that should call the default
constructor. The copy constructor is required only when using an empty
aggregate initializer:
struct B { B() { } private: B(B const); };
struct A { int a; B b; };
int main() {
A a = { };
}
In which case any element should be initialized from an expression of the form
T(), with T being the type of the element. GCC correctly rejects that example,
but incorrectly rejects the first example.
Note that C++0x will make both examples valid (in the latest draft, at least),
and GCC should not reject any of them.
--
Summary: Aggregate initialization requires copy constructor
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40239
[Bug c++/40177] New: ADL with non-unqualified-id
Hello all, this is a follow-up of #34870 . I tried to compile this one, and GCC
accepts, while it should reject it (it's not valid as #34870 might suggest):
struct A { templateint N friend void f(A) { } };
int main() { f1(A()); }
The friend template function declared within class A is not visible at the
point of call in main. However, for forming an unqualified-id that's a
template-id (which is the only form to fulfill the syntactic requirement of an
unqualified-id), the name used in the template-id must be known as a template
first. Since that's not the case here, and name-lookup is also not delayed to a
point where a declaration of A::f are visible by unqualified-lookup, the
example is ill-formed and should be rejected, since f1 must be parsed as a
relational expression not making sense in this context at all.
The same is true when instead of a non-type parameter a type-parameter is used.
It does not change anything w.r.t the interpretation as a non-unqualified-id.
See the note of the C++ Standard at 14.8.1/6 and section 14.2 (especially
14.2/2).
--
Summary: ADL with non-unqualified-id
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40177
[Bug c++/34870] argument-dependent lookup wrongly finds friend declaration
--- Comment #10 from schaub-johannes at web dot de 2009-05-17 16:38 --- A added another bug-report very similar to this that handles the case where the friend definition is about a template: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40177 . GCC accepts in that case, while it should reject. -- schaub-johannes at web dot de changed: What|Removed |Added CC||schaub-johannes at web dot ||de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34870
[Bug c++/38950] [4.3/4.4 regression] ICE: deducing function template arguments for array type.
--- Comment #4 from schaub-johannes at web dot de 2009-02-03 02:02 --- Yes, sorry for not mentioning it. I also think the code is valid. In the link to stackoverflow.com, where i answered that guys question, i gave reasons why i think so. Next time i will put what i think about that directly into the bugreport :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38950
[Bug c++/38950] New: ICE: deducing function template arguments for array type.
The following snippet makes GCC 4.3.2 (and SVN versions as of 09/2008 still)
cause an ICE:
template typename T, T N void f(T()[N]);
int main() {
int x[2];
unsigned int y[2];
f(x); // works
f(y); // ICE
}
Getting this output:
test.cpp: In function 'int main()':
test.cpp:7: internal compiler error: in dependent_type_p, at cp/pt.c:15585
More information about this issue:
http://stackoverflow.com/questions/472530/how-to-pass-an-array-size-as-a-template-with-template-type
--
Summary: ICE: deducing function template arguments for array
type.
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38950
[Bug c++/36843] New: Not able to declare a function using function type template parameter
When you pass a function-type to a template as a type-parameter, you cannot use
that type to declare member functions (in class templates), or to declare free
functions (in function templates). This looks strange to me. comeau allows to
do this.
Testcase with class template:
templatetypename T struct bar { T foo; };
int main() { Barvoid() k; }
output:
report.cpp: In instantiation of 'Barvoid ()()':
report.cpp:1: instantiated from here
report.cpp:1: error: field 'Barvoid ()()::p' invalidly declared function type
Testcase with function template:
templatetypename T void foo() { T bar; }
int main() { foovoid()(); }
report.cpp: In function »void foo() [with T = void ()()]«:
report.cpp:1: instantiated from here
report.cpp:1: Fehler: Variable »bar« hat Funktionstyp
--
Summary: Not able to declare a function using function type
template parameter
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36843
[Bug c++/36843] Not able to declare a function using function type template parameter
--- Comment #1 from schaub-johannes at web dot de 2008-07-15 20:43 ---
(In reply to comment #0)
When you pass a function-type to a template as a type-parameter, you cannot
use
that type to declare member functions (in class templates), or to declare free
functions (in function templates). This looks strange to me. comeau allows to
do this.
Testcase with class template:
templatetypename T struct bar { T foo; };
int main() { Barvoid() k; }
output:
report.cpp: In instantiation of 'Barvoid ()()':
report.cpp:1: instantiated from here
report.cpp:1: error: field 'Barvoid ()()::p' invalidly declared function
type
Testcase with function template:
templatetypename T void foo() { T bar; }
int main() { foovoid()(); }
report.cpp: In function »void foo() [with T = void ()()]«:
report.cpp:1: instantiated from here
report.cpp:1: Fehler: Variable »bar« hat Funktionstyp
I'm sorry for the german output message in the second testcase. i forgot to
change language:
report.cpp: In function 'void foo() [with T = void ()()]':
report.cpp:1: instantiated from here
report.cpp:1: error: variable 'bar' has function type
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36843
[Bug c++/36843] Not able to declare a function using function type template parameter
--- Comment #2 from schaub-johannes at web dot de 2008-07-15 22:22 --- I've written carefully through the Standard, and found this paragraph: 14.3.1p3 If a declaration acquires a function type through a type dependent on a template-parameter and this causes a declaration that does not use the syntactic form of a function declarator to have function type, the program is ill-formed. So i mark this as invalid. -- schaub-johannes at web dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36843
