--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #77 from bonzini at gnu dot org 2009-02-03 17:10 ---
Can't the library just #undef try/catch at the end of each file that includes
exception_defines.h?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
--- Comment #78 from paolo dot carlini at oracle dot com 2009-02-03 17:14
---
Nope, we never do that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
--- Comment #79 from bonzini at gnu dot org 2009-02-03 17:15 ---
Yeah, but it seems better than uglifying __try/__catch all over the place...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
--- Comment #80 from paolo dot carlini at oracle dot com 2009-02-03 17:20
---
Many solutions are better, in principle, but really this issue is too old.
After all we are uglifying also in other cases. Let's do that and be done with
it. Unless there are objections (or, better,
--- Comment #81 from paolo at gcc dot gnu dot org 2009-02-03 23:45 ---
Subject: Bug 25191
Author: paolo
Date: Tue Feb 3 23:44:53 2009
New Revision: 143913
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143913
Log:
2009-02-03 Paolo Carlini paolo.carl...@oracle.com
PR
--- Comment #82 from paolo dot carlini at oracle dot com 2009-02-03 23:46
---
Fixed for 4.4.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #74 from jason at gcc dot gnu dot org 2009-02-02 20:27 ---
Since my suggested patch proved somewhat controversial, for 4.4 I'd like to
fall back on the simpler solution that Howard proposed in the initial bug
report; it is inappropriate for library headers to redefine
--- Comment #76 from paolo dot carlini at oracle dot com 2009-02-02 21:11
---
Ok, let's wait a couple of days and, assuming there are no objections, I
volunteer to implement that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
--- Comment #75 from mark at codesourcery dot com 2009-02-02 20:29 ---
Subject: Re: exception_defines.h #defines try/catch
jason at gcc dot gnu dot org wrote:
Since my suggested patch proved somewhat controversial, for 4.4 I'd like to
fall back on the simpler solution that Howard
--- Comment #73 from jason at redhat dot com 2008-11-23 00:02 ---
Subject: Re: exception_defines.h #defines try/catch
pinskia at gcc dot gnu dot org wrote:
I think this patch will not handle:
int main(void)
{
try {
}catch (int a)
{
a = 1;
}
}
Ah yes, I probably
--- Comment #69 from pinskia at gcc dot gnu dot org 2008-11-21 22:19
---
I think this patch will not handle:
int main(void)
{
try {
}catch (int a)
{
a = 1;
}
}
-- CUT ---
In fact exception_defines.h's defines does not handle them correctly anyways.
I am working on a patch
--- Comment #70 from pinskia at gcc dot gnu dot org 2008-11-21 22:21
---
Also my -fignore-exceptions calls __built_trap for a throw and make sure that
throw with an expression that the expression is evaluated.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
--- Comment #71 from pinskia at gcc dot gnu dot org 2008-11-21 22:23
---
Created an attachment (id=16744)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16744action=view)
My current patch for -fignore-exceptions
Note I have not added the testsuite part yet and this is based on
--- Comment #72 from pinskia at gcc dot gnu dot org 2008-11-21 23:08
---
Created an attachment (id=16745)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16745action=view)
Updated patch with some testcases
Here is updated patch which allows more try/catch to work correctly without
--- Comment #63 from rguenth at gcc dot gnu dot org 2008-11-20 10:01
---
The patch looks reasonable. I understand that the warning is enabled by
default
but does not trigger from libstdc++ because that's system headers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
--- Comment #64 from paolo dot carlini at oracle dot com 2008-11-20 10:24
---
(assuming I understand correctly Jason' approach - didn't really follow in
detail the thread, lately) let me know if you want me to remove the
exception_defines.h tricks from the library...
--
paolo dot
--- Comment #65 from jason at redhat dot com 2008-11-20 15:14 ---
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, make sense to
use try/catch in a
--- 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,
--- Comment #67 from mmitchel at gcc dot gnu dot org 2008-11-20 17:55
---
I think that the current libstdc++ behavior is undesirable, for the reasons
that Howard says. In particular, the fact that including a libstdc++ header
can result in definitions of try and catch as macros is
--- Comment #68 from jason at redhat dot com 2008-11-20 18:10 ---
Subject: Re: exception_defines.h #defines try/catch
mmitchel at gcc dot gnu dot org wrote:
If I recall correctly, unwinding into a frame with no EH data will cause a
runtime abort, so programs will not silently skip
--- Comment #61 from jason at gcc dot gnu dot org 2008-11-19 21:42 ---
Created an attachment (id=16725)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16725action=view)
Compiler patch to allow try/catch and rethrow under -fno-exceptions
I've attached a proposed patch to ignore
--- Comment #62 from l dot lunak at suse dot cz 2008-11-19 22:41 ---
(In reply to comment #60)
-fno-exceptions is a big hammer. It will break exceptions trying to
pass through code compiled with that flag whether or not that code has
any try/catch constructs. If you might have
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #60 from jason at redhat dot com 2008-09-26 21:57 ---
Subject: Re: exception_defines.h #defines try/catch
l dot lunak at suse dot cz wrote:
But only in your perfect world. This bug and its silent discarding of
exception
handling code (and an unintended -fno-exception
--- Comment #59 from l dot lunak at suse dot cz 2008-09-25 09:56 ---
(In reply to comment #58)
It seems reasonable to me for try { X } catch... to mean X when
-fno-exceptions. We don't need to error except on throw.
It seems unreasonable to me that gcc would silently modify
--- Comment #56 from l dot lunak at suse dot cz 2008-09-24 08:50 ---
(In reply to comment #55)
It seems reasonable to me for try { X } catch... to mean X when
-fno-exceptions. We don't need to error except on throw.
It seems unreasonable to me that gcc would silently modify code's
--- Comment #57 from mark at codesourcery dot com 2008-09-24 13:03 ---
Subject: Re: exception_defines.h #defines try/catch
jason at gcc dot gnu dot org wrote:
--- Comment #55 from jason at gcc dot gnu dot org 2008-09-23 20:43
---
It seems reasonable to me for try { X }
--- Comment #58 from jason at redhat dot com 2008-09-24 19:21 ---
Subject: Re: exception_defines.h #defines try/catch
l dot lunak at suse dot cz wrote:
--- Comment #56 from l dot lunak at suse dot cz 2008-09-24 08:50 ---
(In reply to comment #55)
It seems reasonable to me
--- Comment #55 from jason at gcc dot gnu dot org 2008-09-23 20:43 ---
It seems reasonable to me for try { X } catch... to mean X when
-fno-exceptions. We don't need to error except on throw.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
--- Comment #52 from rguenth at gcc dot gnu dot org 2008-09-22 12:40
---
Can we please have
1) -fno-exceptions
This flag turns off C++ exception handling support, which is indicated at
compile time by __GXX_EXCEPTIONS being undefined. Use of the keywords try,
catch, or throw produces
--- Comment #53 from rguenth at gcc dot gnu dot org 2008-09-22 12:41
---
CCing C++ FE maintainers.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #54 from paolo dot carlini at oracle dot com 2008-09-22 14:08
---
(In reply to comment #52)
It seems the library maintainers are not willing to see this problem.
Asking for a new C++ frontend feature as an excuse to not fix the
library problem is very lame IMHO.
For the
--- Comment #49 from paolo dot carlini at oracle dot com 2008-06-03 09:52
---
(In reply to comment #48)
FWIW, let me throw out a suggestion for an implementation of Benjamin's (2)
in the C++ front end:
FWIW, I find your suggestion very sensible and probably have already vaguely
--- Comment #50 from rguenther at suse dot de 2008-06-03 10:00 ---
Subject: Re: exception_defines.h #defines try/catch
On Tue, 3 Jun 2008, paolo dot carlini at oracle dot com wrote:
--- Comment #49 from paolo dot carlini at oracle dot com 2008-06-03
09:52 ---
(In reply
--- Comment #51 from paolo dot carlini at oracle dot com 2008-06-03 10:03
---
(In reply to comment #50)
Well, can't we simply remove the libstdc++ #defines then and declare
libstdc++ unsupported for -fno-exceptions until the FE fixes it properly?
IMHO the libstdc++ #defines are
--- Comment #42 from rguenth at gcc dot gnu dot org 2008-06-02 11:48
---
Can we please do something about this? Either make -fno-exceptions
unconditionally always only execute the try block via frontend support (and not
only if you happen to include some libstdc++ header), or apply
--- Comment #43 from paolo dot carlini at oracle dot com 2008-06-02 12:05
---
Ok, I will just implement the __try / __catch suggestion. Hopefully the other
library maintainers will not disagree...
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #44 from bkoz at gcc dot gnu dot org 2008-06-02 20:20 ---
Either make -fno-exceptions
unconditionally always only execute the try block via frontend support (and
not
only if you happen to include some libstdc++ header)
This is my very strong preference.
--- Comment #45 from paolo dot carlini at oracle dot com 2008-06-02 20:59
---
Frankly, at this point in the history of this issue, I don't have a strong
opinion. If we decide for the library-only solution, I can do it quickly, just
let me know.
--
paolo dot carlini at oracle dot
--- Comment #46 from bkoz at gcc dot gnu dot org 2008-06-02 22:27 ---
To clarify, I would like to see this solution come into being:
1) -fno-exceptions
This flag turns off C++ exception handling support, which is indicated at
compile time by __GXX_EXCEPTIONS being undefined. Use of
--- Comment #47 from sebor at roguewave dot com 2008-06-02 23:08 ---
(In reply to comment #46)
[...]
2) -ftransform-exceptions
should catch(X) expand into else if (false) rather than just if (false)?
That said, I don't think there is a way to do this using the preprocessor
alone.
--- Comment #48 from sebor at roguewave dot com 2008-06-03 00:07 ---
FWIW, let me throw out a suggestion for an implementation of Benjamin's (2)
in the C++ front end:
1. try is a no-op
2. catch blocks are syntax-checked but eliminated as dead code
3. throw checks to see if a
--- Comment #40 from pinskia at gcc dot gnu dot org 2008-04-24 08:40
---
*** Bug 36032 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #41 from pinskia at gcc dot gnu dot org 2008-04-24 08:42
---
I'd rather you work around this in objective-c or objective c++.
Well guess what, it is more than an objective-c or objective C++ issue as PR
36032 had a good example for why, it can produce wrong code:
#include
--- Comment #35 from pcarlini at suse dot de 2007-04-27 10:04 ---
(In reply to comment #34)
Also, if you argue against __try/__catch, why do you already use
__throw_exception_again, which is just a different name for throw? If you can
use this, you can as well use __try and __catch.
--- Comment #36 from pcarlini at suse dot de 2007-04-27 12:04 ---
Humm, probably, however, I'm finally getting Gaby's point about the front-end
involvement (sorry, I wasn't really paying attention to this PR until a few
days ago): if we implement something like Howard's change we would
--- 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 #38 from pcarlini at suse dot de 2007-04-27 14:22 ---
(In reply to comment #37)
Thanks for looking at this issue.
Also consider Andrew's point about useful diagnostics, for example from
comment #4.
Of course, if/when the front-end is changed as I was outlining,
--- Comment #39 from l dot lunak at suse dot cz 2007-04-27 14:41 ---
I find the reasoning that this change should not be done because somebody
possibly might be using the libstdc++'s different semantics of try/catch rather
weak, for several reasons:
- it's not documented anywhere, at
--- Comment #34 from l dot lunak at suse dot cz 2007-04-24 10:54 ---
I think the reason why the discussion here is so complicated is that you
libstdc++ people are, because of exception_defines.h, confused about what
-fno-exceptions actually does. From comment #15: Then, why what is this
--- 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 #23 from gdr at cs dot tamu dot edu 2006-01-11 15:56 ---
Subject: Re: exception_defines.h #defines try/catch
hhinnant at apple dot com [EMAIL PROTECTED] writes:
| #define'ing try and catch is non-conforming.
You forgot to mentin that -fno-exceptions is neither mandated,
--- 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 not
--- Comment #25 from gdr at cs dot tamu dot edu 2006-01-11 16:41 ---
Subject: Re: exception_defines.h #defines try/catch
hhinnant at apple dot com [EMAIL PROTECTED] writes:
| --- Comment #24 from hhinnant at apple dot com 2006-01-11 16:10 ---
| (In reply to comment #23)
|
--- 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 #27 from gdr at cs dot tamu dot edu 2006-01-12 00:12 ---
Subject: Re: exception_defines.h #defines try/catch
hhinnant at apple dot com [EMAIL PROTECTED] writes:
| Or are our quality standards higher than that?
The way you solve this is neither through rhetorics, neither
--- Comment #28 from gdr at cs dot tamu dot edu 2006-01-12 00:12 ---
Subject: Re: exception_defines.h #defines try/catch
hhinnant at apple dot com [EMAIL PROTECTED] writes:
| --- Comment #26 from hhinnant at apple dot com 2006-01-11 18:02 ---
| (In reply to comment #25)
|
--- Comment #30 from gdr at cs dot tamu dot edu 2006-01-12 01:10 ---
Subject: Re: exception_defines.h #defines try/catch
hhinnant at apple dot com [EMAIL PROTECTED] writes:
| (In reply to comment #28)
| Subject: Re: exception_defines.h #defines try/catch
|
| | No, try in this
--- Comment #31 from gdr at cs dot tamu dot edu 2006-01-12 01:15 ---
Subject: Re: exception_defines.h #defines try/catch
hhinnant at apple dot com [EMAIL PROTECTED] writes:
[...]
| I'm simply pointing out that the effort could be improved.
| Obviously no standard is going to back
On Jan 11, 2006, at 8:10 PM, gdr at cs dot tamu dot edu wrote:
| I realize that once the customer specifies -fno-exceptions, all bets
| are off.
Great. Fix the problem in the front-end.
As I said before, there is still a diagnostic issue and now it is worse
with
doing that in the front-end
--- Comment #32 from pinskia at gcc dot gnu dot org 2006-01-12 01:26
---
Subject: Re: exception_defines.h #defines try/catch
On Jan 11, 2006, at 8:10 PM, gdr at cs dot tamu dot edu wrote:
| I realize that once the customer specifies -fno-exceptions, all bets
| are off.
Great.
--- 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
--- Comment #21 from pinskia at gcc dot gnu dot org 2005-12-13 20:03
---
One more thing is that this is not documented anywhere (I can find) that
libstdc++ does this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
--- Comment #20 from bkoz at gcc dot gnu dot org 2005-12-07 19:01 ---
I have customers using Obj C++ who want to turn off C++
exception support, but retain Obj C exception support. [snip]
What does this even mean? Can you detail or explain how this is supposed to
work?
They are
--- 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++ is
|
--- 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 #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 it is
--- Comment #17 from gdr at integrable-solutions dot net 2005-12-04 02:54
---
Subject: Re: exception_defines.h #defines try/catch
hhinnant at apple dot com [EMAIL PROTECTED] writes:
[...]
| But I won't apologize for being customer focused.
Geeat! And people disagreeing with you
--- Comment #2 from bkoz at gcc dot gnu dot org 2005-12-02 18:59 ---
We are trying to keep the libstc++ code as clean and representative of
standards-conforming C++ code as possible, and have avoided __try, __catch,
etc. or other uglification in favor of the actual C++ terms, ie try,
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-02 19:01 ---
(In reply to comment #2)
We are trying to keep the libstc++ code as clean and representative of
standards-conforming C++ code as possible, and have avoided __try, __catch,
etc. or other uglification in favor of
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-02 19:04 ---
Confirmed. This also causes problems in normal C++ code which does:
#include string
int f(void);
int main(void)
{
try {
f();
}catch (a) {}
}
Without the include, you get an error but with the include, you
--- 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 #7 from gdr at integrable-solutions dot net 2005-12-02 19:23
---
Subject: Re: exception_defines.h #defines try/catch
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Confirmed. This also causes problems in normal C++ code which does:
|
| #include string
|
|
--- Comment #6 from gdr at integrable-solutions dot net 2005-12-02 19:18
---
Subject: Re: exception_defines.h #defines try/catch
I agree with Benjamin.
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| I personally would like this fixed in libstdc++ as it is changing
|
--- Comment #8 from gdr at integrable-solutions dot net 2005-12-02 19:29
---
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 ---
| (In reply to comment
--- 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 #10 from pinskia at gcc dot gnu dot org 2005-12-02 21:06
---
(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 issue.
We really
--- 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 #12 from gdr at integrable-solutions dot net 2005-12-03 00:58
---
Subject: Re: exception_defines.h #defines try/catch
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| We really should not be defining keywords in the headers at all. If we
define
| bool
--- Comment #13 from gdr at integrable-solutions dot net 2005-12-03 01:02
---
Subject: Re: exception_defines.h #defines try/catch
hhinnant at apple dot com [EMAIL PROTECTED] writes:
| (In reply to comment #8)
| Subject: Re: exception_defines.h #defines try/catch
|
| hhinnant at
--- 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
--- Comment #15 from gdr at integrable-solutions dot net 2005-12-03 04:20
---
Subject: Re: exception_defines.h #defines try/catch
hhinnant at apple dot com [EMAIL PROTECTED] writes:
| --- Comment #14 from hhinnant at apple dot com 2005-12-03 01:25 ---
| (In reply to comment
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-30 23:57 ---
This is a library issue and not a front-end issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
84 matches
Mail list logo
