Douglas Walls' Weblog

Sun Studio Express Program December 2006 Build available

Sun Studio Express Program December 2006 Build available

Want a peek at the latest Sun Studio Compilers and Tools under development from Sun?

The Sun Studio Express Program provides the Sun developer community with an early look at new features and technologies of the Sun Studio Compilers and Tools.  The Sun developer community can assess the benefits of the most current compiler and tools innovations.  Through the Sun Studio forums, the Sun developer community can ask question and give feedback, long before they are released as products.

Wonder if the next revision of the Sun Studio Compilers is going to give your application a performance boost?  Now you can find out.

The December 2006 Build includes a new Integrated Development Environment (IDE). The new Sun Studio IDE is based on NetBeans 5.5.1 and adds many new features. It supports C and C++ projects, and includes appropriate project templates for applications, dynamic and static libraries, and projects with existing code. The IDE includes a C and C++ class browser. The powerful language-aware built-in editor supports code completion. This build also includes C, C++, and Fortran compilers for the Linux platform, and improvements to the previously released Data Race Detection Tool, which has been renamed the Sun Studio Thread Analyzer.

So go check out the Sun Studio Express Program at:
http://developers.sun.com/prodtech/cc/downloads/express.jsp

Some of the other features being introduces with the June 2006 Build include:

• Sun C compiler accepts the attributes always_inline, noinline, pure, const, malloc and aligned are now supported by the __attributes__ clause.
• Sun C++ compiler recognizes __typeof__ keyword, __alignof__ expressions, and extern template
• All Sun compilers (C/C++/Fortran 95) generate DWARF 2 symbolic information on all platforms.
• Thread Analyzer (formerly known as the Data Race Detection Tool)

( Dec 19 2006, 03:03:22 PM PST ) Permalink Comments [0]

What About Binary Compatibility?

»What will happen if I try to run my application on a newer Solaris OS release?

»What will happen if I try to compile my application using one version of the Sun Studio compilers and link it with libraries compiled with earlier compiler versions?

Important questions to consider, and luckily both Solaris and the Sun Studio compilers guarantee a certain degree of binary compatibility between releases.

Here are some things to keep in mind

• Binary Compatibility among versions of Solaris:
  Executables created with a supported compiler release on an earlier Solaris OS version will run on later Solaris OS versions. This is part of the Solaris binary compatibility guarantee. Such executables might need the Sun Studio runtime libraries that are part of the compiler with which the executable was created. For example, an executable created using Forte Devloper 6 update 2 on Solaris 2.6, along with the shared runtime libraries of Forte Developer 6 update 2, will run correctly without recompilation or relinking on Solaris 10.
  
  
• Binary Compatibility among object files: 
  Libraries and object files created with an earlier release of a Sun Studio compile can be used when linking with a later versions of that compiler. When you link with a mixed set of object files and libraries created with different versions of the Sun Studio compilers, you must use the latest compiler that produced any of the object files or libraries being linked. For example, a shared object (.so) file created with an FD6u2 compiler can be used when linking with the Sun Studio 11 version of that same compiler.
  
  There are some important considerations for Fortran 95 with FD6u2:
  
  • If you compile with the -aligncommon option you should not mix object files produced by Forte Developer 6 update 2 Fortran 95 with objects produced by a later version of the compiler if the common blocks contain either derived types or variables typed with an explicit kind value.
    
  • Module information files generated by Forte Developer 6 update 2 release f95 compiler are not guaranteed to be compatible with future releases

---

Specific Questions I get often:

        »Can I compile my application on Solaris 10 and run it on Solaris 9 and Solaris 8?

No.  Might work, but since you compiled it on Solaris 10, it might also be using system interfaces that did not exist on Solaris 8 and 9 or have changed in Solaris 10.

        »Can I compile my application on Solaris 8 and run it on Solaris 9 and Solaris 10?

 Yes!  This is what binary compatibility is all about.  (See above)

        »Can I compile and build my shared library on Solaris 10 and use it on Solaris 9 and Solaris 8?

No.  Might work, but since you compiled it on Solaris 10, it might also be using system interfaces that did not exist on Solaris 8 and 9 or have changed in Solaris 10.

        »If I compile the code in my shared library using the Sun Studio 11 compilers, can my customers who are still using Forte 6 Update 1 compilers link with these shared libraries?

No.  You must always link with the same compiler used to create the newest objects in your application or library.  So, if Sun Studio 11 compilers are used to compile the code in a shared library, Sun Studio 11 compilers must be used when linking with that shared library.
 

