ReportedBy: hhinnant at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29224
--- Comment #14 from hhinnant at apple dot com 2006-11-01 23:33 ---
So swallowing a cancel-exception (in C++) is sometimes the right thing to do.
Imagine a thread pool executing a queue of tasks. These tasks can well have
handles so that clients can wait/join with results
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hhinnant at apple dot com
GCC host triplet: Mac OS 10.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27168
template static data
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hhinnant at apple dot com
GCC host triplet: darwin
--- Comment #5 from hhinnant at apple dot com 2006-06-13 21:23 ---
(In reply to comment #4)
For Darwin we do not want explicit instantiations to be
linkonce. */
This is why this testcase fails on darwin.
We should instead of just adding DECL_EXPLICIT_INSTANTIATION, check
--- Comment #7 from hhinnant at apple dot com 2006-06-13 21:41 ---
(In reply to comment #6)
Subject: Re: lack of guard variables for explicitly instantiated template
static data
#define NEEDS_GUARD_P(decl) (TREE_PUBLIC (decl) (DECL_COMMON (decl
--- Comment #9 from hhinnant at apple dot com 2006-06-13 22:02 ---
(In reply to comment #8)
Thanks. That not only makes sense to me now, but it passes the test. :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28017
--- Comment #10 from hhinnant at apple dot com 2006-06-19 18:11 ---
It turns out this still isn't quite right. Looks like we need:
#define NEEDS_GUARD_P(decl) (TREE_PUBLIC (decl) (DECL_COMMON (decl) \
|| DECL_ONE_ONLY (decl
linkage not part of function type
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hhinnant at apple dot com
GCC
at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
--- Comment #5 from hhinnant at apple dot com 2005-12-02 19:07 ---
(In reply to comment #2)
I'd rather you work around this in objective-c or objective c++.
How? I'm open to suggestions.
-Howard
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
--- Comment #9 from hhinnant at apple dot com 2005-12-02 21:00 ---
(In reply to comment #8)
Subject: Re: exception_defines.h #defines try/catch
hhinnant at apple dot com [EMAIL PROTECTED] writes:
| --- Comment #5 from hhinnant at apple dot com 2005-12-02 19:07
--- Comment #11 from hhinnant at apple dot com 2005-12-02 21:21 ---
(In reply to comment #10)
(In reply to comment #9)
Not being someone with a lot of FE experience, I have more hesitation about
this latter approach.
That solution still does not solve my issue of the diagnostic
--- Comment #14 from hhinnant at apple dot com 2005-12-03 01:25 ---
(In reply to comment #13)
Subject: Re: exception_defines.h #defines try/catch
I'm saying that if you're intending to use try/catch and yet not
want what the mean in standard C++, nor what they would mean in GNU
C
--- Comment #16 from hhinnant at apple dot com 2005-12-04 02:12 ---
(In reply to comment #15)
Subject: Re: exception_defines.h #defines try/catch
I don't think anybody is disputing that. It is also a simple fact
that GCC documents what happens with -fno-exceptions.
I think
--- Comment #18 from hhinnant at apple dot com 2005-12-04 15:55 ---
(In reply to comment #15)
Subject: Re: exception_defines.h #defines try/catch
It is also a simple fact
that GCC documents what happens with -fno-exceptions.
I'm trying to find this documentation. So far all I've
--- Comment #19 from hhinnant at apple dot com 2005-12-06 01:19 ---
(In reply to comment #17)
Subject: Re: exception_defines.h #defines try/catch
hhinnant at apple dot com [EMAIL PROTECTED] writes:
| I don't know what that means. Or even how it would be relevant. ObjC
at gcc dot gnu dot org
ReportedBy: hhinnant at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466
at gcc dot gnu dot org
ReportedBy: hhinnant at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25467
--- Comment #4 from hhinnant at apple dot com 2005-12-17 22:01 ---
Agreed, (that's brutal ;-) ).
Sorry about the duplicate. My clumsy fingers hit refresh on my browser and
that generated the duplicate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466
--- Comment #22 from hhinnant at apple dot com 2006-01-11 15:30 ---
Conforming C++ programs exist that work correctly with -fno-exceptions as long
as they don't include any libstdc++ header. These same programs can fail (at
either compile time or run time) if they also include some
--- Comment #24 from hhinnant at apple dot com 2006-01-11 16:10 ---
(In reply to comment #23)
You forgot to mentin that -fno-exceptions is neither mandated, nor
required to work with programs that play tricks with try/catch.
So, your assertion is unfounded.
The demo program does
--- Comment #26 from hhinnant at apple dot com 2006-01-11 18:02 ---
(In reply to comment #25)
Subject: Re: exception_defines.h #defines try/catch
| The demo program does not play tricks with try/catch.
It does, with xlgue(try, ).
No, try in this context is not a keyword
--- Comment #33 from hhinnant at apple dot com 2006-01-12 02:49 ---
(In reply to comment #32)
As I said before, there is still a diagnostic issue and now it is worse
with
doing that in the front-end since people don't read docs that well so
we will
be getting bug reports about
: unassigned at gcc dot gnu dot org
ReportedBy: hhinnant at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25894
: unassigned at gcc dot gnu dot org
ReportedBy: hhinnant at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25913
--- Comment #2 from hhinnant at apple dot com 2006-01-22 20:25 ---
(In reply to comment #1)
Does the problem exist if you configure with --disable-c99?
I haven't tried that configuration. The docs say that setting may change
libstdc++'s ABI.
So this is expected behavior
--- Comment #4 from hhinnant at apple dot com 2006-01-22 20:49 ---
(In reply to comment #3)
(3) even when isnormal is enable-if hacked, you still potentially
run into the same problem.
For example?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25913
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hhinnant at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25950
--- Comment #3 from hhinnant at apple dot com 2006-01-24 22:51 ---
More information:
I now believe I unknowingly misled when I surmized that EDG had implemented cwg
391. If you declare the copy ctor private in the example, EDG rejects g(X())
based on accessibility. Rather I am now
--- Comment #6 from hhinnant at apple dot com 2006-01-25 02:05 ---
At the risk of continuing off-topic...
Thank you Andrew for your continuing prompt and high quality work. It is a
very valuable service and I've never had any complaints with the way you
provide it. Good Job and Thank
--- Comment #9 from hhinnant at apple dot com 2006-01-25 02:54 ---
(In reply to comment #8)
Changing to request for enhancement. The requested behaviour is a change
in th working paper. Existing behaviour is what is required by the standard
(even when it can be argued that checking
--- Comment #13 from hhinnant at apple dot com 2006-01-25 03:24 ---
(In reply to comment #11)
| Did you read comment 3?
Yes. Is your claim that whether the copy constructor is converting or
not does not matter?
No. My suspicion is that there is a 99.99% chance that EDG
for conditional
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hhinnant at apple dot com
http://gcc.gnu.org/bugzilla
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hhinnant at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24758
--- Comment #5 from hhinnant at apple dot com 2005-11-12 19:02 ---
(1) Strong-arm a C++ front-end guru into implementing rvalue references,
then use them in the TR1 function objects. Heck, we'll need 'em
for C++0x anyway :)
At the risk of being reckless. Yes... well
--- Comment #2 from hhinnant at apple dot com 2006-11-22 16:21 ---
If there is a plan, I don't know about it.
Russell Yanofsky has a prototype implementation here:
http://russ.yanofsky.org/rref/
I haven't looked at it enough to know how complete it is. It was done a couple
of years
--- Comment #3 from hhinnant at apple dot com 2006-11-29 18:36 ---
Recent work:
http://mndfck.org/~pedro.lamarao/projects/c++0x/
http://home.twcny.rr.com/hinnant/cpp_extensions/rvalue_ref_test/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29939
--- Comment #12 from hhinnant at apple dot com 2007-02-07 16:46 ---
At the ad-hoc LWG meeting in Batavia, Jan 22-24, 2007, the LWG decided that
self referencing code in list::remove must work. Here is a preview of the
issue which is currently set to become official at the Spring '07
--- Comment #13 from hhinnant at apple dot com 2007-02-07 16:59 ---
(In reply to comment #12)
If we have a utility similar to boost::address_of, that might be better than
using operator to get the address of the value_type (to accommodate types
which overload operator).
Oops, I
--- Comment #15 from hhinnant at apple dot com 2007-02-07 17:22 ---
(In reply to comment #14)
Unless __value comes from the list, does the standard require
__a.address(__value) to work?
That's a good question Chris. The way I read the current draft, I believe the
answer
--- Comment #5 from hhinnant at apple dot com 2007-02-21 20:17 ---
Russell Yanofsky has submitted a patch implementing N2118:
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01760.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29939
--- Comment #16 from hhinnant at apple dot com 2007-04-15 16:13 ---
(In reply to comment #15)
This makes clean up / rethrow during cancellation awkward. Code would have to
check for two (or more) different kinds of cancellation: Am I executing in an
OS thread, or in a thread pool
--- Comment #37 from hhinnant at apple dot com 2007-04-27 14:15 ---
Thanks for looking at this issue.
Also consider Andrew's point about useful diagnostics, for example from comment
#4. And the followup to that point in #33 which includes field experience on
how other compilers deal
--- Comment #66 from hhinnant at apple dot com 2008-11-20 17:40 ---
(In reply to comment #65)
Subject: Re: exception_defines.h #defines try/catch
No, it doesn't make any sense to use try/catch in a program that you're
planning to build with -fno-exceptions. It does, however
45 matches
Mail list logo
