[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006
--- Comment #5 from jwakely dot gcc at gmail dot com 2010-06-04 14:56 --- I don't have the SPEC benchmarks either, but probably deal.II uses ptrdiff_t unqualified, without explicitly including either cstddef or stddef.h http://www.dealii.org/developer/doxygen/deal.II/block__vector_8h.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44416
[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006
--- Comment #6 from jwakely dot gcc at gmail dot com 2010-06-04 15:00 --- certainly true for an older version http://ganymed.iwr.uni-heidelberg.de/~deal/5.2.0/doxygen/deal.II/block__vector_8h.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44416
[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors
--- Comment #11 from jwakely dot gcc at gmail dot com 2010-06-03 09:18 --- (In reply to comment #10) (In reply to comment #9) I've been experimenting with this patch, which warns if there is a missing mem-initializer for a scalar. It gives a false positive for cases were the member is assigned to in the constructor body, or otherwise initialized before use, but it's a start, and has already helped me find some missing mem-initializers in real code. Nice but I am afraid there may be too many false positives. Yes, I'm not proposing it in that state. It's just an experiment but has been useful for me already. And what is different between this and the -Weffc++ warning given just below it? -Weffc++ also enables dozens of other warnings, most of which I don't find useful. It is about good style, not dangerous code, and I don't like the compiler to enforce style. In this specific case, the Weffc++ warning complains if *any* member has no mem-initializer. I only care about POD members which will be uninitialized, I don't want to add a mem-initializer for e.g. a std::string member which has a default constructor. +case OPT_Wmeminit: + warn_meminit = value; + break; + You do not need this. This is handled automatically when you defined Var in the opt files. Ah OK, thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972
[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors
--- Comment #12 from jwakely dot gcc at gmail dot com 2010-06-03 09:27 --- Apart from the false positives, another problem is that the check for layout_pod_type_p is not right. An empty class is a POD but doesn't need initialising. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972
[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors
--- Comment #14 from jwakely dot gcc at gmail dot com 2010-06-03 11:24 --- Created an attachment (id=20817) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20817action=view) better -Wmeminit patch This version ignores empty classes and checks for a nontrivial default ctor instead of layout_pod_type. This patch doesn't enable the warning unless explicity requested. I realise that this warning is about enforcing style (members should be initialised in the mem-initializer-list not in the ctor body) but that's ok because it's my preferred style, I just don't want the compiler to enforce other people's preferred style ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972
[Bug c++/44399] Problem with command line arguments in windows
--- Comment #4 from jwakely dot gcc at gmail dot com 2010-06-03 13:24 --- If it's a cygwin executable the behaviour might be caused by cygwin's globber In any case, it's not gcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44399
[Bug c++/44380] [C++0x]: result_of broken for functor references.
--- Comment #8 from jwakely dot gcc at gmail dot com 2010-06-02 17:09 --- gcc 4.3 was released 18 months before the FCD, at that time the specification of result_of was quite different. Also, until the gcc 4.5.0 release std::result_of was based on the tr1::result_of code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44380
[Bug libstdc++/40296] [C++0x] std::exception_ptr comparisons
--- Comment #12 from jwakely dot gcc at gmail dot com 2010-06-02 17:17 --- The NullablePointer concept is new, so yes, it's changed. I'll deal with this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40296
[Bug libstdc++/40296] [C++0x] std::exception_ptr comparisons
--- Comment #14 from jwakely dot gcc at gmail dot com 2010-06-02 17:26
---
(In reply to comment #10)
AFAIK, the following code should work but does not anymore cause of this bug
fix:
std::exception_ptr e;
if (e)
{
/* ... */
}
I'm fairly sure that's not valid.
That relies on an implicit conversion to bool, not a contextual conversion to
bool, and 18.8.5 also says exception_ptr shall not be implicitly convertible
to any arithmetic, enumeration, or pointer type.
This should work though:
if (bool(e))
I'll fix that and add tests to check implicit conversions don't work (I think
that requirement is also new since exception_ptr was last worked on.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40296
[Bug libstdc++/40296] [C++0x] std::exception_ptr comparisons
--- Comment #15 from jwakely dot gcc at gmail dot com 2010-06-02 17:30 --- (In reply to comment #14) I'm fairly sure that's not valid. That relies on an implicit conversion to bool actually that's nonsense ... that is a contextual conversion! anyway, I'll look into it properly and fix it asap -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40296
[Bug libstdc++/44339] Usage of std::weak_ptr in ordered stl container (C++0x)
--- Comment #7 from jwakely dot gcc at gmail dot com 2010-05-31 10:16 --- n2637 removed comparisons on weak_ptr http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2637.pdf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44339
[Bug c++/44283] New: bad error recovery for explicit template instantiation in wrong namespace
namespace NS
{
typedef int X;
templatetypename T void f(X f, T t) { }
}
template void f(X, int); // (1)
template void f(int, char); // (2)
The code is invalid, the explicit instantiations should be inside NS or should
be qualified e.g.
template void NS::func(X, int);
But the diagnostic for instantiation (1) is unhelpful:
bug.cc:8:17: error: variable or field 'f' declared void
bug.cc:8:16: error: expected ';' before '(' token
This is closely related to Bug 16663 but the diagnostic for (2) implies it
might be possible to improve things without fixing bug 16663, as this is much
better:
bug.cc:10:26: error: 'f' is not a template function
Is it possible to give the same is not a template function diagnostic for
(1)?
Comeau does significantly better, reporting:
identifier X is undefined
and
f is not a class or function template name in the current scope
If the invalid instantiation is for a class template the diagnostic is fine:
namespace NS
{
templatetypename T struct S;
}
template struct SX;
bug2.cc:6:17: error: 'S' is not a template
bug2.cc:6:19: error: 'X' was not declared in this scope
bug2.cc:6:17: error: explicit instantiation of non-template type 'S'
The only improvement I would make would be to add something like in this
scope to the first error.
Here's another bad diagnostic for instantiating a template function, which
doesn't have any undeclared type:
namespace NS
{
templateint N void g() { }
}
template void g0();
bug3.cc:6:15: error: variable or field 'g' declared void
bug3.cc:6:16: error: expected ';' before '' token
Surely it's possible to say g is not a template function when the compiler
sees template ... g... ?
Comeau is much better again:
ComeauTest.c, line 6: error: g is not a template,
Should it be XX::g?, where XX is some namespace?
Did you #include the right header?
template void g0();
^
ComeauTest.c, line 6: error: invalid explicit instantiation declaration
template void g0();
^
--
Summary: bad error recovery for explicit template instantiation
in wrong namespace
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jwakely dot gcc at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44283
[Bug c++/44285] Need an option that will create symbols for all public c++ methods, not only for those which bodies are outside the class declaration
--- Comment #3 from jwakely dot gcc at gmail dot com 2010-05-26 16:36 --- If you don't want the functions to be treated as inline don't make them inline Have you tried -fkeep-inline-functions ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44285
[Bug c++/44285] Need an option that will create symbols for all public c++ methods, not only for those which bodies are outside the class declaration
--- Comment #7 from jwakely dot gcc at gmail dot com 2010-05-26 16:55 --- If you only want meth_used and meth_unused to be emitted but you insist on making them inline, then put them in a separate translation unit and compile that with -fkeep-inline-functions. If I understand what you want then you can already do it with no need for new attributes or visibility types. You just need to structure your code appropriately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44285
[Bug c++/44021] Templates with -Wtype-limits produces warnings.
--- Comment #1 from jwakely dot gcc at gmail dot com 2010-05-07 08:49 --- this seems like a good candidate for using template specialisation to alter the behaviour I think the warning is still useful for templates, since it warns you of a potential mistake in your logic. It doesn't make sense to have a template that can handle unsigned integers with negative values so I want to be warned if I write such code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44021
[Bug c++/43646] New: decltype and std::integral_constant
This was originally sent as an email to gcc-bugs:
http://gcc.gnu.org/ml/gcc-bugs/2010-04/msg00167.html
I'm entering it here on his behalf...
The following translation unit seems to show a bug exhibited by 4.4.3 and 4.5.
#include type_traits
templateclass X, class Y struct plus
: std::integral_constant
decltype(X::value + Y::value),
X::value + Y::value
{ };
int main(int argc, char* argv[]) {
return 0;
}
Compiling this file (test.cpp) with
g++ -std=c++0x -l stdc++ test.cpp
yields the following diagnostic:
test.cpp:7: error: 'decltype ((X::value + Y::value))'
is not a valid type for a template constant parameter
Am I missing something? The following works as intended:
#include type_traits
#include utility
templateclass X, class Y struct plus
: std::integral_constant
typename std::identitydecltype(X::value + Y::value)::type,
X::value + Y::value
{ };
int main(int argc, char* argv[]) {
return 0;
}
(i.e. just wrapping the use of decltype with std::identity)
--
Summary: decltype and std::integral_constant
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jwakely dot gcc at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43646
[Bug c++/43646] decltype and std::integral_constant
--- Comment #1 from jwakely dot gcc at gmail dot com 2010-04-05 11:39 --- Is this related to DR 743 or 950, and so likely to get fixed when N3049 is supported? -- jwakely dot gcc at gmail dot com changed: What|Removed |Added Known to fail||4.4.3 4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43646
[Bug libstdc++/43183] std::unique_ptr::reset() does not conform to N3035.
--- Comment #16 from jwakely dot gcc at gmail dot com 2010-03-02 11:41 --- I might have caused a regression with this change: FAIL: 30_threads/promise/members/set_value3.cc execution test WARNING: program timed out. Will investigate later today... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43183
[Bug libstdc++/43183] std::unique_ptr::reset() does not conform to N3035.
--- Comment #17 from jwakely dot gcc at gmail dot com 2010-03-02 12:44 --- The 30_threads/promise/members/set_value3.cc test had a latent bug which was revealed by the unique_ptr fix. I'll change the test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43183
[Bug libstdc++/43183] std::unique_ptr::reset() does not conform to N3035.
--- Comment #5 from jwakely dot gcc at gmail dot com 2010-03-01 15:05
---
OK, I'm back and have had time to look at this. I vaguely remember noticing
that the assignment and the deleter invocation happened in the wrong order in
our implementation, but I must have forgotten about it as I don't have any
uncommitted change (or even a comment) in my working copy.
The suggested change is still incorrect: the wrong condition is checked. The
deleter must be invoked when old_p != NULL, rather than when old_p != p.
Consider:
unique_ptrint p1;
p1.reset(new int);
The deleter should not be invoked by the call to reset, because old_p ==
nullptr.
Another case:
unique_ptrint p(new int);
p.reset(p.get());
p.release();
This should not leak, but with the suggested change it will, because the
deleter will not get invoked.
A better implementation would be (untested):
void
reset(pointer __p = pointer())
{
pointer __old = get();
std::get0(_M_t) = __p;
if (__old != 0)
std::get1(_M_t)(__old);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43183
[Bug libstdc++/43183] std::unique_ptr::reset() does not conform to N3035.
--- Comment #7 from jwakely dot gcc at gmail dot com 2010-03-01 16:23 --- I think it should be fixed for 4.5 and then updated when nullptr is available. I assume that LWG 834 will be accepted in some form, so we will need an update at some point anyway, to use nullptr in release and operator bool and in the assertions in operator* and operator- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43183
[Bug libstdc++/43183] std::unique_ptr::reset() does not conform to N3035.
--- Comment #8 from jwakely dot gcc at gmail dot com 2010-03-01 16:35
---
Actually, we could just use pointer() everywhere, which would work today and
would be equivalent to using nullptr, assuming the current proposed resolution
of 834 or something similar. I would be very surprised if 834 is resolved in a
way that allows different semantics for get() == nullptr and get() == pointer()
i.e.
explicit operator bool() const
{ return get() == pointer() ? false : true; }
// Modifiers.
pointer
release()
{
pointer __p = get();
std::get0(_M_t) = pointer();
return __p;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43183
[Bug libstdc++/43005] Segmentation fault(not always) while running binary which has gcc and g++ compiled shared object files
--- Comment #2 from jwakely dot gcc at gmail dot com 2010-02-09 10:49 --- In addition to what Paolo said: You're using -lpthread, did you also use the relevant preprocessor options? For powerpc -pthread does everything you need. That code doesn't qualify the names from namespace std, so I don't see how it even compiles. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43005
[Bug libstdc++/42819] [C++0x] std::async fails to compile with simple tests, including N3000 example
--- Comment #25 from jwakely dot gcc at gmail dot com 2010-02-09 18:28 --- This is now LWG 1315 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42819
[Bug c++/42983] [C++0x] Defaulted virtual destructor isn't virtual
--- Comment #5 from jwakely dot gcc at gmail dot com 2010-02-08 12:35 --- n3000 says Only special member functions may be explicitly defaulted, and the implementation shall define them as if they had implicit definitions. An implicit destructor is not virtual. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#906 changes this wording -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42983
[Bug c++/42983] [C++0x] Defaulted virtual destructor isn't virtual
--- Comment #8 from jwakely dot gcc at gmail dot com 2010-02-08 13:56 --- (In reply to comment #6) Interesting. Thus I get Core 906 [Ready] as meaning that this snippet is just illegal, and should be rejected, in other terms, this is an accept invalid, right? Yes, I believe 4.5.0 should reject this (but can't check if it does.) I don't really know what 4.4.1 should do, it wasn't clear, which is why core 906 was opened to clarify it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42983
[Bug c++/42983] [C++0x] Defaulted virtual destructor isn't virtual
--- Comment #10 from jwakely dot gcc at gmail dot com 2010-02-08 14:00 --- (In reply to comment #7) There is a thread in comp.std.c++ about this. Yes, but I don't think anyone's mentioned core issue 906, which makes all the arguments rather moot. Read that resolution, not n3000. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42983
[Bug c++/42983] [C++0x] Defaulted virtual destructor isn't virtual
--- Comment #11 from jwakely dot gcc at gmail dot com 2010-02-08 14:04
---
(In reply to comment #9)
I'm not sure to understand your last comment (sorry I 'm not a natural english
speaker). Do you mean that virtual ~A() = default; should be an error ? If we
Yes. GCC implements the resolution to core issue 906
can not default virtual destructor, well, the feature seems less interesting.
You can do it, but not on the first declaration:
struct A {
virtual ~A();
};
A::~A() = default;
I think this should be OK (but maybe not in GCC 4.4 only in 4.5)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42983
[Bug libstdc++/42819] [C++0x] std::async fails to compile with simple tests, including N3000 example
--- Comment #23 from jwakely dot gcc at gmail dot com 2010-02-05 18:40 --- I realised the other day I hadn't followed up on a fix for this. Here's some of the email I got from Lawrence just before Christmas, I haven't heard anything more recent: I noticed while implementing it that in n3000 std::asyncF,... returns std::futuretypename F::result_type Is the requirement on a nested typedef intentional, or is it a relic of an earlier version using concepts? N3000 has a bad merge of two papers voted into the standard, so there is much cleanup to be done. Detlef and I will need address this issue as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42819
[Bug libstdc++/42925] Not possible to compare unique_ptr with 0
--- Comment #2 from jwakely dot gcc at gmail dot com 2010-02-01 17:01 --- I think the code is invalid. In 4.4 the expression (ptr != 0) converted ptr to an unspecified-bool-type and compared that to 0. In 4.5 the impicit conversion has been removed, and you need to say static_castbool(ptr) or (bool)ptr instead. This is required by the current working draft -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42925
[Bug libstdc++/42925] Not possible to compare unique_ptr with 0
--- Comment #4 from jwakely dot gcc at gmail dot com 2010-02-01 17:22 --- there is this comparison function: templateclass T1, class D1, class T2, class D2 bool operator!=(const unique_ptrT1, D1 x, const unique_ptrT2, D2 y); What should T2 and D2 be deduced as, in the conversion from nullptr_t to unique_ptrT2, D2 ? Or to put it another way: unique_ptr is not a type, it's a template. So what type do you mean when you say build an empty unique_ptr object ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42925
[Bug libstdc++/42925] Not possible to compare unique_ptr with 0
--- Comment #6 from jwakely dot gcc at gmail dot com 2010-02-01 17:36 --- (In reply to comment #5) Jon, is there a thread on the reflector about related issues? I spotted something but couldn't exactly remember... LWG 834 is about comparing unique_ptrT,D::pointer to nullptr_t LWG 1307 is about missing != comparisons for other types. Neither is related to this issue, and I don't know of any thread on this topic. The code would work if there was: templateclass T1, class D1 bool operator!=(const unique_ptrT1, D1 x, const nullptr_t); (along with a version with the arguments reversed, and similarly for operator==) But there is no such function in the WP. Nor is there a member unique_ptr::operator!=(nullptr_t) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42925
[Bug c++/42810] Enumeration with sequential values has its for-loop exit condition optimized out.
--- Comment #22 from jwakely dot gcc at gmail dot com 2010-01-28 10:13 --- (In reply to comment #14) So does the C++ standard say that it is acceptable for the compiler to drop support for an out-of-range enumeration value in a way that the programmer has no idea it happens--but to support out-of-range enumeration values in other situations? The standard says nothing about warnings, a program is either correct or not. If it's not correct, the standard doesn't apply. The standard only defines what happens if you stick to its rules. It can't possibly legislate what happens if you go outside those rules, pretty much by definition. In other words, if gcc is so provably correct according to the standard in refusing to support an out-of-range-by-one enumeration value, why does it run the code at lesser optimization levels? Couldn't the fact that it runs the code without complaint in the majority of cases by considered a bug? No. Undefined behaviour is undefined, not defined to behave consistently at all optimisation levels. I think a warning for this would be helpful, but asking for the compiler to assume types can have values that they can't have is not a good idea. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42810
[Bug libstdc++/34106] [parallel mode] Atomic operations compatibility layer needs cleanup
--- Comment #5 from jwakely dot gcc at gmail dot com 2010-01-28 17:46 --- and I thought everyone had forgotten about that patch ;) granted, ICC uses libstdc++, but doesn't it already have to support the same atomic builtins as used elsewhere in the library? And my patch changes parallel mode to use those same builtins (which are designed after the Intel intrinsics anyway, so likely to work in ICC!) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34106
[Bug libstdc++/34106] [parallel mode] Atomic operations compatibility layer needs cleanup
--- Comment #6 from jwakely dot gcc at gmail dot com 2010-01-28 17:47 --- similarly, if cygwin and mingw32 implement __sync_fetch_and_add etc. then why keep custom versions for those platforms? (but maybe the builtins aren't implemented on those platforms - I have no idea) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34106
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #39 from jwakely dot gcc at gmail dot com 2010-01-27 18:15 --- looks as though the .ii was created using -std=c++0x and then the compiler output obtained by compiling it without -std=c++0x that's never going to work -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42871] g++: Internal error: Segmentation fault (program cc1plus)
--- Comment #1 from jwakely dot gcc at gmail dot com 2010-01-26 12:24 --- Severity should be normal and a testcase is needed to reproduce the problem. -- jwakely dot gcc at gmail dot com changed: What|Removed |Added Summary|g++: Internal error:|g++: Internal error: |Segmentation fault (program |Segmentation fault (program |cc1plus)|cc1plus) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42871
[Bug c++/42877] ICE when checking the type of a lambda
--- Comment #1 from jwakely dot gcc at gmail dot com 2010-01-26 17:29 --- probably a dup of Bug 42082 or Bug 42737 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42877
[Bug c++/42877] [C++0x] ICE when checking the type of a lambda
--- Comment #4 from jwakely dot gcc at gmail dot com 2010-01-26 18:07 --- I assume the original version is also intended to work with non-empty captures, when operator() is non-static -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42877
[Bug c++/42824] c++ compilation complains about error: call of overloaded
--- Comment #7 from jwakely dot gcc at gmail dot com 2010-01-22 11:50 --- Is Boost.MPL needed? I haven't tried, but it looks like you could remove mpl entirely as it isn't directly involved where the error occurs. That would make the testcase MUCH smaller -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42824
[Bug c++/42840] const-ref argument in a variadic template arglist is mishandled
--- Comment #3 from jwakely dot gcc at gmail dot com 2010-01-22 12:00 --- N.B. duplicate of Bug 14404 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42840
[Bug libstdc++/42819] [C++0x] std::async fails to compile with simple tests, including N3000 example
--- Comment #2 from jwakely dot gcc at gmail dot com 2010-01-21 10:35 --- Yes, it's a defect (a concepts hangover) - the example is invalid according to the async spec. I pointed it out to Lawrence and he's dealing with it for the next draft. I implemented async as defined in n3000 - I can change it to use result_of / decltype if desired. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42819
[Bug libstdc++/42819] [C++0x] std::async fails to compile with simple tests, including N3000 example
--- Comment #5 from jwakely dot gcc at gmail dot com 2010-01-21 10:42 --- (In reply to comment #2) Yes, it's a defect (a concepts hangover) - the example is invalid according to the async spec. I pointed it out to Lawrence and he's dealing with it for the next draft. To expand on this: std::async is defined in terms of Fn::result_type, assuming that Concepts would provide Callable::result_type, so the example would be valid. Without concepts, that doesn't work, so the example is invalid. The most likely fix will be to use result_ofFn(Args...)::type instead, making the example valid again. I chose to follow the spec, not the example which appears in a non-normative note. (In reply to comment #4) Well, using result_of / decltype would make it more usable in the meanwhile, should not be a big deal, right? Yes, I think we could do that. I'll ask Lawrence how he's planning to address it - we might as well do that way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42819
[Bug libstdc++/42819] [C++0x] std::async fails to compile with simple tests, including N3000 example
--- Comment #7 from jwakely dot gcc at gmail dot com 2010-01-21 10:54 --- btw, Jack, thanks for testing it. Your feedback is appreciated -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42819
[Bug c++/42822] ice on invalid code in joust
--- Comment #3 from jwakely dot gcc at gmail dot com 2010-01-21 11:07 --- this is a dup of Bug 42701 and so should not ICE in a newer snapshot -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42822
[Bug libstdc++/42819] [C++0x] std::async fails to compile with simple tests, including N3000 example
--- Comment #10 from jwakely dot gcc at gmail dot com 2010-01-21 16:08 --- (In reply to comment #8) Is there an easy workaround I can apply locally for this? I tried replacing all instances of `typename _Fn::result_type` with `typename result_of_Fn(_Args...)::type` in future just to see if I can get things going That should be all that's needed, in theory. /usr/local/gcc-4.5-r156097/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/functional:183:9: error: 'std::declval [with _Tp = std::launch, typename std::add_rvalue_reference_Tp::type = std::launch]()' cannot be used as a function I'm not sure what's going on here and can't look into it now. Does the example in Comment 1 work? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42819
[Bug libstdc++/42819] [C++0x] std::async fails to compile with simple tests, including N3000 example
--- Comment #12 from jwakely dot gcc at gmail dot com 2010-01-21 16:14 --- Aha - I see what's happening. As well as changing _Fn:result_type everywhere please change line 1327 in future to this: return async_Fn, _Args...(launch::any, std::forward_Fn(__fn), The problem is the wrong overload of async() is being selected, and it is trying to use launch::any as the functor, which gives the cannot be used as a function error. Paolo, this is the problem I had with std::bind, I think there might be a larger problem with overloaded variadic template functions ... I'll think about it further. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42819
[Bug libstdc++/42819] [C++0x] std::async fails to compile with simple tests, including N3000 example
--- Comment #13 from jwakely dot gcc at gmail dot com 2010-01-21 16:19 --- (In reply to comment #12) Paolo, this is the problem I had with std::bind, I think there might be a larger problem with overloaded variadic template functions ... I'll think about it further. To be clear: a problem in the standard, not g++ I'm starting to think that having std::bind and std::async as overloaded variadic functions is a mistake. It would be easier if one overload was renamed std::bind_r and std::async_any, as you wouldn't need to specify explicit template arguments to disambiguate the overloads. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42819
[Bug libstdc++/42819] [C++0x] std::async fails to compile with simple tests, including N3000 example
--- Comment #15 from jwakely dot gcc at gmail dot com 2010-01-21 16:28 --- (In reply to comment #14) Anyway, we also have the residual nit that I had to change to public the explicit constructor future(const __state_type). I suppose isn't a big issue... Did you change _Fn::result_type on lines 122 and 561? async _should_ be a friend, and not need the public constructor -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42819
[Bug libstdc++/42819] [C++0x] std::async fails to compile with simple tests, including N3000 example
--- Comment #20 from jwakely dot gcc at gmail dot com 2010-01-21 18:20 --- Eurgh - yes, we should disable one overload. I'm getting less and less happy about overloaded variadics. I'll look into it later. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42819
[Bug c++/5458] address of overloaded template function as argument for template
--- Comment #16 from jwakely dot gcc at gmail dot com 2010-01-21 19:00
---
Shouldn't it get the same error as for this case?
templateclass T
T foo() { return T(); }
int main()
{
foo;
}
That example can be made valid like so:
int (*pf)() = foo;
Which demonstrates that the angle brackets are not necessary, *if* the compiler
can determine which specialisation is intended. So the cannot resolve address
of overloaded function error is arguably correct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5458
[Bug libstdc++/42201] [C++0x] std::vectorstd::unique_futureT::push_back fails
--- Comment #7 from jwakely dot gcc at gmail dot com 2010-01-20 14:38 --- I was going to ask you the same thing :-) I would like to update future for 4.5, I'll send the patch when I get home in a few hours -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42201
[Bug c++/42780] Incorrect warning message
--- Comment #2 from jwakely dot gcc at gmail dot com 2010-01-18 11:23 --- N.B. the Host/Target/Target fields are meant for the host triplet such as i686-pc-cygwin Feel free to include the snapshot date and OS details in the main report, but putting them in the Host field just makes it harder to search bug reports. As it says at http://gcc.gnu.org/bugs/ the system type is output by 'gcc -v' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42780
[Bug libstdc++/42761] std::bind doesn't work for simple class types
--- Comment #1 from jwakely dot gcc at gmail dot com 2010-01-15 18:34 --- OK, I'll revert it all tomorrow if necessary -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42761
[Bug c++/42737] [c++0x] error returning a lambda function
--- Comment #4 from jwakely dot gcc at gmail dot com 2010-01-14 10:21 --- Obviously it shouldn't ICE, but I don't think this code is valid: the type of a lambda expression is a class type not a function pointer, and I don't think it's convertible to a function pointer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42737
[Bug c++/42737] [c++0x] error returning a lambda function
--- Comment #6 from jwakely dot gcc at gmail dot com 2010-01-14 12:30 --- (In reply to comment #5) Does it matter that lambdas with no-capture are special, per n2989? (also see http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01690.html) ah yes, that would make it valid! I wasn't aware of that change, sorry -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42737
[Bug c++/42743] Inexplicable error message with constructing SIMD values
--- Comment #1 from jwakely dot gcc at gmail dot com 2010-01-14 12:36
---
(In reply to comment #0)
vec_t tmp2 = {}; // Causes warnings about uninitialized members in
myvec
The warning doesn't smean it's uninitialized, just that there are not
initializers present for all members:
-Wmissing-field-initializers
Warn if a structure's initializer has some fields missing. For
example, the following code would cause such a warning, because x.h is
implicitly
zero:
struct s { int f, g, h; };
struct s x = { 3, 4 };
You can disable that with -Wno-missing-field-initializers (but that doesn't
help for cases where vec_t cannot be aggregate initialized)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42743
[Bug libstdc++/42733] Use of std::string with threads causes process hanging following a fork()
--- Comment #2 from jwakely dot gcc at gmail dot com 2010-01-13 18:23 --- Can you attach a debugger or produce a core file to see where it hangs? In any case, 3.4.6 is unsupported now and it seems to work OK on 4.4.2 Unless you can show where it hangs and/or reproduce it on a current release it's unlikely anyone will look into this -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42733
[Bug libstdc++/24803] [c++0x] reference_wrapper and pointers to member functions
--- Comment #21 from jwakely dot gcc at gmail dot com 2010-01-12 17:19 --- (In reply to comment #20) I'd like only to make sure we don't forget about the issue with pointers to member functions: is there a DR open already? It's been raised on the lib reflector byme, Stephan T. Lavavej and Alisdair Meredith. I'm not sufficiently motivated to open an issue for it, there are workarounds using mem_fn. The proposed resolution for LWG 1225 reinforces my interpretation that result_of does not support pointers-to-members. Maybe we could also find a way to mention it in the code, if you haven't done that already, didn't check. No, I didn't mention it in the code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24803
[Bug c++/42687] The prevention of ADL with the help of parentheses doesn't work
--- Comment #1 from jwakely dot gcc at gmail dot com 2010-01-11 18:37 --- This was changed by http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#705 and didn't appear in the working draft until November. It's hardly surprising that a compiler released in October doesn't support it -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42687
[Bug libstdc++/42573] [C++0x] shrink_to_fit() missing
--- Comment #4 from jwakely dot gcc at gmail dot com 2010-01-08 10:05 --- It would be conforming to add the function with an empty body ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42573
[Bug other/42540] c++ error message [vtable undefined] is unhelpful
--- Comment #3 from jwakely dot gcc at gmail dot com 2010-01-06 10:42 --- The linker error alone doesn't make the root cause obvious, but it's a fairly well known and well documented problem: http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
[Bug c++/17920] add __attribute__((reimpl)) as a replacement for the (optional) virtual keyword for reimplementations of virtual functions
--- Comment #13 from jwakely dot gcc at gmail dot com 2010-01-06 11:58 --- See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2928.htm which is part of the current C++ draft Related to Bug 31397 and Bug 36848 - we don't need three open bugs requesting similar features. I've suggested ((override)) ((base_check)) and ((hiding)) should be implemented using __attribute__ until C++1x attributes are supported -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17920
[Bug c++/35669] NULL (__null) not considered different from 0 with C++
--- Comment #15 from jwakely dot gcc at gmail dot com 2009-12-22 10:36 --- (In reply to comment #14) so [implicit] conversion from NULL to int is OK. That's true where NULL is defined as 0 (or eg 0L), but that's not the only permitted definition of NULL. Nice selective quoting, you missed the part where I said but 0 is still a valid definition of NULL You claimed in comment 12 that the compiler will be *required* to reject conversions from NULL to int, which is patently not true if 0 or 0L is a valid definition of NULL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35669
[Bug libstdc++/42201] [C++0x] std::vectorstd::unique_futureT::push_back fails
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-12-22 10:48 --- I'm planning to send a patch for feedback in the next 48 hours, including everything except atomic_future, because I think we need to implement [util.smartptr.shared.atomic] to support atomic_future -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42201
[Bug libstdc++/42198] [C++0x] Using std::thread without -pthread causes immediate crash
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-12-17 09:43 --- Looks sensible to me, although maybe resource_unavailable_try_again is a better error: resource_unavailable_try_again the system lacked the necessary resources to create another thread, or the system-imposed limit on the number of threads in a process would be exceeded. Without -pthread the system lacks the resources to create *any* new threads :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42198
[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations
--- Comment #23 from jwakely dot gcc at gmail dot com 2009-12-17 11:55
---
I can't see any 100% reliable way to prevent this problem, because the
catch-all specialisation of iterator_traits can be instantiated with
non-iterator types.
We could try tricks like this to restrict std::next to things that look like
iterators:
// deduction fails if _Iter doesn't meet InputIterator requirements
templatetypename _Iter,
typename _Sfinae1 = decltype(*std::declval_Iter()),
typename _Sfinae2 = decltype(++std::declval_Iter()),
typename _Sfinae3 = decltype(std::declval_Iter()++),
typename _Sfinae4 = decltype(*std::declval_Iter()++),
typename _Sfinae5 = decltype(std::declval_Iter()==std::declval_Iter())
typename iterator_traits_Iter::difference_type
__safe_iterator_diff_type(_Iter);
templatetypename _InputIterator
inline _InputIterator
next(_InputIterator __x, decltype(__safe_iterator_diff_type(__x)) __n = 1)
{
std::advance(__x, __n);
return __x;
}
But that will still fail for types that have an iterator-like interface. Then
again, I think such types would be detected as iterators even with concepts.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations
--- Comment #24 from jwakely dot gcc at gmail dot com 2009-12-17 12:01 --- Although that breaks if any of the iterator-like operators exists but is not accessible - I think concepts would have worked in that case, but I'm not sure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations
--- Comment #27 from jwakely dot gcc at gmail dot com 2009-12-17 12:23 --- ha! std::next would want is_input_iterator and std::prev would ideally want is_bidi_iterator, so maybe more than one trait -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
[Bug libstdc++/21772] exception safety testing
--- Comment #13 from jwakely dot gcc at gmail dot com 2009-12-16 11:14 --- (In reply to comment #12) Some are really puzzling... Hard to believe something is wrong in array, for example. I haven't looked into it, but the problem in array could be bug 41449 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21772
[Bug c++/42350] The attached file causes an internal compiler error
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-12-11 09:30 --- there's no ICE with 4.1.2 or 4.4.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42350
[Bug c++/36587] Feature: add warning for constructor call with discarded return.
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-12-11 10:39 --- (In reply to comment #4) But I'm not convinced that doing this is always a mistake. Since we don't care about the object, we must care about the constructor side effect. I seem to be under the impression that ISO C++ allows the construction of temporary objects to be optimized away---even if there are side effects in the constructor or destructor! Therefore, it's hard to see a valid use case for this. Certain temporaries (such as those created during copying or reference binding) can be optimised away, I don't think it's true of temporaries created explicitly like this. e.g. I think this should work: std::ofstream(lockfile); // creates ./lockfile if it doesn't exist (assuming write permission in the directory, and ignoring races and other reasons it might be a bad idea) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36587
[Bug c++/41039] Member reordering rule is overly strict
--- Comment #4 from jwakely dot gcc at gmail dot com 2009-08-12 09:41
---
I think maybe the second example is rejected because of 2) not 3)
2) A name N used in a class S shall refer to the same declaration in its
context and when re-evaluated in the
completed scope of S. No diagnostic is required for a violation of this rule.
'foo' is used in the class, but in the completed scope which includes the
function body of S::foo() 'foo' refers to the member function.
If you don't want to use -fpermissive you can convince gcc to compile it by
referring to the type as '::foo' because in that case the name always refers to
the global type even in the completed scope.
struct foo { };
struct bar {
::foo foo();
};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41039
[Bug c++/31397] Useful compiler warning missing (virtual functions in derived classes used without 'virtual')
--- Comment #12 from jwakely dot gcc at gmail dot com 2009-08-11 14:16 --- revised 'Explicit Virtual Function Overrides' paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2928.htm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31397
[Bug c++/20423] Warning -Woverloaded-virtual triggers to often
--- Comment #10 from jwakely dot gcc at gmail dot com 2009-08-11 14:24 --- as with bug 31937, there is overlap between this enhancement and the 'Explicit Virtual Function Overrides' paper, http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2928.htm the attributes proposed in that paper allow the derived class to explicitly state whether a function should override or hide the same name in the base class, making it ill-formed if there is unintended hiding -- jwakely dot gcc at gmail dot com changed: What|Removed |Added CC||jwakely dot gcc at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20423
[Bug c++/41020] Can't declare an extern C friend.
--- Comment #2 from jwakely dot gcc at gmail dot com 2009-08-10 10:40 --- Apart from the semi-colon after the extern C block the code is valid and this is a recent regression on trunk. -- jwakely dot gcc at gmail dot com changed: What|Removed |Added CC||jwakely dot gcc at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41020
[Bug c++/41002] Redundant diagnostic when class member function's name overlaps with class field's name
--- Comment #2 from jwakely dot gcc at gmail dot com 2009-08-10 11:34 --- (In reply to comment #0) To my mind statement test.cpp: In constructor 'testclass::testclass()': test.cpp:4: error: class 'testclass' does not have any field named 'number' is redundant because statements test.cpp:15: error: declaration of 'int testclass::number' test.cpp:9: error: conflicts with previous declaration 'int testclass::number() const' that appear before already cover this case. We already have a member named 'number' so we certainly can't have field with the same name. Diagnostic claims that a member 'number' already exist and field with that name cannot be created seems to be more reasonable here, but test.cpp:15 and test.cpp:9 already said that. The errors for lines 9 and 15 relate to the duplicate declaration of a member with the name 'number', whereas the error on line 4 refers to the invalid member initializer for 'number'. Those are separate errors. If you removed the declaration of 'int number;' (fixing the error on line 15) then there would still be an error on line 4, so I definitely don't consider that diagnostic to be redundant. Besides I found it interesting that swapping public: and private: blocks around makes diagnostic even more unclear: Huh? The errors are the same except for swapping which declaration is treated as the duplicate and which as the previous declaration, and that's because you swappged the order. What did you expect? Why is it more unclear? (In reply to comment #1) By the way using gcc instead of g++ doesn't changed things. Good - it shouldn't make any difference in this case. The difference with Comeau apears to be that name lookup finds the member variable 'number' whereas GCC finds the member function 'number' - maybe Comeau's name lookup finds the last declaration of that name and GCC's finds the member function - I'm not sure. Since the code is invalid neither compiler is right or wrong, and personally I don't have a strong preference. Both compilers point out that 'number' is declared twice, which is the main problem in the code that needs to be fixed, and both compilers print that as the first error. Note that if you put the declaration of 'int number;' first then Comeau has a very similar error to GCC's when the member function is first - it complains about the invalid member initializer and about the return statement in the member function. i.e. when the member function is declared later, Comeau's name lookup finds that one, and behaves similarly to GCC. I don't think there's much scope for improvement here. -- jwakely dot gcc at gmail dot com changed: What|Removed |Added CC||jwakely dot gcc at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41002
[Bug c++/41002] Redundant diagnostic when class member function's name overlaps with class field's name
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-08-10 11:35 --- (In reply to comment #2) Note that if you put the declaration of 'int number;' first then Comeau has a very similar error to GCC's when the member function is first - it complains about the invalid member initializer and about the return statement in the member function. i.e. when the member function is declared later, Comeau's name lookup finds that one, and behaves similarly to GCC. Just to be clear: this means Comeau also prints the error that you consider to be redundant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41002
[Bug libstdc++/41005] Unable to link fstream open and ctor with std::string argument.
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-08-10 12:26 --- Does libstdc++-v3/src/fstream-inst.cc get compiled in C++0x mode? If not, then the C++0x-only symbols would not be instantiated in the library -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005
[Bug libstdc++/41005] Unable to link fstream open and ctor with std::string argument.
--- Comment #2 from jwakely dot gcc at gmail dot com 2009-08-10 13:17 --- Since the C++0x changes to fstream are only additions, the simplest solution is probably to compile src/fstream-inst.cc in c++0x mode, which just means adding new targets to src/Makefile.am so that -std=gnu++0x is used. I'll test that fix tonight if noone beats me to it. The problem seems to be present on the 4.4 branch as well as trunk. -- jwakely dot gcc at gmail dot com changed: What|Removed |Added CC||jwakely dot gcc at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005
[Bug c++/41002] Redundant diagnostic when class member function's name overlaps with class field's name
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-08-10 14:44 --- (In reply to comment #4) Those are seperate errors of course. I've meant that when compiler already discovered that there is a conflict between number and number() it looks like it's keeping on emitting errors on every occurence of symbol that becoms a source of that conflict. In fact GCC found out that it is able to create nor property number nor member number(); later compiler descried a reference to a variable that is not exist (because it killed this variable later) and omitted another error. I agree that compiler exhibits its strict behaviour there but I'm not shure is it good for non-pedantic mode. Ah, I see what you mean. -pedantic controls something different and I don't think it should suppress later errors as you suggest. You might want to try -Wfatal-errors, which will cause compilation to stop at the first error. That's still not exactly what you want, as it will prevent *all* further errors being printed and not just those which are related to the first one, but I think in general it would be very difficult for the compiler to determine if individual errors are caused by an earlier error and suppress them conditionally. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41002
[Bug c++/41020] [4.5 Regression] Can't declare an extern C friend.
--- Comment #4 from jwakely dot gcc at gmail dot com 2009-08-10 17:05 --- It's irrelevant to this bug and is just me being more pedantic than -pedantic, however ... even with -pedantic GCC has always accepted stray semi-colons at namespace scope, but it's not valid. At function scope a lone ';' is a valid expression-statement, but expression-statements are not allowed at namespace scope, only declarations are, and ';' is not a valid declaration. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41020
[Bug libstdc++/41005] [C++0x] Unable to link fstream open and ctor with std::string argument.
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-08-10 19:39 --- The definitions are in that header, but the 'extern template' extension is used to prevent the compiler from instantiating the code in your program, see http://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html Instead of instantiating that code in every object a single explicit instantiation is provided in libstdc++.so, that's the purpose of src/fstream-inst.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005
[Bug libstdc++/41005] [C++0x] Unable to link fstream open and ctor with std::string argument.
--- Comment #6 from jwakely dot gcc at gmail dot com 2009-08-10 20:05 --- (In reply to comment #5) Instead of instantiating that code in every object a single explicit instantiation is provided in libstdc++.so, that's the purpose of src/fstream-inst.cc ... but in this case it fails to provide an explicit instantiation of the new C++0x members because src/fstream-inst.cc is not compiled with -std=c++0x or -std=gnu++0x So the library tells the compiler not to instantiate the templates in your code, promising to provide explicit instantiations, and then fails to provide the explicit instantiations. So the workaround I gave in comment #3 provides them in your program. Another workaround would be to compile with -D_GLIBCXX_EXTERN_TEMPLATE=0, which disables the extern template feature, causing the compiler to implicitly instantiate the templates in every file that needs them, and then rely on the linker to merge the duplicate definitions. But the right fix is just to ensure src/fstream-inst.cc is compiled in C++0x mode, so that the instantiations are present in libstdc++.so and you don't need any workaround. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005
[Bug c++/40997] Wrong address returned in covariant return
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-08-07 12:31 --- Adding this to Bart::InnerBart::getOuter(): cout BaseIf1: (BaseIf*)outer endl; and this to Bar::InnerBar::getVal(): cout BaseIf2: (BaseIf*)bar endl; shows different values for the BaseIf base, which should be unique and unambiguous as it is virtually inherited. BaseIf1: 0x7fff86f73460 BaseIf2: 0x7fff86f73478 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40997
[Bug c++/40997] Wrong address returned in covariant return
--- Comment #4 from jwakely dot gcc at gmail dot com 2009-08-07 12:42 --- Ah, [class.virtual] paragraph 5 says: If the return type of D::f differs from the return type of B::f, the class type in the return type of D::f shall be complete at the point of declaration of D::f or shall be the class type D. The class Bart is not complete at the point of declaration of Bart::InnerBart::getOuter(), which might explain why the pointer adjustment does not happen. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40997
[Bug c++/31423] Improve upon invalid use of member (did you forget the '' ?)
--- Comment #8 from jwakely dot gcc at gmail dot com 2009-08-06 09:51 --- I don't think any of those tests would be made correct simply by replacing 'f' with 'f' Maybe they would have been accepted by GCC 2.95 with the ampersand present, but current GCC correctly requires 'C::f' I know some users want the compiler to suggest how to fix their errors, but it's hard to make a useful suggestion for most of the nearly infinite number of invalid expressions users can come up with. The suggestion is misleading in too many cases (specifically, the did you forget the ''? hint doesn't solve the problem in any of the examples given in this PR.) -- jwakely dot gcc at gmail dot com changed: What|Removed |Added CC||jwakely dot gcc at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31423
[Bug c++/13979] Error message about no matching function for call with derived class arguments could be improved
--- Comment #9 from jwakely dot gcc at gmail dot com 2009-08-05 10:03
---
This example has four slightly different errors:
struct B {};
struct D : B {};
struct X {};
int foo(B*);
int i = foo( (B*)0 );
int j = foo( (D*)0 );
D* pd = 0;
int k = foo( pd );
X* px = 0;
int l = foo( px );
GCC 4.4.1 gives:
pr13979.cc:8:20: error: invalid initialization of non-const reference of type
B* from a temporary of type B*
pr13979.cc:6:5: error: in passing argument 1 of int foo(B*)
pr13979.cc:10:20: error: invalid initialization of non-const reference of type
B* from a temporary of type D*
pr13979.cc:6:5: error: in passing argument 1 of int foo(B*)
pr13979.cc:13:17: error: invalid initialization of reference of type B* from
expression of type D*
pr13979.cc:6:5: error: in passing argument 1 of int foo(B*)
pr13979.cc:16:17: error: invalid initialization of reference of type B* from
expression of type X*
pr13979.cc:6:5: error: in passing argument 1 of int foo(B*)
Comeau gives equivalent errors in all four cases. The only significant
difference is that Comeau doesn't mention the types in the first two errors.
GCC 2.95.2 is quite different:
pr13979.cc:8: initialization of non-const reference type `struct B *'
pr13979.cc:8: from rvalue of type `B *'
pr13979.cc:6: in passing argument 1 of `foo(B *)'
pr13979.cc:10: initializing non-const `B *' with `D *' will use a temporary
pr13979.cc:6: in passing argument 1 of `foo(B *)'
pr13979.cc:13: initializing non-const `B *' with `D *' will use a temporary
pr13979.cc:6: in passing argument 1 of `foo(B *)'
pr13979.cc:16: type `B' is not a base type for type `X'
pr13979.cc:6: in passing argument 1 of `foo(B *)'
I think the current diagnostics are better than the 2.95 ones. As I said
above, will use a temporary is misleading. The fourth error saying is not a
base type may be true, but is also misleading, because it wouldn't compile
even if it was a base type.
As I said earlier, it might be nice if the third error said e.g.
pr13979.cc:13:17: error: invalid initialization of reference of type B* from
expression of type D*
pr13979.cc:6:5: error: in passing argument 1 of int foo(B*)
pr13979.cc:13:17: note: conversion from `D*' to `B*' would create a temporary
However,
(In reply to comment #8)
I don't even know if we have different codepaths for those!
if it's not possible then I think the current diagnostics are reasonable, and
at least as good as Comeau's.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13979
[Bug c++/31423] Improve upon invalid use of member (did you forget the '' ?)
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-08-05 16:40 --- c.f isn't even valid, it should be C::f I didn't check the code, but that message isn't used for member variables or nested types, so if it does only apply to member functions then I think changing '' to '()' unconditionally makes sense. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31423
[Bug c++/40944] [C++0x] rejects well-formed code: SFINAE, decltype, function call
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-08-04 12:35
---
I think you're right that this is a bug, this is a slightly reduced testcase
showing the same error:
templatetypename T
struct make { static T it(); };
void (*pf)(int) = 0;
template typename T
int bar(T const x,
decltype( pf(makeT const::it()) )* = 0 // SFINAE!
) {
return 1;
}
int bar(...) {
return 0;
}
int main() {
return bar(42);
}
I think this should compile and return 0
--
jwakely dot gcc at gmail dot com changed:
What|Removed |Added
CC||jwakely dot gcc at gmail dot
||com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40944
[Bug c++/40942] GCC accepts code that Comeau and MSVC deems invalid.
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-08-04 12:48
---
Testcase can be reduced to:
struct S
{
template typename T
S (T const *)
{ }
template size_t N
S (char const ()[N])
{ }
};
int
main()
{
S s1 (test);
}
GCC still accepts this while Comeau rejects it.
--
jwakely dot gcc at gmail dot com changed:
What|Removed |Added
CC||jwakely dot gcc at gmail dot
||com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40942
[Bug c++/13979] Error message about no matching function for call with derived class arguments could be improved
--- Comment #7 from jwakely dot gcc at gmail dot com 2009-08-04 17:48
---
(In reply to comment #5)
Here's a small testcase:
struct B {};
struct D : B {};
struct S {
int foo(B* taskData);
};
int i = S().foo((D*)0);
-
That tries to initialise a B* with a D* rvalue, which would fail even if D was
the same type as B. This might be a slightly better testcase:
struct B {};
struct D : B {};
struct S {
int foo(B* taskData);
};
D* p = 0;
int i = S().foo(p);
It might be an improvement if GCC gave different diagnostics for the case where
a suitable conversion sequence exists but cannot be used because it would
create an rvalue which cannot bind to a non-const reference, and the case where
there is no suitable conversion (i.e. the types are unrelated)
That seems to be what 2.95 attempted to do by saying initializing 'blah' with
'blah' will use a temporary but I find that message confusing, as it *won't*
use a temporary because doing so is not valid. The message should really have
been something like initializing 'blah' with 'blah' would use a temporary, but
that's not allowed
--
jwakely dot gcc at gmail dot com changed:
What|Removed |Added
CC||jwakely dot gcc at gmail dot
||com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13979
[Bug c++/40901] Access qualifiers of embedded templates are discarded
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-07-29 11:01 --- looks similar to bug 40843 but I'm not sure if it's the same -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40901
[Bug bootstrap/40337] PPLLIBS flags do not include -lm
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-07-28 14:04 --- You didn't say how you configured the build, but you might want to use something like: --with-host-libstdcxx='/usr/local/gcc-4.4/lib/libstdc++.a -lm' as documented at http://gcc.gnu.org/install/configure.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40337
[Bug c++/35989] code rejected in template specialization (4.2 did accept)
--- Comment #4 from jwakely dot gcc at gmail dot com 2009-07-24 10:12
---
(In reply to comment #3)
Simple case :
templatetypename C struct A {};
templatetypename C struct B { struct Inner {}; };
templatetypename K
struct Atypename BK::Inner {};
4.1.2/VS2005 compile quietly. 4.3.2 (g++ -c test.cpp) gives :
kk.cpp:5: error: template parameters not used in partial specialization:
kk.cpp:5: error: K
I think this is invalid because K is used in a non-deduced context
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35989
[Bug c++/35989] code rejected in template specialization (4.2 did accept)
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-07-24 10:29 --- (In reply to comment #4) I think this is invalid because K is used in a non-deduced context Which is the same problem as with the original testcase - this is not a bug in gcc. According to 14.5.4.1 [temp.class.spec.match] paragraph 2 the template arguments of the partial specialisation must be deduced, but in the testcases they appear in non-deduced contexts as defined by 14.8.2.4 [temp.deduct] paragraph 4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35989
[Bug c++/40828] Rejected valid specialization of member class template
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-07-23 14:06
---
The code is invalid. This is allowed:
template
template class T
class Outerint::InnerT {};
but not the other way around. The diagnostic is correct to say enclosing
class templates are not explicitly specialized
See the last specialisation in the example following 14.7.3 [temp.expl.spec]
paragraph 18
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40828
[Bug c++/31397] Useful compiler warning missing (virtual functions in derived classes used without 'virtual')
--- Comment #11 from jwakely dot gcc at gmail dot com 2009-07-21 10:51 --- There is a lot of overlap between this warning and the functionality described by http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2852.html (which will be updated by N2928 in a couple of weeks.) It might make sense to add attributes rather than a -W switch, as that might make it easier to implement the C++0x [[base_check]] and [[override]] attributes. It would also be easier for user code to transition from GNU-style __attribute__((override)) to C++0x-style [[override]] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31397
[Bug c++/20423] Warning -Woverloaded-virtual triggers to often
--- Comment #9 from jwakely dot gcc at gmail dot com 2009-07-21 17:36 --- (In reply to comment #0) This is also not conforming to the specification in http://gcc.gnu.org/ml/gcc-bugs/1999-08n/msg01069.html Warn when a derived class function declaration may be an error in defining a virtual function. In a derived class, the definitions of virtual functions must match the type signature of a virtual function declared in the base class. With this option, the compiler warns when you define a function with the same name as a virtual function, but with a type signature that does not match any declarations from the base class. But that's not what it does. The description in the manual describes the current behaviour correctly, that description above doesn't. (In reply to comment #6) A really wild-guess patch. Comments? ... + /* If at least one method has the same signature, + the not overloaded variants are just + hidden. */ + just_hidden = true; Shouldn't this say not overridden variants ? I don't like the name -Wpartial-overloaded-virtual for the same reason. The name should clearly distinguish whether it is triggered by overloading, overriding or hiding. -Woverloaded-virtual is a reasonable name for the current behaviour; it triggers if there is an overload that hides a virtual (whether the overload is itself virtual or not.) The proposed -Wpartial-overloaded-virtual name makes no sense. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20423
[Bug c++/40793] Error: no matching function for call to XYZ doesn't display function-template-arguments
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-07-21 17:45 --- It tells you the location of the call. If you've specified the template arguments at that location then you can see what they are, I don't see how putting them in the diagnostic will save hours if you could find out the same info in seconds by looking at the line. There's no candidate list because there is no match for the template arguments you used. The empty candidate list tells you something by itself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40793
