On 10/13/15 07:02, Mike Stump wrote:
> On Oct 12, 2015, at 3:32 PM, Chen Gang <[email protected]> wrote:
>>
>> OK, thanks. If we really need to fix it, which target hook should I use?
>> (or do we need a new target hook?)
>
> So, the first discussion would be if it is, or is not a bug. If it isn’t,
> then there is no fix. No fix, no target hook. So far, Bernd said not a bug.
>
OK, under the bugzilla, the maintainer treated it as expected behavior
(not a bug). For me, we need more explanation for it (why we treat it
as expected behavior).
> So, I’ll note that one _can_ do this with the stack pointer, as a fixed
> register.
> When the frame pointer is fixed, one cannot do this.
>
Excuse me, I do not quite understand, could you please provide more
details?
> The code that does this is:
>
> /* Diagnose uses of the hard frame pointer when it is used as a global
>
>
> register. Often we can get away with letting the user appropriate
>
>
> the frame pointer, but we should let them know when code generation
>
>
> makes that impossible. */
> if (global_regs[HARD_FRAME_POINTER_REGNUM] && frame_pointer_needed)
> {
> tree decl = global_regs_decl[HARD_FRAME_POINTER_REGNUM];
> error_at (DECL_SOURCE_LOCATION (current_function_decl),
> "frame pointer required, but reserved");
> inform (DECL_SOURCE_LOCATION (decl), "for %qD", decl);
> }
>
> to `fix it’, one would simple remove this chunk as misguided and fix up any
> code gen issues exposed.
>
If there were not only one issues related with it, for me, what you said
sounds reasonable to me.
Thanks.
--
Chen Gang (陈刚)
Open, share, and attitude like air, water, and life which God blessed
