ify 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 tr
--- 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 'in
--- 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
--- 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
--- 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. A
--- 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
--- 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, bu
qualified 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-
--- 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
--- 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 (&qu
--- 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
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 tar
--- 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:
template
void f(U&) { } // #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43453
--- Comment #3 from Johannes Schaub 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("
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
Priorit
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: norma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46731
--- Comment #2 from Johannes Schaub 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 doi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46731
--- Comment #5 from Johannes Schaub 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 c
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
P
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
dTo: 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
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
s
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
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
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
ned 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
--- 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") { }
> > };
>
NCONFIRMED
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)
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
Compon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46005
--- Comment #2 from Johannes Schaub 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’"
--- 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.
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
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
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
ef 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: i
--- 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
--- 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.
--- 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" writes:
>
&
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-
--- 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
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-li
--- 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
ersion: 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-g
--
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
R
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
c
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-
--- 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
--- 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 tha
50 matches
Mail list logo