https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92606
--- Comment #26 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #25)
> For ICF (or more generally IPA) there's comp_type_attributes which
> we already check and which dispatches to target code. We're also
> rejecting differing DECL_ATTRIBUTES:
>
> /* Merging two definitions with a reference to equivalent vtables, but
> belonging to a different type may result in ipa-polymorphic-call
> analysis
> giving a wrong answer about the dynamic type of instance. */
> if (is_a <varpool_node *> (n1))
> {
> ...
> /* For functions we compare attributes in equals_wpa, because we do
> not know what attributes may cause codegen differences, but for
> variables just compare attributes for references - the codegen
> for constructors is affected only by those attributes that we lower
> to explicit representation (such as DECL_ALIGN or DECL_SECTION). */
> if (!attribute_list_equal (DECL_ATTRIBUTES (n1->decl),
> DECL_ATTRIBUTES (n2->decl)))
> return return_false_with_msg ("different var decl attributes");
> if (comp_type_attributes (TREE_TYPE (n1->decl),
> TREE_TYPE (n2->decl)) != 1)
> return return_false_with_msg ("different var type attributes");
>
> so I wonder what happens here? Does AVR not actually add the progmem
> attribute?
Ah, this is for merging of _functions_ which is rejected when there's
a reference to variables which differ in this way. Interesting that
we disregard those for merging of referrees but not when mergin the
decls themselves. IMHO those should be equal, thus either call that
function from the two equals_wpa function or duplicate the bits we
have in the function case also to the variable case.
The comment above seems to be misleading here, at least for target attributes
such as this one.
Honza?
