On Jan 25 2023, Richard Biener wrote:
> where we'd prefer -funwind-tables over -fno-unwind-tables when the
> options do not match
> across TUs. Note that you likely want to add
> -f[asynchronous-]unwind-tables handling
> in lto-options.cc:lto_write_options as well so the default is streamed
> as
On Wed, Jan 18, 2023 at 11:17 AM Andreas Schwab via Gcc-patches
wrote:
>
> The -funwind-tables and -fasynchronous-unwind-tables options are relevant
> for the output pass, thus they need to be passed through by the lto
> wrapper.
>
> gcc/
> * lto-wrapper.cc (merge_and_complain): Pass
On Wed, Jan 18, 2023 at 4:07 PM Jan Hubicka wrote:
>
> > No unwind tables are generated, as if -funwind-tables is ignored. If
> > LTO is disabled, everything works as expected.
> I think it is because dwaf2out_do_eh_frame is called out of function
> context at the end of compilation. At that
On Wed, Jan 18, 2023 at 05:25:10PM +0100, Jan Hubicka wrote:
> > On Jan 18 2023, Michael Matz wrote:
> >
> > > The purest solution is to emit unwind tables for all functions that
> > > request it into .eh_frame and for those that don't request it put
> > > into .debug_frame (if also -g is on).
> On Jan 18 2023, Michael Matz wrote:
>
> > The purest solution is to emit unwind tables for all functions that
> > request it into .eh_frame and for those that don't request it put
> > into .debug_frame (if also -g is on).
>
> The assembler does not allow switching back to .eh_frame once a
>
On Jan 18 2023, Michael Matz wrote:
> The purest solution is to emit unwind tables for all functions that
> request it into .eh_frame and for those that don't request it put
> into .debug_frame (if also -g is on).
The assembler does not allow switching back to .eh_frame once a
different format
Hello,
On Wed, 18 Jan 2023, Jakub Jelinek wrote:
> > > > > Partly OT, what is riscv not defaulting that on as well? Does it have
> > > > > usable unwind info even without that option, something else?
> > > >
> > > > The RISC-V ABI does not address this, AFAICS.
> > >
> > > And neither do many
On Wed, Jan 18, 2023 at 03:16:07PM +, Michael Matz wrote:
> On Wed, 18 Jan 2023, Jakub Jelinek wrote:
>
> > On Wed, Jan 18, 2023 at 04:09:08PM +0100, Andreas Schwab wrote:
> > > On Jan 18 2023, Jakub Jelinek wrote:
> > >
> > > > Partly OT, what is riscv not defaulting that on as well? Does
Hello,
On Wed, 18 Jan 2023, Jakub Jelinek wrote:
> On Wed, Jan 18, 2023 at 04:09:08PM +0100, Andreas Schwab wrote:
> > On Jan 18 2023, Jakub Jelinek wrote:
> >
> > > Partly OT, what is riscv not defaulting that on as well? Does it have
> > > usable unwind info even without that option,
On Jan 18 2023, Jakub Jelinek wrote:
> Neither of that will always match all the states of all the functions.
But if the translation units are compiled with -funwind-tables, we want
the ltrans "units" to behave the same.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196
On Wed, Jan 18, 2023 at 04:09:08PM +0100, Andreas Schwab wrote:
> On Jan 18 2023, Jakub Jelinek wrote:
>
> > Partly OT, what is riscv not defaulting that on as well? Does it have
> > usable unwind info even without that option, something else?
>
> The RISC-V ABI does not address this, AFAICS.
On Jan 18 2023, Jakub Jelinek wrote:
> Partly OT, what is riscv not defaulting that on as well? Does it have
> usable unwind info even without that option, something else?
The RISC-V ABI does not address this, AFAICS.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196
> No unwind tables are generated, as if -funwind-tables is ignored. If
> LTO is disabled, everything works as expected.
I think it is because dwaf2out_do_eh_frame is called out of function
context at the end of compilation. At that time cfun is NULL
and the flag is read from global settings that
On Wed, Jan 18, 2023 at 02:03:42PM +, Michael Matz wrote:
> On Risc-V btw. (which, unlike i386,aarch64,s390,rs6000 does not
> effectively enable funwind-tables always via either backend or
> common/config/$arch/ code, which is the reason why the problem can't be
> seen there). It's an
On Wed, Jan 18, 2023 at 03:14:01PM +0100, Andreas Schwab wrote:
> On Jan 18 2023, Michael Matz wrote:
>
> > So, it's quite clear that the option merging algorithm related to all this
> > is somewhat broken, the global (or per function, or whatever)
> > -funwind-tables option from hello.o
On Jan 18 2023, Michael Matz wrote:
> So, it's quite clear that the option merging algorithm related to all this
> is somewhat broken, the global (or per function, or whatever)
> -funwind-tables option from hello.o doesn't make it correctly into the
> output (when -g is there). Adding
On Wed, 18 Jan 2023, Andreas Schwab via Gcc-patches wrote:
> No unwind tables are generated, as if -funwind-tables is ignored. If
> LTO is disabled, everything works as expected.
On Risc-V btw. (which, unlike i386,aarch64,s390,rs6000 does not
effectively enable funwind-tables always via
On Jan 18 2023, Jakub Jelinek wrote:
> That is streamed in by lto1 back and on each set_cfun such saved options
> are stored into global_options{,_set}.
Is that done in time for dwarf2out_do_eh_frame?
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE
No unwind tables are generated, as if -funwind-tables is ignored. If
LTO is disabled, everything works as expected.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
On Wed, Jan 18, 2023 at 01:39:18PM +0100, Andreas Schwab wrote:
> On Jan 18 2023, Jakub Jelinek wrote:
>
> > With LTO each function has the DECL_FUNCTION_SPECIFIC_OPTIMIZATION
> > (and _TARGET), for functions with optimize attribute obviously as without
> > LTO specific to what options have been
On Jan 18 2023, Jakub Jelinek wrote:
> With LTO each function has the DECL_FUNCTION_SPECIFIC_OPTIMIZATION
> (and _TARGET), for functions with optimize attribute obviously as without
> LTO specific to what options have been overridden (but with defaults from
> TU's command line etc.), for
On Wed, Jan 18, 2023 at 01:30:53PM +0100, Andreas Schwab wrote:
> On Jan 18 2023, Jakub Jelinek wrote:
>
> > On Wed, Jan 18, 2023 at 12:25:11PM +0100, Andreas Schwab via Gcc-patches
> > wrote:
> >> On Jan 18 2023, Richard Biener wrote:
> >>
> >> > On Wed, Jan 18, 2023 at 11:17 AM Andreas Schwab
On Jan 18 2023, Jakub Jelinek wrote:
> On Wed, Jan 18, 2023 at 12:25:11PM +0100, Andreas Schwab via Gcc-patches
> wrote:
>> On Jan 18 2023, Richard Biener wrote:
>>
>> > On Wed, Jan 18, 2023 at 11:17 AM Andreas Schwab via Gcc-patches
>> > wrote:
>> >>
>> >> The -funwind-tables and
On Wed, Jan 18, 2023 at 12:25:11PM +0100, Andreas Schwab via Gcc-patches wrote:
> On Jan 18 2023, Richard Biener wrote:
>
> > On Wed, Jan 18, 2023 at 11:17 AM Andreas Schwab via Gcc-patches
> > wrote:
> >>
> >> The -funwind-tables and -fasynchronous-unwind-tables options are relevant
> >> for
On Jan 18 2023, Richard Biener wrote:
> On Wed, Jan 18, 2023 at 11:17 AM Andreas Schwab via Gcc-patches
> wrote:
>>
>> The -funwind-tables and -fasynchronous-unwind-tables options are relevant
>> for the output pass, thus they need to be passed through by the lto
>> wrapper.
>
> They are already
On Wed, Jan 18, 2023 at 11:17 AM Andreas Schwab via Gcc-patches
wrote:
>
> The -funwind-tables and -fasynchronous-unwind-tables options are relevant
> for the output pass, thus they need to be passed through by the lto
> wrapper.
They are already stored per function, and ...
> gcc/
> *
The -funwind-tables and -fasynchronous-unwind-tables options are relevant
for the output pass, thus they need to be passed through by the lto
wrapper.
gcc/
* lto-wrapper.cc (merge_and_complain): Pass through
-funwind-tables and -fasynchronous-unwind-tables.
27 matches
Mail list logo