( Dec 04 2006, 02:19:06 PM PST ) Permalink Comments [3]

October 23-27 meeting of ISO SC22 WG14, the C programming language committee (Part 3 of 3)

Highlights of the October 23-27 meeting of ISO SC22 WG14, the C programming language committee:

• Lawrence Crowl of Google gave a presentation on where C++ threads is going.
• A proposal for Sequence Points work for the C rationale.  This is in response to C++ threads work in understanding sequence points.
• Proposal to augment the interface of malloc, et al.
• DTR 24732, Decimal Floating Point headed for final balloting after some minor updates.
• DR review
• TR24731, Part II, Bounds Checking via dynamic allocation.
• We also had a visitor this meeting, Ulrich Drepper from Red Hat, Ulrich talked about his perceptions of the future of C.  This lead to the main surprise of this meeting, committee sentiment to consider opening the C standard for another revision.
  

Here are the details on Decimal Floating Point, Bounds Checking, and couple of DRs.

Details (Part III):

DTR 24732, Decimal Floating Point.

Discussion of the National Bodies comments on the draft were reviewed in detail.  This lead to some minor changes to the draft.  There will be a small review committee to incorporate these changes.  The WG14 convenor will then forward that draft to SC22 for final ballot.

IBM is the only company known to have hardward to support Decimal Floating Point at this time ...

---

TR24731, Part II, Bounds Checking. N1193 (Stoughton)

This document is a proposed Part II to TR24731, Bounds Checking via dynamic allocation.  There is no invention here. All of the functions already exist in implementations, particularly in POSIX.  The document is organized the same way as Part I.   The intent of this document is to provide programmers with an additional mechanism to address issues of buffer overflow, etc., as does Part I.  A key difference is that the mechanisms are via dynamic memory allocation, and heavily dependent on malloc.  There are some minor changes that need to be made, the document is still a working draft, but it has sufficient substance to be ready for CD registration.  Small editorial group to go over the document.

---

We went through all the open and under review DRs.  Those of interest to us include:

DR 329  (N1181) Math functions and directed rounding

The result is DBL_MIN*DBL_EPSILON, a subnormal number. But, if the implementation does not support subnormal numbers, such as IBM S/360 hex floating-point, then it is either zero or DBL_MIN, depending upon the current rounding direction mode. Hence, the sentence "Thus, the remainder is always exact." in footnote 204 in C99+TC1+TC2 (N1124) is wrong. This problem also applies to remquo and fmod.

Issue for non-754 implementations.

remove the sentence from the footnote, move the rest of the edits to annex f, instead of section 7

DR 332  (N1194)  gets is generally unsafe

Committee consensus to have words crafted to deprecate gets. This is a political issue in response to lots of bashing of the committee being non responsive to the security issues. Which of course is not true, but WG14 wants to soften the rhetoric.

Proposed Technical Corrigendum:

Add to subclause 7.26.9 (future library directions for ):

The gets function is obsolescent, and its use is deprecated.

[Note: Rationale wording might be useful.] [Editorial note: add a forward reference to this from gets subclause 7.19.7.7.]

Reviewed state in Portland 10/06 Expedited, will include in TC3 pending results of the disposition of this DR (DR 332) by WG14

---

Tom Plum Report: Macro Regions Proposal

This effort is essentially in the 'stalled' proposal list within the Evolution Working Group (EWG) in C++ (WG21/J16).  Tom believes it solves real problems with the preprocessor.  There is opposition within this committee to changing the C Standard.

( Nov 20 2006, 08:49:10 AM PST ) Permalink Comments [0]

October 23-27 meeting of ISO SC22 WG14, the C programming language committee (Part 2 of 3)

 

Highlights of the October 23-27 meeting of ISO SC22 WG14, the C programming language committee:

• Lawrence Crowl of Google gave a presentation on where C++ threads is going.
• A proposal for Sequence Points work for the C rationale.  This is in response to C++ threads work in understanding sequence points.
• Proposal to augment the interface of malloc, et al.
• DTR 24732, Decimal Floating Point headed for final balloting after some minor updates.
• DR review
• TR24731, Part II, Bounds Checking via dynamic allocation.
• We also had a visitor this meeting, Ulrich Drepper from Red Hat, Ulrich talked about his perceptions of the future of C.  This lead to the main surprise of this meeting, committee sentiment to consider opening the C standard for another revision.
  

