--- 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 #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=gcc&view=rev&rev=143913
Log:
2009-02-03 Paolo Carlini
PR libstdc++/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, constructi
--- 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 #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 #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
--
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 #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 #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 keyword
--- 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 p
--- 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=16745&action=view)
Updated patch with some testcases
Here is updated patch which allows more try/catch to work correctly without
--- 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=16744&action=view)
My current patch for -fignore-exceptions
Note I have not added the testsuite part yet and this is based on 4.
--- 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 #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 #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 #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 #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 #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 ge
--- 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 ca
--- 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 #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
--- 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=16725&action=view)
Compiler patch to allow try/catch and rethrow under -fno-exceptions
I've attached a proposed patch to ignore try
--
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
--- 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
--- 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 #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 #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 #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 t
--- 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 #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 #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 #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 #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
hin
--- 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 user-
--- 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 #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 the
--- 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 com
--- 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.
-fno-excep
--- 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 #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 the
--- 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 #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 #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 lea
--- 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, diag
--- 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 wi
--- 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 c
--- 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 #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 #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 abou
--- 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.
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 #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
--- 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
--- Comment #29 from hhinnant at apple dot com 2006-01-12 00:59 ---
(In reply to comment #28)
> Subject: Re: exception_defines.h #defines try/catch
>
> | No, "try" in this context is not a keyword.
>
> I did not say it was a keyword. I know what it is in that phase.
>
> try/catch ar
--- 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 #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, neith
--- 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 #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 #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 n
--- 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 mandate
--- 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 (not
--- 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+
--- 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 #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 yo
--- 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
--- 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 comm
--- 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 #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
| >
| > "hhin
--- 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 somew
--- 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 diag
--- 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 sho
--- 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 #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 commen
--- 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 #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
|
| int
--- 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 #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
int f(void);
int main(void)
{
try {
f();
}catch (a) {}
}
Without the include, you get an error but with the include, you don't w
--- 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 #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, ca
--- 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
--
85 matches
Mail list logo
