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:
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
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
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
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
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
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
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
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
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
--- 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
--- 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
-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
--- 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
--- 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
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
: 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
.
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
--- 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
: 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
--- 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
--- 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
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
--- 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
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
-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
--- 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
--- 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
-johannes at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41815
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
--- 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
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
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
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
: 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
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
: 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
: 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
--- 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
--- 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
.
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
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
--- 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
--- 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
50 matches
Mail list logo