Here are the details on augmenting the interface of malloc, modeling sequence points to aid C++ work on concurrency, and committee discussions on revising the C standard.

Details (Part II):

Tom Plum Report #2, WG21/N1085 C++ Proposal to augment the interface of malloc, et al.

WG21/N1085 is a proposal by Howard Hinnant. Ulrich wants to add alignment considerations to this C++ proposal.  POSIX is now using a function called posix_memalign() that seems suitable for the original proposal.  That function came from an X/Open function named memalign(). Some of the members of J11 believe a function of this sort would be useful for C as well. Ulrich expressed concern that C++ might put a different spin on this. Bill Plauger prefers that we not push this work on to C++.  Sees it as simply adding to layers of complexity.   It's not clear whether or not C++ will even ever adopt this. Bill Plauger sees it as low on the list of things to do.

After much debate and several straw polls we agreed to this Liaison Report

WG14 urges WG21 to incorporate into the next C++ revision ("C++0x"):

1. The functions sizeof_alloc and resize_alloc from WG14/N1085 ("Proposal to augment the interface of malloc/free/realloc/calloc", by Howard Hinnant); and
2. A function along the lines of posix_memalign - see www.opengroup.org/onlinepubs/000095399/functions/posix_memalign.html

---

Sequence Points

N1188 is a paper that explains the C language sequence point model, and may be suitable as an addition to the C99 rationale.  The difficulty seems to be in determining all the possible orderings of sequence point, which makes teaching it difficult.

Making use of the model here is important in providing liaison input to C++ for their concurrency model. We want to make sure our underlying model does not get broken by C++ concurrency. We have plenty of time to get this in the C99 rationale, but there is more urgency in nailing down our model for C++ concurrency.

---

Future of C - Ulrich Drepper

Ulrich believes that the state of C compiler development is such that the C Standard is well behind the technology being used by the community. Virtually all major C compiler developers have developed extensions to the language that go well beyond the Standard. We can either subsume ourselves to C++, or plan on revising the C Standard to adopt existing technologies.  Bill Plauger pointed out that our pace has been deliberate, and that adoption of C99 has been slow.  We probably should consider reopening the Standard soon, and look at adopting things like multi-treading, security features, and others.  Ulrich believes we should focus on existing practice, features that are in wide use, minimize the risk of standardizing features that no one will use.  Doug Gwyn believes that C will have longevity in embedded programming, but that if we work on a 5 year schedule we should probably consider starting now.  There are a number of things that C can probably do better than other languages. Round table discussion on whether or not we should consider revising the C Standard.  David Keaton believes that are real commercial needs that C can address, such as security.  General feeling that making a decision to revise the C Standard with a focus on existing practice would be a good thing. Many developers make use of extensions to the language, some do not.  Invention of new feature sets is not a good idea.  John Benito: No one is saying no. If we are going to do this we will need to work on our charter, and proceed from there.

The next step. John Benito (WG14 Convenor): We need to start putting a charter together that will define the scope a revision to the C Standard.  Tom Plum is in favor of using the wiki as a vehicle to propose ideas.  Bill Plauger suggests using a full day in London to process such a list.  Start by generating a list, filter it based on criteria, then let the world know what we are doing.  We are not ruling out proposals from the outside.

( Nov 12 2006, 06:09:38 PM PST ) Permalink Comments [0]

October 23-27 meeting of ISO SC22 WG14, the C programming language committee (Part 1 of 3) Highlights of the October 23-27 meeting of ISO SC22 WG14, the C programming language committee:

• Lawrence Crowl of Google gave a presentation on where C++ threads is going.
• A proposal for Sequence Points work for the C rationale.  This is in response to C++ threads work in understanding sequence points.
• Proposal to augment the interface of malloc, et al.
• DTR 24732, Decimal Floating Point headed for final balloting after some minor updates.
• DR review
• TR24731, Part II, Bounds Checking via dynamic allocation.
• We also had a visitor this meeting, Ulrich Drepper from Red Hat, Ulrich talked about his perceptions of the future of C.  This lead to the main surprise of this meeting, committee sentiment to consider opening the C standard for another revision.

Details (Part I):

Here are the details on what Lawrence Crowl presented on where C++ threads is going ...

Lawrence Crowl gave a presentation on where C++ threads is going.  C++ is trying to make threads correspond to operating system threads, POSIX and Windows, but not cover all of the functionality. They will be heavyweight, preemptive, and independent. Not a replacement for existing Standards.  Presuming that all writes are available to all threads is not viable, and C++ wants to adopt a message memory model.

