IRIS Development Option 6.2

home *** CD-ROM | disk | FTP | other *** search

/ IRIS Development Option 6.2 / IRIS_Development_Option_6.2_814-0478-001.iso / relnotes / c_dev / ch3.z / ch3

Wrap

Text File | 1996-03-14 | 17KB | 528 lines

- 1 - 6.2 ANSI C Release Notes - 2 - DDDDooooccccuuuummmmeeeennnntttt NNNNuuuummmmbbbbeeeerrrr 000000007777----1111666655559999----000011110000 3. _N_e_w__F_e_a_t_u_r_e_s__o_f__T_h_i_s__R_e_l_e_a_s_e This chapter contains two sections. The first details significant changes between the 3.18/3.19 and 6.2 C compiler releases. The second details changes between the 6.1 and 6.2 C compiler releases. 3.1 _C_h_a_n_g_e_s _B_e_t_w_e_e_n _t_h_e _3._1_9 _a_n_d _6._2 _C_o_m_p_i_l_e_r _R_e_l_e_a_s_e_s Whereas the 3.19 C Compiler release supported compilation only in 32-bit mode, the 6.2 Compiler release supports compilation in three modes: 32-bit (-32), 64-bit (-64) and High Performance 32-bit (-n32). Each compilation mode can be explicitly set on the command line or through the use of the SGI_ABI environment variable. Thus, the following command: %setenv SGI_ABI -64 sets the default compilation mode to be -64. 3.1.1 _3_2_-_b_i_t__C_o_m_p_i_l_a_t_i_o_n_s The default compilation mode on all non-R8000 systems is -_3_2. In 32-bit mode, there are three differences between the 6.2 C compiler and the 3.19 C compiler: +o Starting with this release, default 32-bit compilations will produce mips2 objects instead of the mips1 objects generated in previous releases. +o Common object file format (COFF) is no longer supported. +o Use of the -_c compilation flag is no longer compatible with -_O_3 -_3_2. Instead of -_c use -_j. For more information about these flags, please check the _c_c(1) man pages. - 3 - 32-bit mode is limited to generating code for only the MIPS2 and MIPS1 ABI's. 3.1.2 _6_4_-_b_i_t__C_o_m_p_i_l_a_t_i_o_n_s The default compilation mode on R8000 systems is -_6_4. All SGI platforms support the development of -_6_4 applications, but the subsystems containing the appropriate libraries are not always installed by default. During installation, you may have to select subsystems with names like _p_r_o_d_u_c_t._s_w_6_4 for -_6_4 libraries. The 64-bit compilation mode employs the LP64 model, in which pointers and _l_o_n_g integral types are 64 bits wide. These new language semantics may require source modification when porting old code to a 64-bit system. Both _N_U_L_L and _s_i_z_e__t, among other types in the standard header files, become 64 bits wide in 64-bit mode. The new 64-bit ABI changes the subprogram interface protocol in such a manner that inconsistencies between the use and definition of subprograms may produce unpredictable results. NNNNooootttteeee:::: Always use a prototyped function in the scope of a correctly prototyped declaration of the function, and never mix prototyped and non-prototyped declarations for the same function. The new ABI also resulted in changes to the <_s_t_d_a_r_g._h> and <_v_a_r_a_r_g_s._h> macros, which make them incompatible with their -_3_2 counterparts. The -_6_4 compiler has a different front-end and back-end from the -_3_2 compiler, and the supported _c_c command-line options vary between the two modes of compilation. In particular, the -_w_l_i_n_t option is not available in 64-bit mode; instead, it provides a fuller set of diagnostics with the -_f_u_l_l_w_a_r_n option. Also, a variety of new options are provided in -_6_4 mode to tailor optimizations for a particular application. See the _c_c manual pages for further details. The set of diagnostic message numbers (and hence the application of the -_w_o_f_f command-line option), are completely different for -_6_4 and -_3_2 mode. - 4 - The 64-bit mode compiler allows inlining of arbitrary or individually specified functions, to a given depth of nesting, by means of the front-end command-line options -_W_f,-_i_n_l_i_n_e (inline any function), -_W_f,-_i_n_l_i_n_e__d_e_p_t_h=_n (inline functions up to _n levels of nested calls; the default is _n==0), -_W_f,- _i_n_l_i_n_e=_F_1:_F_2:...:_F_n (inline functions named _F_1, _F_2, ..., and _F_n). An extended set of intrinsic functions are supported in 64-bit mode. These are indicated for a function _o_p as: #pragma intrinsic(_o_p) in <_m_a_t_h._h>, <_s_t_r_i_n_g._h>, <_c_u_r_s_e_s._h>, and <_s_t_d_i_o._h>. The intrinsic functions in <_c_u_r_s_e_s._h> and <_s_t_d_i_o._h> will only be inlined in terms of more specialized functions when the command-line option -_O_P_T:_f_a_s_t__i_o is used. Otherwise, the handling of intrinsics is the same in 64-bit mode as in 32-bit mode. In 64-bit mode, the "typedef" storage class specifier cannot apply to a prototyped parameter. In 32-bit mode this is allowed, but with a warning and ambiguous semantics: should we treat it as a typedef and a parameter or exclusively one or the other? Note that a typedef declaration in a list of unprototyped parameter declarations is acceptable in -_c_c_k_r mode, both for 32-bit and 64-bit compilations. (ANSI/ISO 9899-1990: sections 6.7.1 and 6.5.4.3). Error diagnostics are issued for implicit conversions between integral types and pointer types, as well as between integral types and struct types, in ANSI conformance modes (-_a_n_s_i, -_x_a_n_s_i, -_a_n_s_i_p_o_s_i_x). We have no intention of allowing such (extremely error-prone and non- portable) implicit conversions in any ANSI conformance mode, and the error diagnostics will indicate source code that needs to be fixed. Note that such implicit conversions may compile with warnings instead of errors in -_c_c_k_r mode. The following will produce an error message in all modes: - 5 - struct X {int i;} *j, *k; main() { j = k?k:k?0:0; } since k?0:0 always will be considered an int, as opposed to a ``null pointer'' expression, which is incompatible with the pointer operand k. There are also other differences in the diagnostics provided in 32-bit versus 64-bit mode, and we are generally a little stricter in enforcing ANSI C rules in 64-bit mode. 64-bit mode is limited to generating code for only the MIPS4 and MIPS3 ABI's. Refer to the _M_I_P_S_p_r_o _C_o_m_p_i_l_i_n_g, _D_e_b_u_g_g_i_n_g _a_n_d _P_e_r_f_o_r_m_a_n_c_e _T_u_n_i_n_g _G_u_i_d_e, the _M_I_P_S_p_r_o _6_4-_B_i_t _P_o_r_t_i_n_g _a_n_d _T_r_a_n_s_i_t_i_o_n _G_u_i_d_e, and the _c_c(1) man pages for a full description of the differences between 32-bit and 64-bit compilation. 3.1.3 _N_3_2__C_o_m_p_i_l_a_t_i_o_n_s Compilation in the High Performance 32-bit (N32) mode must be specified either at the command line (i.e. %cc -n32 foo.c) or through the use of the SGI_ABI environment variable (i.e. %setenv SGI_ABI -n32). It is not the default compilation mode on any platform. N32 incorporates data type sizes from 32-bit mode with calling conventions and code generation from 64-bit mode. Thus, it will be easier to port 32-bit applications to N32 rather than to 64-bits, but N32 retains the performance benefits of MIPS IV instructions for floating point intensive applications. The -_n_3_2 compiler has the same front-end and back-end as the -_6_4 compiler and the supported _c_c command-line options and diagnostic messages are identical under these two modes of compilation. N32 compilations are limited to generating code for only the MIPS4 and MIPS3 ABI's. - 6 - For more information about N32, please consult the _M_I_P_S_p_r_o _N_3_2 _A_B_I _H_a_n_d_b_o_o_k. 3.1.4 _C_u_s_t_o_m__M_e_m_o_r_y__A_l_l_o_c_a_t_o_r Bundled with this release is the customalloc memory allocation package written by Dirk Grunwald and Benjamin Zorn of the University of Colorado at Boulder. It is packaged in the _c__d_e_v._s_r_c._c_u_s_t_o_m_a_l_l_o_c subsystem which also contains the source file for its man page. The man page provides additonal information about this memory allocator and can be viewed by executing the following commands: %cd usr/share/src/customalloc %man -d customalloc.man 3.2 _C_h_a_n_g_e_s _B_e_t_w_e_e_n _t_h_e _6._1 _a_n_d _6._2 _C_o_m_p_i_l_e_r _R_e_l_e_a_s_e_s Whereas the 6.1 C Compiler release supported compilation only in 32-bit mode and 64-bit mode, the 6.2 Compiler release supports these two modes and introduces the High Performance 32-bit (-n32). Each compilation mode can be explicitly set on the command line or through the use of the SGI_ABI environment variable. Thus, the following command: %setenv SGI_ABI -n32 sets the default compilation mode to be -n32. This section highlights the differences between the 6.2 and 6.1 C Compiler releases under the 32-bit and 64-bit modes. For an introduction to N32 please refer to the section above. 3.2.1 _3_2_-_b_i_t__C_o_m_p_i_l_a_t_i_o_n_s In 32-bit mode, there are two differences between the 6.2 C compiler and the 6.1 C compiler: +o Starting with this release, default 32-bit compilations will produce mips2 objects instead of the mips1 objects generated in previous releases. - 7 - +o Common object file format (COFF) is no longer supported. 32-bit mode is limited to generating code for only the MIPS2 and MIPS1 ABI's. 3.2.2 _6_4_-_b_i_t__C_o_m_p_i_l_a_t_i_o_n_s In 64-bit mode, there are three differences between the 6.2 C compiler and the 6.1 C compiler: +o The 6.2 release of the ANSI C compiler is incompatible with 6.1 release in the way small (4 bytes or less) C structures and unions are passed as parameters when compiled -64 or -n32. As a result, both the caller and the callee functions must be compiled with the same version of the compiler, if they use small structures or unions as parameters. Under our 64-bit and n32 calling conventions, small structures or unions are left justified when passed as parameters. The 6.1 release of the compiler implemented the convention incorrectly in code of both the callee and caller functions, but in a consistent way (Code passing small structs still "worked"). This bug has been fixed, but this results in the incompatibility described above. +o The default level of enabled exceptions for speculative code motion (-TENV:X=n) has been changed to X=1 at all optimization levels. This change was made to provide the most uniform behavior across all SGI platforms. For the 6.1 release, this level was documented to be X=1, but implemented as X=3. As a result, some applications running on R8000 systems may experience performance degradation if they are recompiled with the default flags. If this performance degradation is significant, you should recompile with -TENV:X=3 explicitly set in your compilation command line. For more information about this flag, please check the _c_c(1) man pages. +o New processor specific fast floating point math libraries (libfastm) are being provided for the R8000, R10000 and R5000. Their locations can be added to the linker library search path by adding -_r_8_0_0_0, - 8 - -_r_1_0_0_0_0 and -_r_5_0_0_0 to your compilation line. For more information about these flags, please check the _c_c(1) man pages.