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
--- 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
--- 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
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
--- 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
++
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
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
-gruppe dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21084
--- 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
--- Additional Comments From sstrasser at systemhaus-gruppe dot de
2005-04-18 12:08 ---
fixed
--
What|Removed |Added
Status|NEW
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
--- 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
--- 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
--- 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
--- 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
: 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
--- 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
--- 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
: 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
--- 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
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
: 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
--- 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
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
--- 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
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
--- 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
--- 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
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
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
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
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
--- 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
--- 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
--
What|Removed |Added
Summary|wrong tree for extern C |wrong linkage of extern C
|variables |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
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
--- 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
--- 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
++
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
--- 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
--
What|Removed |Added
Summary|cp_namespace_decl not |cp_binding_level::names not
|returning all decls |returning all decls
--
What|Removed |Added
Summary|cp_binding_level::names not |cp_binding_level
|returning all decls |
--
What|Removed |Added
Summary|cp_binding_level|cp_binding_level::names not
||returning all decls
44 matches
Mail list logo