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 throu
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 time
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
> d
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 i
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, somethin
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 BA
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.
A
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 BAD8
> 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 a
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 inte
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 doesn't
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 -fexcept
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 either
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 1
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 o
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 functions
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 -fasynchronou
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 the
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/
> * l
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.
(append_compiler
27 matches
Mail list logo