Sequencing has been redefined. Sequence points are gone. Relations are sequenced-before and indeterminately-sequenced.  A write-to and read-from a location that are not sequence-before and not indeterminately-sequenced results in undefined behavior.

The sequence rules have been extended to concurrency.  Relations are synchronizes-with and happens-before are based on acquire and release. Race conditions are defined. The existence of a race condition makes the program undefined.

A location is a non-bitfield primitive data object. Adjacent bitfields together constitute a single location, enables unsynchronized read-modify-write.

The C++ Committee decided there needs to be some compromised between the language and the hardware.  Ulrich has an opinion that needs to be communicated back to WG21 via liaison. He has been talking with Hans Boehm in WG21 about this and prefers to have the POSIX type binding for threads (pthreads).

Optimizers are affected. Some speculative writes and reads are no longer legal. Loops without synchronization may be assumed to terminate.

All threads observe the same sequence of values for an atomic type. Atomic operations acquire, release, both, and neither. Atomic types are struct, but could be primitive type. Operators are type generic macros in C. The default assignment operator for both C and C++ is wrong, and cannot be disable in C99. It can be disable in C++98, but doing so breaks C/C++ compatibility.  C++ has a template for making any type atomic.

The types are comprehensive over the important primitive types: atomic_flag, atomic_bool, atomic_integers, atomic_void_pointer.  Atomics may be compiled by both C and C++.  Atomic operations must be lock-free to be used in signals. A macro will indicate if a type is lock-fee. Atomic operations must be address-free if used between processes. If an operation is lock-free , it must also be address-free.  Sequential consistency is not settled, and can be affected by hardware design. Example: How to program 'total store order'. Experts doubt whether mortals can program effectively without a total store order.

Thread-local storage has been implemented by at least five vendors. Some have slightly different syntax. A new thread duration has been defined. Dynamic initialization and destruction of static-duration variables can be tricky.  Without implicit synchronization, there is the potential for data races. With implicit synchronization, there is the potential for deadlock.

The thread semantic model initiates a thread with a fork on a function call (semantically like pthreads). Join waits for the function to return.  Some open questions remain. Is there a test for ready for join? Is there a join with a timeout? Does join return a function value?

Mutexes provide mutual exclusion. The Standard (C++) will have a least a simple mutex, and may have read-write and reentrant mutexes. Conditional variables enable the monitor paradigm. Threads may wait on a conditional variable.

Thread termination is voluntary. Return form outermost function, likely to have some form of cooperative termination, possible have some for of synchronous cancellation (exists in Windows) and there is strong opposition to asynchronous cancellation.  Thread scheduling is limited.

Locks hold a mutex within a given scope.

Higher level primitives may be built on primitives such as tread pools, thread groups, parallel iterators, etc.

Further threads work is being prepared for inclusion in C++ TR2, which will follow the next revision of C++ scheduled for 2009.

---

I'll cover the other topics in some future postings

( Nov 03 2006, 03:44:58 PM PST ) Permalink Comments [0]

Sun Studio 11 Training Now Available!
href=http://www.sun.com/training/catalog/courses/WP-100-S10.xml

This web based training introduces Solaris software platform developers to Sun Studio software. It provides developers with an overview of how to compile, edit, debug, and analyze performance with Sun Studio.
( Sep 05 2006, 11:34:58 AM PDT ) Permalink Comments [0]

Resolving problems creating reproducible binaries using Sun Studio Compilers

Certain flags (-g, -xipo, -xcrossfile) invoke features of the Sun
Studio Compilers and tools that must make static data global.  To avoid
namespace collisions, the data is globalized using a unique
globalization prefix.  The drawback of using a unique globalization
prefix is that the resulting object files will be different every time
the source file is compiled, even though the sources and compilation
options are identical.  So, if you compare the resulting object files
from two identical compilations they will differ.

If you are in an environment that requires the ability to reproduce
identical object files, this becomes a problem.

Both C and C++ have an undocumented flag (-xglobalstatic) that can be
passed to the compiler front-end which will force the use of a static
globalization prefix based on the source filepath, instead of the usual
algorithm that guarantees a unique prefix.  To pass the flag to cc use
the -W0 option as follows:

cc -W0,-xglobalstatic

To pass the flag to CC use the -Qoption ccfe option as follows:

CC -Qoption ccfe -xglobalstatic

