------- Comment #5 from rguenth at gcc dot gnu dot org 2010-05-16 10:58 -------
(In reply to comment #2)
> OK, here's what's going wrong:
>
> The LTO design is such that EH is only enabled if we encounter a function with
> an EH personality.
>
> With -fwhopr we process one translation unit at a time, so when we look at
> 20081109_1.C we only see foo(int).
>
> Before my patch foo(int) contained an ERT_MUST_NOT_THROW region, so we
> required
> the C++ personality function. After my patch, it contains an ERT_CLEANUP
> region instead, which doesn't require the C++ personality function
>
> So cgraph doesn't set DECL_FUNCTION_PERSONALITY, so lto1 doesn't think that
> foo
> needs EH, so it never sets flag_exceptions, so we don't get unwind
> information,
> so the throw can't unwind through foo.
>
> There seem to be two issues here:
> 1) lto1 incorrectly thinks foo doesn't need EH.
> 2) -fwhopr means that lto1 can make different decisions about EH for different
> translation units, so things blow up when linked together.
>
> With #2 fixed, #1 isn't as big a problem--but it could still be an issue if we
> aren't compiling the entire program, i.e. a shared library wants to throw from
> a callback. If anything we call can throw, we need unwind information and
> should turn on -fexceptions.
2) should be fixed by deciding on EH info at WPA stage (and not re-deciding
at LTRANS stage for every translation unit).
The current way of detecting whether to init EH is somewhat of a hack, and
there is no convenient place to store such overall properties (no, the
current option saving/restoring machiner is not it).
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu dot
| |org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44150
