Re: Getting bounds information (thus, attributes) within diagnose_mismatched_decls()

Martin Uecker via Gcc-help <[email protected]> Sun, 14 Dec 2025 19:09:34 +0100
Newsgroups gmane.comp.gcc.help
Message-ID <[email protected]>
Hi Alex,

Am Donnerstag, dem 13.11.2025 um 00:31 +0100 schrieb Alejandro Colomar:
> Hi Joseph, Martin,
> 
> I'm trying to add diagnostics about mismatches in bounds between the
> forward declaration of a parameter and the actual declaration of the
> parameter.
> 
> I'm trying to do something like this:
> 
> 	diff --git i/gcc/c/c-decl.cc w/gcc/c/c-decl.cc
> 	index 0a368e410e57..eb301669885c 100644
> 	--- i/gcc/c/c-decl.cc
> 	+++ w/gcc/c/c-decl.cc
> 	@@ -2387,6 +2387,12 @@ diagnose_mismatched_decls (tree newdecl, tree olddecl,
> 				 OPT_Wenum_int_mismatch,
> 				 "conflicting types for %q+D due to enum/integer "
> 				 "mismatch; have %qT", newdecl, newtype);
> 	+  else if (TREE_CODE (newdecl) == PARM_DECL
> 	+          && TREE_CODE (olddecl) == PARM_DECL)
> 	+    {
> 	+      location_t loc = DECL_SOURCE_LOCATION (olddecl);
> 	+      warn_parm_array_mismatch (loc, XXX, XXX, olddecl, newdecl, XXX, false);
> 	+    }
> 	 
> 	   /* Redeclaration of a type is a constraint violation (6.7.2.3p1),
> 	      but silently ignore the redeclaration if either is in a system
> 
> which calls the function I recently split:
> 
> 	/* Helper for warn_parms_array_mismatch.  Compare the mappings of
> 	   two function parameters and diagnose mismatches.  ORIGLOC is the
> 	   location of the first function declaration.  CURP and NEWP are the
> 	   parameters in the first and second function declarators,
> 	   respectively.  PARMPOS is the position of the parameters within the
> 	   list of parameter declarations.  BUILTIN is true if the function is
> 	   a builtin.  */
> 
> 	static void
> 	warn_parm_array_mismatch (location_t origloc, rdwr_map *cur_idx,
> 				  rdwr_map *new_idx, tree curp, tree newp,
> 				  unsigned parmpos, bool builtin)
> 
> However, I don't know where to get the 'rdwr_map*' from, which
> warn_parm_array_mismatch() uses for getting the bounds information.
> 
> Is there a way to get that information here somehow?

See init_attr_rdwr_indices in attribs.cc


So the overall story is this: 

For arguments declared as arrays we add an (internal)
"arg spec" attribute (build_arg_spec_attribute) in
grokdeclarator in c/c-decl.cc.  

In c-family/c-attribs.cc build_attr_access_from_parms then
creates an "access" attribute with some string parameter
that encodes the information.  It is called later from
finish_decl (c-decl.cc).  Explicit access attributes are
also transformed into this internal representation
(handle_access_attribute ...).

The warning code in c-family/c-warn.cc  and also some
middle-end warning code uses this information to emit warning.
For this it uses init_attr_rdwr_indices (attribs.cc)
to reconstruct a per-parameter access specification 
(attr_spec) and this gives some information.

So basically instead of using types properly, we create
internal attributes, transform them in complicated ways
to attach them to the function decl, and then recompute per
parameter information when needed.  

I fixed various bugs in this code and changed the
arg spec attribute to simply preserve the original type,
but I think this needs to be refactored more.

> 
> Maybe warn_parm_array_mismatch() could be split into yet another helper
> which doesn't get the parameter position and the rdwr_map*'s and instead
> gets the attributes in a form that I can produce within
> diagnose_mismatched_decls(), to be able to share that code.  (But I'd
> still need to know how to get a form that can be shared with the other
> code.)

My recommendation is to rewrite the FE warning code to not
rely on init_attr_rdwr_indices at all but make use of the
types directly (the original type is now in the "arg spec"
for each parameter). This should be much clearer.  So if you
add new warnings, I would do this directly in this way.


Martin