> > Overall the logic in this pass is rather convoluted and
> > could deserve some cleanups and separation of concerns.
> > e.g. it would be better to separate tail calls and tail
> > recursion. But I'm not trying to rewrite the pass here.
>
> Understood. For a v9, can you squash the tree-tailcal
On Sat, Jul 6, 2024 at 7:08 PM Andi Kleen wrote:
>
> On Fri, Jul 05, 2024 at 01:45:17PM +0200, Richard Biener wrote:
> > On Sat, Jun 22, 2024 at 9:00 PM Andi Kleen wrote:
> > >
> > > Move the error reporting for caller attributes to be
> > > after the tail call discovery, so that we can give prop
On Fri, Jul 05, 2024 at 01:45:17PM +0200, Richard Biener wrote:
> On Sat, Jun 22, 2024 at 9:00 PM Andi Kleen wrote:
> >
> > Move the error reporting for caller attributes to be
> > after the tail call discovery, so that we can give proper
> > error messages tagged to the calls.
>
> Hmm. This all
On Sat, Jun 22, 2024 at 9:00 PM Andi Kleen wrote:
>
> Move the error reporting for caller attributes to be
> after the tail call discovery, so that we can give proper
> error messages tagged to the calls.
Hmm. This all gets a bit awkward. I realize that early checking
gets us less compile-time
Move the error reporting for caller attributes to be
after the tail call discovery, so that we can give proper
error messages tagged to the calls.
gcc/ChangeLog:
* tree-tailcall.cc (maybe_error_musttail): Declare.
(suitable_for_tail_opt_p): Take call and report errors.
(su