The drawback to using the filepath to generate the globalization prefix
is the increased risk of a namespace collision at link time between
static data with the same name that has been globalized from two files
with the same filepaths.  Though rare it does occur more often than
using a randomly generated prefix.

If you do run into namespace collisions, you might need to assign
the globalization prefix.  For C this can be done with the
wizard option -W0,-xp<prefix>, for example:

-W0,-xp\$XAqalkBBa5_D2Mo

For C++ this can be done with the wizard options
-Qoption ccfe -prefix -Qoption ccfe <prefix>, for example:

-Qoption ccfe -prefix -Qoption ccfe \$XA0ZlkBtDTxEGkV.

( Jul 24 2006, 02:45:48 PM PDT ) Permalink Comments [1]

Linux Technology Preview, Build 24 - June 2006

Update: Sun Studio Compilers for Linux Technology Preview

We've just made Build 24 - June 2006 available for download visit:
http://developers.sun.com/prodtech/cc/downloads/tech_preview.jsp

Some of the features changes available in this update include:

• OpenMP support for cc and f95
• -xipo, whole-program interprocedural optimization

• For Sun C and C++ compilers:

• For Fortran compiler:

( Jun 27 2006, 05:55:27 PM PDT ) Permalink Comments [0]

Sun Studio Express Program June 2006 Build

Sun Studio Express Program June 2006 Build

Want a peek at the latest Sun Studio Compilers and Tools under development from Sun?  The Sun Studio Express Program provides the Sun developer community with an early look at new features and technologies of the Sun Studio Compilers and Tools.  The Sun developer community can assess the benefits of the most current compiler and tools innovations.  Through the Sun Studio forums, the Sun developer community can ask question and give feedback, long before they are released as products.

Wonder if the next revision of the Sun Studio Compilers is going to give your application a performance boost?  Now you can find out.

With the June 2006 Build, the Sun Studio Express Program is featuring the Data Race Detection Tool (DRDT), a cool new tool for datarace detection in OpenMP, threaded and parallel programs.  DRDT works with code written using the POSIX thread API, the Solaris Operating System(R) thread API, OpenMP directives, Sun parallel directives, Cray(R) parallel directives, or a mix of these.

So go check out the Sun Studio Express Program at:
http://developers.sun.com/prodtech/cc/downloads/express.jsp

Some of the other features being introduces with the June 2006 Build include:

• For Sun C and C++ compilers

• For Fortran compiler:

• Sun Performance Library:

• lock_lint a static data race and deadlock detection tool for C programs is now available on Solaris Intel

• For the Analyzer:

( Jun 26 2006, 08:00:25 PM PDT ) Permalink Comments [0]

Report bugs on Sun Studio Compilers and Tools at bugs.sun.com
You can now report bugs on Sun Studio Compilers and Tools at bugs.sun.com.

Here is how:

• Visit bugs.sun.com
• Select "Report a Bug" under Bug Database list on the right hand side of the page.
• Check the box under header "Submit a Bug", and click on button "Start a new Report"
• Under *Product/Category *pulldown menu, you will see 8 entries for eight components under the main one "Sun Studio Compilers and Tools":

 

Check it out.

Comming soon, the ability to search for Sun Studio Compilers and Tools bugs at bugs.sun.com ...

( Jun 15 2006, 12:41:40 PM PDT ) Permalink Comments [0]

The real story on the cc command and the -xregs=frameptr option
Alas the Sun Studio 11 C User's Guide documentation about -xregs=frameptr and -fast expansion that includes -xregs=frameptr is incorrect to the point of being completely confusing.

http://docs.sun.com/source/819-3688/cc_ops.app.html Appendix B 2.16, Table B-5 -fast option description incorrectly list -fast on x86 as expanding to -xregs=no%frameptr.  That is not correct.  The -fast macro option on x86 expansion includes -xregs=frameptr.

Later in Appendix B at 2.129, near the end of the description of -xregs, exists the following incorrect sentence:

-xO5 has no effect what-so-ever on -xregs option.  The sentence should read:


Unfortunately the cc man page also has the equivalent errors incorrectly showing -fast expanding to -xregs=no%frameptr, and claiming -xO5 implies -xregs=frameptr.

---

So to recap, here is an accurate description of -xregs=frameptr, and how the -fast macro expands for cc on x86/64:

-xregs=frameptr    Tells the compiler it is allowed to use the frame-pointer
                              register as an unallocated callee-saves register for purposes
                              of optimization.

-xregs=no%frameptr  Tells the compiler it is NOT allowed to use the frame=pointer
                                   register for purposes of optimization.

