--- 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
--- 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 #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
--- 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
--- 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
--- 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 #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'm fairly sure that's not valid
--- 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
--- 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
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
--- 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 #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
::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
--- 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 #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
--- 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
--- 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 #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
--- 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-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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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 #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
--- 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 #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
--- 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
--- 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(_Args...)::type` in future
--- 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
--- 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
--- 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
--- 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?
templateclass T
T foo() { return T(); }
int main()
{
foo;
}
That example can be made valid like so:
int (*pf)() = foo;
Which demonstrates
--- 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
--- 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
--- 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 #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
--- 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
--- 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
--- 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 reflector byme, Stephan T
--- 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
--- 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 #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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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 #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
--- 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
effect. I seem to be under the impression
--- 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 #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 #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
--- 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
--- 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
--- 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
--- 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 #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 #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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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/configure.html
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
1 - 100 of 218 matches
Mail list logo
