This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: tail call optimization vs. debugging
- To: "Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>
- Subject: Re: tail call optimization vs. debugging
- From: "Geert Bosch" <bosch at gnat dot com>
- Date: Sat, 25 Mar 2000 16:09:25 -0500
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>,"haible at ilog dot fr" <haible at ilog dot fr>, "rth at cygnus dot com" <rth at cygnus dot com>
- Reply-To: "Geert Bosch" <bosch at gnat dot com>
On Sat, 25 Mar 2000 21:50:46 +0100, Martin v. Loewis wrote:
Does this mean you don't want the compiler to support the inline
keyword? Because with inlining, you cannot set a break-point on an
inlined function, and get a useful stack backtrace with arguments
right now.
This is a different case, as this only applies to functions explicitly
marked inline. The user can usually see this in the sources, and
will expect that some debugging functionality may be lost.
In the case of tail call optimizations, this wouldn't be the case, and
the user might come to the wrong conclusion that the function has
not been called.
Fortunately Richard has clarified this issue a bit, although
it would be nice to force the compiler to put the arguments in place.
Richard wrote:
With tail recursion (which we had before, but will trigger more often
now) I can only say "probably". It's implemented with a goto internally,
so the optimizer has the chance to not put the new arguments in place.