https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93926
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
CC| |msebor at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
--- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> ---
The bug here is in the mismatch between the permissive way the front-end
validates declarations of built-ins and the more restrictive validation done by
the middle-end.
The front-end silently accepts as valid redeclarations whose number of
arguments and their modes (as well as the mode of the return type) match the
built-in, even if types are different. So 'long malloc(int)' is treated as a
built-in.
But the middle-end validation looks like this:
if (DECL_IS_MALLOC (decl)
&& !POINTER_TYPE_P (TREE_TYPE (TREE_TYPE (decl))))
{
error ("malloc attribute should be used for a function that "
"returns a pointer");
error_found = true;
}
DECL_IS_MALLOC(decl) is set but the return type is wrong.
I think incompatible redeclarations should be diagnosed regardless of whether
their type modes match; they could still keep being accepted as built-ins
because it helps find bugs in their use. The middle-end checking would then
need to change to match the front-end. It seems that abstracting the checking
into a common function used by both would help keep the two from getting out of
sync. Let me look into making that happen.