The x86 default is -xregs=no%frameptr unless you specify the -fast macro option whose expansion includes -xregs=frameptr.

---

-xregs=frameptr allow the compiler to use the frame-pointer register (%ebp on IA32, %rbp on AMD64) as an unallocated callee-saves register.  Using this register as an unallocated callee-saves register may improve program run time. However, it also reduces the capacity of some tools to inspect and follow the stack. This stack inspection capability is important for system performance measurement and tuning.  Therefor, using this optimization may improve local program performance at the expense of global system performance.

• Tools, such as the Performance Analyzer, that dump the stack for postmortem diagnosis will not work.
• Debuggers (e.g adb, mdb, dbx) will not be able to dump the stack or directly pop stack frames.
• The dtrace performance analysis facility will be unable to collect information on any frames on the stack before the most recent frame missing the frame pointer.
• Posix pthread_cancel will fail trying to find cleanup handlers.
• C++ exceptions cannot propagate through C functions.

The failures in C++ exceptions occur when a C function that has lost its frame pointer calls a C++ function that throws an exception through the C function. Such calls typically occur when a function accepts a function pointer (for example, qsort) or when a global function, such as malloc, is interposed upon. The last two affects listed above may impact the correct operation of applications. Most application code will not encounter these problems.

---

Note some might also be confused by the following bullet item in the C man page ...

The documentation at the top of the cc man page about -xregs=no%frameptr is incorrect, it currently says:

     o A new x86-only flag for the -xregs option,
     -xregs=[no%]frameptr, lets you use the frame-pointer regis-
     ter as an unallocated callee-saves register to increase the
     run-time performance of applications.

This needs to be corrected to say:

     o A new x86-only flag for the -xregs option,
     -xregs=frameptr, lets you use the frame-pointer regis-
     ter as an unallocated callee-saves register to increase the
     run-time performance of applications.

---

Note the Sun Studio 10 C User's guide does not have these errors, i.e. it correctly describes -xregs=frameptr and -fast  ( Jun 02 2006, 02:59:24 PM PDT ) Permalink Comments [0]

C99 inline function and the Sun C Compiler
Note, the C standard says that inline is only a suggestion to the C compiler.  The C compiler can choose not to inline anything, and attempt to call the actual function.

The Sun C compiler does not inline C function calls unless optimizing at -xO3 or above.  And that inlining is done by the backends.  And then only if the backend's heuristics decide it is profitable to do so.  The Sun C compiler gives no way to force a function to be inlined.

For static inline functions it is simple.  Either a function defined with the inline function specifier is inlined at a reference or a call is made to the actual function.  The compiler can choose which to do at each reference.  The Sun C compiler decides if it is profitable to inline at -xO3 and above.  When not profitable to inline, or at an optimization of less than -xO3 a reference to the actual function will be generated.  If any reference to the actual function is generated the function definition will be generated in the object code.  Note if the address of the function is taken, the actual function will be generated in the object code.

