Red Hat Developer Toolset 1.x User Guide - Linux

More documents

Recommendations

Info

72 Changes in Version 1.0 A.1.1.6. Miscellaneous -Ofast is now supported as a general optimization level. It operates similar to -O3, adds options that can yield better-optimized code, but in turn might invalidate standards compliance (for example, -ffastmath is enabled by -Ofast). GCC can now inform users about cases in which code generation might be improved by adding attributes such as const, pure, and noreturn to functions declared in header files. Use the - Wsuggest-attribute=[const|pure|noreturn] command line option to enable this. Assembler code can now make use of a goto feature that allows for jumps to labels in C code. A.1.2. Language Compatibility In this section, we describe the compatibility between the Red Hat Developer Toolset compilers and the Red Hat Enterprise Linux system compilers at the programming-language level (for example, differences in the implementation of language standards such as C99, or changes to the warnings generated by - Wall). Some of the changes are a result of bug fixing, and some old behaviors have been intentionally changed in order to support new standards, or relaxed in standards-conforming ways to facilitate compilation or runtime performance. Some of these changes are not visible to the naked eye and will not cause problems when updating from older versions. However, some of these changes are visible, and can cause grief to users porting to Red Hat Developer Toolset's version of GCC. The following text attempts to identify major issues and suggests solutions. A.1.2.1. C Constant expressions are now handled by GCC in a way that conforms to C90 and C99. For code expressions that can be transformed into constants by the compiler but are in fact not constant expressions as defined by ISO C, this may cause warnings or errors. Ill-formed redeclarations of library functions are not accepted anymore by the compiler. In particular, a function with a signature similar to the built-in declaration of a library function (for example, abort() or memcpy()) must be declared with extern "C" to be considered as a redeclaration, otherwise it is illformed. Duplicate Member Consider the following struct declaration: struct A { int *a; union { struct { int *a; }; }; }; Previously, this declaration used to be diagnosed just by the C++ compiler, now it is diagnosed also by the C compiler. Because of the anonymous unions and structs, there is ambiguity about what .a actually refers to and one of the fields therefore needs to be renamed. A.1.2.2. C++ Header Dependency Changes , , and other STL headers that previously included as an implementation detail (to get some feature macros for gthr*.h purposes) no longer do so, because it was a C++ standard violation. This can result in diagnostic output similar to the following:
Red Hat Developer Toolset 1.x User Guide 73 error: ‘truncate’ was not declared in this scope error: ‘sleep’ was not declared in this scope error: ‘pipe’ was not declared in this scope error: there are no arguments to 'offsetof' that depend on a template parameter, so a declaration of 'offsetof' must be available To fix this, add the following line early in the source or header files that need it: #include Many of the standard C++ library include files have been edited to no longer include to get namespace-std-scoped versions of size_t and ptrdiff_t. As such, C++ programs that used the macros NULL or offsetof without including will no longer compile. The diagnostic produced is similar to the following: error: 'ptrdiff_t' does not name a type error: 'size_t' has not been declared error: 'NULL' was not declared in this scope error: there are no arguments to 'offsetof' that depend on a template parameter, so a declaration of 'offsetof' must be available To fix this issue, add the following line: #include Name Lookup Changes G++ no longer performs an extra unqualified lookup that it incorrectly performed in the past. Instead, it implements the two-phase lookup rules correctly, and an unqualified name used in a template must have an appropriate declaration that: 1. is either in scope at the point of the template's definition, or 2. can be found by argument-dependent lookup at the point of instantiation. Code that incorrectly depends on a second unqualified lookup at the point of instantiation (such as finding functions declared after the template or in dependent bases) will result in compile-time errors. In some cases, the diagnostics provided by G++ include hints how to fix the bugs. Consider the following code: template int t(T i) { return f(i); } int f(int i) { return i; } int main() { return t(1); } The following diagnostics output will be produced:
Page 1 and 2:
Red Hat Developer Toolset 1.x User
Page 3 and 4:
Page 5 and 6:
Page 7 and 8:
Page 9 and 10:
Page 11 and 12:
Part I. Introduction Red Hat Develo
Page 13 and 14:
Page 15 and 16:
Page 17 and 18:
Page 19 and 20:
Part II. Development Tools Red Hat
Page 21 and 22: Red Hat Developer Toolset 1.x User
Page 47 and 48: Red Hat Enterprise Linux 5 provides
Page 71: Red Hat Developer Toolset 1.x User
show all

Red Hat Developer Toolset 1.x User Guide - Linux

Create successful ePaper yourself

Delete template?

Save as template?