This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH to i386_pe_encode_section_info


Danny Smith wrote:

No, all encode_section_info does for stdcall/fastcal now is  encode the
RTL name.  targetm.merge_type_attributes takes care of duplicate decl
conflicts.

That's not quite my question. Assume we have an old decl and a new decl that are compatible, but may have different attributes. Those are combined by merge_type_attributes. What we want is to set the RTL name based on the *merged* attributes, which is not necessarily the same as the attributes of the old declaration.

However, if it is an error for the __stdcall__ and __fastcall_
attributes to be different in the old and new decl, as indicated
by your testcase, then it is safe to just use the "old" attributes.

I changed my patch to:

  if (first && TREE_CODE (decl) == FUNCTION_DECL)
    {
      tree type_attributes = TYPE_ATTRIBUTES (TREE_TYPE (decl));
      rtx rtlname = XEXP (rtl, 0);
      if (GET_CODE (rtlname) == MEM)
	rtlname = XEXP (rtlname, 0);
      if (lookup_attribute ("stdcall", type_attributes))
	XSTR (rtlname, 0) = gen_stdcall_suffix (decl);
      else if (lookup_attribute ("fastcall", type_attributes))
	XSTR (rtlname, 0) = gen_fastcall_suffix (decl);
    }

If that boostraps and builds my test application, I'll check it in.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]