On 1/8/25 2:17 PM, Marek Polacek wrote:
On Wed, Jan 08, 2025 at 07:40:32PM +0100, Jakub Jelinek wrote:
On Wed, Jan 08, 2025 at 01:33:15PM -0500, Marek Polacek wrote:
On Fri, Jan 03, 2025 at 10:46:27PM +0100, Jakub Jelinek wrote:
Hi!
The following testcase ICEs due to re-entering diagnostics.
When diagnosing -Wformat-security warning, we try to print instantiation
context, which calls tsubst with tf_none, but that in the end calls
cp_build_function_call_vec which calls check_function_arguments which
diagnoses another warning (again -Wformat-security).
The other check_function_arguments caller, build_over_call, doesn't call
that function if !(complain & tf_warning), so I think the best fix is
to do it the same in cp_build_function_call_vec as well.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
LGTM. I was going to say we could also check warn_nonnull etc. before
calling check_function_arguments, as build_over_call does so that we
don't do unnecessary work if we're not going to warn but I see:
/* check_function_restrict sets the DECL_READ_P for arguments
so it must be called unconditionally. */
warned_p |= check_function_restrict (fndecl, fntype, nargs, argarray);
except that I don't see where it actually sets DECL_READ_P...
That might be mark_exp_read, but I don't see that called anywhere in
c-common either.
Dunno why that comment was added in PR84919.
Might be nice to replace the comment with if (warn_restrict) then.
I've seen the extra checks on warn_this and that too but decided not to
bother with that when it was called unconditionally.
I can certainly try to change that.
Nah, I think your patch is fine as is. Thanks.
OK.
Jason