Extern inline functions are more complicated.  There are two types of extern inline functions, an inline definition which never provides an extern (global) definition of the function and an extern inline function which always provide a global definition of the function.  To quote the C99 standard:

       [#6]  Any  function  with  internal linkage can be an inline
       function.   For  a  function  with  external  linkage,   the
       following restrictions apply: If a function is declared with
       an inline function specifier, then it shall also be  defined
       in  the  same  translation  unit.   If all of the file scope
       declarations for a function in a  translation  unit  include
       the  inline  function  specifier  without  extern,  then the
       definition in that translation unit is an inline definition.
       An inline definition does not provide an external definition
       for the function, and does not forbid an external definition
       in  another translation unit.  An inline definition provides
       an alternative to an external definition, which a translator
       may  use  to  implement any call to the function in the same
       translation unit.  It is unspecified whether a call  to  the
       function   uses   the  inline  definition  or  the  external
       definition.

       [#7] EXAMPLE  The declaration of  an  inline  function  with
       external   linkage   can   result   in  either  an  external
       definition, or a definition available for  use  only  within
       the  translation unit.  A file scope declaration with extern
       creates an external definition.  The following example shows
       an entire translation unit.

               inline double fahr(double t)
               {
                       return (9.0 * t) / 5.0 + 32.0;
               }

               inline double cels(double t)
               {
                       return (5.0 * (t - 32.0)) / 9.0;
               }

               extern double fahr(double);     // creates an external definition

               double convert(int is_fahr, double temp)
               {
                       /* A translator may perform inline substitutions */
                       return is_fahr ? cels(temp) : fahr(temp);
               }

       [#8]  Note  that  the  definition  of  fahr  is  an external
       definition because fahr is also declared  with  extern,  but
       the  definition  of  cels  is an inline definition.  Because
       cels has external linkage and  is  referenced,  an  external
       definition  has  to  appear in another translation unit (see
       6.9); the inline definition and the external definition  are
       distinct and either may be used for the call.

So, for an inline definition, the programmer is required to supply an extern definition of the function in another translation-unit for references to the function that are not inlined.

For an inline definition, the compiler must not create a global definition of the function.  That means any reference to an inline definition that is not inlined must be a reference to a global function defined elsewhere.  Put another way, the object file produced by compiling this translation unit will not contain a global symbol for the inline definition.  And any reference to the function that is not inlined will be to an extern (global) symbol provided by some other object file or library at link time.

For an extern inline function declared by a file scope declaration with the extern storage-class-specifier (i.e. the function definition and/or prototype), the compiler must provide a global definition of the function in the resulting object file.  The compiler can choose to inline any references to that function seen in the translation unit where the function definition has been provided, or the compiler can choose to call the global function.

The behavior of any program that relies on whether or not a function call is actually inlined, is undefined.

Note also an inline function with external linkage may not declare or reference a static variable anywhere in the translation-unit.

Definition of translation-unit: A source file and all of its includes, recursively.

Like it does for static functions, the Sun C compiler decides if it is profitable to inline a reference to an inline definition or an extern inline function at -xO3 and above.  When not profitable to inline, or at an optimization of less than -xO3 a reference to the global function will be generated.  Likewise a reference to the address of the function is always a reference to the global function.

The rules for C++ differ: a function which is inline anywhere must be inline everywhere and must be defined identically in all the translation units that use it.

gcc

The GNU C rules differ and are described in the GNU C manual, which can be found here http://gcc.gnu.org.

• A function defined with inline and without either extern or static keywords, will always cause a global function to be emitted.  gcc may inline references to the function within the object code for the translation-unit in which it appears.  And references to the function from other translation-units in the program will be satisfied by linking with this object code.

• For a function defined with "extern inline" a global function is never emitted.  References to the function are either inlined or are made to a global function that must be defined somewhere else.

• A function defined with "static inline" acts the same as C99.

Sun C compiler gcc compatibility for inline functions

To obtain behavior from the Sun C compiler that is compatible with gcc's implementation of extern inline functions for most programs, use the -features=no%extinl flag.  When this flag is specified the Sun C compiler will treat the function as if it was declared as a static inline function.

The one place this is not compatible will be when the address of the function is taken.  With gcc this will be an address of a global function, and with Sun's compiler the local static definition address will be used.

( May 22 2006, 08:11:19 AM PDT ) Permalink Comments [1]

Finding the canonical path to an executable
Below is a coding example of how an executable can determine the canonical path to itself on the file system.  Compiler drivers, like cc, CC, f95 need to do this in order to exec the component executables that compile a program.  For example, the compiler front-end, an optimizer, and a linker.

% cat findself.c
#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>

#ifndef MAXPATHLEN
#define MAXPATHLEN      1024
#endif

/* find_run_directory - find executable file in PATH
 * PARAMETERS:
 *      cmd     filename as typed by user
 *      cwd     where to return working directory
 *      dir     where to return program's directory
 *      run     where to return final resolution name
 * RETURNS:
 *      returns zero for success,
 *      -1 for error (with errno set properly).
 */
int
find_run_directory (char *cmd, char *cwd, char *dir, char **run)
{
    char                *s;

    if (!cmd || !*cmd || !cwd || !dir) {
        errno = EINVAL;         /* stupid arguments! */
        return -1;
    }

    if (*cwd != '/')
        if (getcwd (cwd, MAXPATHLEN - 1) == NULL )
            return -1;          /* cant get working directory */

    if (strchr (cmd, '/') != NULL) {
        if (realpath(cmd, dir) == NULL) {
            int lerrno = errno;
            if (chdir((const char *)cwd) == NULL)
                errno = lerrno;
            return -1;
        }
    } else {
#ifdef __linux__
        /* getexecname() not available on Linux */
        if (readlink("/proc/self/exe", dir, MAXPATHLEN) == -1) {
#else
        if (realpath(getexecname(), dir) == NULL) {
#endif
            int lerrno = errno;
            if (chdir((const char *)cwd) == NULL)
                errno = lerrno;
            return -1;
        }
    }

    s = strrchr (dir, '/');
    *s++ = 0;
    if (run)            /* user wants resolution name */
        *run = s;

    return 0;
}

char current_working_directory[MAXPATHLEN];
char run_directory[MAXPATHLEN];
char * run_exec_name = NULL;

int
main(int argc, char **argv)
{

    if ( !find_run_directory (argv[0],
                              current_working_directory,
                              run_directory, &run_exec_name) ) {
        (void)printf("argv[0] = %s\n"
                         "cwd = %s\n"
                         "run_dir = %s\n"
                         "run_exec = %s\n",
                     argv[0],
                     current_working_directory,
                     run_directory,
                     run_exec_name);
    } else {
        (void) printf("%s\n", "Unaable to find run directory.");
    }

    exit (0);
}


% cc findself.c -O -o prod/bin/findself
% ls
bin         findself.c  prod
% ls bin
findself
% ls -laF bin
total 6
drwxr-xr-x   2 me      staff        512 Mar  5 10:37 ./
drwxr-xr-x   4 me      staff        512 Mar  5 10:37 ../
lrwxrwxrwx   1 me      staff         20 Mar  5 10:37 findself -> ../prod/bin/findself*
% ls -laF prod/bin         
total 22
drwxr-xr-x   2 me      staff        512 Mar  5 10:37 ./
drwxr-xr-x   3 me      staff        512 Mar  5 10:37 ../
-rwxr-xr-x   1 me      staff       8992 Mar  5 10:37 findself*
% bin/findself
argv[0] = bin/findself
cwd = /home/me/blog
run_dir = /home/me/blog/prod/bin
run_exec = findself
% prod/bin/findself
argv[0] = prod/bin/findself
cwd = /home/me/blog
run_dir = /home/me/blog/prod/bin
run_exec = findself
% setenv PATH /home/me/bin:${PATH}
% findself
argv[0] = findself
cwd = /home/me/blog
run_dir = /home/me/blog/prod/bin
run_exec = findself
%


( May 08 2006, 06:36:27 PM PDT ) Permalink Comments [0]

Special Math Functions Draft Technical Report
There were three major items to come out of the Berlin ISO C standard committee meeting which will move forward in the process of becoming Technical Reports.

• Decimal Floating Point DTR
• Extensions to the C Library Part I: Bounds-checking interfaces DTR
• Special Math Functions DTR

I talked about the Decimal Floating Point and Bounds-checking interface Draft Technical Reports in previous blog entries:  Decimal Floating Point Types & Managed Strings.

Today, I'll briefly mention the Special Math Functions DTR, which the committee also is moving forward through the SC22 registration process.  These are essentially the same functions being adopted by C++ in their library TR, tailored to the C language.  They include, among others:

• Bessel functions
• confluent hypergeometric functions
• Neumann functions
• Riemann zeta function
• Legendre functions

For details of the functions in the draft have a look at the last committee draft:

http://www.dkuug.dk/jtc1/sc22/wg14/www/docs/n1051.pdf

During the committee discussions it was pointed out that the values computed with special math functions are very susceptible to ‘sensitivities’ based on the input values provided.  Outside of specific ranges, the values computed are essentially useless.  Thus, implementations of these functions are not likely to be nearly as robust as implementations of the C90, and C99 math libraries.  A few functions will likely be dropped from the TR in sync with those already dropped from the C++ TR.  WG14 will extract from the existing C++ TR, account for DRs that exist for the C++ TR, have a small editorial review committee review the document, and forward it to SC22 for registration.

( May 01 2006, 11:38:46 AM PDT ) Permalink Comments [0]

Linux Technology Preview #3
While in Berlin at the ISO C standards meeting Sun announced:

Linux Compiler Technology Preview (TP) #3

The announcement went out to the Sun Studio Forum for Linux users, here.
TP #3 has some interesting features:

• Closer feature parity with Solaris/x86/64, with features like OpenMP, -xautopar, TLS, -xipo, -xprofile all work on Linux now.
• And C++ is in much better shape.

Other than the usual 80/20 rule, i.e. we have 80% of the features working with 20% of the work, the only significant component of the Sun Studio compilers yet to be ported to Linux is the Sun Performance Library.

For more details see the SunStudio for Linux Forum where you can download the latest version.

You might also want to have a peek at the C/C++ Development NetBeans project.  ( Apr 24 2006, 11:24:37 AM PDT ) Permalink Comments [0]