Contents

1. Introduction
2. About the Forte Developer 7 C Compiler
3. New and Changed Features
4. Software Corrections
5. Problems and Workarounds
6. Limitations and Incompatibilities
7. Documentation Errors

 

---

A. Introduction

This document contains information about the Forte[tm] Developer 7 C compiler. This document describes the new features that are included with this release, software software corrections that are addressed by this release, and lists known problems, limitations, and incompatibilities. Information in this document overrides information in the manuals for this release.

Information in the release notes overrides information in all readme files. To access the release notes and the complete Forte Developer documentation set, go to the documentation index at file:/opt/SUNWspro/docs/index.html. The documentation index provides access to the following C documents:

• C Compiler Readme
• C User's Guide
• Math Libraries Readme
• Numerical Computation Guide
• Incremental Link Editor Readme
• Sun Performance Library Readme
• Sun Performance Library Reference Manual
• Sun Performance Library User's Guide for Fortran and C

To view the text version of this readme, type the following at a command prompt:

   cc -xhelp=readme

To view the HTML version of this readme, go to:

   file:/opt/SUNWspro/docs/index.html

Note - If your Forte Developer 7 software is not installed in the /opt directory, ask your system administrator for the equivalent path on your system.

 

---

B. About the C Compiler

This release of the C Compiler is available on the Solaris[tm] operating environment (SPARC[tm] Platform Edition) versions 7, 8, and 9.

This compiler conforms with the following standards:

• The ISO/IEC 9899:1990, Programming Languages - C standard.
• The FIPS 160 standard.

This compiler also supports some of the features specified in the following standard:

• The ISO/IEC 9899:1999, Programming Language - C.
  See Support for Additional C99 Features for more information.

The 64-bit SPARC architecture features in this development release are support for the C International Standard and for -xarch=v9.

 

---

C. New and Changed Features

This section describes the following new and changed features for this release of the C compiler. For information about other Forte Developer components, see the What's New manual. To access this manual on your local system or network, go to file:/opt/SUNWspro/docs/index.html. You can also access this manual by going to http://docs.sun.com.

• Compiling for the Native Connector Tool
• Enhanced Interprocedural Optimizations (SPARC)
• New Prefetch Levels (SPARC)
• Stack-Overflow Checking (SPARC)
• Labels as Values
• Support for Additional C99 Features
• Improved Formatting Control of Error Messages
• Support for UltraSPARC IIICu Processor

• Compiling for the Native Connector Tool

  Use the -xnativeconnect option when you want to include interface information inside object files and subsequent shared libraries so that the shared library can interface with code written in the Java[tm] programming language (Java code). You must also include -xnativeconnect when you build the shared library with cc -G.

  When you compile with -xnativeconnect, you are providing the maximum, external, visibility of the native code interfaces. The Native Connector Tool (NCT) enables the automatic generation of Java code and Java[tm] Native Interface (JNI) code so that C shared libraries can be called from Java code. For more information on how to use the NCT, see the Forte Developer online help.

  -xnativeconnect[=a[,a]...]
  a can be one of the following: %all|%none|[no%]interfaces

  • If you do not specify -xnativeconnect, the compiler sets the option to -xnativeconnect=%none.
  • If you specify only -xnativeconnect, the compiler sets the option to -xnativeconnect=interfaces.
  • -xnativeconnect=interfaces forces the generation of Binary Interface Descriptors (BIDS).

  This option does not accumulate. The compiler uses the last setting that is specified.

• Enhanced Interprocedural Optimizations (SPARC)

  With -xipo=1, the compiler performs inlining across all source files. With -xipo=2, the compiler performs interprocedural aliasing analysis as well as optimizations of memory allocation and layout to improve cache performance.

