This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Fix EH breakage in LTO mode
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: gcc-patches at gcc dot gnu dot org,Jan Hubicka <hubicka at ucw dot cz>,Eric Botcazou <ebotcazou at adacore dot com>
- Date: Thu, 09 Nov 2017 20:33:44 +0100
- Subject: Re: [patch] Fix EH breakage in LTO mode
- Authentication-results: sourceware.org; auth=none
- References: <1568718.AUOz7rQ1P4@polaris> <20171109164224.GA17070@atrey.karlin.mff.cuni.cz> <8209935.VjDLlsQAqs@polaris> <20171109180318.GA21022@kam.mff.cuni.cz>
On November 9, 2017 7:03:18 PM GMT+01:00, Jan Hubicka <hubicka@ucw.cz> wrote:
>> > I am not sure I follow your argumentation here. flag_exceptions is
>> > optimization which means that one should not test it globally. For
>that
>> > reason I would just change dwarf2out to simply trigger
>> > dwarf2out_frame_finish if any of the compiled functions needed it
>(had
>> > flag_exceptions set).
>>
>> That's not sufficient for a partition with only EH-neutral functions.
>>
>> > My readon of lto-wrapper is that it will set flag_exceptions for
>whole
>> > compilation unit when one of compilation units were copmiled with
>> > flag_exceptions.
>> >
>> > How that helps the neutral functions?
>>
>> flag_exceptions is never set in a partition with only EH-neutral
>functions.
>
>Hmm, I am still not following. By EH-neutral you mean function compiled
>with -fno-exceptions so it has no unwind info at all or one that has
>unwind
>info but does not do anything with EH?
The latter. We choose a 'neutral' EH personality for those and thus if all behave that way we fail to init EH.
I suppose we could record a TU wide setting of options attached to the TRANSLATION_UNIT_DECL and read global flags from that?
Richard.
>Honza
>>
>> --
>> Eric Botcazou