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

Reply via email to