> Isn't pass_dwarf2_frame enabled whenever we're generating any unwind info?
OK, I've installed this on mainline, 4.8 branch and 4.7 branch.
2013-03-28 Eric Botcazou
* toplev.c (process_options): Do not disable -fomit-frame-pointer on a
general basis if unwind info is request
> Isn't pass_dwarf2_frame enabled whenever we're generating any unwind info?
Essentially, yes:
static bool
gate_dwarf2_frame (void)
{
#ifndef HAVE_prologue
/* Targets which still implement the prologue in assembler text
cannot use the generic dwarf2 unwinding. */
return false;
#endif
On 03/26/2013 03:29 PM, Eric Botcazou wrote:
>> Heh. We've actually fixed this now -- unwind info generation aware of
>> the cfg is exactly what pass_dwarf2_frame does. So I guess this comment
>> has been out of date since gcc 4.7.
>
> I see, thanks. So what do you suggest doing at this point?
> Heh. We've actually fixed this now -- unwind info generation aware of
> the cfg is exactly what pass_dwarf2_frame does. So I guess this comment
> has been out of date since gcc 4.7.
I see, thanks. So what do you suggest doing at this point? Entirely remove
the block of code? But AFAICS pas
On 03/25/2013 04:26 AM, Eric Botcazou wrote:
> process_options has had these lines for a couple of releases:
>
> /* ??? Unwind info is not correct around the CFG unless either a frame
> pointer is present or A_O_A is set. Fixing this requires rewriting
> unwind info generation to be a
Hi,
process_options has had these lines for a couple of releases:
/* ??? Unwind info is not correct around the CFG unless either a frame
pointer is present or A_O_A is set. Fixing this requires rewriting
unwind info generation to be aware of the CFG and propagating states
around
