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: "l dot lunak at suse dot cz" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 25 Sep 2008 09:56:07 -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 #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 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.
But only in your perfect world. This bug and its silent discarding of exception
handling code (and an unintended -fno-exception from the build system) made us
release a broken package. If you want to add support for discarding of
explicitly written exceptions code, ok, whatever, but please make it explicit,
because having it the way it is with this bug is rather pointless (since then
either you don't use exceptions at all and then there's no need to write the
exception handling code, or you mix it and then you soon may find it simpler to
drop the -fno-exception rather than explicitly check all code paths after you
refactor something).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191