• New Prefetch Levels (SPARC)

  Use the new -xprefetch_level=n option to control the aggressiveness of the automatic insertion of prefetch instructions as determined with -xprefetch=auto. n must be one of 1, 2, or 3. The compiler becomes more aggressive, or in other words, introduces more prefetches with each, higher, level of -xprefetch_level.

  The appropriate value for -xprefetch_level depends on the number of cache misses your application has. Higher -xprefetch_level values have the potential to improve the performance of applications with a high number of cache misses.

  This option is effective only when it is compiled with -xprefetch=auto, with optimization level 3 or greater (-xO3), and on a platform that supports prefetch (v8plus, v8plusa, v9, v9a, v9b, generic64, native64).

  • -xprefetch_level=1
    Enables automatic generation of prefetch instructions.
  
  
  
  • -xprefetch_level=2
    Targets additional loops, beyond those targeted at -xprefetch_level=1, for prefetch insertion. Additional prefetches may be inserted beyond those that were inserted at -xprefetch_level=1
    
    
  • -xprefetch_level=3
    Targets additional loops, beyond those targeted at -xprefetch_level=2, for prefetch insertion. Additional prefetches may be inserted beyond those that were inserted at -xprefetch_level=2

  For C, the default is -xprefetch_level=1 when you specify -xprefetch=auto.

• Stack-Overflow Checking (SPARC)

  Compiling with -xcheck=stkovf adds a runtime check for stack overflow of the main thread in a singly-threaded program as well as slave-thread stacks in a multithreaded program. If a stack overflow is detected, a SIGSEGV is generated. If your application needs to handle a SIGSEGV caused by a stack overflow differently than it handles other address-space violations, see sigaltstack(2).

  You can turn off stack-overflow checking by issuing -xcheck=no%stkovf.

  Defaults:

  • If you do not specify -xcheck, the compiler defaults to -xcheck=%none.
  • If you specify -xcheck without any arguments, the compiler defaults to -xcheck=%none.
  • The -xcheck option does not accumulate on the command line. The compiler sets the flag in accordance with the last occurance of the command.

• Labels as Values
  
  

  The C compiler now recognizes this extension to ANSI/ISO C which is also known as computed goto. Computed goto enables runtime determination of branching destinations. The address of a label can be acquired by using the '&&' operator and assigned to a pointer of type void *:

  void *ptr;
  ...
  ptr = &&label1;
  

  A later goto statement can branch to label1 through ptr:

  goto *ptr;
  

  Because ptr is computed at runtime, ptr can take on the address of any label that is in-scope and the goto statement can branch to it.

  One way of using computed goto is for the implementation of a jump table:

  static void *ptrarray[] = { &&label1, &&label2, &&label3 };
  

  Now the array elements can be selected by indexing:

  goto *ptrarray[i];
  

  Addresses of labels can only be computed from the current function scope. Attempting to take addresses of labels out of the current function yields unpredictable results.

  The jump table works similarly to a switch statement though there are some key differences and the jump table can make it more difficult to follow program flow. A notable difference is that the switch-statement jump-destinations are all in the forward direction from the switch reserved word; using computed goto to implement a jump table enables branching in both forward and reverse directions.

  #include <stdio.h>
  void foo()
  {
    void *ptr;
    
    ptr = &&label1;
    
    goto *ptr;
    
    printf("Failed!\n");
    return;
    
    label1:
    printf("Passed!\n");
    return;
  }
  
  int main(void)
  {
    void *ptr;
    
    ptr = &&label1;
    
    goto *ptr;
    
    printf("Failed!\n");
    return 0;
    
    label1:
    foo();
    return 0;
  }
  

  The following example also makes use of a jump table to control program flow:

  #include <stdio.h>
  
  int main(void)
  {
    int i = 0;
    static void * ptr[3]={&&label1, &&label2, &&label3};
    
    goto *ptr[i];
  	
    label1:
    printf("label1\n");
    return 0;
  
    label2:
    printf("label2\n");
    return 0;
  
    label3:
    printf("label3\n");
    return 0;
  }
  
  example% a.out
  example% label1
  
  

  Another application of computed goto is as an interpreter for threaded code. The label addresses within the interpreter function can be stored in the threaded code for fast dispatching.

  Here is an alternate way to write the above example:

  static const int ptrarray[] = { &&label1 - &&label1, &&label2 - &&label1, &&label3 - &&label1 };
  goto *(&&label1 + ptrarray[i]);
  

  This is more efficient for shared library code, as it reduces the number of dynamic relocations that are needed, and by consequence, allows the data (ptrarray elements) to be read-only.

 

