[Bug c++/11582] Odd error message with dynamically sized template arg printing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11582 Wolfgang Bangerth changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #13 from Wolfgang Bangerth --- Sure, good enough. I think `' isn't quite correct: it's a variably-sized type, so the size can not be determined at compile time. This is the part that is missing from the error message. But I don't think it's worthwhile keeping the report open.
[Bug tree-optimization/63945] New: Missing vectorization optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63945
Bug ID: 63945
Summary: Missing vectorization optimization
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bangerth at gmail dot com
(Reporting this for Bruno Turcksin bruno.turck...@gmail.com.)
The loop in the following testcase cannot be vectorized, we get the error:
note: not vectorized: latch block not empty.
note: bad loop form.
The reason is that val is a member of the class, is evaluated in the if, and is
used in the loop that should be vectorized. If these three conditions are
satisfied the loop cannot be vectorized.
...
#include vector
class TEST
{
public :
TEST();
void test();
private :
const double val;
};
TEST::TEST()
:
val(2.)
{}
void TEST::test()
{
const unsigned int n(1000);
std::vectordouble a(n);
std::vectordouble b(n);
std::vectordouble c(n);
for (unsigned int i=0; in; ++i)
{
a[i] = 1.;
b[i] = 1.;
}
if (val100.)
{
#pragma omp simd
for (unsigned int i=0; in; ++i)
c[i] = val*a[i]+b[i];
}
}
int main ()
{
TEST a;
a.test();
}
...
[Bug preprocessor/33415] Can't compile .cpp file with UTF-8 BOM.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33415 --- Comment #9 from Wolfgang Bangerth bangerth at gmail dot com 2013-03-25 13:50:00 UTC --- Vikas: This was fixed in GCC in 2008. The version of GCC you are using (3.4.6) was released in 2006 and the entire 3.4.x tree is in fact from 2004. It is time for you to upgrade your system after almost a decade if there are features you need.
[Bug libstdc++/56257] std::vector allows access to the elements of _Vector_base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56257 --- Comment #3 from Wolfgang Bangerth bangerth at gmail dot com 2013-02-09 21:37:55 UTC --- :-) Sure, and of course I did tell him don't do that. In essence it's a question of how easy it is to shoot yourself in the foot by exposing internal details of the implementation.
[Bug libstdc++/56257] New: std::vector allows access to the elements of _Vector_base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56257
Bug #: 56257
Summary: std::vector allows access to the elements of
_Vector_base
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bange...@gmail.com
To my complete consternation, a student of mine came by and showed me some code
her wrote that essentially looked like this:
---
#include vector
struct X :
public std::vectorint
{
X()
{
this-_M_impl;
}
};
---
While accessing the implementation details of std::vector was a clever
optimization in his case, it's certainly an end-run around the encapsulation
principle. It also doesn't lead to portable code.
Is it intentional that the derivation of std::vector from _Vector_base is only
protected and not private?
Best
W.
[Bug c/47043] allow deprecating enum values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47043 Wolfgang Bangerth bangerth at gmail dot com changed: What|Removed |Added CC||joseph.h.garvin at gmail ||dot com --- Comment #2 from Wolfgang Bangerth bangerth at gmail dot com 2013-01-05 23:31:11 UTC --- *** Bug 45168 has been marked as a duplicate of this bug. ***
[Bug c/45168] There should be a way to mark specific enum members as deprecated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45168 Wolfgang Bangerth bangerth at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||bangerth at gmail dot com Resolution||DUPLICATE --- Comment #1 from Wolfgang Bangerth bangerth at gmail dot com 2013-01-05 23:31:11 UTC --- Confirmed, and a duplicate of an PR that had already been confirmed. *** This bug has been marked as a duplicate of bug 47043 ***
[Bug c/47043] allow deprecating enum values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47043 Wolfgang Bangerth bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com --- Comment #3 from Wolfgang Bangerth bangerth at gmail dot com 2013-01-05 23:32:04 UTC --- Indeed a good idea -- I'm missing it too. For the record, clang++ accepts the code.
[Bug c++/54844] [4.8 Regression] ice tsubst_copy, at cp/pt.c:12352
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54844 --- Comment #10 from Wolfgang Bangerth bangerth at gmail dot com 2012-10-22 11:58:58 UTC --- Given that this bug has been found 3 times already (and I extracted my testcase from the widely used BOOST library), is there an ETA for a fix? W.
[Bug c++/54844] [4.8 Regression] ice tsubst_copy, at cp/pt.c:12352
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54844 --- Comment #12 from Wolfgang Bangerth bangerth at gmail dot com 2012-10-22 13:05:36 UTC --- Thanks, Jakub!
[Bug c++/54994] New: [4.8 regression] New ICE in tsubst_copy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54994
Bug #: 54994
Summary: [4.8 regression] New ICE in tsubst_copy
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bange...@gmail.com
May or may not be related to PR 54844:
This little piece of code has recently started to produce an ICE on mainline:
..
template bool class X {};
template typename T struct A {
X(sizeof(T)sizeof(long double)) x;
};
Aint a;
..
c++ -c numerics/a.cc
numerics/a.cc: In instantiation of 'struct Aint':
numerics/a.cc:7:8: required from here
numerics/a.cc:4:24: internal compiler error: in tsubst_copy, at cp/pt.c:12387
X(sizeof(T)sizeof(long double)) x;
^
linux-vdso.so.1: No such file or directory
0x596d03 tsubst_copy
../../mainline/gcc/cp/pt.c:12387
0x586762 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../mainline/gcc/cp/pt.c:13514
0x585b81 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../mainline/gcc/cp/pt.c:13539
0x585602 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../mainline/gcc/cp/pt.c:13494
0x58e6a4 tsubst_expr
../../mainline/gcc/cp/pt.c:13194
0x5a1002 tsubst_template_arg
../../mainline/gcc/cp/pt.c:9039
0x5a75e2 tsubst_template_args
../../mainline/gcc/cp/pt.c:9489
0x5add71 tsubst_aggr_type
../../mainline/gcc/cp/pt.c:9686
0x59e773 tsubst(tree_node*, tree_node*, int, tree_node*)
../../mainline/gcc/cp/pt.c:11039
0x599216 tsubst_decl
../../mainline/gcc/cp/pt.c:10329
0x59eb8c tsubst(tree_node*, tree_node*, int, tree_node*)
../../mainline/gcc/cp/pt.c:10965
0x5c4a5c instantiate_class_template_1
../../mainline/gcc/cp/pt.c:8778
0x5c4a5c instantiate_class_template(tree_node*)
../../mainline/gcc/cp/pt.c:9020
0x64eb2b complete_type(tree_node*)
../../mainline/gcc/cp/typeck.c:134
0x54b548 start_decl_1(tree_node*, bool)
../../mainline/gcc/cp/decl.c:4621
0x5675e1 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../mainline/gcc/cp/decl.c:4584
0x6415dc cp_parser_init_declarator
../../mainline/gcc/cp/parser.c:15887
0x641f6f cp_parser_simple_declaration
../../mainline/gcc/cp/parser.c:10560
0x63ce27 cp_parser_block_declaration
../../mainline/gcc/cp/parser.c:10441
0x647f3b cp_parser_declaration
../../mainline/gcc/cp/parser.c:10338
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
Best
W.
[Bug c++/54844] [4.8 Regression] ice tsubst_copy, at cp/pt.c:12352
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54844 Wolfgang Bangerth bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com --- Comment #7 from Wolfgang Bangerth bangerth at gmail dot com 2012-10-20 02:23:30 UTC --- May be related to PR 54994.
[Bug c++/54575] [4.8 Regression] ICE with std::vector::insert and -std=c++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54575 --- Comment #13 from Wolfgang Bangerth bangerth at gmail dot com 2012-09-18 15:32:17 UTC --- Thanks, all, for the quick turnaround. This works again, not just on the testcase but on the entire code base. Best W.
[Bug c++/54575] [4.8 Regression] ICE with std::vector::insert and -std=c++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54575
--- Comment #4 from Wolfgang Bangerth bangerth at gmail dot com 2012-09-14
11:48:56 UTC ---
Would this do? ;-)
..
templatetypename _From, typename _To
struct is_convertible { static const bool value = true; };
templatebool struct enable_if { };
template struct enable_iftrue { typedef int type; };
templatetypename _InIter
using _RequireInputIter
= typename enable_ifis_convertible_InIter,bool::value::type;
templatetypename _Tp struct X {
templatetypename _InputIterator,
typename = _RequireInputIter_InputIterator
void insert(_InputIterator) {}
};
templatetypename void foo() {
Xint subdomain_indices;
subdomain_indices.insert(0);
}
.
gcc -std=c++11 -c x.ii
x.ii: In function 'void foo()':
x.ii:13:7: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in strip_typedefs, at cp/tree.c:1215
typename = _RequireInputIter_InputIterator
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/54575] New: ICE with std::vector::insert and -std=c++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54575
Bug #: 54575
Summary: ICE with std::vector::insert and -std=c++11
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bange...@gmail.com
The following currently produces an ICE when using -std=c++11:
..
#include vector
template class DH
void
foo()
{
std::vectorunsigned int local_dof_indices;
std::vectorunsigned int subdomain_indices;
subdomain_indices.insert(subdomain_indices.end(),
local_dof_indices.begin(),
local_dof_indices.end());
}
..
/home/bangerth/bin/gcc-mainline/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/bangerth/bin/gcc-mainline/bin/gcc
COLLECT_LTO_WRAPPER=/home/bangerth/bin/gcc-mainline/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../mainline/configure --prefix=/home/bangerth/bin/gcc-mainline
--enable-languages=c,c++ --disable-multilib
Thread model: posix
gcc version 4.8.0 20120913 (experimental) [trunk revision 183295] (GCC)
/home/bangerth/bin/gcc-mainline/bin/gcc -c -std=c++11 x.cc
In file included from
/home/bangerth/bin/gcc-mainline/include/c++/4.8.0/vector:65:0,
from dofs/dof_tools.cc:1:
/home/bangerth/bin/gcc-mainline/include/c++/4.8.0/bits/stl_vector.h: In
function 'void foo()':
/home/bangerth/bin/gcc-mainline/include/c++/4.8.0/bits/stl_vector.h:1042:9:
internal compiler error: tree check: expected class 'type', have 'exceptional'
(error_mark) in strip_typedefs, at cp/tree.c:1215
typename = std::_RequireInputIter_InputIterator
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/2316] g++ fails to overload on language linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316 Wolfgang Bangerth bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com --- Comment #41 from Wolfgang Bangerth bangerth at gmail dot com 2012-01-04 12:28:13 UTC --- I would expect a lot of code to trigger this warning. It is quite common to pass the address of a static member function to pthread_create but since there is no way to make a static member function 'extern C', I can't see how to do that without major contortions. I'm rather sure that this will turn out to be an unpopular warning :-) W.
[Bug c++/30539] Accepts invalid explicit specialization declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30539 --- Comment #3 from Wolfgang Bangerth bangerth at gmail dot com 2012-01-03 19:11:09 UTC --- Excellent, and thanks! It's good to see that some of the 5+ year old reports are still being closed on occasion :-) (Although I have to say that this one was one of the more humorous, allowing to write template void X1::X2::X3::X4::f(); I'm almost going to miss that ;-)
[Bug c++/10200] Weird clash with same names in different scopes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10200 Wolfgang Bangerth bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com --- Comment #17 from Wolfgang Bangerth bangerth at gmail dot com 2011-10-09 13:34:27 UTC --- Still happens with gcc 4.5.1.
[Bug c++/15272] lookup, dependent base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15272 Wolfgang Bangerth bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com --- Comment #7 from Wolfgang Bangerth bangerth at gmail dot com 2011-10-09 13:36:06 UTC --- Still happens with gcc4.5.1.
[Bug c++/6936] member using binds wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6936 Wolfgang Bangerth bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com --- Comment #2 from Wolfgang Bangerth bangerth at gmail dot com 2011-10-09 13:38:29 UTC --- Still happens with gcc4.5.1. Note that it doesn't matter which of the variables are accessed since it's a name lookup problem and name lookup happens before access control checking.
[Bug c++/11814] Code with missing template keyword wrongly accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11814 Wolfgang Bangerth bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com --- Comment #12 from Wolfgang Bangerth bangerth at gmail dot com 2011-10-09 13:52:05 UTC --- Still happens with gcc4.5.1.
[Bug c++/10291] error referencing a static local from a local struct in template code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10291 Wolfgang Bangerth bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com --- Comment #9 from Wolfgang Bangerth bangerth at gmail dot com 2011-10-09 13:55:10 UTC --- Still happens with gcc4.5.1.
[Bug c++/10852] Old for-scoping rules improperly used?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10852 Wolfgang Bangerth bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com --- Comment #6 from Wolfgang Bangerth bangerth at gmail dot com 2011-10-09 13:59:42 UTC --- Still happens for gcc4.5.1.
[Bug libstdc++/49717] New: Debug version checking algorithmic preconditions may have different complexity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49717 Summary: Debug version checking algorithmic preconditions may have different complexity Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: bange...@gmail.com This is essentially just a request to state something more explicitly on the website: We've started using the libstdc++ debug mode for running our testsuite (and found a dozen or so bugs with it -- yay) but I've come to realize that a bunch of tests now time out: they've become orders of magnitude slower. The reason I found for this is that many of the algorithms in libstdc++ (rightfully) check preconditions. For example, std::lower_bound checks whether indeed the given element partitions the sequence. The problem here is that these checks violate the complexity guarantees of the algorithms: std::lower_bound is supposed to be O(log(N)) but with the check for partitioning, it is now O(N). In our case, we call this function for each element of a sequence, and so we get O(N**2) instead of O(N log(N)) and the result is the increase in compute time. There is little one can do about this -- the debug mode is meant to check these things and it can't be done in O(log(N)). But it would be good to state this prominently somewhere in the corresponding web sites. Thanks W.
[Bug libstdc++/49717] Debug version checking algorithmic preconditions may have different complexity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49717 Wolfgang Bangerth bangerth at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Wolfgang Bangerth bangerth at gmail dot com 2011-07-12 14:00:05 UTC --- Aw, thanks for the link -- I wonder how I missed that :-( I'm looking forward to trying 4.6 whenever our sysadmins decide to put it onto our machines -- the things you mention are one of many goodies worth trying. Thanks W.
[Bug c++/48818] Wrong copy constructor used when using std::pair in .so and app.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48818 Wolfgang Bangerth bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com --- Comment #3 from Wolfgang Bangerth bangerth at gmail dot com 2011-05-26 05:44:18 UTC --- Are you saying that you have classes that have the same name but are different? This violates the One Definition Rule, no?
[Bug c++/44629] [4.3 Regression] ICE in unify, at cp/pt.c:15155
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44629
Wolfgang Bangerth bangerth at gmail dot com changed:
What|Removed |Added
CC||bangerth at gmail dot com
--- Comment #12 from Wolfgang Bangerth bangerth at gmail dot com 2011-03-09
21:52:52 UTC ---
(In reply to comment #4)
templatetypename T int cmp1(T a, T b);
templatetypename T int cmp2(T a, T b);
templatetypename T, int (*cmp)(T, T) = cmp1 struct A { };
I'm confused why this would be an overload set. cmp1 is a template so I
can't see how this code would even begin to be valid without specifying
the template argument in the default argument...
W.
[Bug c++/44629] [4.3 Regression] ICE in unify, at cp/pt.c:15155
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44629 --- Comment #14 from Wolfgang Bangerth bangerth at gmail dot com 2011-03-10 04:27:49 UTC --- (In reply to comment #13) Once you know A's T, you have a desired type int (*)(T, T) from which to determine which specialization of the template to use. Hm, I agree that the type could be deduced. I could nevertheless have sworn that this should be invalid: .. template typename T int cmp1(T a, T b); int (*cmp)(int, int) = cmp1; ... But it compiles in fact. I had no idea a template name could be implicitly instantiated in this context. Thanks for educating me! Best W.
[Bug c++/45606] [4.5/4.6 Regression] match a method prototyped a typedef alias with the original type (using stdlib)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45606 Wolfgang Bangerth bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com --- Comment #8 from Wolfgang Bangerth bangerth at gmail dot com 2011-02-27 22:52:54 UTC --- If this is fixed in 4.6, shouldn't the bug summary be adjusted to make this clear?
[Bug c++/45329] When printing a list of candidate functions, explain why each function failed to match.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45329 Wolfgang Bangerth bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com --- Comment #1 from Wolfgang Bangerth bangerth at gmail dot com 2010-11-17 23:00:20 UTC --- I think the patch that has just been posted is awesome. My favorite reasons for functions not matching is if you pass a const object to a non-const reference or if there is only a non-const member function that you try to call on a const object. In either case, assuming that a sufficient number of arguments are involved and if they are all templates of the kind std::vectorstd::vectorT (with all the defaulted template arguments) it becomes essentially impossible to see easily why the call failed. May I make a suggestion regarding the proposed format of the error message/note: the candidate list is currently already indented to align candidates. Would it be possible to indent the reason why the candidate failed *relative to the candidate*? For example something of the kind: 1 pr45329.C:26:7: error: no matching function for call to 'foo(int)' 2 cc1plus: note: candidates are: 3 pr45329.C:7:5: note: int foo(int, int) 4 pr45329.C:7:5: candidate expects 2 arguments, 1 provided 5 pr45329.C:19:5: note: int foo(const S) 6 pr45329.C:19:5: no known conversion for argument 1 from 'int' to 'const S' (note the lack of the note text on lines 4,6 relative to the patch you posted), or 1 pr45329.C:26:7: error: no matching function for call to 'foo(int)' 2 cc1plus: note: candidates are: 3 pr45329.C:7:5:int foo(int, int) 4 pr45329.C:7:5: reason: candidate expects 2 arguments, 1 provided 5 pr45329.C:19:5: int foo(const S) 6 pr45329.C:19:5: reason: no known conversion for argument 1 from 'int' to 'const S' In either case, it breaks up the long list of candidates one often gets into self-contained blocks that are easier to parse for the human eye. Thanks W.
[Bug c++/45329] When printing a list of candidate functions, explain why each function failed to match.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45329
--- Comment #3 from Wolfgang Bangerth bangerth at gmail dot com 2010-11-18
02:42:01 UTC ---
(In reply to comment #2)
In either case, assuming that a sufficient number of arguments are
involved and if they are all templates of the kind
std::vectorstd::vectorT
(with all the defaulted template arguments) it becomes essentially
impossible
to see easily why the call failed.
Testcase?
#include vector
void f(int, std::vectorint );
void f(char, std::vectorint );
void bar()
{
const std::vectorint v;
f(2,v);
}
.
x.cc: In function 'void bar()':
x.cc:8:8: error: no matching function for call to 'f(int, const
std::vectorint)'
x.cc:2:6: note: candidates are: void f(int, std::vectorint)
x.cc:3:6: note: void f(char, std::vectorint)
Previous versions of gcc printed not just std::vectorint but
the whole std::vectorint,std::allocator... thing.
I think the lack of note would be the difficult part. I don't think we have
diagnostics without prefix.
Sorry, I misremembered. All lines have 'note', but only the first has
'candidates are'. Either way, the following ones are indented which I think
makes it more readable.
Even if such diagnostic were implemented note: is a translated string, so
the
indentation has to be relative to it.
But is it currently? (I.e. with the candidates are: string that is omitted in
following lines?)
I don't see why removing the notes: adds/removes blocks, since it is the
same prefix every line. But I like the idea of using a reason: prefix, why
not a candidate: prefix also?
I don't care how it's done but if you've stared long enough at template-laden
error messages involving half a dozen function arguments of half a dozen
candidate functions, you'd really appreciate some substructuring of the list.
But personally, I would prefer everything in the same line:
pr45329.C:26:7: error: no matching function for call to 'foo(int)'
pr45329.C:7:5: note: candidate 'int foo(int, int)' expects 2 arguments, 1
provided
pr45329.C:19:5: note: candidate 'int foo(const S)': no known conversion for
argument 1 from 'int'
I think also that this latest version would require fewer testsuite changes.
That would work for me as well. I think the testsuite argument is mistaken,
though: the goal should be to produce quality diagnostics, not to minimize the
number of changes in the testsuite.
Best
W.
[Bug c++/45114] implement C++0x alias-declaration
--- Comment #2 from bangerth at gmail dot com 2010-09-07 18:08 --- Corresponding paper, for reference: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2258.pdf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45114
[Bug c++/40793] Error: no matching function for call to XYZ doesn't display function-template-arguments
--- Comment #8 from bangerth at gmail dot com 2010-07-01 21:38 --- I think that would already be an improvement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40793
[Bug c++/44486] [4.3/4.4/4.5/4.6 regression] missing space in __PRETTY_FUNCTION__ expansion in anonymous namespace
--- Comment #2 from bangerth at gmail dot com 2010-06-10 03:27 ---
This is a regression:
2.95: struct S {anonymous}::f()
3.4: S unnamed::f()
4.0: Sunnamed::f()
W.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC||bangerth at gmail dot com
Known to fail||4.0.4 4.5.0
Known to work||3.4.6
Summary|missing space in|[4.3/4.4/4.5/4.6 regression]
|__PRETTY_FUNCTION__ |missing space in
|expansion in anonymous |__PRETTY_FUNCTION__
|namespace |expansion in anonymous
||namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44486
[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006
--- Comment #7 from bangerth at gmail dot com 2010-06-04 16:36 --- As the author of the benchmark I can confirm that we apparently forgot to include the proper header file. So you can call it a defect in 447.dealII. The question is how to deal with this, of course. W. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44416
[Bug c++/44021] Templates with -Wtype-limits produces warnings.
--- Comment #5 from bangerth at gmail dot com 2010-05-07 13:15 --- *** This bug has been marked as a duplicate of 11856 *** -- bangerth at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44021
[Bug c++/11856] unsigned warning in template
--- Comment #28 from bangerth at gmail dot com 2010-05-07 13:15 --- *** Bug 44021 has been marked as a duplicate of this bug. *** -- bangerth at gmail dot com changed: What|Removed |Added CC||crossroads at googlemail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856
[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair
--- Comment #12 from bangerth at gmail dot com 2010-04-19 14:57 --- (In reply to comment #9) Also, make_pair's reason for existing is to deduce template arguments. If you don't want argument deduction why use make_pair? True. I don't know why one would want to do this either, but several people happened to do so about half a dozen times in our 500,000 lines of code. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43785
[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair
--- Comment #15 from bangerth at gmail dot com 2010-04-19 15:51 --- (In reply to comment #14) Well it's about time someone put a stop to it ;-) Seriously though, it's quicker to write e.g. return std::pairuint32_t, uint32_t(x, y) than return std::make_pairuint32_t, uint32_t(x, y); No question. The point I wanted to make is that such code exists out there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43785
[Bug c++/43787] [4.5/4.6 Regression] memory copy of empty class (sizeof is one)
--- Comment #9 from bangerth at gmail dot com 2010-04-19 22:18 --- Dereferencing the null pointer invokes undefined behavior, independent on whether the type of the dereferenced pointer is an empty class or not. Typically, dereferencing NULL results in a trap. GCC simply preserves this behavior here. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43787
[Bug c++/43785] very basic regression in std::make_pair
--- Comment #2 from bangerth at gmail dot com 2010-04-18 19:02 --- Confirmed. Including utility doesn't help. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-18 19:02:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43785
[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair
--- Comment #7 from bangerth at gmail dot com 2010-04-19 02:59 --- I think the point Andrew wanted to make is that it's a regression *from the user perspective*. I had a half dozen places in our code that now no longer compile in c++0x mode. Apparently others do too. If the standard is not finished yet, I would think it rather useful if we could implement something that is at least backward compatible. In my eyes, the fact that we reject working code from previous standards is a defect in the current draft. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43785
[Bug tree-optimization/43771] [4.5/4.6 Regression] ICE on valid when compiling ParMetis with gcc 4.5.0 and -O3
--- Comment #2 from bangerth at gmail dot com 2010-04-17 02:55 --- Ouch. ParMetis is one of the most widely used libraries in the parallel scientific computing area... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43771
[Bug c++/43680] G++ is too aggressive in optimizing away bounds checking with enums
--- Comment #9 from bangerth at gmail dot com 2010-04-08 12:53 --- I'm not saying we *should* apply a mask (in fact, I think that would be silly). But we *could*, and if we did then VRP's actions might lead to faster but not different code. All I want to say is that VRP is a powerful tool. Let's not just throw the baby out with the bath water. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43680
[Bug c++/43648] [4.5/4.6 regression] ICE with explicit destructor call and typedef
--- Comment #6 from bangerth at gmail dot com 2010-04-07 16:17 --- Jason, thanks a lot for the quick turnaround, and my apologies for not testing this stuff on a more frequent basis so I find earlier than the day before branch day :-) W. -- bangerth at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43648
[Bug c++/43680] G++ is too aggressive in optimizing away bounds checking with enums
--- Comment #1 from bangerth at gmail dot com 2010-04-07 23:16 --- (In reply to comment #0) I think the C++ standard can definitely be read to allow this optimization I would most definitely think so. 7.2/6 specifically says that the values an enum variable can take on are, in your example, 0...3. See, in particular, footnote 81 in C++98. Everything outside would invoke undefined behavior, and I like that the compiler can make inferences from that. Don't we already have a warning that warns about assigning values outside the range of an enum? W. -- bangerth at gmail dot com changed: What|Removed |Added CC||manu at gcc dot gnu dot org, ||bangerth at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43680
[Bug c++/43648] New: [4.5 regression] ICE with explicit destructor call and typedef
With mainline from 20100107, the following code fails on Mac OS X:
--
namespace dealii
{
namespace FEValuesViews
{
template int dim, int spacedim struct Scalar {};
}
template int dim, int spacedim
struct X
{
FEValuesViews::Scalardim,spacedim scalars[dim*spacedim];
void f()
{
typedef dealii::FEValuesViews::Scalardim,spacedim ScalarView;
scalars[0].ScalarView::~ScalarView ();
}
};
template struct X2,2;
}
-
From what I can gather from the person who told me this, the error message
looks along the lines (line numbers/function names/file names are wrong,
though):
source/fe/fe_values.cc: In constructor
#8216;dealii::internal::FEValuesViews::Cachedim, spacedim::Cache(const
dealii::FEValuesBasedim, spacedim) [with int dim = 1, int spacedim =
1]#8217;:
source/fe/fe_values.cc:1486:31: instantiated from
#8216;dealii::FEValuesBasedim, spacedim::FEValuesBase(unsigned int, unsigned
int, dealii::UpdateFlags, const dealii::Mappingdim, spacedim, const
dealii::FiniteElementdim, spacedim) [with int dim = 1, int spacedim =
1]#8217;
source/fe/fe_values.cc:3941:16: instantiated from here
source/fe/fe_values.cc:1057:4: error: no type named #8216;ScalarView#8217; in
#8216;class dealii::FEValuesViews::Scalar1#8217;
source/fe/fe_values.cc:1057:4: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
The problem is that the code was written with the typedef, rather than
explicitly spelling out the full qualified class name, since some other
compilers do not grok it any other way.
Best
W.
--
Summary: [4.5 regression] ICE with explicit destructor call and
typedef
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43648
[Bug c++/43648] [4.5 regression] ICE with explicit destructor call and typedef
--- Comment #2 from bangerth at gmail dot com 2010-04-05 12:46 --- Thanks Richard for the quick confirmation. I should have mentioned that this worked on previous versions up to at least 4.3.3. W. -- bangerth at gmail dot com changed: What|Removed |Added Known to fail||4.5.0 Known to work||4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43648
[Bug c++/43646] [C++0x] decltype and std::integral_constant
--- Comment #2 from bangerth at gmail dot com 2010-04-05 12:56 --- I think this should work. I can't see how it would be invalid as template argument for integral_constant but valid for identity. W. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-05 12:56:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43646
[Bug c++/41884] diagnostics: error vs. context
--- Comment #15 from bangerth at gmail dot com 2010-04-05 15:28 --- FWIW, let me say that I believe that few people use -Wfatal-errors. Most of the time, experienced programmers are able to fix multiple bugs in one go-around if they get to see all error messages, and the less experienced programmers likely don't know about -Wfatal-errors. This said, I quite frequently find it annoying that the actual error message is so hard to find between the text printed above and below it. A defined place either at the top or at the bottom would be highly useful in my mind. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41884
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
--- Comment #8 from bangerth at gmail dot com 2010-04-02 11:37 --- I think this is a bug the MingW maintainers should handle. While I understand Andrew's position, it seems to me that this is nevertheless a definite regression from the user's perspective. W. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
[Bug c++/43522] [4.4 regression] Attempts to instantiate unnecessary code
--- Comment #4 from bangerth at gmail dot com 2010-03-25 18:37 --- (In reply to comment #2) So you are saying the standard thinks FixedPointPower::allow_double_instantiations is dependent. That is the correct question. We get the error message during template parsing, not during template instantiation (otherwise the error message would have [with Power=4]). So apparently the compiler thinks that Self::allow_double_instantiations is non-dependent and so tries to instantiate the tester template I think this is wrong: if you write it as Self::allow_double_instantiations it should be dependent, whereas if you write it without the Self:: it should be non-dependent. Can someone double check whether this also happens with mainline? W. -- bangerth at gmail dot com changed: What|Removed |Added CC||jason at redhat dot com, ||bangerth at gmail dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-25 18:37:17 date|| Summary|4.4 regression: Attempts to |[4.4 regression] Attempts to |instantiate unnecessary code|instantiate unnecessary code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43522
[Bug c++/43452] Array delete causes error on incomplete type
--- Comment #3 from bangerth at gmail dot com 2010-03-20 11:26 ---
(In reply to comment #2)
class Foo;
Foo* f();
int main() {
Foo* p = f();
delete [] p;
}
I can't see how the compiler could possibly do anything useful in this case
if Foo is incomplete. I can't find any statement that would say that the code
is ill-formed, however.
If there really is no such statement, I still don't think we should make it a
priority to compile this code without an error.
W.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC||bangerth at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43452
[Bug c/43405] sinl is not computed correctly
--- Comment #6 from bangerth at gmail dot com 2010-03-18 20:47 --- Also: 1e22 is not exactly representable as a floating point number. By consequence, 1e22 is different numbers when stored as a double or a long double, and we should expect different results when applying the sine to it. W. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43405
[Bug c++/6709] typeof() cannot be used with the :: operator
--- Comment #9 from bangerth at gmail dot com 2010-03-08 14:29 --- *** Bug 43285 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6709
[Bug c++/43285] typeof doesn't act like a type in ::
--- Comment #2 from bangerth at gmail dot com 2010-03-08 14:29 --- *** This bug has been marked as a duplicate of 6709 *** -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43285
[Bug c++/43272] -Wmissing-prototypes doesn't work in C++ mode
--- Comment #9 from bangerth at gmail dot com 2010-03-08 16:23 --- (In reply to comment #7) The code that calls the function also *compiles* cleanly, and only the link fails. By compiling I meant translating from source code to executable. That includes linking. The point I want to make is that warnings are meant for exactly those cases where you wouldn't otherwise get an error. In the case you request, the warning is redundant with the error you would get anyway at a later time. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43272
[Bug c++/43282] GCC looks into dependent bases during unqualified lookup
--- Comment #1 from bangerth at gmail dot com 2010-03-07 23:41 --- The error message I get is this: g/x c++ -c x.cc x.cc: In member function 'void BarT::bar() [with T = A::Baz]': x.cc:18: instantiated from here x.cc:10: error: no matching function for call to 'BarA::Baz::foo(A::Baz)' x.cc:3: note: candidates are: void HasFooT::foo() [with T = A::Baz] This error message is given upon instantiation time since the call was (correctly) considered dependent. At instantiation time, gcc finds the function in the base class but decides that the arguments don't match -- producing the error. Note that the first scope in which a function is found terminates the search for possible other candidates, even if the functions in the first scope in which functions are found don't match. Consequently the code is rejected. Why do you think this is not the correct behavior? W. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43282
[Bug c++/43282] GCC looks into dependent bases during unqualified lookup
--- Comment #3 from bangerth at gmail dot com 2010-03-08 00:19 ---
But that would mean that the following code should be invalid
because the compiler should never find HasFooT::foo even at
instantiation time:
-
templatetypename T
struct HasFoo {
void foo(T) { }
};
templatetypename T
struct Bar : HasFooT {
void bar() { foo(T()); }
};
int main() { Barint b; b.bar(); }
-
I don't think the intent is to make this invalid.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43282
[Bug c++/43282] GCC looks into dependent bases during unqualified lookup
--- Comment #5 from bangerth at gmail dot com 2010-03-08 00:36 --- OK, so the question is whether the testcase in comment #3 should be rejected based on the wording of 14.6.2/3. Jason, as our resident language lawyer, would you mind commenting? W. -- bangerth at gmail dot com changed: What|Removed |Added CC||jason at redhat dot com Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43282
[Bug c++/13687] -Wmissing-prototypes should not be ignored for C++
--- Comment #19 from bangerth at gmail dot com 2010-03-08 04:26 --- *** Bug 43272 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13687
[Bug c++/43272] -Wmissing-prototypes doesn't work in C++ mode
--- Comment #5 from bangerth at gmail dot com 2010-03-08 04:26 --- What I'm saying is that this entire discussion is already present in PR13687 and that there is nothing more to say. The warning exists in C because it can lead to hard-to-find bugs in C code because you can call a function without a prototype in C. You can't do that in C++, and on top of that you can overload functions in C++ which makes it impossible to determine for a compiler whether a prototype matches a definition. Warnings are not generally meant to make programming simpler (as in the case you are making) but to warn about cases that can lead the compiler to generate code that may not have been intended that way but that compiles cleanly anyway. This isn't the case here, and the community has decided in PR 13687 that it doesn't want to support this feature in C++. W. *** This bug has been marked as a duplicate of 13687 *** -- bangerth at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43272
[Bug c++/43272] -Wmissing-prototypes doesn't work in C++ mode
--- Comment #3 from bangerth at gmail dot com 2010-03-07 05:49 --- (In reply to comment #2) So does this mean bug #13687 is going to be reopened? Or is there some workaround that hasn't been mentioned? No. I think the issue has been discussed at length there. W. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43272
[Bug libstdc++/43241] std::tr1::regex is not fully implemented yet
--- Comment #4 from bangerth at gmail dot com 2010-03-03 19:30 --- I think INVALID is the wrong resolution of this PR. This clearly is a bug (if we offer a class we should make sure it can be used), but we may choose to say that we won't work on this bug. The right resolution therefore... -- bangerth at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43241
[Bug libstdc++/43241] std::tr1::regex is not fully implemented yet
--- Comment #5 from bangerth at gmail dot com 2010-03-03 19:31 --- ...is WONTFIX. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43241
[Bug c++/20397] g++ rejects valid code with 'is inaccessible' error
--- Comment #8 from bangerth at gmail dot com 2010-03-03 19:40 --- (In reply to comment #7) The use of a base class ( class B : A ) is not a declaration of A. Thus the base class ( class A ) is visible and not private. Reopen the bug and fix it. Andrew was right: the name 'A' is injected into the class 'A' upon declaration of the class 'A', into 'B' upon deriving from it, and from 'B' into 'C'. This amounts to a 'using' declaration. As such, 'A' exists in 'C' as a name, but it is private and consequently inaccessible. Since you cite chapter and verse, take a look at 3.4/3 and 9.1/2. As stated before, if you don't want the locally injected name, use ::A instead. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20397
[Bug c/43162] option to set the promoted type of parameters of arithmetic
--- Comment #2 from bangerth at gmail dot com 2010-02-25 05:12 --- I don't think we should be doing this. GCC strives to be standards-conforming and the requested feature would purposefully make us violate the standard. There is a point for extensions, but I don't think changing the meaning of a perfectly well-formed program is not what we should be doing. The same effect can of course be achieved by simply adding the explicit cast to the code. W. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43162
[Bug c++/43149] Partial optimization
--- Comment #1 from bangerth at gmail dot com 2010-02-23 15:13 --- This feature already exists. See the discussion of the optimize attribute in http://gcc.gnu.org/onlinedocs/gcc-4.4.3/gcc/Function-Attributes.html#Function-Attributes W. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME Summary|Partial optimization|Partial optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43149
[Bug c++/43149] Partial optimization
--- Comment #3 from bangerth at gmail dot com 2010-02-23 15:53 --- So the attribute would have to be attached to the namespace, I guess. We can keep the PR open, but my best guess is that this is going to be one of those PRs that stay open forever as there is so little demand for this kind of feature. Maybe you can explain what you need this for? W. -- bangerth at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43149
[Bug tree-optimization/42640] wrong code for -ftree-loop-distribution in 175.vpr
-- bangerth at gmail dot com changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-23 20:38:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42640
[Bug c++/2288] Variable declared in for-loop-header is in wrong scope
--- Comment #10 from bangerth at gmail dot com 2010-02-23 20:40 --- (In reply to comment #9) Is there a reason this hasn't been fixed? Lack of public demand? There's only one duplicate of this bug that has been reported in the last 9 years... If not, I'll try. I think that would still be cool! W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2288
[Bug c++/43135] Possible bug in name resolution during template instantiation
--- Comment #2 from bangerth at gmail dot com 2010-02-22 03:56 --- This is not a bug. Because the base class of Node::OpNode does not depend on template arguments, the members of the base class are visible in Node::OpNode::f(). On the other hand, since the base class of Node::FooOpNode depends on template arguments, the members of the base class are not visible during parsing and before template arguments are substituted. You need to write the call to test as this-test(op.i) W. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43135
[Bug c++/43135] Possible bug in name resolution during template instantiation
--- Comment #4 from bangerth at gmail dot com 2010-02-22 04:29 ---
(In reply to comment #3)
But doesn't this error happens during instantiation as the error message
indicates? If definition of Node::FooNode is commented out, the templates
themselves are accepted.
What I meant to say is this: during parsing, it doesn't see Node::test as
a member of the base class, but it sees it as a member of the enclosing
class in the same way as S::I::f() in
struct S {
int i;
struct I {
int f() { return i; }
};
}
would see S::i -- since they are both members of the same enclosing class S.
I.e., Node::FooOpNode::f() sees Node::test() as a sibling, not a member
of the base class, and so the call is registered as a function call, not
a call of a member function with this as argument.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43135
[Bug c/25733] missed diagnostic about assignment used as truth value.
--- Comment #10 from bangerth at gmail dot com 2010-02-21 01:25 --- (In reply to comment #7) (In reply to comment #3) As another data-point, if ( (a=10) ) ; also doesn't warn. I'm not sure what the standard says on that, but other contemporary compilers do give the an assignment used as truth value warning for the example above. How do other compilers deal with false positives? That is, how can a programmer specify that they really want to do an assignment? We could use a cast to bool. I think at least in C++ the warning is useful. Conditions in if(...) statements have type bool, and things like if (a=10) use the implicit conversion from int to bool. If a programmer wants to avoid the warning, one can always be explicit and write if ( (a=10) != 0) W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25733
[Bug c++/33801] Missing warning
--- Comment #2 from bangerth at gmail dot com 2010-02-21 01:27 --- I don't see what should be warned about. The 'const' in the signature of 'f' has no effect here, but it also doesn't hurt -- its presence or absence simply doesn't make a difference. W. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33801
[Bug c++/9990] locale_facets.h contains invalid typedef
--- Comment #9 from bangerth at gmail dot com 2010-02-18 20:29 --- (In reply to comment #8) For the record, all the compilers I have at hand, EDG based too, accept this in the most strict mode. I seriously doubt there is really something to fix here. That said: if it is unclear to people well versed in the language standard whether the code is correct or not (and does what it is supposed to do or not) then one could argue that the code is also hard to read. In other words: there may not be a need to change the code for *correctness reasons*, but the *is* a need to change the code to make it more maintainable. I believe that's a valid argument in software design to change things. W. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9990
[Bug c++/43117] New: Accepts invalid typedef
This is the remaining part of PR 9990 that concerns interpretation of
the core language rules. Consider this code snippet:
-
struct B { typedef int type; };
template typename T struct D : B {
typedef typename D::type type;
};
Dchar cc;
Dchar::type tcc;
-
All GCC versions accept this. The question is whether the typedef in D is
well-formed: does D::type refer to the typedef in the base class, or to the
typedef we are currently declaring?
The issue is confusing because if D is not a template, like here:
-
struct B { typedef int type; };
struct D : B {
typedef typename D::type type;
};
Dchar cc;
Dchar::type tcc;
-
then apparently the code is ill-formed:
tmp c++ -c a.cc
a.cc:3: error: using 'typename' outside of template
a.cc:6: error: 'D' is not a template
a.cc:7: error: 'D' is not a template
a.cc:7: error: expected initializer before 'tcc'
It is at best confusing that templates and non-templates should behave
differently in this regard.
I don't claim to know whether the current behavior is correct. Putting
this issue into a separate PR cleans up PR 9990, however.
Best
W.
--
Summary: Accepts invalid typedef
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43117
[Bug c++/43117] Accepts invalid typedef
--- Comment #1 from bangerth at gmail dot com 2010-02-19 00:56 --- *** Bug 9990 has been marked as a duplicate of this bug. *** -- bangerth at gmail dot com changed: What|Removed |Added CC||nasgaard at ca dot ibm dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43117
[Bug c++/9990] locale_facets.h contains invalid typedef
--- Comment #14 from bangerth at gmail dot com 2010-02-19 00:56 --- (In reply to comment #13) The library issue doesn't exist anymore ;) Thus, let's not be distracted by the trivial library case, ok? I see, that's convenient :-) In any case, in order to keep PRs focused on single issues, I have opened PR 43117 to track the remaining language issue, and will make the current PR a duplicate of that one. Best W. *** This bug has been marked as a duplicate of 43117 *** -- bangerth at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9990
[Bug c++/43117] Accepts invalid typedef
--- Comment #2 from bangerth at gmail dot com 2010-02-19 00:59 --- Darn, I did not pay attention at all. Scrap the text starting with The issue is confusing... above which is entirely pointless because the code I pasted is wrong in at least two ways (as the error messages correctly point out) and when fixed the problem goes away. So there is no difference between templates and non-templates. The issue raised in PR 9990 (and reproduced in the first part of the post) remains, however. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43117
[Bug c++/26261] Rejects template with const static data member used in return type
--- Comment #8 from bangerth at gmail dot com 2010-02-16 23:42 ---
(In reply to comment #6)
Clarified summary. Since this isn't a regression and there is a workaround,
it
doesn't seem like a high priority for 4.5.
But if I understand comment #3 correctly, then the workaround originally
proposed for this PR, namely
template int dim class X {};
template class T class Y {
static const unsigned int dim = 1;
Xdim f();
};
template class T
XYT::dim YT::f() { return Xdim(); }
---
no longer compiles?
I don't have current sources around here, but this worked with 4.3.2.
If it doesn't work with mainline, then this *would* be a regression.
Can someone check?
Thanks
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26261
[Bug c++/26261] Rejects template with const static data member used in return type
--- Comment #10 from bangerth at gmail dot com 2010-02-17 01:45 --- (In reply to comment #9) The workaround in Comment #5 does work in mainline. Right, but that wasn't the question. Does my program in comment #8 work? If not, then that would be a regression. As for the workaround in #5: it would be a workaround for a workaround. That would be sorta silly. Best W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26261
[Bug c++/43101] New: [4.5 regression] Rejects template with const static data member used in return type
The kludge used as a workaround for PR 26261 doesn't work any more:
---
template int dim class X {};
template class T class Y {
static const unsigned int dim = 1;
XYT::dim f();
};
template class T
XYT::dim YT::f() { return Xdim(); }
--
This compiled with gcc 4.3, but with a mainline snapshot from
last October we get this:
a.cc:9:14: error: prototype for 'XY::dim YT::f()' does not match any in
class 'YT'
a.cc:5:18: error: candidate is: X1 YT::f()
So this is a regression.
Best
W.
--
Summary: [4.5 regression] Rejects template with const static data
member used in return type
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at gmail dot com
OtherBugsDependingO 26261
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43101
[Bug c++/26261] Rejects template with const static data member used in return type
--- Comment #12 from bangerth at gmail dot com 2010-02-17 02:00 --- (In reply to comment #11) Only if the transitive property doesn't hold for workarounds. I think it does ;) But you keep dodging the question whether we have regressed on the workaround. Anyway, this is now PR 43101 W. -- bangerth at gmail dot com changed: What|Removed |Added BugsThisDependsOn|43101 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26261
[Bug c++/42824] c++ compilation complains about error: call of overloaded
--- Comment #10 from bangerth at gmail dot com 2010-01-25 18:39 --- This works with gcc 4.3 and 4.4 I don't have mainline lying around here but if it really fails there it would be a 4.5 regression which should get it P1 status. Can someone try? W. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42824
[Bug c++/42768] ICE: libstdc++-v3/libsupc++/vec.cc:354
--- Comment #3 from bangerth at gmail dot com 2010-01-25 18:42 --- Someone on a win64 machine may have to check this. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42768
[Bug c++/40239] Aggregate initialization requires copy constructor
--- Comment #3 from bangerth at gmail dot com 2010-01-12 20:58 --- Dodji, thanks for the patch. As a matter of etiquette (I think we've had this conversation with others in the past already): in your patch, you mark the testcase as Contributed by Dodji Seketeli, but in fact the testcase is identically the one posted by the reporter of this PR. It seems unfair that you take credit for it when it's really by someone else. That said, I think all of us C++ users really appreciate the number of PRs you've taken care of recently! Cheers W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40239
[Bug c++/40239] Aggregate initialization requires copy constructor
--- Comment #5 from bangerth at gmail dot com 2010-01-12 21:52 --- (In reply to comment #4) I will stop adding the 'Contributed by' line from now, and will remove it from this patch. If you want, I can remove it from all the test cases I did commit. I don't think that's necessary, I just meant to point this out. No worries. Thank you. Though, in all fairness, I think those thanks should be directed to my employer who allows me to work on those PRs. I'm willing to extend my thanks to your employer while leaving them with you as well :-) W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40239
[Bug c++/40155] [c++0x] variadic template pack problem
--- Comment #3 from bangerth at gmail dot com 2010-01-05 13:20 --- (In reply to comment #2) I believe this should be flagged P1, even if it doesn't seem to be a regression. I'm obviously not impartial, but this is the sort of code that template packs are supposed to support, and forwarding calls is one of its main objectives. So I would definitely support getting this to work in 4.5... W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40155
[Bug c++/6259] Explicit instantiation of template constructor not allowed
--- Comment #7 from bangerth at gmail dot com 2009-11-24 21:52 --- Jason, is this PR related to your recent work on injecting class names into scopes? I don't know what makes gcc reject the constructor specialization, but it seems to me that it might be because it parses the X part of template X::X (T2 ) as a class name with an invalid template argument list, rather than as the constructor name. W. -- bangerth at gmail dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6259
[Bug c++/41840] g++ compiler giving error for array of pointers of abstract base class
--- Comment #3 from bangerth at gmail dot com 2009-10-28 05:17 --- (In reply to comment #0) There are many other such deviations we noticed in this compiler from the normal C++ principles. In addition to the previous answer: since gcc3.3, many many bugs have been fixed where gcc erroneously accepted code that did not conform to the C++ standard. We believe that gcc4.x is much closer to the C++ standard than 3.3 was. That said, it does occasionally happen that a bug is introduced. In that case, please open other bug reports. Best Wolfgang -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41840
[Bug c++/41825] useless -Wshadow warning on function argument in local class
--- Comment #1 from bangerth at gmail dot com 2009-10-26 04:52 --- Confirmed. Though I'd note that if this was a *nested* function (not a function in a *nested structure*) -- or a lambda function--, then the warning would make sense. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-26 04:52:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41825
[Bug c++/7932] Emit debug information about non-type template parameters
--- Comment #3 from bangerth at gmail dot com 2009-08-31 22:05 --- (In reply to comment #2) I think this bug should be fixed in trunk (4.5) by the patch for PR debug/30161. Can we close this bug or should we wait for GDB ? What does GDB currently say for the testcase shown in the initial report? W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7932
[Bug c++/7932] Emit debug information about non-type template parameters
--- Comment #5 from bangerth at gmail dot com 2009-08-31 22:49 --- (In reply to comment #4) What does GDB currently say for the testcase shown in the initial report? I think GDB doesn't know about the new type debug information added by gcc yet. So it won't say anything. I just tried with GDB 6.6, and you are right: it doesn't know about dim. But I haven't test GDB HEAD. My reasoning was that maybe we could open a GDB bug to track this there now that we generate debug info for this case ? Or is there a GDB bug opened for this already ? I didn't open a GDB bug back then, and I don't have any experience with GDB bugs in the first place. Would you mind opening a bug with their bugzilla (or whatever they use)? Either way, yes, we can close this PR now. Thanks W. -- bangerth at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7932
[Bug c++/40146] Unexplained 'anonymous' is used uninitialized in this function warning
--- Comment #5 from bangerth at gmail dot com 2009-08-27 11:35 --- The warning isn't triggered any more with current mainline. Can someone gives this a try with the current 4.4.x branch? W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40146
[Bug c++/40561] [4.3 regression] code does not compile -- compiles fine when replacing != with !(==)
--- Comment #6 from bangerth at gmail dot com 2009-08-26 18:49 --- It's also fixed on mainline and it works on 4.2.1. I don't have a version of 4.3 lying around, but that would be the only open branch which appears to still have the problem. Would someone mind testing this on a current 4.3.x? W. -- bangerth at gmail dot com changed: What|Removed |Added Known to fail||4.3.3 Known to work||4.2.1 4.4.1 4.5.0 Last reconfirmed|-00-00 00:00:00 |2009-08-26 18:49:58 date|| Summary|code does not compile --|[4.3 regression] code does |compiles fine when replacing|not compile -- compiles fine |!= with !(==) |when replacing != with !(==) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40561
[Bug c++/40561] [4.3 regression] code does not compile -- compiles fine when replacing != with !(==)
--- Comment #8 from bangerth at gmail dot com 2009-08-26 19:43 --- (In reply to comment #7) pr.cc:38: error: invalid operands of types #8216;bool#8217; and #8216;int#8217; to binary #8216;operator==#8217; This is doubly fascinating as there is no operator== in this line ;-) W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40561
[Bug c++/40942] GCC accepts code that Comeau and MSVC deems invalid.
--- Comment #2 from bangerth at gmail dot com 2009-08-25 13:24 --- Why would this be ambiguous? A string literal has type array of n const char (see 2.13.4/1), so it should go with the array constructor. Do you disagree? W. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40942
[Bug c++/40997] Wrong address returned in covariant return
--- Comment #8 from bangerth at gmail dot com 2009-08-25 13:27 --- Already confirmed. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-08-25 13:27:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40997
[Bug c++/41002] Redundant diagnostic when class member function's name overlaps with class field's name
--- Comment #7 from bangerth at gmail dot com 2009-08-25 13:29 --- I would think so. -- bangerth at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41002
