[Bug c++/38908] [4.4 regression] Unexplained 'anonymous' is used uninitialized in this function warning in cc1plus -m64
--- Comment #3 from bangerth at dealii dot org 2009-01-23 19:26 --- I see this as well. It triggers a ton of time in boost::graph code. I think it should have higher priority than P3. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org, ||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38908
[Bug middle-end/38851] [4.4 regression] Compiler warns about uninitialized variable that is an object with a constructor
--- Comment #7 from bangerth at dealii dot org 2009-01-23 19:31 ---
I see this as well. It triggers a lot when using boost::graph which
uses empty classes as tags all over the place. A simple case with
boost::graph would be this:
--
#include boost/graph/adjacency_list.hpp
using namespace boost;
adjacency_listvecS, vecS, undirectedS,
propertyvertex_color_t, default_color_type,
propertyvertex_degree_t,int g;
void create_graph () { add_edge(1,2, g); }
--
boost/graph/detail/adjacency_list.hpp: In function 'void create_graph()':
boost/graph/detail/adjacency_list.hpp:819: warning: 'p' may be used
uninitialized in this function
boost/graph/detail/adjacency_list.hpp:2210: note: 'p' was declared here
This problem makes -Wuninitialize pretty much useless for anyone who uses
boost::graph. I think it would be a shame if we shipped a compiler that
has a problem with this.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||mmitchel at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38851
[Bug libstdc++/35569] [c++0x] std::bind result functor doesn't accept rvalues
--- Comment #7 from bangerth at dealii dot org 2009-01-18 03:58 --- (In reply to comment #6) Maybe this issue isn't sufficiently clarified in the audit. Unless I'm badly mistaken (Jon, Chris will correct me), this is not a bug for a C++03 + TR1 bind (indeed the testcases provided by Doug are rather clear about that). Only in C++0x the specs say it must work. Of course implementations can also fix it for C++03 + TR1, but this is not in general the way we are managing these issues, we prefer leaving the TR1 version alone. And it should work if you do -std=c++0x, which I believe (from the title of the PR) is what the original intent was. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35569
[Bug c++/38888] New: [C++0x] badly readable diagnostic output with variadic templates
Maybe it isn't too late yet to change the specification in the ABI (or
maybe there isn't even one yet) for cases like this -- consider
template typename... T struct X {
template typename... U int f() { this-error; }
};
template int Xint,double::fint,double();
We get this error message:
g/x c++ -std=c++0x -c x.cc
x.cc: In member function 'int XT::f() [with U = int, double, T = int,
double]':
x.cc:4: instantiated from here
x.cc:2: error: 'struct Xint, double' has no member named 'error'
What bothers me is this bit:
[with U = int, double, T = int, double]
where it isn't quite clear due to lack of parentheses/braces/... which types
belong where. I think it would be a lot clearer if it read like this:
[with U = {int, double}, T = {int, double}]
I'm sure it would also make automated parsing of such strings a lot simpler
if someone wanted to do that.
Best
Wolfgang
--
Summary: [C++0x] badly readable diagnostic output with variadic
templates
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
[Bug libstdc++/38889] New: [C++0x] std::bind doesn't work
I feel like I must be doing something incredibly stupid (and I'm sorry
if indeed I do) but this:
#include functional
void goo(int);
void foo() {
std::bind (goo,1)(); // works
std::bind (goo,std::placeholders::_1)(1); // does not work
}
doesn't appear to work:
g/x /home/bangerth/bin/x86/gcc-mainline/bin/c++ -std=c++0x -c x.cc
x.cc: In function 'void foo()':
x.cc:6: error: no match for call to '(std::_Bindvoid (*
()(std::_Placeholder1))(int)) (int)'
/home/bangerth/bin/x86/gcc-mainline/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/tr1_impl/functional:1190:
note: candidates are: typename std::result_of_Functor ()(typename
std::result_ofstd::_Mu_Bound_args, std::is_bind_expression::value,
(std::is_placeholder::value 0) ()(_Bound_args, std::tuple_UElements
...)::type ...)::type std::_Bind_Functor ()(_Bound_args
...)::operator()(_Args ...) [with _Args = int, _Functor = void (*)(int),
_Bound_args = std::_Placeholder1]
/home/bangerth/bin/x86/gcc-mainline/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/tr1_impl/functional:1201:
note: typename std::result_ofconst _Functor ()(typename
std::result_ofstd::_Mu_Bound_args, std::is_bind_expression::value,
(std::is_placeholder::value 0) ()(_Bound_args, std::tuple_UElements
...)::type ...)::type std::_Bind_Functor ()(_Bound_args
...)::operator()(_Args ...) const [with _Args = int, _Functor = void
(*)(int), _Bound_args = std::_Placeholder1]
/home/bangerth/bin/x86/gcc-mainline/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/tr1_impl/functional:1213:
note: typename std::result_ofvolatile _Functor ()(typename
std::result_ofstd::_Mu_Bound_args, std::is_bind_expression::value,
(std::is_placeholder::value 0) ()(_Bound_args, std::tuple_UElements
...)::type ...)::type std::_Bind_Functor ()(_Bound_args
...)::operator()(_Args ...) volatile [with _Args = int, _Functor = void
(*)(int), _Bound_args = std::_Placeholder1]
/home/bangerth/bin/x86/gcc-mainline/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/tr1_impl/functional:1226:
note: typename std::result_ofconst volatile _Functor
()(typename std::result_ofstd::_Mu_Bound_args,
std::is_bind_expression::value, (std::is_placeholder::value 0)
()(_Bound_args, std::tuple_UElements ...)::type ...)::type
std::_Bind_Functor ()(_Bound_args ...)::operator()(_Args ...) const volatile
[with _Args = int, _Functor = void (*)(int), _Bound_args =
std::_Placeholder1]
What do I miss?
Thanks in advance
Wolfgang
--
Summary: [C++0x] std::bind doesn't work
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38889
[Bug libstdc++/38889] [C++0x] std::bind doesn't work
--- Comment #1 from bangerth at dealii dot org 2009-01-16 23:15 --- Btw, the equivalent that uses boost::bind works just fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38889
[Bug libstdc++/35569] [c++0x] std::bind result functor doesn't accept rvalues
--- Comment #5 from bangerth at dealii dot org 2009-01-17 01:41 --- (In reply to comment #2) I'm seeing the same thing with Boost.Bind (boost 1.37, GCC 4.2.1). boost.bind appears to work just fine for me, though!? W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35569
[Bug c++/57] [DR 325] GCC can't parse a non-parenthesized comma in a template-id within a default argument
--- Comment #41 from bangerth at dealii dot org 2009-01-06 15:46 --- (In reply to comment #40) I read all comments and saw a patch. But I don't know how I can fix my gcc with this patch. The easiest way is to wait for gcc 4.4. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
[Bug c++/37831] New: -Wshadow warns about variable names that aren't equal
-Wshadow is silly about this piece of code:
-
class Foo {
int bar_;
public:
void bar(int bar)
{
bar_ = bar;
}
};
-
This is a fairly common style. Note that local and member variable have
names that differ by the underscore. Yet:
g/x c++ -Wshadow -c x.cc
x.cc: In member function 'void Foo::bar(int)':
x.cc:5: warning: declaration of 'bar' shadows a member of 'this'
I think that's being overly pedantic.
W.
--
Summary: -Wshadow warns about variable names that aren't equal
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37831
[Bug c++/37831] -Wshadow warns about variable names that aren't equal
--- Comment #1 from bangerth at dealii dot org 2008-10-15 01:38 --- Note also that the documentation plainly states: @item -Wshadow @opindex Wshadow @opindex Wno-shadow Warn whenever a local variable shadows another local variable, parameter or global variable or whenever a built-in function is shadowed. The current behavior could therefore simply be classified as a bug. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37831
[Bug c++/37831] -Wshadow warns about variables inside classes member functions
--- Comment #3 from bangerth at dealii dot org 2008-10-15 01:51 --- (In reply to comment #2) bar the function shadows bar the variable. I think the warning is correct. The variable _bar is not being taken into account at all. Ah, bummer, I didn't even look close enough to see that the function and its argument are named the same. Silly me, I just saw this piece of code another project was unhappy about and thought I should submit this as a bug. You're right, and I agree that the warning is valid. W. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37831
[Bug c++/950] Template problem: decay of pointer-to-member-of-derived to p-o-m-o-base
--- Comment #12 from bangerth at dealii dot org 2008-09-10 15:26 --- Still happens with gcc version 4.4.0 20080801 (experimental) [trunk revision 138448] -- bangerth at dealii dot org changed: What|Removed |Added Last reconfirmed|2006-09-03 21:39:06 |2008-09-10 15:26:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=950
[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors
--- Comment #7 from bangerth at dealii dot org 2008-09-10 15:30 --- Still the same with gcc version 4.4.0 20080801 (experimental) [trunk revision 138448] -- bangerth at dealii dot org changed: What|Removed |Added Last reconfirmed|2005-12-11 21:47:09 |2008-09-10 15:30:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972
[Bug c++/37116] installing gcc in a non-conventional place has problems finding libstdc++.
--- Comment #1 from bangerth at dealii dot org 2008-08-13 16:14 --- (In reply to comment #0) By default, I suppose a -Wl,-rpath,prefix-lib would be useful... No, since you can't override that and then you can't use another libstdc++ than the one that comes with the compiler you built with. W -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37116
[Bug c++/37093] [4.2/4.3/4.4 Regression] ICE with pointer to member template parameters
--- Comment #1 from bangerth at dealii dot org 2008-08-13 16:17 --- Confirmed. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Keywords||ice-on-invalid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37093
[Bug c++/37088] Functions with default parameters not correctly handled inside templates.
--- Comment #2 from bangerth at dealii dot org 2008-08-13 16:21 --- (In reply to comment #0) bool pred4(const char *, const char *, const char *x = , const char *y = ); The type of pred4 is still bool (*) (const char *, const char *, const char *x, const char *) and so when you pass this function through a pointer it can't be called with only two parameters. Andrew is right that this used to be one of the many ill-conceived gcc extensions. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37088
[Bug c++/37087] Segfault on compiling template defined in wrong namespace.
--- Comment #4 from bangerth at dealii dot org 2008-08-13 16:24 --- This also failed with 4.2.1, and the reporter's compiler was 4.0. Paolo, do you want to apply your patch to 4.3.x as well? If not, I vote for closing the PR: It's not a recent regression, it's an ICE on invalid, and unless you apply the patch there is unlikely going to be any further activity. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37087
[Bug c++/37070] bogus unreachable warning on throw statement
--- Comment #5 from bangerth at dealii dot org 2008-08-13 16:27 --- Confirmed. What I believe Andrew was pointing out are the internal reasons why this warning happens. However, the warning is clearly bogus, the flag -Wunreachable-code isn't useful if it warns on this sort of code. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-08-13 16:27:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37070
[Bug c++/37047] Missing warning for deprecated use of static
--- Comment #2 from bangerth at dealii dot org 2008-08-13 16:31 --- (In reply to comment #1) I don't think this is a good warning really as static is used all over the place. In system headers and really in almost all C++ code in general. The key is the phrase ...in a namespace scope. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37047
[Bug c++/12242] g++ should warn about out-of-range int-enum conversions
--- Comment #17 from bangerth at dealii dot org 2008-08-07 13:13 --- (In reply to comment #16) The expression cannot be very complicated because it needs to be a INTEGER_CST. Sure, but it can be of the form ~SOME_PREPROCESSOR_MACRO | (MACRO2 ^ MACRO3) What I meant to say is that the value of the expression may not be obvious to the author of the code. On the other hand, I agree that it is best to give users as much information as reasonable. I think it is better if you comment in gcc-patches so reviewers can see your proposal. Will do next time, I guess for this time we're stuck here :-) I would prefer to not repeat twice %T, though. Also, I think users are going to have trouble to understand that the range of the enumeral is larger than the number of enumerators it contains. Perhaps we should print the range of %T? the result of %static_cast% is unspecified because %qE is outside the range [%d,%d] of type %qT. That would be an excellent idea as well. Thanks Wolfgang -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12242
[Bug c++/12242] g++ should warn about out-of-range int-enum conversions
--- Comment #14 from bangerth at dealii dot org 2008-08-07 05:41 --- Patch now here: http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00436.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12242
[Bug c++/12242] g++ should warn about out-of-range int-enum conversions
--- Comment #15 from bangerth at dealii dot org 2008-08-07 05:41 --- Hi Manu, just saw your patch for PR 12242 and have a comment: I believe the warning message would be much better if it said *why* the result is unspecified (if the expression being cast is a bit more complicated then it may not be immediately clear to the casual observer that the reason is that the value is out of range; one could also think that for whatever reason conversions between enums are unspecified -- which of course isn't the true reason). So I think a better wording would be + warning (OPT_Wconversion, +the result of %static_cast%T(%E)% is unspecified because the + value is out of range for type %T, +type, expr, type); Best Wolfgang -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12242
[Bug c++/36760] Simple std::bind use causes warnings with -Wextra
--- Comment #22 from bangerth at dealii dot org 2008-07-10 13:23 --- (In reply to comment #21) Two questions: 1/ Is the text in the documentation that Dirk Mueller added in the last commit of PR 30601 now wrong/outdated? I don't know, I'm not a documentation expert, maybe some tweaks will be necessary but I may not be able to come to it in the near future, really quite a few things in my todo list these days, I'm sorry. Reading through the current text, I think it is sufficiently vague for it to remain as it is. 2/ Does your patch also fix the testcase in PR 36052? The warning is not emitted anymore, for sure. Great, thanks a lot! W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36760
[Bug c++/36760] Simple std::bind use causes warnings with -Wextra
--- Comment #10 from bangerth at dealii dot org 2008-07-09 17:04 ---
(In reply to comment #8)
I was also trying to raise the issue of whether we think the warning is
useful.
If it's not practical to avoid the warning in the library, then I wonder if
it's practical to avoid it other generic-programming code.
I agree with this. As I mentioned in PR 30601, code like this
template typename T class ArrayView {
T operator();
T operator() const;
};
is quite common and I don't see a need to make it more complicated than
necessary just for a warning. Yet, this class will trigger a warning if
instantiated as ArrayViewconst double because the return type of the second
operator() is now 'const double'. (Think of the class as providing a view
to a part of an array, so instantiating it with T=const double provides a
view that does not allow the elements to be modified.)
Personally, I find the fact that the compiler now warns about this very
annoying indeed.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36760
[Bug c++/36760] Simple std::bind use causes warnings with -Wextra
--- Comment #15 from bangerth at dealii dot org 2008-07-09 19:22 --- (In reply to comment #14) Ah, I didn't consider this option! Seems also trivial to implement, just remove completely the pt.c version of the warning and keep the one in decl.c. Then, over the next hours, if I don't see objections, I'm going to implement and post it, proposing it for 4_3-branch too, because of the very annoying warning from functional per this PR... I think that would be awesome! W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36760
[Bug c++/30601] [4.3 regression] -Wreturn-type warns about more than what the documentation says
--- Comment #15 from bangerth at dealii dot org 2008-07-10 03:38 ---
(In reply to comment #11)
Subject: Re: [4.3 regression] -Wreturn-type warns about more
than what the documentation says
I think this was done on purpose.
It is contrary to what the documentation says. I think it also doesn't
make much sense in C++ if the return type results from a template
substitution. For example, the following case is rather common:
template typename T class Array {
T operator();
T operator() const;
};
This class will trigger a warning if instantiated as Arrayconst double
because the return type of the second operator() is now 'const double'.
This issue has now been addressed with the most recent patch for PR 36760.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30601
[Bug c++/36760] Simple std::bind use causes warnings with -Wextra
--- Comment #20 from bangerth at dealii dot org 2008-07-10 03:40 --- (In reply to comment #19) Fixed for 4.4.0. Thanks a lot! Two questions: 1/ Is the text in the documentation that Dirk Mueller added in the last commit of PR 30601 now wrong/outdated? 2/ Does your patch also fix the testcase in PR 36052? Thanks W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36760
[Bug c++/36641] erroneous ambiguous error for subclasses overloaded templated interfaces
--- Comment #2 from bangerth at dealii dot org 2008-07-07 23:17 --- Yes, the code is indeed ambiguous. Both icc and pgCC also agree. W. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36641
[Bug c++/36699] not compile code, but must
--- Comment #1 from bangerth at dealii dot org 2008-07-07 23:30 --- Not a bug: type arguments to templates need to be *named* types with external linkage. The declaration of 'x' uses an unnamed structure, the declaration of 'z' a type of function-scope (and so internal) linkage. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36699
[Bug c++/36749] sizeof returns 0 for class
--- Comment #5 from bangerth at dealii dot org 2008-07-07 23:36 --- Zero-sized arrays are a GNU extension to the C++ standard. Since the compiler can't know the size of the object, sizeof returns zero. This behavior is documented in the Extensions part of the GCC manual, in the Arrays of Length Zero section. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36749
[Bug c++/33435] internal compiler error with templates and openmp
--- Comment #5 from bangerth at dealii dot org 2008-06-16 15:03 --- This appears to work for me now with gcc version 4.4.0 20080527 (experimental) [trunk revision 136055] (GCC) Can you check whether it also works for you? W. -- bangerth at dealii dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33435
[Bug c++/36203] explicit member function template lookup fails from templated function
--- Comment #6 from bangerth at dealii dot org 2008-05-11 02:17 ---
(In reply to comment #5)
Yet Sun, IBM and Microsoft all somehow manage it.
But which function do they take in this case:
--
void f();
template typename T struct B
{
void f();
};
template typename T struct D : BT
{
void g()
{
f();
}
};
---
The standard prescribes that in D::g() the function ::f() is called. Are
you suggesting that the compiler pick B::f() instead? Or do you suggest
that the compiler picks B::f() if such a function exists, and ::f() otherwise?
That wouldn't be very intuitive either.
The rules may not always be intuitive, but they're there for a good reason,
not to annoy users.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36203
[Bug c++/36203] explicit member function template lookup fails from templated function
--- Comment #8 from bangerth at dealii dot org 2008-05-11 02:59 --- (In reply to comment #7) That little bit of ambiguity bothers me a lot less that [...] If that's your opinion, then you've never worked with large software systems. Writing a few this- here and there because the compiler complains is a small effort compared to debugging why your code doesn't work. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36203
[Bug c++/36203] explicit member function template lookup fails from templated function
--- Comment #11 from bangerth at dealii dot org 2008-05-11 03:32 --- (In reply to comment #10) VC6,7,8,9 I suppose that's the compiler you should use then. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36203
[Bug c++/36149] -O2 optimization generates wrong code
--- Comment #8 from bangerth at dealii dot org 2008-05-07 04:17 --- The point is: without the complete source code nothing definitive can be said whether it's the compiler's or the programmer's fault. Your chances that someone will take the time to try to understand what's going on increase exponentially if you manage to produce a small testcase, whereas they are pretty low if all you can show is several thousand lines of code. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36149
[Bug c++/36159] C++ compiler should issue a warning with missing new operator
--- Comment #3 from bangerth at dealii dot org 2008-05-07 04:21 --- How is the compiler supposed to know about what alignment malloc can produce? How can it know that ::operator new doesn't increase the alignment automatically? W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36159
[Bug c++/36052] New: [4.3/4.4 regression] bogus type qualifiers ignored warning
Here's an annoying regression:
-
struct S {
typedef double value_type;
};
template typename T struct Traits {
typedef const typename T::value_type dereference_type;
};
template class BlockVectorType struct ConstIterator {
typedef typename TraitsBlockVectorType::dereference_type
dereference_type;
dereference_type operator * () const { return 0; }
};
template class ConstIteratorS;
-
For this, we get:
deal.II/lac g++ -W -Wall -c a.cc
a.cc: In instantiation of 'ConstIteratorS':
a.cc:16: instantiated from here
a.cc:13: warning: type qualifiers ignored on function return type
We didn't use to produce this warning. I also think it's hard to avoid:
if the class S would declare its value_type as a reference, then the
addition of the 'const' in the Traits class would matter; here, it doesn't,
but that's only because of chance.
What's worse is that the warning is also inconsistent: if we replace
template class BlockVectorType struct ConstIterator {
typedef typename TraitsBlockVectorType::dereference_type
dereference_type;
by
template class BlockVectorType struct ConstIterator {
typedef const typename BlockVectorType::value_type dereference_type;
then the warning goes away despite the fact that the actual types are
exactly the same. Weird.
W.
--
Summary: [4.3/4.4 regression] bogus type qualifiers ignored
warning
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36052
[Bug other/36046] Demangler fails on templates with non-type reference parameters
--- Comment #2 from bangerth at dealii dot org 2008-04-26 00:22 --- Confirmed. The demangler gets a valid symbol it can't demangle. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-26 00:22:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36046
[Bug other/36046] Demangler fails on templates with non-type reference parameters
--- Comment #3 from bangerth at dealii dot org 2008-04-26 00:25 --- By the way, the return code of __cxa_demangle is -2: mangled_name is not a valid name under the C++ ABI mangling rules. as per http://docs.mandragor.org/files/Programming_languages/Cpp/libstdcpp_v3_Source_Documentation/namespaceabi.html The string that can't be demangled is 3barILZ3bazEE. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36046
[Bug c++/35929] Argument type of non-member operator-*
--- Comment #3 from bangerth at dealii dot org 2008-04-14 14:17 --- Yes. Note that it requires an argument of *class* type, not *pointer to class* type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35929
[Bug libgomp/35912] omp parallel for wrong result
--- Comment #2 from bangerth at dealii dot org 2008-04-14 14:28 --- (In reply to comment #1) I don't think this is a bug as you did not mark the operations on s as atomic. Yes, exactly. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35912
[Bug c++/35927] befriending a whole template in another namespace fails
--- Comment #1 from bangerth at dealii dot org 2008-04-14 14:21 --- I too believe that z1.cc is valid. icc accepts it. Not a regression, the code fails back to 2.95. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-14 14:21:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35927
[Bug c++/35904] Poor error message
--- Comment #1 from bangerth at dealii dot org 2008-04-14 14:34 --- You are asking for too much. The problem is that in your first example the compiler knows that you want to call the grab() function and therefore can give you an informative error message. But in the second example it can't: there's a template, and the compiler tries to match your call's argument types with the template types, but it can't find a set of template types for which the call would match the signature of the function template. In other words, it doesn't know which function you want to call -- there doesn't appear to be one that would match what you want. To implement what you suggest would require the compiler to speculate what you wanted, for example by speculating that you wanted grabint. We've found over the years that letting the compiler speculate sometimes produces a better diagnostic, but most of the time leads to messages that really don't have anything to do with what the user really wanted -- and then become really confusing. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35904
[Bug tree-optimization/35787] [4.4 Regression]: Revision 133680 breaks 447.dealII
--- Comment #2 from bangerth at dealii dot org 2008-04-01 14:54 --- (In reply to comment #0) error_estimator.cc: In static member function 'static void KellyErrorEstimatordim::integrate_over_irregular_face(const DoFHandlerdim, const Quadrature(dim - 1), const std::vectorconst InputVector*, std::allocatorconst InputVector* , const std::vectorbool, std::allocatorbool , const Functiondim*, std::maptypename DoFHandlerdim::face_iterator, std::vectordouble, std::allocatordouble , std::lesstypename DoFHandlerdim::face_iterator, std::allocatorstd::pairconst typename DoFHandlerdim::face_iterator, std::vectordouble, std::allocatordouble, KellyErrorEstimatordim::PerThreadData, const typename DoFHandlerdim::active_cell_iterator, unsigned int, FEFaceValuesdim, FESubfaceValuesdim) [with InputVector = BlockVectorfloat, int dim = 3]': error_estimator.cc:801: internal compiler error: in set_value_range, at tree-vrp.c:347 I'm the guy responsible for this, uh, let's say: awkward, function signature. I'm sorry you had to hit this error in the function with the worst number of arguments in all of 447.dealII :-) W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35787
[Bug c++/35778] Wishlist: To override all C pointers with C++ wrappers
--- Comment #1 from bangerth at dealii dot org 2008-03-31 19:45 --- Maybe so, but gcc only tries to implement what the C++ standard describes. Please take your idea for this extension to the relevant standards committees. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35778
[Bug c++/33878] Pure virtual method body omitted from template
--- Comment #4 from bangerth at dealii dot org 2008-03-31 19:51 --- (In reply to comment #3) I believe that the main problem here is that GCC allows defining pure virtual functions. No, that's perfectly legal. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33878
[Bug c++/33878] Pure virtual method body omitted from template
--- Comment #5 from bangerth at dealii dot org 2008-03-31 19:54 --- (In reply to comment #0) The following stripped down code shows pure virtual method definitions for both a normal base class and a templated base class. To my surprise, the templated class' body is not generated, Your example code contains neither a call to TBaseint::pvMethod (which would trigger an implicit instantiation of this function from its template) nor an explicit instantiation of either the entire class or of this function. Consequently, the compiler doesn't instantiate your template. If you intend to call TBaseint::pvMethod from somewhere where the definition of this template is not visible, you need to add an explicit instantiation of this function for 'int' as the template arg. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33878
[Bug c++/35773] [4.3/4.4 regression] auto_ptr references don't convert
--- Comment #1 from bangerth at dealii dot org 2008-03-31 20:07 --- I tend to think that this should indeed work. Nice self-contained testcase! W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-03-31 20:07:09 date|| Summary|[4.3 regression] auto_ptr |[4.3/4.4 regression] |references don't convert|auto_ptr references don't ||convert http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35773
[Bug other/35618] [4.3/4.4 regression] ICE in cgraph_estimate_size_after_inlining, at ipa-inline.c:188
--- Comment #4 from bangerth at dealii dot org 2008-03-25 18:58 --- I can't reproduce this with tmp/g /home/bangerth/bin/x86/gcc-mainline/bin/gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../mainline/configure --prefix=/home/bangerth/bin/x86/gcc-mainline --enable-languages=c,c++ --enable-checking --with-gmp=/home/bangerth/bin/x86 --with-mpfr=/home/bangerth/bin/x86 Thread model: posix gcc version 4.4.0 20080317 (experimental) [trunk revision 133287] (GCC) Can you state which flags you actually need to reproduce the bug with your preprocessed sources? W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35618
[Bug c++/35650] [4.1/4.2/4.3/4.4 Regression] Can't bind ref-to-function through using-decl. in namespace
--- Comment #2 from bangerth at dealii dot org 2008-03-25 19:02 ---
Confirmed again. Funny enough, this works:
-
void f();
namespace N { using ::f; }
void h()
{
void ( b)() = N::f; // not ok
void ( c)() = *N::f; // ok!?
}
-
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35650
[Bug other/35618] [4.3/4.4 regression] ICE in cgraph_estimate_size_after_inlining, at ipa-inline.c:188
--- Comment #6 from bangerth at dealii dot org 2008-03-25 19:37 --- It appears to work with gcc version 4.4.0 20080317. Can you see if it works for you as well with a more recent gcc version (either from top-of-tree or the top of the 4.3 branch that you used in your experiments)? W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35618
[Bug libstdc++/35622] Cannot declare vector of unordered_maps
--- Comment #1 from bangerth at dealii dot org 2008-03-18 05:12 --- What happens when you do this? And what are the header files you use? -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35622
[Bug c++/35394] Aggressive template instantiation?
--- Comment #2 from bangerth at dealii dot org 2008-03-05 02:55 ---
This is called two-stage name lookup: when parsing a template all occurrences
of things that do not depend on the template parameter are bound to their
global definitions. Thus, here...
template class Reason
class not_compilable
{
enum { dummy_value = sizeof (static_assertfalse) };
};
...even though we're in a template the compiler sees that static_assertfalse
is a classname that does not depend on the (currently) unknown template
parameter 'Reason' and so is supposed to be replaced for sizeof. This fails,
a behavior mandated by the C++ standard.
On the other hand, here...
template class Reason
class not_compilable
{
static static_assertfalse dummy_fct ();
enum { dummy_value = sizeof (dummy_fct ()) };
};
...you ask the compiler to evaluate sizeof
(not_compilableReason::dummy_fct())
which depends on the template parameter 'Reason' and so its evaluation is
deferred till we know the template type 'Reason', i.e. till instantiation
time. If you never instantiate it, there's no error.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||bangerth at dealii dot org
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35394
[Bug c++/26266] [4.0/4.1/4.2/4.3/4.4 regression] Trouble with static const data members in template classes
--- Comment #21 from bangerth at dealii dot org 2008-02-27 16:52 --- Can someone check which of the testcases now work and separate those that don't into PRs of their own? This PR has become a bit confusing. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26266
[Bug c++/34950] [4.2/4.3 Regression] ICE in svn boost math toolkit
--- Comment #12 from bangerth at dealii dot org 2008-02-12 08:17 ---
The following variant of the testcase in comment #8 is definitely
valid but produces an ICE:
-
template class T = int struct policy {
typedef int unnecessary;
};
template class Policy struct A {
typedef int type;
typedef typename Policy::unnecessary unused;
};
template class T struct S {
typedef int type;
typedef typename AT::type unused;
};
template class, class T typename ST::type foo();
template class Spolicy ::type foo();
template typename T int def(T);
const int i = def(fooint);
---
tmp/g /home/bangerth/bin/x86/bin/c++ -c x.cc
x.cc: In instantiation of 'AT':
x.cc:12: instantiated from 'ST'
x.cc:19: instantiated from here
x.cc:7: internal compiler error: in dependent_type_p, at cp/pt.c:15553
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
This is a regression introduced in gcc3.4.x.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||bangerth at dealii dot org
Known to fail|4.2.3 4.3.0 |4.2.3 4.3.0 3.4.6
Known to work||2.95.3 3.3.6
Last reconfirmed|2008-01-24 15:52:12 |2008-02-12 08:17:03
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34950
[Bug c++/35167] Problem with non-type template parameter and name lookup in template.
--- Comment #2 from bangerth at dealii dot org 2008-02-12 06:26 --- Not a bug: The name of a member (static or not) without class qualification can not be used in an address-of expression or decay to a pointer as desired in the current context: 5.19/2: Other expressions are considered constant-expressions only for the purpose of non-local static object initialization (_basic.start.init_). Such constant expressions shall evaluate to one of the following: -- a null pointer value (_conv.ptr_), -- a null member pointer value (_conv.mem_), -- an arithmetic constant expression, -- an address constant expression, [...] 5.19/4 An address constant expression is a pointer to an lvalue designating an object of static storage duration, a string literal (_lex.string_), or a function. The pointer shall be created explicitly, using the unary operator, or implicitly using a non-type template parameter of pointer type, or using an expression of array (_conv.array_) or function (_conv.func_) type. 5.3.1/2 The result of the unary operator is a pointer to its operand. The operand shall be an lvalue or a qualified-id. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35167
[Bug c++/35146] [4.1/4.2 regression] weird error in template function specialization
--- Comment #4 from bangerth at dealii dot org 2008-02-11 03:38 --- (In reply to comment #3) While the original testcase works for me on trunk, the testcase in comment #2 does not. Or am I missing sth? I see the same behavior with yesterday's svn version. The testcase in comment #2 is definitely valid, so we still have a regression. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35146
[Bug c++/35146] [4.1/4.2 regression] weird error in template function specialization
--- Comment #2 from bangerth at dealii dot org 2008-02-10 01:13 ---
Confirmed. This was introduced in 3.4.x, and worked before. As Andrew
already noted, this has been fixed in mainline.
The problem can be more succinctly shown by the following testcase:
template typename T struct S {};
template typename R struct ref;
templatestruct refdouble { typedef double result; };
template typename T void foo(typename refT::result, ST*);
templatevoid foo(Sdouble, Sdouble*);
templatevoid foo(double alpha,Sdouble* x)
{
alpha; x;
}
---
g/x c++-4.2.1 -S x.cc
x.cc: In function 'void foo(typename refR::result, ST*) [with T = double]':
x.cc:10: error: 'alpha' was not declared in this scope
x.cc:10: error: 'x' was not declared in this scope
What is happening is that we are looking up the parameters from the wrong
declaration. The function in question on line 10 of course has them
declared and named, but we are looking at the specialization in line 7:
if the parameters are named there, then the code compiles. However, as
shown in the original testcase, the parameters then have the wrong
type.
It shouldn't be too hard to construct a case where this produces wrong
code.
Can someone determine whether this is still wrong with the released
4.2.3? I consider this a particularly heinous bug since it's almost
impossible to see in a real code where the error is coming from (if
we get one) or why the produced code is wrong.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||bangerth at dealii dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to fail||4.2.1 4.1.2 4.0.4 3.4.6
Known to work|4.3.0 |4.3.0 3.3.6
Last reconfirmed|-00-00 00:00:00 |2008-02-10 01:13:11
date||
Summary|weird error in template |[4.1/4.2 regression] weird
|function specialization |error in template function
||specialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35146
[Bug c++/35140] wrong result due to -O2 optimization in combination with std::list
--- Comment #4 from bangerth at dealii dot org 2008-02-08 21:59 --- Can this be reproduced with gcc 4.2.x or current mainline? -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35140
[Bug c++/35138] [4.3 Regression] g++ rejects valid code
--- Comment #4 from bangerth at dealii dot org 2008-02-08 21:51 --- This should get higher priority than P3... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35138
[Bug bootstrap/33992] Building libstdc++-v3: include/limits: stray '\275' in program
--- Comment #13 from bangerth at dealii dot org 2008-02-06 01:19 --- Re-confirmed here: http://gcc.gnu.org/ml/gcc/2008-02/msg00066.html -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-02-06 01:19:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33992
[Bug c++/33620] [4.3 regression] internal compiler error: canonical types differ for identical types const QListQStringList and const QListQStringList
--- Comment #10 from bangerth at dealii dot org 2008-02-02 04:07 --- Sharad, what compiler version did you use for the new testcases? -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33620
[Bug libstdc++/35000] #include sometimes fails in namespaces
--- Comment #3 from bangerth at dealii dot org 2008-01-31 14:53 --- This way you make the compiler believe that all the functions are in a namespace when the compiler that compiled these functions into a .dll assumed that they are not. This can't work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35000
[Bug c++/33553] [4.1/4.2/4.3 Regression] Bogus array bound is not an integer constant for parameter in template method of template class
--- Comment #8 from bangerth at dealii dot org 2008-01-30 20:26 --- I agree. This is valid and common code and we need to be able to compile it. I would rate this as a blocker. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33553
[Bug c++/13717] duplicated parameter name not caught ?
--- Comment #9 from bangerth at dealii dot org 2008-01-22 22:06 --- Apparently fixed. -- bangerth at dealii dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13717
[Bug c++/17729] [4.0/4.1/4.2/4.3 Regression] Duplicate __attribute__((deprecated)) warning
--- Comment #10 from bangerth at dealii dot org 2008-01-22 22:08 --- The patch was withdrawn. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17729
[Bug c++/34927] New: Duplicate error message about abstract class
I get a duplicate error message for this code:
--
class A {};
struct C : A
{
virtual ~C () = 0;
} c;
-
bangerth/tmp c++ -c x.cc
x.cc:6: error: cannot declare variable 'c' to be of abstract type 'C'
x.cc:4: note: because the following virtual functions are pure within 'C':
x.cc:5: note: virtual C::~C()
x.cc:5: note: virtual C::~C()
I'd say one is enough.
W.
--
Summary: Duplicate error message about abstract class
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34927
[Bug libstdc++/33486] parallel v3: functions not in right namespace
--- Comment #4 from bangerth at dealii dot org 2008-01-21 22:01 --- I don't know. What namespace are the parallel containers in, and what namespace are the parallel algorithms in? W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33486
[Bug c++/34406] [reject valid?] incomplete type 'Y' used in nested name specifier.
--- Comment #3 from bangerth at dealii dot org 2008-01-13 16:31 --- (In reply to comment #2) i'd ask why the first code is invalid? class Y looks pretty complete so why typedef expression throws an error? A class is complete at the closing brace. You use it before that. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34406
[Bug c++/34758] [4.1/4.2/4.3 regression] Bad diagnostic for circular dependency in constructor default argument
--- Comment #2 from bangerth at dealii dot org 2008-01-13 02:02 --- If the original warning is ever restored, please make it read circular dependency in default argument instead of the abbreviate language circular dependency in default args W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34758
[Bug c++/34726] explicit specialization in non-namespace scope strange behavior
--- Comment #1 from bangerth at dealii dot org 2008-01-13 02:17 --- Explicit specializations of member templates need to be declared outside the declaration of the outer class, as per 14.7.3/2. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34726
[Bug c++/34724] Trouble with friend declaration across namespaces
--- Comment #1 from bangerth at dealii dot org 2008-01-13 02:20 --- Confirmed. The code should be rejected since the friend declaration has only one template parameter, whereas the template has two. W. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-13 02:20:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34724
[Bug c++/34624] valid c++ code doesn't compile for x86_64, but for i386
--- Comment #1 from bangerth at dealii dot org 2008-01-13 02:23 --- Can you try to reduce this to something smaller that doesn't require boost? -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34624
[Bug c++/34603] [4.1/4.2/4.3 regression] ICE with broken template declaration
--- Comment #1 from bangerth at dealii dot org 2008-01-13 02:25 --- Confirmed. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-13 02:25:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34603
[Bug c++/34749] Incorrect warning when applying dllimport to friend function
--- Comment #1 from bangerth at dealii dot org 2008-01-13 02:12 --- One could make the argument that the dllimport specifier is a storage-class-specifier which, per 11.4/6 is not allowed on the friend declaration. Since a friend function declaration needs to be preceded by a declaration of the function itself, it will always be sufficient if the dllimport specifier is only on the original function declaration. I therefore think that the PR is invalid, but leave the final decision to someone with more knowledge. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34749
[Bug c++/34550] reference data template args appear to be broken in 4.2.1 ?
--- Comment #3 from bangerth at dealii dot org 2008-01-13 02:29 --- As per Andrew's comment, this is invalid. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34550
[Bug c++/34531] local typedef conflicts with global definition of a type having the same name
--- Comment #4 from bangerth at dealii dot org 2008-01-13 02:31 ---
(In reply to comment #0)
template typename class X {};
class Y {
typedef Xint X;
};
produces the following error:
redef.cpp:4: error: declaration of 'typedef class Xint Y::X'
redef.cpp:1: error: changes meaning of 'X' from 'class Xint'
What the error message says is this: before the typedef declaration,
referring to the name 'X' inside the class refers to the global
template ::X. After the declaration, 'X' inside the class refers
to the typedef. C++ does not allow declarations to change the
meaning of names.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||bangerth at dealii dot org
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34531
[Bug c++/34406] [reject valid?] incomplete type 'Y' used in nested name specifier.
--- Comment #1 from bangerth at dealii dot org 2008-01-13 02:33 --- What is the question you want to ask? The first code you show is invalid, the second valid... W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34406
[Bug c++/34021] Segmentation fault in G++ 4.1.3 with -O2
--- Comment #4 from bangerth at dealii dot org 2008-01-13 02:43 --- Confirmed, but fixed in 4.2.x. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34021
[Bug c++/33885] member reference to a temporary object being deleted too early
--- Comment #3 from bangerth at dealii dot org 2008-01-13 02:45 --- Indeed invalid. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33885
[Bug c++/33821] function with ambiguous covariant return-type is not rejected
--- Comment #1 from bangerth at dealii dot org 2008-01-13 02:49 --- Confirmed. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2008-01-13 02:49:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33821
[Bug c++/33810] gcc 4.1.2 mangles results on x86_64 in bitfield operations
--- Comment #1 from bangerth at dealii dot org 2008-01-13 03:10 ---
Confirmed. Here's a slightly simplified testcase:
---bar.h
typedef struct {
unsigned : 16;
unsigned : 16;
} foo;
---bar.c
#include stdio.h
#include bar.h
foo bar(unsigned i)
{
printf(bar: i is %u.\n,i);
foo myfoo;
return myfoo;
}
-foo.cc
#include stdio.h
#include bar.h
extern C foo bar(unsigned int);
int main(void)
{
foo myfoo;
unsigned i = 3;
printf(foo: i is %u.\n,i);
myfoo = bar(i);
return 0;
}
---
tmp/g gcc -I. -c bar.c
tmp/g g++ -I. -o foo foo.c bar.o
tmp/g ./foo
foo: i is 3.
bar: i is 1289971520.
Something appears to go wrong when calling the extern C function...
This is a wrong-code regression on valid code.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||bangerth at dealii dot org,
||mmitchel at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2008-01-13 03:10:24
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33810
[Bug c++/33786] C data and static const data members mangled the same
--- Comment #2 from bangerth at dealii dot org 2008-01-13 03:12 --- So fixed. This is the error message one would expect. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33786
[Bug c++/34696] Overloaded template losing type in invoking a superclass method?
--- Comment #1 from bangerth at dealii dot org 2008-01-07 17:34 --- (In reply to comment #0) o arg; This line calls the global operator ostream operator (ostream, char*) whereas this one std::ostringstream::operator(arg); clearly needs a member function operator. The best one is the one with void* argument. So not a bug. W. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34696
[Bug libstdc++/34095] parallel mode: segfault in std::sort
--- Comment #4 from bangerth at dealii dot org 2007-12-13 22:54 --- By the way, the size of the vector affects whether the testcase fails or not. Apparently the algorithms decide that if the vector is too small then it's not worth subdividing the work. On my 2-processor machine, 20,000 is enough to trigger the error, but for example 100 is not. YMMV. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34095
[Bug libstdc++/34095] parallel mode: segfault in std::sort
--- Comment #3 from bangerth at dealii dot org 2007-12-12 22:44 --- (In reply to comment #2) Let's just close it if you can't reproduce now. I'll just try to run everything again some time from now and if I have the same problem again I'll re-open. Hm, so I got around to check this out again and in fact the same happens with today's svn version: examples/step-14 c++ -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --prefix=/tmp/bangerth/bin/gcc-mainline --with-mpfr=/tmp/bangerth/bin --with-gmp=/tmp/bangerth/bin --disable-multilib --enable-languages=c,c++ Thread model: posix gcc version 4.3.0 20071212 (experimental) (GCC) examples/step-14 c++ -D_GLIBCXX_PARALLEL -fopenmp -march=native -mtune=native a.cc -g -O2 examples/step-14 ./a.out Segmentation fault examples/step-14 uname -a Linux bloc640b 2.6.22.9-0.4-default #1 SMP 2007/10/05 21:32:04 UTC i686 i686 i386 GNU/Linux This is with the program posted before, with pretty much the same backtrace. Johannes, does the program work for you? Best Wolfgang -- bangerth at dealii dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34095
[Bug libstdc++/34095] New: parallel mode: segfault in std::sort
I tried to figure out what is going on here, but it's getting
to complicated in the libstdc++ innards for me to spot the problem.
In any case, this little program
---
#include vector
#include algorithm
struct S
{
unsigned int line;
std::vectordouble entries;
bool operator (const S a) const
{
return line a.line;
}
};
int main ()
{
std::vectorS lines(2);
std::sort (lines.begin(), lines.end());
}
produces a segfault for me when compiled with parallel mode.
A backtrace is here:
(gdb) bt
#0 0x0805cf59 in ~vector (this=0xb6439ffc)
at
/tmp/bangerth/bin/gcc-mainline/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/stl_vector.h:304
#1 0x0805cf9d in ~S (this=0xb6439ff8) at step-14.cc:5
#2 0x0806d1b9 in
__gnu_parallel::parallel_sort_mwms_pu__gnu_cxx::__normal_iteratorS*,
std::__cxx1998::vectorS, std::allocatorS , std::lessS (
d=0x807722c, [EMAIL PROTECTED])
at
/tmp/bangerth/bin/gcc-mainline/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/parallel/multiway_mergesort.h:312
#3 0x08057c73 in
__gnu_parallel::parallel_sort_mwms__gnu_cxx::__normal_iteratorS*,
std::__cxx1998::vectorS, std::allocatorS , std::lessS (
.omp_data_i=0xbfffd450)
at
/tmp/bangerth/bin/gcc-mainline/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/parallel/multiway_mergesort.h:391
#4 0xb6dd03e0 in gomp_thread_start (xdata=0xbfffd330)
at ../../../svn/libgomp/team.c:108
#5 0xb6db2aa7 in start_thread () from /lib/tls/libpthread.so.0
This is in the worker thread, not the main thread from which it was spawned.
Hope this helps, cheers
W.
--
Summary: parallel mode: segfault in std::sort
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34095
[Bug c++/34090] -O3 wrong code, -O2 OK
--- Comment #5 from bangerth at dealii dot org 2007-11-15 04:26 --- So done. -- bangerth at dealii dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34090
[Bug c++/33990] bug in lookup of member template conversion operator for pointer to member functions
--- Comment #2 from bangerth at dealii dot org 2007-11-15 04:33 --- Confirmed with 2.95 and 4.2.1. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Known to fail||2.95 4.2.1 Last reconfirmed|-00-00 00:00:00 |2007-11-15 04:33:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33990
[Bug c++/34089] [4.1/4.2/4.3 regression] Segfault on specialization using struct instead of template function.
--- Comment #1 from bangerth at dealii dot org 2007-11-15 04:38 --- Confirmed, a regression introduced in 4.0.x. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Known to fail||4.1.2 4.2.0 4.0.4 Known to work||3.4.6 Last reconfirmed|-00-00 00:00:00 |2007-11-15 04:38:59 date|| Summary|Segfault on specialization |[4.1/4.2/4.3 regression] |using struct instead of |Segfault on specialization |template function. |using struct instead of ||template function. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34089
[Bug c++/34094] Undefined static data member in anonymous namespace can acquire a definition anyway
--- Comment #2 from bangerth at dealii dot org 2007-11-15 04:40 --- It may also be that the compiler sees that the store is dead and removes it. Did you check whether the store appears in the assembler output? W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34094
[Bug c++/34049] Parentheses-enclosed expression.
--- Comment #1 from bangerth at dealii dot org 2007-11-15 04:35 --- Confirmed with gcc 2.95 and 4.2.1. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Known to fail||2.95 4.2.1 Last reconfirmed|-00-00 00:00:00 |2007-11-15 04:35:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34049
[Bug c++/33839] [4.3 regresssion] ICE with decltype
--- Comment #1 from bangerth at dealii dot org 2007-10-20 23:36 ---
The code should be invalid precisely because this is also invalid:
---
templateint struct A;
void foo()
{
A0;
}
---
g/x c++ -c x.cc
x.cc: In function 'void foo()':
x.cc:5: error: declaration does not declare anything
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33839
[Bug c++/33620] [4.3 regression] internal compiler error: canonical types differ for identical types const QListQStringList and const QListQStringList
--- Comment #4 from bangerth at dealii dot org 2007-10-19 23:54 ---
This is the shortest I can come up with:
--
template typename T
struct __attribute__((visibility(default))) List {};
int bar(Listint args);
bool test(const Listint );
int i = bar(Listint());
bool test(const Listint ) {}
-
tmp/bangerth /tmp/bangerth/bin/gcc-mainline/bin/c++ -c x.cc
x.cc: In function 'bool test(const Listint)':
x.cc:9: internal compiler error: canonical types differ for identical types
const Listint and const Listint
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33620
[Bug libstdc++/33489] parallel v3: not default constructible issues
--- Comment #12 from bangerth at dealii dot org 2007-10-18 18:46 --- Yes, sorry. I meant to report of course that I believe that it works now. Thanks for your work! W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33489
[Bug c++/33744] function-style cast not allowed in template argument
--- Comment #1 from bangerth at dealii dot org 2007-10-12 12:52 --- It's not the parentheses or the greater-than sign, but the cast that triggers the error. I will have to look up whether a cast is allowed here. For reference, icc accepts the code. W. -- bangerth at dealii dot org changed: What|Removed |Added Summary| within function-style cast|function-style cast not |incorrectly parsed as |allowed in template argument |closing template angle | |bracket | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33744
[Bug c++/33744] [4.1/4.2/4.3 regression] function-style cast and '' not allowed in template argument
--- Comment #4 from bangerth at dealii dot org 2007-10-12 15:21 ---
(In reply to comment #3)
(I'm told that) these two function-style casts compile fine on 4.2.1:
template bool cond
struct A {
};
Abool (2) y;
Abool (2 1) z;
Uh, indeed, I see. This is weird indeed. So in other words, these codes
compile:
--
template bool struct A {};
Abool(1) a;
Abool(12) b;
A(bool)(12) c;
--
but this one doesn't:
--
template bool struct A {};
Abool(12) b;
--
This is indeed very weird: it only fails with the function-style cast
and the greater-than sign...
Since this worked in gcc 3.3, this is a regression.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||rejects-valid
Known to fail||4.1.2 4.2.0 4.3.0
Known to work||3.3.6
Last reconfirmed|-00-00 00:00:00 |2007-10-12 15:21:49
date||
Summary|function-style cast not |[4.1/4.2/4.3 regression]
|allowed in template argument|function-style cast and ''
||not allowed in template
||argument
Target Milestone|--- |4.2.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33744
[Bug c++/33750] initialization of non-integral member constant not rejected
--- Comment #7 from bangerth at dealii dot org 2007-10-12 15:16 --- This used to be a GCC extension in the old days, which may explain why it isn't rejected by default. I believe it was deprecated several releases ago, you may find something to that effect in release notes... W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33750
[Bug c++/33744] function-style cast not allowed in template argument
--- Comment #2 from bangerth at dealii dot org 2007-10-12 13:04 --- The rule for template non-type arguments of integral type is 14.3.2/1: 1 A template-argument for a non-type, non-template template-parameter shall be one of: -- an integral constant-expression of integral or enumeration type; ... Integral constant-expressions are dealt with in 5.19/1: Anintegral constant-expression can involve only literals (_lex.literal_), enumerators, const variables or static data members of integral or enumeration types initialized with constant expressions (_dcl.init_), non-type template parameters of integral or enumeration types, and sizeof expressions. Floating literals (_lex.fcon_) can appear only if they are cast to integral or enumeration types. Only type conversions to integral or enumeration types can be used. In particular, except in sizeof expressions, functions, class objects, pointers, or references shall not be used, and assignment, increment, decrement, function-call, or comma operators shall not be used. I do not know whether bool(1) is considered a function-call. Gcc rejects it as a template argument. However, it does accept (bool)1. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33744
[Bug target/33704] AIX runs c++ constructors in incorrect order
--- Comment #10 from bangerth at dealii dot org 2007-10-09 14:53 --- If it's a request to improve the AIX linker, should we even keep this PR open? David, as a sidenote (because you're at IBM), this is the sort of thing that makes AIX such an unpopular target to do development on. It just surprises me that 10+ years after everyone else had their linker fixed to support proper C++ templates and initialization order, IBM's linker still can't do it. I found porting our 350 kloc template-heavy code to AIX one of the more painful exercises I ever did. That's not your fault, but maybe you can pass it on to someone in charge. Sigh, and sorry for the digression... W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33704
