--- 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 ide
--- 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 ch
--- 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
--- 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_cast(ptr
--- Comment #4 from jwakely dot gcc at gmail dot com 2010-02-01 17:22
---
there is this comparison function:
template
bool operator!=(const unique_ptr& x, const unique_ptr& y);
What should T2 and D2 be deduced as, in the conversion from nullptr_t to
unique_ptr ?
Or to put it
--- 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_ptr::pointer to nul
--- 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 whi
--- 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&#
;0>();
^
"ComeauTest.c", line 6: error: invalid explicit instantiation declaration
template void g<0>();
^
--
Summary: bad error recovery for explicit template instantiation
in wrong namespace
Product: gcc
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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.c
--- 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=20817&action=view)
better -Wmeminit patch
This version ignores empty classes and checks for a nontrivial default ctor
--- 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
--- 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 or
http://www.dealii.org/developer/doxygen/deal.II/block__vector_8h
--- 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
--- Comment #3 from jwakely dot gcc at gmail dot com 2007-11-06 14:34
---
Some related discussion:
http://gcc.gnu.org/ml/libstdc++/2007-10/msg00180.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24347
--- Comment #13 from jwakely dot gcc at gmail dot com 2007-11-14 13:27
---
(In reply to comment #10)
>
> I do not have access to std::basic_ios from MyStream. Solution here?
Yes you do. The warning can be prevented by initialising the virtual base:
MyStream() : std::ios(
--- Comment #7 from jwakely dot gcc at gmail dot com 2007-11-14 13:38
---
Isn't this warning simply bogus? In other contexts if a default constructor is
available it will be used without warning, whether explicitly used or not.
e.g.
non-virtual bases in constructor initializer
--- Comment #4 from jwakely dot gcc at gmail dot com 2007-12-17 22:14
---
Between http://gcc.gnu.org/onlinedocs/libstdc++/20_util/shared_ptr.html
and http://gcc.gnu.org/onlinedocs/libstdc++/ext/concurrence.html and the
shared_ptr code, which has been simplified and commented, I think
--- Comment #7 from jwakely dot gcc at gmail dot com 2008-06-16 11:12
---
This has now been broken for at least 3 releases and is going to stay broken in
4.4 at this rate. Could a build maintainer comment on Richard's analysis in bug
35248? CCing Paolo again.
--
jwakely dot g
--- Comment #14 from jwakely dot gcc at gmail dot com 2008-06-24 20:46
---
Fixed for 4.4
--
jwakely dot gcc at gmail dot com changed:
What|Removed |Added
--- Comment #3 from jwakely dot gcc at gmail dot com 2008-07-28 20:27
---
(In reply to comment #2)
> Jonathan, can you have a look? If you can confirm the issue, is it just matter
> of adding a call to __enable_shared_from_this_helper(_M_refcount, _M_ptr,
> _M_ptr) to __s
--- Comment #1 from jwakely dot gcc at gmail dot com 2008-07-29 19:24
---
I will try to look at it next week some time, but don't have much spare time in
the near future, so don't hold your breath for me to do it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36962
--- Comment #3 from jwakely dot gcc at gmail dot com 2008-07-30 21:27
---
Created an attachment (id=15979)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15979&action=view)
unique_ptr and rvalue-reference updates from WP
I'm going to be offline until next week so h
201 - 231 of 231 matches
Mail list logo