• Support for Additional C99 Features

  This release of the C compiler provides support for the following C99 features in addition to the supported C99 features from the last release.

  Note: Though the compiler support-level defaults to the features of C99 listed below, the standard headers provided by Solaris in /usr/include do not yet conform with the 1999 ANSI/ISO C standard. If you encounter error messages, try using -xc99=%none to obtain the 1990 ANSI/ISO C standard behavior for these headers.

  The -xc99 flag controls compiler recognition of the implemented features from the C99 standard (ISO/IEC 9899:1999, Programming Language - C).

  -xc99=[%all|%none]

  If you do not specify -xc99, or specify -xc99 without =%none, the compiler assumes -xc99=%all. -xc99=%all turns on recognition of the C99 features implemented so far.

  1. Idempotent Qualifiers
  2. _Pragma
  3. Mixed Declarations and Code
  4. Static and Other Type Qualifiers Allowed in Array Declarators
  5. Flexible Array Members
  6. Disallowed Implicit int and Implicit Function Declarations
  7. Declaration in for Loop-Statement
  8. Keywords
  9. __func__
  10. Macros With Variable Number of Arguments
  11. Variable Length Arrays (VLAs)
  12. inline Specifier for Static Functions
  13. Commenting Code With //

   

  1. Idempotent Qualifiers

     C99 6.7.3 Type qualifiers:
     If the same qualifier appears more than once in the same specifier-qualifier-list, either directly or through one or more typedefs, the behavior is the same as when the type qualifier appears only once.

     In C90, the following code would cause an error:

     example% cat test.c
     
     const const int a;
     
     int main(void) {
       return(0);
     } 
     
     example% cc -xc99=%none test.c
     "test.c", line 1: invalid type combination
     

     The Forte Developer 7 C compiler accepts multiple qualifiers.

     example% cc -xc99 test.c
     example% 
     

  2. _Pragma

     C99 6.10.9 _Pragma operator:
     The new unary operator expression _Pragma(string) is supported. _Pragma offers an advantage over #pragma in that _Pragma can be used in a macro definition. _Pragma(string) behaves exactly the same as #pragma string.

  3. Mixed Declarations and Code

     C99 6.8.2 Compound statement
     The C compiler now accepts mixing type declarations with executable code as shown by the following example:

     #include <stdio.h>
     
     int main(void){
       int num1 = 3;
       printf("%d\n", num1);
       int num2 = 10;
       printf("%d\n", num2);
       return(0);
     }
     

  4. Static and Other Type Qualifiers Allowed in Array Declarators

     C99 6.7.5.2 Array declarator:
     The keyword static can now appear in the Array declarator of a parameter in a function declarator to indicate that the compiler can assume at least that many elements will be passed to the function being declared. Allows the optimizer to make assumptions about which it otherwise could not determine.

  5. Flexible Array Members

     C99 6.7.2.1 Structure and union specifiers
     Also known as the "struct hack". Allows the last member of a struct to be an array of zero length, such as int foo[]; Such a struct is commonly used as the header to access malloced memory.

     For example, in this structure, struct s { int n; double d[]; } S;, the array, d, is an incomplete array type. The C compiler does not count any memory offset for this member of S. In other words, sizeof(struct s) is the same as the offset of S.n.

  6. Disallowed Implicit int and Implicit Function Declaration

     C99 6.7.2 Type specifiers:
     At least one type specifier shall be given in the declaration specifiers in each declaration.

     Impicit declarations are no longer allowed in the 1999 C standard as they were in the 1990 C standard. Previous versions of the C compiler issued warning messages about implicit definitions only with -v (verbose). These messages and new additional warnings about implicit definitions, are now issued whenever identifiers are implicitly defined as int or functions.

     This change is very likely to be noticed by nearly all users of this compiler because it can lead to a large number of warning messages. Common causes include a failure to include the appropriate system header files that declare functions being used, like printf which needs included. The 1990 C standard behavior of accepting implicit declarations silently can be restored using -xc99=%none.

  7. Declaration in for Loop-Statement

     C99 6.8.5 Iteration statements
     The C compiler now accepts a type declaration as the first expression in a for loop-statement:

     for (int i=0; i<10; i++){ //loop body };
     

     The scope of any variable declared in the initialization statement of the for loop is the entire loop (including controlling and interation expressions).

  8. Keywords
     
     C99 6.4.1 Keywords:
     The C99 standard introduces the following new keywords. The compiler issues a warning if you use these keywords as identifiers while compiling with -xc99=%none. Without -xc99=%none the compiler issues a warning or an error message for use of these keywords as identifiers depending on context.
     • inline
     • _Imaginary
     • _Complex
     • _Bool
     • restrict

     An object that is accessed through a restrict qualified pointer requires that all accesses to that object use, directly or indirectly, the value of that particular restrict qualified pointer. Any access to the object through any other means may result in undefined behavior. The intended use of the restrict qualifier to allow the compiler to make assumptions that promote optimizations.

     See Appendix D of the C User's Guide for more information.

  9. __func__

     C99 6.4.2.2 Predefined Identifiers:
     The compiler provides support for the predefined identifier __func__. __func__ is defined as an array of char which contains the name of the current function in which __func__ appears.

  10. Macros With Variable Number of Arguments

      6.10.3 Macro replacement.
      Macros with variable arguments are now accepted.

      debug(a, ...) fprintf(stderr, __VA_ARGS__)

  11. Variable Length Arrays (VLAs)

      C99 6.7.5.2 Declarators:
      VLAs are allocated on the stack as if by calling the alloca function. Their lifetime, regardless of their scope, is the same as any data allocated on the stack by calling alloca; until the function returns. The space allocated is freed when the stack is released upon returning from the function in which the VLA is allocated.

      The compiler provides C99 support for VLAs. Not all constraints are yet enforced. Constraint violations lead to undefined results.

      #include <stdio.h>
      
      void foo(int);
      
      int main(void) { 
        foo(4);
        return(0);
      }
      
      void foo (int n) {
        int i;
        int a[n];
      
        for (i = 0; i < n; i++)
          a[i] = n-i;
      
        for (i = n-1; i >= 0; i--)
          printf("a[%d] = %d\n", i, a[i]);
      }
      
      example% cc test.c
      example% a.out
      a[3] = 1
      a[2] = 2
      a[1] = 3
      a[0] = 4
      

  12. inline Specifier For Static Functions

      C99 6.7.4 function-specifier: inline
      The C99 function-specifier inline has been added. inline is fully functional for functions with internal linkage. For functions defined with external linkage use of the inline function-specifier creates an inline definition only, no external definition of the function is created. Thus pointers to inline functions with external linkage are unique to each translation unit and do not compare as equal.

  13. Commenting Code With //

      6.4.9 Comments:
      The characters // introduce a comment that includes all multibyte characters up to, but not including, the next new-line character except when the // characters appear within a character constant, a string literal, or a comment.

 

• Improved Formatting Control of Error Messages

  The compiler now offers two new options which you can use to change the formatting of error messages:

  • -errfmt[=[no%]error]
    Specify this option if you want to prefix the string "error:" to the beginning of error messages so they are more easily distinguishable from warning messages. The prefix is also attached to warnings that are converted to errors by -errwarn.

    If you do not specify this option, the compiler sets it to -errfmt=no%error. If you specify -errfmt, but do not supply a value, the compiler sets it to -errfmt=error.

  • -errshort=i
    Specify this option to control how much detail is in the error message produced by the compiler when it discovers a type mismatch. This option is particularly useful when the compiler discovers a type mismatch that involves a large aggregate.

    i can be one of the following:

    • short
      Error messages are printed in short form with no expansion of types. Aggregate members are not expanded, neither are function argument and return types.
    
    
    
    • full
      Error messages are printed in full verbose form showing the full expansion of the mismatched types.
    
    
    
    • tags
      Error messages are printed with tag names for types which have tag names. If there is no tag name, the type is shown in expanded form.

    If you do not specify -errshort, the compiler sets the option to -errshort=full. If you specify -errshort, but do not provide a value, the compiler sets the option to -errshort=tags. This option does not accumulate, it accepts the last value specified on the command line.




• Support for UltraSPARC IIICu Processor
  The compiler's -xtarget, -xchip, and -xcache options support the latest UltraSPARC processor, the UltraSPARC IIICu.

 

---

D. Software Corrections

The fix for bug 4522629, "Disagreement between C++ and C when returning a struct (C violates ABI)", breaks binary compatibility on sparc V9 architectures only.

The C compiler has been fixed to fully conform to the v9 ABI. The fix affects any code with a function definition or function reference in which the return value, or any argument, is defined as a small struct that contains an array of type float, double, or long double. A small struct is defined as 16 bytes for arguments, 32 bytes for return values. The incompatibility causes undefined behavior and exists if the function definition and all function references have not all been recompiled using the Forte[tm] Developer 7 C compiler for Early Access 2.

Binaries compiled with earlier versions of the Forte Developer or DevPro compilers that do not have the appropriate patch and that have function definitions or function references where the return value or any argument is defined as a small struct containing an array of floating-point type, are incompatible with binaries compiled with the Forte Developer 7 C compiler for Early Access 2.

The following patched compilers fully conform to the v9 ABI and produce binaries that are compatible in all respects with Forte Developer 7 C version 5.4:

• Forte Developer 6 update 2 C 5.3 111679-04
• Forte Developer 6 update 1 C 5.2 109513-08

This fix is likely to only affect compatibility between programs compiled in C++ with extern C, calling C using small structs as described above. There are no known incompatibilites with any system libraries, as small structs as described below are not passed or returned.

The following is an example of a small struct containing an array of floating-point type:

typedef struct {
    double tf[4];
} t_st;

t_st myfunc(t_st arg) {
    t_st rv;
    return rv;
}

 

---

E. Problems and Workarounds

This section discusses known software problems and possible workarounds for those problems. For updates, check Forte Developer Hot Product News at http://www.sun.com/forte/fcc/hotnews.html.

• OpenMP-C: atomic expression syntax is not being checked (4380803)

  The OpenMP standard states that the expression statement for atomic must have one of the following forms:

  x binop = expr
  x++
  ++x
  x--
  --x
  

  The following example should have an error (or at least a warning that it does not conform to the standard):

  #include <omp.h>
  #include <stdio.h>
  
  void main(void)
  {
    int i;
  
    #pragma omp parallel
    {
      #pragma omp atomic
      i = i + 1;                            /* expression error */
      printf("t#: %i  i: %i\n", omp_get_thread_num(), i);
    }
  }
  

 

---

F. Limitations and Incompatibilities 

This section discusses limitations and incompatibilities with systems or other software. There is no new information for this release.

 

---

G. Documentation Errors 

• The -xalias_level command is specific to the SPARC architecture. The C User's Guide for Forte Developer 6 update 2 does not specify this fact.

 

---

Copyright © 2002 Sun Microsystems, Inc., All rights reserved. Use is subject to license terms.