--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
;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 #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&#
--- 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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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-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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
--- Comment #8 from jwakely dot gcc at gmail dot com 2009-08-12 08:55
---
Created an attachment (id=18344)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18344&action=view)
compile fstream-inst.cc as c++0x to instantiate new members
i'm testing this patch
--- Comment #7 from jwakely dot gcc at gmail dot com 2009-08-11 23:02
---
This patch (and running autoreconf) fixes the problem, but I'm still trying to
work out the right changes to the linker script so that the new symbols are
versioned as GLIBCXX_3.4.13 not GLIBCXX_3.4
Index
--- 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 p
--- 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
--- 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 i
--- 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/gc
--- 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 func
--- 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
--- 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
--- 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
--- 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
>
--- 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 &#
--- 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
--- Comment #6 from jwakely dot gcc at gmail dot com 2009-08-07 12:59
---
(In reply to comment #4)
> 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
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-08-07 12:47
---
Moving the definition of InnerBart outside the body of Bart (which requires
making Bart::createInner non-covariant) allows the assertion to pass, the
addresses are all correct. So I believe this program is
--- 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
--- 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 << "B
--- Comment #2 from jwakely dot gcc at gmail dot com 2009-08-07 12:26
---
The line before the assertion shows the address of the 'Bar' subobject, which
is not the same value as previously given for that subobject (on the 2nd and
5th lines of output.)
Like the reporter, I ex
--- 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
--- 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
--- 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 =
--- 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);
>
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-08-04 12:48
---
Testcase can be reduced to:
struct S
{
template
S (T const *)
{ }
template
S (char const (&)[N])
{ }
};
int
main()
{
S s1 ("test");
}
GCC still accepts this while Com
--- 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:
template
struct make { static T&& it(); };
void (*pf)(int&) = 0;
template< typename T
--- 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
--- 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
1 - 100 of 231 matches
Mail list logo
