* COMPONENT_NAME: (vac) C for AIX compiler * * FUNCTIONS: README * * (C) COPYRIGHT International Business Machines Corp. 1994,1996,1997,1998 * * All Rights Reserved. * Licensed Materials - Property of IBM * * US Government Users Restricted Rights - Use, duplication or * disclosure restricted by GSA ADP Schedule Contract with IBM Corp. * =========================================================================== The name for this compiler is C for AIX 4.4. The number is the version of the compiler. It is not the version of the OS. These filesets install files to the /usr/vac directory. There are no executables present in /usr/bin, due to conflicts with the existing C for AIX and C Set ++ for AIX 3.1.4 products. This product will overwrite the C for AIX 4.1 and 4.3 compiler in /usr/vac. If you have the C for AIX 4.1/4.3 compiler installed, you should uninstall it before installing C for AIX 4.4. To uninstall C for AIX 4.1/4.3, enter: installp -u vac installp -u memdbg If you do not uninstall previous C for AIX 4.1/4.3 compilers, then you may have incorrect functionality with regards to library placements. WARNING: If you ran the script replaceCSET to replace the links in /usr/bin, then you should run it again after installing AIX 4.4. Otherwise, your users may suffer unexplained failures. You can check whether you have ran the replaceCSET script by checking the actual links in /usr/bin/xlc: Enter: ls -l /usr/bin/xlc If it is: lrwxrwxrwx 1 bin bin 20 Apr 28 16:51 /usr/bin/xlc -> /usr/lpp/xlC/bin/xlC Then you have not run the replaceCSET script and you have a dual environment of CSET and C for AIX coexisting. If it is: lrwxrwxrwx 1 bin bin 20 Apr 28 16:51 /usr/bin/xlc -> /usr/vac/bin/xlc Then you have run the replaceCSET script, and you should rerun the script again after the uninstallation of CSET and the installtion of C for AIX 4.4 If you wish to keep CSET and the C for AIX 4.4 coexistance, and you wish the links in /usr/bin/xlc to continue to call CSET, then you should add /usr/vac/bin to your path or invoke the compiler by full path name, such as /usr/vac/bin/c89 helloworld.c. The online hypertext documentation for this product can be found in /usr/vac/html. Use a standard browser to view the online documentation by entering the line below for the web page location. file://usr/vac/html/en_US/index.htm This README has the following contents: A. SMP specific issues B. 64-bit migration issues i. Language-specific issues ii. Operating System-specific issues iii.Installation issues C. Changes from CSet 3.1.4 to C for AIX 4.4 D. Documentation issues A. SMP specific issues ---------------------- 1. Explicit and automatic parallelization are enabled by -qsmp option. Note that, on AIX 4.1-4.2, this option must be used only with thread-safe compiler invocations (using _r stanzas). 2. Explicit parallelization directives should be applied only to countable loops (countable loops are defined in the online documentation). If a loop is not countable, a diagnostic message will be issued. However, in some cases the compiler might be able to parallelize a loop even if does not exactly fit into the definition of being countable. Then, the loop will be parallelized and diagnostic message will not be issued. 3. Runtime does not generate an error message if chunk size is negative. It proceeds with the default value for the specified scheduling type. 4. -qsmp=nested_par should be used with care. While introducing overhead of parallelization, it does not necessary make nested loops execute in parallel. Depending on the number of threads available and the amount of work in an outer loop, inner loops might be executed sequentially even if this option is in effect. 5. In the online documentation, in the definition of a countable loop: " incr Loop invariant signed integer expression. The value of the expression is known at run-time and is not 0." should read: " incr Loop invariant signed integer expression. The value of the expression is known at compile time and is not 0." B. 64-bit migration issues -------------------------- i. Language-specific issues that can affect 64-bit compilation. 1. Unsuffixed numbers A number like 4294967295,(UINT_MAX) when parsed by the compiler will be typed signed long in 32-bit mode. This is OK since signed long is 4 bytes and mixing long with int is usually OK in 32-bit mode. In 64-bit mode, this same number will choose signed long, which is 8-byte, leading to some operations like comparing the sizeof(4294967295) to return 8. In general, suffix all constants. The fix for the above case is to write the number as 4294967295U. This will allow the compiler to pick unsigned int. 2. Undeclared functions return int. Any function that returns a pointer should be declared in 64-bit mode. Otherwise, the compiler will assume they return an int and truncate the resulting pointer even if you were to assign it into a valid pointer. Code such as: int a=calloc(25); which used to work fine in 32-bit mode, will now get a truncated pointer silently. Even -qwarn64 can not trap this since we have an int to int assignment. The fix is to include the correct header which is actually stdlib.h and not malloc.h as you might believe. 3. Structure with pointers and long types will change size and alignment in 64-bit mode. Any structure or unions with pointer or long types will change size and alignment in 64-bit mode. Some structures may not change size because they happen to fall on the exact 8 byte boundary even in 32-bit mode. 4. __int64 is a long type in 64-bit mode. __int64 types will look like long long in 32-bit mode, but long in 64-bit mode. When they look like long long types, they will not be promoted into. When they look like long types, they will participate in promotion rules and arithmatic conversions. 5. Long bitfields in 64-bit mode may change in future In 32-bit mode, only in extended mode was non-integer bitfields tolerated (but not respected). But if you have long type bitfields in 64-bit mode, their exact alignment may change in future even if the bitfield size is under 32-bit. 6. Va_arg function parameters involving structures of 8 byte multiples passed by value If passing a structure of 8-byte multiple by value to a va_arg argument in 64-bit mode, the member values may not be accessed properly. This is a known limitation of the Operating System. 7. Beware of zero extension from unsigned int to unsigned long in 64-bit extended mode. When you zero extend an unsigned int that is negative, such as 0xFFFF FFFF, you will get a preservation of the bit pattern resulting in 0x0000 0000 FFFF FFFF. This can cause 64-bit results to become a large positive number. ii. Operating System-specific issues that may affect your code: 1. time_t has changed size from AIX 4.2 to 4.3/4.4 Library functions which take an argument of time_t or return type time_t may find type mismatches with your existing code in 32-bit mode because time_t has changed from long type in AIX 4.2 to int type in AIX 4.3/4.4. 2. MB_CUR_MAX has changed from int to size_t in AIX 4.3/4.4 MB_CUR_MAX is a macro defined in stdlib.h that calls _getmbcurmax(). This function now returns size_t which has always been unsigned long. It used to be prototype to return int in AIX 4.2. 3. setlocale in 64-bit mode If you have user locales defined, you need to recompile them in 64-bit mode using localedef. This generates a 32-bit and 64-bit versions of your locale file. Otherwise, calling setlocale in 64-bit mode will not find the user defined locale file. However, localedef in 4.4 supports only the charmap that came with the 4.4 distribution. If you need to use the charmaps that came from an older AIX distribution, you must explicitly copy them into your directory befor using localedef with your custom locale definition file. Also, localedef by default is set up to use /bin/cc and /usr/bin/cc. The C for AIX 4.4 compiler does not setup links in /usr/bin or /bin in respect of CSet distributions. Since localedef requires the use of a 64-bit compiler, you need to run /usr/vac/bin/replaceCSet to replace the links with the C for AIX 4.4 links, run localedef, then run restoreCSet to restore the links as they were before. 4. Make doesn't discriminate object formats. Make only discriminates on timestamp of files. The one case where this can cause problem is when you try to add the same named 32 and 64-bit object into the archive. Running make in 32-bit mode, then 64-bit mode will not update the 2nd object. Make only checks the timestamp of the first object it finds with the correct name. 5. int64 is typedefined in inttypes.h If you use int64 as a variable name, this is now a typedef in inttypes.h 6. Header file predefined types that are based on long There are many header file predefined types such as size_t and ptrdiff_t which remains the same type regardless of 32 ot 64-bit mode. This presents subtle opportunity for differences when compiling the same code in different mode of the compiler. Although size_t remains the same type (unsigned long), the length of size_t will change between different modes of AIX. This can subtlely cause library functions that return or take size_t to change behaviour in 32-bit to 64-bit mode. Specifically, sizeof will return an 8-byte value in 64-bit and a 4-byte value in 32-bit mode. The same applies to prtdiff_t which is signed long in both modes. iii. Installation issues 1. Operating System level-specific files During installation, packaging will determine your AIX Operating System level. This will decide the corerct OS-specific version of the following files to install: vac.cfg libhmd.a libhmu_r.a libhm.a libhmd_r.a libhu.a libhm_r.a libhmu.a libhu_r.a libpdf.a libxlsmp.a profiled/libhmd.a profiled/libhmu_r.a profiled/libhm.a profiled/libhmd_r.a profiled/libhu.a profiled/libhm_r.a profiled/libhmu.a profiled/libhu_r.a B. Changes from CSet 3.1.4 to C for AIX 4.4 ------------------------------------------- 1. The main() function must be visible to IPA (i.e. in a .o compiled by IPA), thus if main() is in a .a, .S, or .so or any other file type, IPA will return an error. 2. Since IPA is responsible for calling the linker when it is active, the -# option (which shows the compilation steps without executing them) will not display anything after the IPA 2nd pass because IPA is not actually called. This is not a bug and is known expected behaviour. 3. #pragma options arch=suboption in source files is not supported. 4. C++ compile is not supported thus the C++ stanzas (xlC, xlC_r, etc.) cannot be used. The C stanzas (xlc, cc, etc.) will not compile C++ (.C, .cpp, .cxx) suffixes. The -+ option is also not supported. 5. Some utilities which were shipped with CSet 3.1.4 are not shipped with C for AIX 4.4. These are tcov, the Source Code Browser, and the HeapView Debugger. Thus the options -a, -ae, -qbrowse, and -qhd are not supported. However, some of the functionalities of the old HeapView Debugger can be found in the new memory debug routines accessible via the -qheapdebug option. 6. The default links in /usr/bin (xlc, cc ,c89, ... etc) will not be set up to point to /usr/vac/bin of C for AIX 4.4. This is done at the discretion of the product installer using replaceCSET. After using this script, /usr/bin/xlc (cc, c89, etc.) will point into /usr/vac/bin/xlc (cc, c89, etc.). If the links are not setup, they may point to the old CSet release (3.1.4 and older), and you may not be using the new C for AIX 4.4 release. If you want individual scripts in /usr/bin to point to the new C for AIX 4.4 release and also maintain simultaneous usage of /usr/bin/xlc (cc, c89, etc.) to point to the old CSET compiler, then create these scripts in /usr/bin: vaxlc vacc vac89 vacc128 vaxlc128 vacc_r vaxlc_r All these scripts could be links to the /usr/bin/vaxlc script which simply contains: #! /usr/bin/ksh exec /usr/vac/bin/${0##*va} "$@" #end of script vaxlc Note that use of this script is not supported as it may have unknown side effects through aliases and macros in the .kshrc file. This is provided only as a suggestion. 7. When using -qipa, some symbols which are clearly referenced or set in the source code may be optimized away by IPA, resulting in loss of these symbols in debug, nm or dump outputs. This is normal. Using -g with IPA will generally result in non-steppable source. 8. Files compiled with older versions of IPA cannot be mixed with files compiled with C for AIX 4.4 IPA. 9. Invoking xlc by itself will generate a return code of 40 after displaying the help file. Invoking xlc with an option but without a file will generate a return code of 249. 10. Using IPA with #pragma disjoint may produce incorrect code. 11. When generating a listing with -qipa using -qlist, IPA will generate an a.lst file which may overwrite any existing a.lst file. Also if your source file is named a.c, the IPA listing will overwrite the normal compiler listing a.lst. This is a known limitation. You can cause IPA to generate an alternate listing via the option -qipa=list=. 12. Any pdf files generated with CSet 3.1.4 cannot be mixed with new pdf files as optimizations are performed differently. Pdf files should always be created using the same release/ptf level. Both -qpdf1 and -qpdf2 should use the same xlCcode. 13. The profile directed feedback option (-qpdf1) generates a -lpdf to look for the libpdf.a archive. This archive is in /usr/vac/lib. The user should add the option -L/usr/vac/lib to allow -qpdf1 to find the correct library. This is a known issue. 14. In the config file, the stanza attribute "inline" defines the location of the Intermediate code inliner. This is no longer used and the file xlCinline is also no longer shipped. This does not affect the -Q or -qinline option. The -Q and -qinline options are still functional. 15. This release of C for AIX uses License Use Management (LUM) instead of iFOR/LS. For details, please read the hardcopy README instructions that came with the product and /usr/vac/README.password. D. Documentation issues ----------------------- a) Documentation is in HTML format and must be viewed with a frames-capable HTML browser. Documentation can be accessed by pointing your frame-capable HTML browser to either of the following files: /usr/vac/html/en_US/doc/index.htm /usr/vac/html/en_US/doc/index.html Note: Certain versions of Netscape Communicator have a well-known problem with HTML frames when they are first loaded. According to Netscape, you should restart the browser to make subsequent calls to framesets will display properly. b) Browser Settings: i) Ensure that the environment SOCKS_NS is not set. ii)Your browser must not have proxy handling for the localhost port. Ensure you turn off proxy handling for localhost in your browser. In Netscape 3: 1. Select Options... Network Preferences... 2. Click the Proxies tab 3. Click View at the Manual Proxy Configuration selection 4. Type: localhost:49213 in the "No proxies for" box. If you have other entries here, separate the new entry with a comma. 5. Click OK, then click OK to exit the Proxies tab. In Netscape 4 (Communicator): 1. Select Edit... Preferences.. 2. Double-click Advanced in the Category tree 3. Click Proxies in the Advanced subtree 4. Click View at the Manual Proxy Configuration selection 5. Type: localhost:49213 in the "Exceptions... Do not use proxy servers for domains beginning with" box. If you have other entries here, separate the new entry with a comma. 6. Click OK, then click OK to exit the Preferences Window. c) If you experience a problem installing the IMNSearch component, completely remove the component and re-install. Do not rely on installp -u to clean up everything, such as "group" creates. Note: this only applies to new installs of the IMNSearch component. If you have a previous version of the IMNSearch component, you should not remove the component before trying to re-install.