--- Comment #4 from jwakely dot gcc at gmail dot com 2007-08-03 23:30
---
re-confirmed with latest 4.3 snapshot:
tests$ ~/gcc/4.x/bin/g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/jwakely/src/gcc-4.3-20070727/configure
--prefix=/home/jwakely/gcc
--- Comment #4 from jwakely dot gcc at gmail dot com 2007-10-02 23:28
---
Created an attachment (id=14287)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14287&action=view)
add example to diagnostic
This adds ", e.g. '(...->*pmf) (...)'" to the
--- Comment #6 from jwakely dot gcc at gmail dot com 2007-10-02 23:54
---
(From update of attachment 14287)
>Index: gcc/cp/typeck.c
>===
>--- gcc/cp/typeck.c(revision 128908)
>+++ gcc/cp/typeck.c(
--- Comment #8 from jwakely dot gcc at gmail dot com 2007-10-02 23:59
---
Yes, it looks better with spaces, thanks.
I think ->* still looks clearer than .* even with the spaces.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23194
--- Comment #10 from jwakely dot gcc at gmail dot com 2007-10-03 00:16
---
Andrew, unfortunately that format fails with -Werror
I'm testing now, but my machine's developed a hardware problem and keeps
segfaulting, which makes it hard to build GCC let alone run the
--- Comment #12 from jwakely dot gcc at gmail dot com 2007-10-03 00:31
---
I'm bootstrapping mainline as of yesterday (r128908) with gcc version 4.1.2
20070626 (Red Hat 4.1.2-13)
The format I tried was:
error ("must use %<.*%> or %<->*%>
--- Comment #7 from jwakely dot gcc at gmail dot com 2008-08-05 19:06
---
(In reply to comment #5)
> Hi again. I have essentially only one substantive comment: can you double
> check
> the implementation is correct vs 20.7.12.2.1/37 ?
I believe the use of std::ref was to m
us: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jwakely dot gcc at gmail dot com
GCC build triplet: sparc-sun-solaris2.10
GCC host triplet: sparc-sun-solaris2.10
GCC target tri
--- Comment #1 from jwakely dot gcc at gmail dot com 2008-08-29 13:11
---
Created an attachment (id=16161)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16161&action=view)
gcc/gtyp-input.list
Here is the generated file with the duplicate entry
--
http://gcc.gnu.org/b
--- Comment #2 from jwakely dot gcc at gmail dot com 2008-08-29 13:36
---
I think this is a regression against 4.2.2 as I have working compilers for
sparc-sun-solaris2.10 and sparc64-sun-solaris2.10 which were both configured
with --with-dwarf2 (although I didn't build them myse
--- Comment #4 from jwakely dot gcc at gmail dot com 2008-09-01 08:39
---
Yes, I realise that, but it's still documented and it was apparently harmless
with 4.2.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37277
Priority: P3
Component: libstdc++
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=37351
--- Comment #9 from jwakely dot gcc at gmail dot com 2008-09-03 15:00
---
I have another patch ready for this, but it doesn't work with unique_ptr
where D is a reference type, due to Bug 37351
e.g. constructing from unique_ptr&> fails to compile
because std::refer
--- Comment #3 from jwakely dot gcc at gmail dot com 2008-09-03 15:04
---
Agreed, the reason I reported this is that it causes problems with my work on
Bug 36962 because std::reference_wrapper uses result_of
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37351
--- Comment #11 from jwakely dot gcc at gmail dot com 2008-09-03 15:08
---
Yes, the problem is with result_of, not my changes to shared_ptr. It will work
with unique_ptr if a type D::result_type exists, so I'll submit the new
patch tonight.
--
http://gcc.gnu.org/bug
--- Comment #12 from jwakely dot gcc at gmail dot com 2008-09-03 23:43
---
Created an attachment (id=16216)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16216&action=view)
updated patch
this replaces tr1_impl/boost_shared_ptr.h with separate files in tr1/ and bits/
as
--- Comment #15 from jwakely dot gcc at gmail dot com 2008-09-04 13:52
---
Sure, I can do that
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36962
--- Comment #17 from jwakely dot gcc at gmail dot com 2008-09-04 21:39
---
Created an attachment (id=16226)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16226&action=view)
new patch
As requested, except I didn't split tr1_impl/boost_sp_counted_base.h
My preference
--- Comment #19 from jwakely dot gcc at gmail dot com 2008-09-04 22:40
---
fixed for 4.4
--
jwakely dot gcc at gmail dot com changed:
What|Removed |Added
--- Comment #5 from jwakely dot gcc at gmail dot com 2008-09-05 10:23
---
this seems pretty easy to fix with decltype and variadic templates, patch
coming soon ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37351
--- Comment #7 from jwakely dot gcc at gmail dot com 2008-09-08 10:36
---
I've got result_of working but am also fixing up reference_wrapper and
__invoke() to forward correctly using rvalue-references.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37351
--- Comment #6 from jwakely dot gcc at gmail dot com 2008-11-01 16:18
---
This is a compile-time test which should fail because undef cannot be
instantiated, but the deallocation function is not used.
#include
template class undef;
struct A {
A() { throw 1; }
};
template class
--- Comment #9 from jwakely dot gcc at gmail dot com 2008-11-05 01:09
---
Created an attachment (id=16625)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16625&action=view)
update result_of and reference_wrapper
In the current draft, reference_wrapper invocation requires C
--- Comment #9 from jwakely dot gcc at gmail dot com 2008-11-05 01:12
---
I've added a patch in bug 24803, comment 9
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37351
--- Comment #11 from jwakely dot gcc at gmail dot com 2008-11-05 02:08
---
Fixed for 4.4
--
jwakely dot gcc at gmail dot com changed:
What|Removed |Added
--- Comment #14 from jwakely dot gcc at gmail dot com 2008-11-05 02:54
---
the problem is due to bug 35569 - I'll have to revert my patch until I can fix
that properly
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24803
--- Comment #4 from jwakely dot gcc at gmail dot com 2008-03-08 13:41
---
(In reply to comment #2)
> Finding this spot,
> however, is the sole purpose of offering the debug mode libstdc++.
I agree with every word of Wolfgang's, but this is the key point.
User code would
--- Comment #2 from jwakely dot gcc at gmail dot com 2008-03-08 15:25
---
(In reply to comment #0)
> // 1
> #include
>
> typedef int value_type;
>
> // void argument type
> template class std::unary_function;
eurgh, even more of an abomination than int f(v
--- Comment #7 from jwakely dot gcc at gmail dot com 2008-03-09 15:51
---
Created an attachment (id=15284)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15284&action=view)
make nested iterator typedefs private in debug mode
It's "accepts implementation-defi
--- Comment #8 from jwakely dot gcc at gmail dot com 2008-03-09 15:52
---
Created an attachment (id=15285)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15285&action=view)
new test
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247
assume with 4.4 too.
--
Summary: Parse error in when user declares template-name
c
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned a
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-03-09 14:25
---
(In reply to comment #2)
> FWIW, if I use v3 together with the Intel C++ compiler, it builds...
>
That's interesting, Comeau's online compiler gives a very similar error to gcc
4.3.2
--
ht
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-03-09 15:19
---
Well, the as-if rule allows (x.c < ((y.c)) too of course.
I could be wrong and the compiler should parse it ok, I haven't thought about
it very hard.
The same problem occurs here, although it&#
--- Comment #6 from jwakely dot gcc at gmail dot com 2009-03-09 15:20
---
(In reply to comment #5)
> Well, the as-if rule allows (x.c < ((y.c)) too of course.
bah - it would allow it if I could type the right number of closing
parentheses!
--
http://gcc.gnu.org/bu
--- Comment #10 from jwakely dot gcc at gmail dot com 2009-03-09 16:08
---
reduced:
template struct x;
template struct y { int x; };
template
bool operator<(const y& l, const y& r) { return l.x < r.x; }
It doesn't happen except in a template context, so it
--- Comment #14 from jwakely dot gcc at gmail dot com 2009-03-09 18:13
---
aha, on PR 11814 you mention PR 20308 which is the same.
Thanks, Andrew!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-03-11 14:29
---
Created an attachment (id=17438)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17438&action=view)
remove support for other compilers
this patch re-implements the parallel mode's atomic operati
--- Comment #7 from jwakely dot gcc at gmail dot com 2009-04-07 14:45
---
I think you have the syntax wrong, if you want to know the return type of a
function type (or function pointer, or function reference) you need to say:
result_of::type
what you probably want is:
typedef
--- Comment #9 from jwakely dot gcc at gmail dot com 2009-04-07 14:51
---
This is not a bug in C++0x either. The spec is:
Given an rvalue fn of type Fn and values t1, t2, ..., tN of types T1, T2, ...,
TN in ArgTypes, respectively,
the type member is the result type of the expression
--- Comment #12 from jwakely dot gcc at gmail dot com 2009-04-07 15:40
---
See what I wrote at http://gcc.gnu.org/ml/libstdc++/2008-09/msg00124.html under
point 3)
You want this:
typename std::result_of< decltype(&traits::restore) (S*) >::type
Paolo, let's close thi
--- Comment #13 from jwakely dot gcc at gmail dot com 2009-04-07 15:42
---
(In reply to comment #12)
> typename std::result_of< decltype(&traits::restore) (S*) >::type
Oops, that should be S& not S*
It's not perfect, but for this case std::result_of works if yo
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jwakely dot gcc at gmail dot com
http://gcc.gnu.org/bugzilla/sh
--- Comment #2 from jwakely dot gcc at gmail dot com 2009-04-26 17:40
---
Created an attachment (id=17707)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17707&action=view)
fix call_once without breaking ABI
Fix call_once to not use the global lock object, but retain the
--- Comment #4 from jwakely dot gcc at gmail dot com 2009-04-26 18:06
---
Created an attachment (id=17709)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17709&action=view)
use GLIBCXX_3.4.12 version for new symbols
same patch again, with the new symbols using a new vers
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-04-26 21:39
---
(In reply to comment #4)
> same patch again, with the new symbols using a new version and testsuite
> changes included
passes all regression tests both with and without tls
--
http://gcc.gnu.org/bu
tus: 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=40007
--- Comment #7 from jwakely dot gcc at gmail dot com 2007-06-18 01:36
---
Confirmed on x86-linux, sparc-solaris and ppc-AIX so I've removed the Target.
Also verified that valgrind shows the uninitialised memory reads.
This bug breaks common idioms like:
template
s
--- Comment #2 from jwakely dot gcc at gmail dot com 2007-07-09 10:30
---
I'm seeing the same with this configuration:
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: $SRCS/gcc/gcc-4.1.1/configure --prefix=$DEST/gcc/4.1.1-64bit
--with-gnu-as --with-as=$DEST/bin
--- Comment #3 from jwakely dot gcc at gmail dot com 2007-07-09 10:35
---
In reply to comment #2:
actually, the sparc64-sun-solaris2.8 problem could be slightly different and I
can't confirm it now
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32415
--- 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:
--- 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?
>
Ye
--- 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 resol
--- 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. GC
--- Comment #16 from jwakely dot gcc at gmail dot com 2010-02-08 15:10
---
(In reply to comment #15)
> Destroying an object from a base class pointer whose destructor is not virtual
> is an undefined behaviour according to the standard. I tend to think that
> silently rem
--- 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 nam
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
n: 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
--- 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
--- 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
--- 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
> effec
--- 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 , for
> example.
I haven't looked into it, but the problem in array could be bug 41449
--
http://
--- 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 syst
--- 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 restric
--- 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.c
--- 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
--- 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
--- 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
--
--- 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
--- 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.
--- 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
--- 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 Octob
--- 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 r
--- 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
--- 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 p
--- 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!
--- 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
--- 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
--- 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
--- 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 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
--- 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 define
--- 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
> nex
--- 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
--- 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
--- 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(_A
--- 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
to this:
return async<_Fn, _Args...>(launch::any, std::forward<_Fn>(__fn),
The pro
--- 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
> i
--- 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...
--- 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
--- 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?
template
T foo() { return T(); }
int main()
{
&foo;
}
That example can be made valid like so:
int (*pf)() = &foo;
Which demo
--- 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://g
--- 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
--- 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
--- 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
--- 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
--- 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.c
101 - 200 of 231 matches
Mail list logo
