On 8/17/23 3:54 AM, Richard Biener wrote:
I think it needs a new category, 'inline' is probably the "closest" existing one
but that also tends to be noisy. Maybe 'call' would be a good name? We could
report things like tail-recursion optimization, tail-calling and sibling calling
optimizations
First, if this is no longer the appropriate group for this discussion,
please tell me where to send it.
I've been working to understand all the comments here. From them, I think:
1. It's OK to have gcc report back to the user whether each particular
call in tail position is optimized when -f
Thank you for your comments. I have a few questions.
I don't think this specific case qualifies for -Wdisabled-optimization.
The diagnostic is for cases the user can control and was invented
for limits we put up for compile-time and memory-usage issues
where there exist --param XYZ to adjust li
On 8/5/23 5:53 PM, David Malcolm wrote:
...but the warning branch uses "warning", which implicitly uses the
input_location global variable. Is the warning reported at the correct
place? It's better to use warning_at and pass it the location at which
the warning should be emitted.
Thanks, I ch
On 8/5/23 4:58 PM, Prathamesh Kulkarni wrote:
I don't have comments on the patch, but a new warning will also
require a corresponding entry in doc/invoke.texi.
Thank you for your comment.
-Wdisabled-optimization is an established warning, it's just that I'd
like it to apply in another circums
The patch at the end adds a warning when a tail/sibling call cannot be
optimized for various reasons.
I built and tested GCC with and without the patch with configuration
Configured with: ../../gcc-mainline/configure --enable-languages=c
--disable-multilib --prefix=/pkgs/gcc-mainline --disable
