--- Comment #4 from redi at gcc dot gnu dot org 2009-12-08 09:50 ---
(In reply to comment #3)
(In reply to comment #2)
and i don't want to write lots of const int AN::i...
You have to, your code is not valid if you use A::i in the program but it has
no definition
--- Comment #4 from redi at gcc dot gnu dot org 2009-12-08 09:57 ---
What's wrong with
class baz : protected freeListbar, baz {
voidfrob() {}
friend class freeListbar, baz;
};
or
class baz : protected freeListbar, baz {
voidfrob() {}
templatetypename
--- Comment #13 from redi at gcc dot gnu dot org 2009-12-08 10:48 ---
(In reply to comment #12)
The situation will be different with the upcoming C++1x standard where there
is null_ptr.
Yes, very different. Per the accepted language defect and paper I cited here
yesterday
--- Comment #5 from redi at gcc dot gnu dot org 2009-12-08 11:21 ---
'typename X::T*' is a non-deduced context, so should not be involved in
argument deduction, and 0 is a valid null pointer constant
*** This bug has been marked as a duplicate of 23055 ***
--
redi at gcc dot gnu
--- Comment #5 from redi at gcc dot gnu dot org 2009-12-08 11:21 ---
*** Bug 29577 has been marked as a duplicate of this bug. ***
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from redi at gcc dot gnu dot org 2009-12-08 12:23 ---
(In reply to comment #5)
templateint N const AN::i;
I tried so, but it seems do not work, could you please explain more
detailedly?
thx~
I missed the int out:
templateint N const int AN::i;
--
http
--- Comment #1 from redi at gcc dot gnu dot org 2009-12-08 20:21 ---
There's been an XFAIL about this in g++.old-deja/g++.jason/cond.C for ages, but
it doesn't test the switch case.
Self-contained testcase:
void f() {
if (int foo = 0)
int foo = 1;
switch (int foo = 0
--- Comment #1 from redi at gcc dot gnu dot org 2009-12-08 20:32 ---
reduced:
void f() {
unsigned short i = 0;
void* p = (void*)i;
}
this warns in 32-bit or 64-bit mode using the C compiler, and is controlled by
this option that g++ doesn't support:
-Wno-int-to-pointer-cast (C
--- Comment #1 from redi at gcc dot gnu dot org 2009-12-08 20:45 ---
diagnosing this would be useful and shouldn't require instantiation, it should
be detectable during phase 1
reduced:
struct foo {
templatetypename T foo(int);
};
--
redi at gcc dot gnu dot org changed
--- Comment #5 from redi at gcc dot gnu dot org 2009-12-08 21:06 ---
Assuming that's an accurate reduction of the original code, comment 4 is
correct. I didn't look at the preprocessed source, it includes Boost code that
will be very specific to the GCC 4.0.2 version it was compiled
--- Comment #3 from redi at gcc dot gnu dot org 2009-12-08 21:30 ---
(In reply to comment #2)
I am not sure this is such a good idea. A casting typically means I want to
really do this. GCC normally suppress warnings when casting is added. A
warning when you assign when enum type
--- Comment #4 from redi at gcc dot gnu dot org 2009-12-08 21:58 ---
In resolving dependent names, names from the following sources are considered:
Declarations that are visible at the point of de#64257;nition of the
template.
Declarations from namespaces associated with the types
--- Comment #2 from redi at gcc dot gnu dot org 2009-12-08 22:28 ---
C::dflt has type const int by pd-d[i] has type int, so they do not have the
same type and the warning is correct. This is DR 587 which was just changed in
the latest draft
http://www.open-std.org/jtc1/sc22/wg21/docs
--- Comment #1 from redi at gcc dot gnu dot org 2009-12-08 23:11 ---
Confirmed, the friend declaration appears to be declaring f in namespace A,
despite the :: qualifier
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from redi at gcc dot gnu dot org 2009-12-08 23:29 ---
(In reply to comment #0)
Could the warning message below be revised to include a warning that NULL will
evaluate to false or zero?
What else would it evaluate to?
N.B. with recent versions of GCC -Wconversion
--- Comment #2 from redi at gcc dot gnu dot org 2009-12-08 23:54 ---
[temp.class.spec]/1
A partial specialization shall be declared before the #64257;rst use of a
class template specialization that would make use of the partial specialization
as the result of an implicit or explicit
--- Comment #1 from redi at gcc dot gnu dot org 2009-12-07 11:02 ---
GCC 4.4.2 rejects this
tt.cc: In function 'int main(int, char**)':
tt.cc:3: error: 'A::A()' is private
tt.cc:7: error: within this context
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42302
--- Comment #2 from redi at gcc dot gnu dot org 2009-12-07 15:11 ---
(In reply to comment #1)
I'm wondering if this is not an application of the name hiding rule described
in the IEC 14882:1998 (3.3.7) that says here that the class name T::X is
hidden
by the object static int T::X
--- Comment #2 from redi at gcc dot gnu dot org 2009-12-04 09:48 ---
SMARTA a();
This does not declare an object of type SMARTA, it declares a function called
'a' which returns SMARTA
You need to change that to:
SMARTA a;
or
SMARTA a = SMARTA();
--
redi at gcc dot gnu dot org
--- Comment #2 from redi at gcc dot gnu dot org 2009-12-04 10:54 ---
the suggested change is correct
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42273
--- Comment #3 from redi at gcc dot gnu dot org 2009-12-04 11:00 ---
Although as I noted in Bug 40297 comment 2 I think that function should also
have a memory barrier when m == memory_order_release, which the current code
has by accident because of this bug ... so arguably it's better
--- Comment #4 from redi at gcc dot gnu dot org 2009-12-04 17:31 ---
(In reply to comment #3)
the pb is on line :
template typename X , typename XT2 =T , typename X2 = typename XT2 ::
X SMART(SMARTX value) : data(value.CastUp) {} ;
I don't understand, that line did not appear
--- Comment #5 from redi at gcc dot gnu dot org 2009-12-04 18:46 ---
will do
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
CC
--- Comment #1 from redi at gcc dot gnu dot org 2009-12-03 11:34 ---
(In reply to comment #0)
This leads to an infinite recursion between these two methods:
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// 438. Ambiguity in the do the right thing clause
templateclass _Integer
--- Comment #1 from redi at gcc dot gnu dot org 2009-12-02 12:06 ---
Use -ftime-report and -time to see what step is taking a long time, and compare
that the times on the old system
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42252
--- Comment #1 from redi at gcc dot gnu dot org 2009-12-01 18:21 ---
this is caused by the default argument to resize:
void
resize(size_type __new_size, value_type __x = value_type());
It would be possible to avoid the default construction by replacing that member
with two overloads
--- Comment #2 from redi at gcc dot gnu dot org 2009-12-01 18:30 ---
On second thoughts, it might be necessary to split it into two overloads for
C++1x, because this should work:
#include vector
struct moveable {
explicit moveable(int) { }
moveable(const moveable) = delete
--- Comment #5 from redi at gcc dot gnu dot org 2009-12-01 18:37 ---
(In reply to comment #2)
On second thoughts, it might be necessary to split it into two overloads for
C++1x, because this should work:
Gah, ignore that, I'm talking rubbish and that shouldn't work
Andrew
--- Comment #7 from redi at gcc dot gnu dot org 2009-12-01 18:54 ---
Yes, it would be an ABI change, although that symbol isn't exported from the
library.
vector::resize() was changed from one function to two in the n2284 draft, as a
result of n1858, the rationale is the same
--- Comment #3 from redi at gcc dot gnu dot org 2009-11-30 10:38 ---
(In reply to comment #2)
The issue is pretty simple, actually: std::unique_future (which, by the way,
will be renamed just std::future), is missing move assignment operator. Note,
in N2914 it does *not* exist, has
--- Comment #13 from redi at gcc dot gnu dot org 2009-11-30 16:46 ---
(In reply to comment #12)
Compile-time.
configure with --enable-checking=release to turn off checks that are enabled by
default in pre-release builds, that will give a better comparison between the
4.4.2 release
--- Comment #1 from redi at gcc dot gnu dot org 2009-11-27 10:04 ---
I think this change is intentional, as per the resolutions to
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#696
and
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#23
--
http
--- Comment #3 from redi at gcc dot gnu dot org 2009-11-27 10:46 ---
Paolo, should int x also be set to zero?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42191
--- Comment #1 from redi at gcc dot gnu dot org 2009-11-27 18:31 ---
(In reply to comment #0)
Perhaps -pthread should be implied by -std=c++0x/-std=gnu++0x? (Except at
least
nominally one could use std::thread with DCE or Solaris threads, so is
-pthread
right anyway?)
-pthread
--- Comment #7 from redi at gcc dot gnu dot org 2009-11-23 14:53 ---
(In reply to comment #6)
OK, can't argue with not breaking existing headers I suppose. But this is to
me clearly a bogus usage. What are the semantics of using internal zero sized
arrays in a struct? They have
--- Comment #6 from redi at gcc dot gnu dot org 2009-11-22 13:16 ---
Thanks for the quick answer, I'll find another way to do this then...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42132
--- Comment #7 from redi at gcc dot gnu dot org 2009-11-22 15:19 ---
In std::bind() the call function would be a template function, so argument
deduction is done and SFINAE applies. Changing my testcase to use template
functions gives a different error:
#include utility
using std
--- Comment #9 from redi at gcc dot gnu dot org 2009-11-22 17:32 ---
I'll try that now. Something like:
templatetypename F
struct Bind
{
F func;
templatetypename... Arg, typename SfinaeT = decltype( declvalF()
(declvalArg()...) )
typename result_ofF(Arg...)::type
call
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: redi at gcc dot gnu dot org
OtherBugsDependingO 35569
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42132
--- Comment #1 from redi at gcc dot gnu dot org 2009-11-20 18:09 ---
Looks like this is for compatibility with GNU C, which allows it, but only in
the form char b[0] not char b[]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42121
--- Comment #3 from redi at gcc dot gnu dot org 2009-11-20 18:49 ---
(In reply to comment #2)
In standard C, a size 0 array is forbidden, at least in C99 doc I have handy,
Yes, but it's a long-standing GNU extension:
http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Zero-Length.html#Zero
--- Comment #3 from redi at gcc dot gnu dot org 2009-11-20 21:23 ---
Subject: Bug 42019
Author: redi
Date: Fri Nov 20 21:23:02 2009
New Revision: 154377
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154377
Log:
2009-11-20 Jonathan Wakely jwakely@gmail.com
PR
--- Comment #4 from redi at gcc dot gnu dot org 2009-11-20 21:26 ---
Fixed for 4.5.0
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #4 from redi at gcc dot gnu dot org 2009-11-18 18:47 ---
(In reply to comment #3)
you tell me when they plan to release a stable version of a C++1x compiler ?
After the C++1x standard is finished, which might be next year, or might not.
I don't know of any compiler
--- Comment #3 from redi at gcc dot gnu dot org 2009-11-17 10:01 ---
Also, please note that n2960 is not a standard, it's only a draft, and it's not
even the latest draft.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42063
--- Comment #2 from redi at gcc dot gnu dot org 2009-11-18 01:30 ---
Created an attachment (id=19031)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19031action=view)
proposed patch
I'm testing this, with and without -fno-rtti
Without rtti 20_util/shared_ptr/cons
--- Comment #1 from redi at gcc dot gnu dot org 2009-11-13 10:03 ---
Can you be more specific?
Ordinary unqualified lookup finds ::g and lookup in the associated namespace
finds NS::g, the latter is a better match for the arguments.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #3 from redi at gcc dot gnu dot org 2009-11-13 10:24 ---
Ah yes, this is DR 239
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#239
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from redi at gcc dot gnu dot org 2009-11-13 10:59 ---
A::B should have external linkage according to [basic.link] but the definition
of A::B::foo() is a local symbol:
$ nm A.o
t _ZN1A1B3fooEv
U __gxx_personality_v0
--
redi at gcc dot
--- Comment #1 from redi at gcc dot gnu dot org 2009-11-12 13:24 ---
It should fail to compile because you are specializing a template which was
never declared, not because it is ambiguous.
namespace {
template
void fooint(void) { return; }
}
That is a specialization
--- Comment #2 from redi at gcc dot gnu dot org 2009-11-12 13:28 ---
This fails:
templatetypename
void foo(void);
template
void fooint(void);
namespace {
template
void fooint(void) { return; }
}
int main(int, char **) { fooint(); }
ttt.cc:6: error: specialization
--- Comment #1 from redi at gcc dot gnu dot org 2009-11-12 17:03 ---
Seems like a reasonable request, it will disable at least the get_deleter()
functionality. I'll work on this when I update shared_ptr to match the latest
WP
--
redi at gcc dot gnu dot org changed:
What
--- Comment #1 from redi at gcc dot gnu dot org 2009-11-11 11:50 ---
It would certainly be nice to get warnings about members that are not
initialized in the constructor, I don't think GCC currently does that anywhere.
If you add -O then you will get a warning for the use of the member
--- Comment #10 from redi at gcc dot gnu dot org 2009-11-11 14:05 ---
Sorry for the lack of progress, I'll take another crack at it this week and
report back on what I've got and what doesn't work. If I can't finish it I'll
say so and unassign myself from this PR
--
http
--- Comment #1 from redi at gcc dot gnu dot org 2009-11-09 12:01 ---
probably related to PR 23885 and/or PR 16635
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41995
--- Comment #2 from redi at gcc dot gnu dot org 2009-11-06 08:38 ---
Subject: Bug 41949
Author: redi
Date: Fri Nov 6 08:38:02 2009
New Revision: 153961
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153961
Log:
2009-11-06 Jonathan Wakely jwakely@gmail.com
PR
--- Comment #3 from redi at gcc dot gnu dot org 2009-11-06 08:48 ---
Fixed for 4.5.0
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #9 from redi at gcc dot gnu dot org 2009-11-04 14:41 ---
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#653
and
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#683
and
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2762
I'm still
--- Comment #10 from redi at gcc dot gnu dot org 2009-11-04 15:28 ---
To be clear: In C++0x struct A would have a deleted copy assign operator, and
union U would be allowed, but its copy assignment operator would be deleted.
IMHO C++03 is not clear whether struct A has a trivial
--- Comment #3 from redi at gcc dot gnu dot org 2009-11-03 13:32 ---
(In reply to comment #2)
Is there a sane workaround for this?
Don't use 'const' members of unions.
Union members cannot have a non-trivial copy assignment operator.
The assignment operator for A cannot
--- Comment #5 from redi at gcc dot gnu dot org 2009-11-03 14:21 ---
(In reply to comment #4)
I'm not sure whether using A in a union causes the implicitly-declared copy
assignment operator to be implicitly defined, but that seems to be what's
happening.
No, that's not quite
--- Comment #8 from redi at gcc dot gnu dot org 2009-11-03 18:10 ---
(In reply to comment #6)
The ARM comment (as quoted) is clearly wrong: offhand, I can think of
two other ways of getting an object initialized. There are probably
more.
1. Casting the offending const away
--- Comment #4 from redi at gcc dot gnu dot org 2009-10-30 12:14 ---
(In reply to comment #2)
Isn't ::foo the using'd class from name?
No, see 7.3.1.2 [namespace.memdef]/3 - an unqualified friend declaration refers
to a member of the innermost enclosing namespace. Names brought
--- Comment #5 from redi at gcc dot gnu dot org 2009-10-30 12:15 ---
(In reply to comment #3)
I think it is a bug, because the class test is declared at the scope ::
A friend declaration specifies a class that belongs to the innermost enclosing
namespace scope, outer scopes
--- Comment #2 from redi at gcc dot gnu dot org 2009-10-16 11:42 ---
This looks very similar to bug 41038, but still fails with 4.4.2
N.B. you don't need the friend declaration at all, nested types can access all
members of their enclosing class (this was changed by DR45)
--
http
--- Comment #1 from redi at gcc dot gnu dot org 2009-10-14 09:10 ---
Slightly reduced:
template typename T, int (T::*)() const
struct TSizeEnabler
{
typedef T TClass;
};
template typename X
int
GetAllSize(const X Var)
{ return sizeof(Var); }
template typename X
int
GetAllSize
--- Comment #6 from redi at gcc dot gnu dot org 2009-10-13 11:02 ---
Or see http://gcc.gnu.org/gcc-3.4/changes.html#cplusplus
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41690
--- Comment #1 from redi at gcc dot gnu dot org 2009-10-08 09:42 ---
set::insert never invalidates iterators, so that's not a good example.
set::erase invalidates iterators pointing to erased elements, but debug mode
already catches that.
One problem I see with this request
--- Comment #2 from redi at gcc dot gnu dot org 2009-10-08 09:43 ---
(In reply to comment #1)
std::setint::iterator i = s.insert(5);
Oops, that should be
std::setint::iterator i = s.insert(5).first;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41628
--- Comment #1 from redi at gcc dot gnu dot org 2009-10-07 08:46 ---
The code is not valid, you need to change the line with the error to:
dbLeft.template detectFileChange3();
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from redi at gcc dot gnu dot org 2009-10-07 09:48 ---
(In reply to comment #2)
Thanks for the fast reply! I had tried compilation with VC++ 2008 and there it
worked, so I thought it would be valid.
You should be wary of using VC++ to determine if code is valid, it's
--- Comment #2 from redi at gcc dot gnu dot org 2009-10-07 16:07 ---
(In reply to comment #1)
but I am fairly sure I've done the wrong thing to the linker script
(gnu.ver); I don't really understand the linker script, so it was rather
monkey-see-monkey-do.
I think the commented out
--- Comment #1 from redi at gcc dot gnu dot org 2009-10-05 10:28 ---
Access checking happens after overload resolution.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41575
--- Comment #1 from redi at gcc dot gnu dot org 2009-10-05 10:34 ---
The code should not compile, swapping of rvalues is no longer supported in the
C++0x draft.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41568
--- Comment #14 from redi at gcc dot gnu dot org 2009-10-05 11:30 ---
*** Bug 41333 has been marked as a duplicate of this bug. ***
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from redi at gcc dot gnu dot org 2009-10-05 11:30 ---
(In reply to comment #8)
I have got the issue. The problem is not sed but rather the pattern being
searched from ld --version
My ld --version returns
GNU ld (GNU Binutils)2.18
Where the pattern looked
--- Comment #4 from redi at gcc dot gnu dot org 2009-10-05 14:58 ---
14.3.1 [temp.arg.type] paragraph 2 in the current C++ standard says:
A type without linkage (3.5) shall not be used as a template argument for a
template type parameter.
This is changing for C++0x, based
--- Comment #5 from redi at gcc dot gnu dot org 2009-10-05 17:59 ---
(In reply to comment #4)
Could you elaborate? Did you mean a wrong tar for creating a tarball?
No, he said untar.
I just downloaded the file from that mirror and it matches its md5 sum,
extracts without errors
--- Comment #5 from redi at gcc dot gnu dot org 2009-09-11 09:35 ---
Does the GCC you built for Solaris 10 have symbol versioning enabled? You can
check this by looking in the libstdc++-v3/config.log or by running:
nm /path/to/gcc/lib/libstdc++.so | fgrep @GLIBCXX
If that produces
--- Comment #7 from redi at gcc dot gnu dot org 2009-09-11 15:20 ---
(In reply to comment #6)
configure:114866: WARNING: === Linker version 1800 is too old for
configure:114868: WARNING: === full symbol versioning support in this release
of GCC.
configure:114870: WARNING: === You
--- Comment #7 from redi at gcc dot gnu dot org 2009-09-08 16:00 ---
(In reply to comment #6)
Could you please find from you env where is the file conftest.c and how is
that
generated?
It's created by the configure script, config.log shows the content of the file,
following text
--- Comment #1 from redi at gcc dot gnu dot org 2009-09-03 11:16 ---
You didn't say how you configured it.
As with bug 40950, you might need --enable-stage1-languages=c,c++
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41234
--- Comment #1 from redi at gcc dot gnu dot org 2009-09-03 11:27 ---
*** This bug has been marked as a duplicate of 40664 ***
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from redi at gcc dot gnu dot org 2009-09-03 11:27 ---
*** Bug 41231 has been marked as a duplicate of this bug. ***
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from redi at gcc dot gnu dot org 2009-09-03 11:35 ---
Your testcase works for me.
Please see http://gcc.gnu.org/bugs.html for the information you need to
provide, specifically you haven't said how you configured gcc or what command
you're using to compile the testcase
--- Comment #2 from redi at gcc dot gnu dot org 2009-08-28 10:19 ---
(In reply to comment #0)
#gcc
cd ../gcc-4.4.1
./configure
--prefix=/home/dmarkman/Development/GCC/macintel64/mpfr-2.4.1/build
--with-gmp=/home/dmarkman/Development/GCC/macintel64/gmp-4.3.1/build
is that command
--- Comment #3 from redi at gcc dot gnu dot org 2009-08-28 10:23 ---
Changing component, nothing to do with c++ front end
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from redi at gcc dot gnu dot org 2009-08-28 15:01 ---
it should be --build, not -build
as stated at http://gcc.gnu.org/install/configure.html do NOT build in the
source directory, create a new directory to build in and run $SRCDIR/configure
instead of ./configure
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c++ |libstdc++
Ever
--- Comment #7 from redi at gcc dot gnu dot org 2009-08-27 11:37 ---
(In reply to comment #6)
Is this related to PR 37477?
It looks like a slightly different issue. PR 37477 relates to when
uncaught_exception() stops being true and fixing it might need to wait for the
resolution
--- Comment #9 from redi at gcc dot gnu dot org 2009-08-27 12:18 ---
(In reply to comment #5)
I think the problem is that the uncaught_exception() is true as soon as the
memory for the exception has been allocated, but if the exception's copy
constructor is elided then happens before
--- Comment #11 from redi at gcc dot gnu dot org 2009-08-27 15:19 ---
(In reply to comment #10)
I'm not sure that this applies in this situation. An instance of BadE is
constructed because it is thrown, but BadE::BadE does not [exit] via an
uncaught exception. It both throws
--- Comment #2 from redi at gcc dot gnu dot org 2009-08-26 14:43 ---
IIUC, the top-level const qualifier on const typename FooD::double3 in the
primary template applies to the type, which is not known during phase 1
At instantiation time, double3 is known to be an array type, so decays
--- Comment #3 from redi at gcc dot gnu dot org 2009-08-26 14:51 ---
(In reply to comment #2)
IIUC, the top-level const qualifier on const typename FooD::double3 in the
primary template applies to the type, which is not known during phase 1
i.e. it's equivalent to typename FooD
--- Comment #1 from redi at gcc dot gnu dot org 2009-08-26 15:31 ---
Reduced:
#include cassert
#include exception
struct GoodE {
GoodE()
{
try {
throw 1;
} catch (...) {
}
}
};
struct BadE {
BadE()
try {
throw 1
--- Comment #2 from redi at gcc dot gnu dot org 2009-08-26 15:52 ---
It looks as though uncaught_exception() does not always become false when
entering the handler of a function-try-block, and this causes it to stay true.
Maybe the count of uncaught exceptions is not decremented
--- Comment #3 from redi at gcc dot gnu dot org 2009-08-26 16:01 ---
(In reply to comment #2)
at the end of the handler, causing it to be one more than it should not be.
Oops, obviously I meant one more than it should be
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174
--- Comment #4 from redi at gcc dot gnu dot org 2009-08-26 16:17 ---
(In reply to comment #1)
Note that GoodE doesn't cause the problem. The difference is that BadE has a
function-try-block
And, of course, that the exception is rethrown by BadE at the end of the
handler. Changing
--- Comment #5 from redi at gcc dot gnu dot org 2009-08-26 16:50 ---
I think the problem is that the uncaught_exception() is true as soon as the
memory for the exception has been allocated, but if the exception's copy
constructor is elided then happens before entering the exception's
--- Comment #10 from redi at gcc dot gnu dot org 2009-08-26 19:04 ---
Subject: Bug 41005
Author: redi
Date: Wed Aug 26 19:04:11 2009
New Revision: 151127
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151127
Log:
2009-08-26 Jonathan Wakely jwakely@gmail.com
PR
501 - 600 of 682 matches
Mail list logo
