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. Marek
