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/i386]: -mrtd vs system library declarations


"Zack Weinberg" <zack@codesourcery.com> writes:

| As an alternative, I suggest that you implement machine-specific
| #pragmas that explicitly control the calling convention.  They should
| act as a stack, so you could do
| 
| #pragma GCC call_convention stdcall
| 
| ... declarations here ...
| 
| #pragma GCC call_convention pop

We've a precedent and well-standardized framework for specifying calling
convention (quoting from C++ standard): 

7.5/2

    extern string-literal { declaration-seq }
    extern string-literal declaration

   The string-literal indicates the required language linkage. The
   meaning of the string-literal is implementation-defined. A
   linkage-specification with a string that is unknown to the
   implementation is ill-formed. When the string-literal in a
   linkage-specification names a programming language, the spelling of
   the programming language s name is implementation-defined. [...]

7.5/4

  Linkage specifications nest. When linkage specifications nest, the
  innermost one determines the language linkage. A linkage
  specification does not establish a scope. A linkage-specification
  shall occur only in namespace scope (3.3). In a
  linkage-specification, the specified language linkage applies to the
  function types of all function declarators, function names, and
  variable names introduced by the declaration(s). 


I would strongly advise against reinventing the wheel through
pragmas.  Let's reuse well-understood and standard framework that fits
the same purpose.

-- Gaby


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