This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/25191] exception_defines.h #defines try/catch
- From: "jason at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 24 Sep 2008 19:21:42 -0000
- Subject: [Bug libstdc++/25191] exception_defines.h #defines try/catch
- References: <bug-25191-11686@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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 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 behaviour,
The change I was talking about doesn't modify behavior. If there are no
exceptions, catch blocks will never be executed, so we can optimize them
away in the presence of -fno-exceptions.
> This program, IIRC, is guaranteed to call "f", as a side-effect of the
> presence of the catch-clause? Of course, the C++ FE could still process
> the "catch" clause; my only point is that we cannot literally just throw
> away the catch clause.
True, it would be more like { X } if (0) ...
Jason
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191