![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to Compiler.rtf CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Apple XNU] / GNUtools|
Return to Compiler.rtf CVS log | Up to [Apple XNU] / GNUtools |
1.1 ! root 1: {\rtf0\ansi{\fonttbl\f0\fnil Times-Roman;\f1\ftech Symbol;\f2\fswiss Helvetica;\f3\fmodern Courier;\f4\fnil TradeGothic;\f5\fmodern Ohlfs;} ! 2: \paperw11620 ! 3: \paperh12360 ! 4: \margl120 ! 5: \margr120 ! 6: {\colortbl;\red18\green15\blue15;} ! 7: {\nextcolortbl{\nextcolor1 040b747970656473747265616d8103a2840163c48403737373811212810f0f810f0f84012584067f411b312d34} ! 8: } ! 9: \pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\f0\b0\i0\ulnone\fs24\gray61\fc1\cf1 Release 3.3/3.2hp/PDO2.0 Copyright ! 10: \f1 � ! 11: \f0 1994 by NeXT Computer, Inc. All Rights Reserved.\ ! 12: ! 13: \pard\fs28\li1440\gray61\fc1\cf1 \ ! 14: ! 15: \f2\fs30\li0 \ ! 16: ! 17: \pard\tx0\tx2520\tx2880\tx3240\f0\fs48\li1440\gray61\fc1\cf1 3.3, 3.2hp, PDO 2.0 Release Notes: ! 18: \pard\li1440\gray61\fc1\cf1 \ ! 19: C Compiler ! 20: \fs30 \ ! 21: ! 22: \fs28 \ ! 23: \ ! 24: \ ! 25: ! 26: \b\fs36\li0 Notes Specific to Release 3.3/3.2hp\ ! 27: ! 28: \b0\fs28\li1440 \ ! 29: ! 30: \pard\tx1800\li1440\gray61\fc1\cf1 In this release, the compiler is based on the GNU C compiler version 2.5.8. \ ! 31: \ ! 32: ! 33: \i This is also the compiler for NeXTSTEP/hppa 3.2. Please contack [email protected] if you have eny problems with it, and the problems are not mentioned in this note. \ ! 34: ! 35: \pard\i0\li1440\gray61\fc1\cf1 \ ! 36: ! 37: \pard\tx0\tx2520\tx2880\tx3240\b\li720\gray61\fc1\cf1 Recompilation\ ! 38: ! 39: \pard\b0\li1440\gray61\fc1\cf1 \ ! 40: ! 41: \pard\tx1800\li1440\gray61\fc1\cf1 The following changes in this version of the GNU C compiler requires you to recompile some existing code.\ ! 42: ! 43: \pard\li1440\gray61\fc1\cf1 \ ! 44: ! 45: \pard\tx1800\tx2160\tx2520\tx2880\tx5780\fi-360\li1800\gray61\fc1\cf1 � ! 46: \b C++ name mangling. ! 47: \b0 The method of ``mangling'' C++ function names has been changed. So you must recompile all C++ programs completely when you start using NeXTSTEP 3.3. libg++ is updated to use the new mangling.\ ! 48: \ ! 49: � ! 50: \b Struct arguments on hppa. ! 51: \b0 A bug fix in passing of structure arguments for the hppa architecture makes code compiled with the GNU C compiler incompatible with code compiled with earlier versions (if it passes struct arguments of 33 to 64 bits, interspersed with other types of arguments). This is a very rare problem, since the calling conventions are really changed only when certain conditions are met, so most code will work withou recompilation.\ ! 52: \ ! 53: ! 54: \pard\tx0\tx2520\tx2880\tx3240\b\li720\gray61\fc1\cf1 Features in test bed\ ! 55: ! 56: \pard\b0\li1440\gray61\fc1\cf1 \ ! 57: ! 58: \pard\tx1800\li1440\gray61\fc1\cf1 The following are features which have just been introduced, and are thus not enabled as default:\ ! 59: ! 60: \pard\li1440\gray61\fc1\cf1 \ ! 61: ! 62: \pard\tx1800\tx2160\tx2520\tx2880\tx5780\fi-360\li1800\gray61\fc1\cf1 � ! 63: \b Dylib codegen; ! 64: \b0 ! 65: \b -k. ! 66: \b0 (m68k and i386) Generate code for the new dynamic shared library scheme. Eventually, this flag will be named `-NEXTSTEP-deployment- target 3.3'. \ ! 67: \ ! 68: \ ! 69: ! 70: \pard\tx0\tx2520\tx2880\tx3240\b\li720\gray61\fc1\cf1 New Features\ ! 71: ! 72: \pard\b0\li1440\gray61\fc1\cf1 \ ! 73: ! 74: \pard\tx1800\li1440\gray61\fc1\cf1 The following new features have been added to the GNU C Compiler for Release 3.3. Using some of them may disable you to run the resulting application on pre-3.3 NeXTSTEP. The details of this should be described elsewhere...\ ! 75: ! 76: \pard\li1440\gray61\fc1\cf1 \ ! 77: ! 78: \pard\tx1800\tx2160\tx2520\tx2880\tx5780\fi-360\li1800\gray61\fc1\cf1 � ! 79: \b IEEE Compliant Floating Point. ! 80: \b0 Parts of the backend for the m68k and i386 compilers have been rewritten in order to make sure that the generated code is fully IEEE compliant. Some programmers may have been using -ffloat-store to obtain this, but that option is no longer needed. ! 81: \i To enable this feature, use the -ffppc flag to the compiler in stead of -ffloat-store. -fppc will eventaully be enabled as default, so better test it now before that happens. ! 82: \i0 \ ! 83: This feature is incompatible with pre-3.3 NeXTSTEP threads, and should, once it becomes the default behavior, be turned off using -fno-fppc (and replaced by -ffloat-store) when building binaries using threads to be run on any pre-3.3 systems. \ ! 84: \ ! 85: � ! 86: \b C++ System Header Files. ! 87: \b0 A new pragma ` ! 88: \f3\fs24 #pragma cplusplus ! 89: \f0\fs28 ' is used to resolve the problem of having C++ system header files. All system header files are by default included in implicit ` ! 90: \f3\fs24 extern "C" ! 91: \f0\fs28 '. When ` ! 92: \f3\fs24 #pragma cplusplus ! 93: \f0\fs28 ' appears in a header file, the rest of that file is embeded in an implicit ` ! 94: \f3\fs24 extern "C++" ! 95: \f0\fs28 ' block. Alternatively, if either of ! 96: \f3\fs24 g++ ! 97: \f0\fs28 or ! 98: \f3\fs24 c++ ! 99: \f0\fs28 appears in the full path name to a headerfile (ignoring case), it is also considered C++. \ ! 100: An error is reported if this pragma appears inside an explicit ` ! 101: \f3\fs24 extern "C" \{...\} ! 102: \f0\fs28 '. \ ! 103: \ ! 104: � ! 105: \b Long double on i386. ! 106: \b0 The GNU C compiler now supports `long double' meaningfully on the i386 (96-bit floating point). \ ! 107: \ ! 108: � ! 109: \b Nested functions. ! 110: \b0 Pascal-style nested functions are now supported in C. This have been in the GNU C compiler for a while, but is now also supported for the NeXTSTEP Operating System. Using this will disable you to run the resulting binary on pre-3.3 systems.\ ! 111: ! 112: \pard\tx1800\li1440\gray61\fc1\cf1 \ ! 113: ! 114: \pard\tx1800\tx2160\tx2520\tx2880\tx5780\fi-360\li1800\gray61\fc1\cf1 � ! 115: \b Array and structure initializers. ! 116: \b0 The C syntax for specifying which structure field comes next in an initializer is now ` ! 117: \f3\fs24 . ! 118: \f0\i\fs28 field_name ! 119: \f3\i0\fs24 = ! 120: \f0\fs28 '. The corresponding syntax for array initializers is now ` ! 121: \f3\fs24 [ ! 122: \f0\i\fs28 index ! 123: \f3\i0\fs24 ]= ! 124: \f0\fs28 '. For example,\ ! 125: \ ! 126: ! 127: \f3\fs24 char whitespace[256] = \{ [' ']=1, ['\\t']=1, ['\\n']=1 \}; ! 128: \f0\fs28 \ ! 129: ! 130: \f3\fs24 NXRect point = \{.origin=\{0,0\}, .size=\{2,3\}\}; ! 131: \f0\fs28 \ ! 132: \ ! 133: This was changed to accord with the syntax proposed by the Numerical C Extensions Group (NCEG). C++ does not support this kind of initializers.\ ! 134: \ ! 135: � ! 136: \b Accessing instance variables in class methods. ! 137: \b0 It used to be common programming style in Objective-C to assign self, and then access instance variables as in the context of an instance method. To discurage this anachroistic use, a warning will be issued.\ ! 138: ! 139: \pard\tx1800\li1440\gray61\fc1\cf1 \ ! 140: ! 141: \pard\tx1800\tx2160\tx2520\tx2880\tx5780\fi-360\li1800\gray61\fc1\cf1 � ! 142: \b C++ `smart pointers' and Objective-C. ! 143: \b0 The Objective-C++ compiler has been changed to recognize type conversion operators for the receiver in a message expression. This allows you to implement so called `smart pointers' to Objective-C objects. However, this conversion is a bit subtle for various implementation reasons. You should avoid having multiple type conversion operators (from the same class) to different pointer types. This may confuse the machinery to choose the wrong type. If however, you need more than, you must make an ` ! 144: \f3\fs24 operator id ! 145: \f0\fs28 ' which will then be chosen over any Objective-C class pointer types. For example:\ ! 146: \ ! 147: ! 148: \f3\fs24 @interface Foo \{ id a; \} ... @end\ ! 149: \ ! 150: class ptrFoo \{\ ! 151: Foo* value;\ ! 152: public:\ ! 153: operator Foo*();\ ! 154: \};\ ! 155: \ ! 156: foo (ptrFoo xx) \{\ ! 157: int i = [xx doSomething]; // calls operator Foo*\ ! 158: \}\ ! 159: \ ! 160: ! 161: \f0\fs28 Here, the he compiler will recognize ! 162: \f3\fs24 xx ! 163: \f0\fs28 as statically typed to ` ! 164: \f3\fs24 Foo* ! 165: \f0\fs28 ' in the message expression. However, if ` ! 166: \f3\fs24 class ptrFoo ! 167: \f0\fs28 ' had implemented other ` ! 168: \f3\fs24 operator ! 169: \i X ! 170: \i0 * ! 171: \f0\fs28 ' functions, you would have to implement an ` ! 172: \f3\fs24 operator id ! 173: \f0\fs28 ' since otherwise the compiler would not know which conversion to look for. Actually, the compiler prefers ` ! 174: \f3\fs24 operator id ! 175: \f0\fs28 ' at all time, if it can find it.\ ! 176: ! 177: \pard\tx0\tx2520\tx2880\tx3240\b\li720\gray61\fc1\cf1 \ ! 178: ! 179: \pard\tx1800\tx2160\tx2520\tx2880\tx5780\b0\fi-360\li1800\gray61\fc1\cf1 � ! 180: \b Unaligned text. ! 181: \b0 (i386 only) Using the new flag ! 182: \f3\fs24 -munaligned-text ! 183: \f0\fs28 all alignment for instructions will be turned off. Ocasionally this may be interesting if the code size is significant. ! 184: \pard\tx1800\li1440\gray61\fc1\cf1 \ ! 185: ! 186: \pard\tx0\tx2520\tx2880\tx3240\b\li720\gray61\fc1\cf1 \ ! 187: \ ! 188: Changes\ ! 189: ! 190: \pard\b0\li1440\gray61\fc1\cf1 \ ! 191: ! 192: \pard\tx1800\tx2160\tx2520\tx2880\tx5780\fi-360\li1800\gray61\fc1\cf1 � ! 193: \b Implicit cast from int to enums ! 194: \f2\fs24 . ! 195: \b0 ! 196: \f0\fs28 The compiler used to implicitly allow casts from int to any enum type. According to ANSI C++ and ANSI C, this is not correct behavior, so a warning will be issued when this is needed. It is a problem because you cannot be sure the integer value lies in the range of the enum. \ ! 197: ! 198: \f2\fs24 \ ! 199: ! 200: \f0\fs28 � ! 201: \b Assignment used as conditional. ! 202: \f2\b0\fs24 ! 203: \f0\fs28 With the -Wall flag turned on, the compiler will issue a warning for assignments used as conditionals in if, for, and while statements. For example the code:\ ! 204: ! 205: \f2\fs24 \ ! 206: ! 207: \f4\fs28 ! 208: \f3\fs24 if (i = foo()) \{ ... \}\ ! 209: \ ! 210: ! 211: \f0\fs28 Will generate a warning suggesting an extra set of parenthesis around the assignment, like:\ ! 212: ! 213: \f3\fs24 \ ! 214: if ((i = foo())) \{ ... \}\ ! 215: \ ! 216: ! 217: \f0\fs28 The idea is that this warning will catch situations where you really meant test for equivalence == and not assignment =. \ ! 218: ! 219: \f2\fs24 \ ! 220: ! 221: \f0\fs28 ! 222: \i Note: There has been much discussion and many comments on this warning. Many developers from NeXT have mailed me or come intoo my office complaining about it, or asking if it was going to stay. I have decided that it will stay in the compiler anyway, because several people have come back to me and changed their mind. The first time it actually catches a real bug, you will be glad to have it. ! 223: \f2\b\i0\fs36 \ ! 224: ! 225: \f0\b0\fs28 \ ! 226: � ! 227: \b Pointers to members. ! 228: \f2\b0\fs24 ! 229: \f0\fs28 The C++ compiler used to allow the case in the following code which is now marked as an error. The compiler will issue and error message if those occur.\ ! 230: ! 231: \f3\fs24 \ ! 232: ! 233: \pard\tx1800\tx2160\tx2200\tx2880\tx5780\li2160\gray61\fc1\cf1 class X \{ public: void f(int); \};\ ! 234: class Y : public X \{ public: void f(int); \};\ ! 235: \ ! 236: g (Y* y, X* x)\ ! 237: \{\ ! 238: void (X::*xmp)(int) = &X::f;\ ! 239: void (Y::*ymp)(int) = &Y::f;\ ! 240: \ ! 241: (y->*xmp)(4); // ok\ ! 242: (x->*ymp)(5); // error ! 243: \f2\fs20 (1) ! 244: \f3\fs24 \ ! 245: ymp = &Y::f; // ok\ ! 246: xmp = &Y::f; // error ! 247: \f2\fs20 (2) ! 248: \f3\fs24 \ ! 249: \}\ ! 250: ! 251: \pard\tx1800\tx2160\tx2520\tx2880\tx5780\fi-360\li1800\gray61\fc1\cf1 \ ! 252: ! 253: \f0\fs28 Statement (1) is an error because, intuitively you cannot be sure that an X* ``responds to'' a Y member pointer. The assignment in (2) is an error, because in general you cannot be sure that some member of a derived class (in this case Y::f) is available in any of it's base classes. Even though ymp is initialized to an X member pointer, it cannot safely be applied to an X*. ! 254: \i This was reported as a problem by Mike Monegan.\ ! 255: ! 256: \f2\i0\fs24 \ ! 257: ! 258: \f0\fs28 � ! 259: \b Implicit cast from void* to object pointer. ! 260: \f2\b0\fs24 ! 261: \f0\fs28 The C++ compiler used to implicitly allow casts from void* to any C++ Object pointer type. According to ANSI C++, this is not correct behavior, so a warning will be issued when this is needed. ! 262: \i This was reported as a problem by Mike Monegan.\ ! 263: ! 264: \f2\i0\fs24 \ ! 265: ! 266: \f0\fs28 � ! 267: \b Incrementing enums. ! 268: \b0 The C++ compiler used to allow increment and decrement operations on enums. According to ANSI C++, this is not correct behavior, so a warning will be issued for this. It is a problem because you cannot be sure the resulting integer value lies in the range of the enum. ! 269: \i This was reported as a problem by Mike Monegan. ! 270: \i0 \ ! 271: ! 272: \f2\fs24 \ ! 273: ! 274: \f0\fs28 � ! 275: \f3\b\fs24 volatile ! 276: \f0\fs28 and ! 277: \f3\fs24 const ! 278: \f0\fs28 declarations must match definitions. ! 279: \f2\b0\fs24 ! 280: \f0\fs28 The C compiler used to allow a declaration and it's definition to mis-match on volatile and const-ness. This is no longer allowed, and the compiler will issue an error when such appears.\ ! 281: ! 282: \pard\tx1800\tx2160\tx2520\tx2880\tx5780\fi-360\li1800\gray61\fc1\cf1 \ ! 283: � ! 284: \b -Wno-format. ! 285: \b0 This warning option used to be called -Wnoformat (without the dash), but has been renamed to be consistent with the rest of the compiler flags. On the 3.2hp release, both forms are accepted.\ ! 286: \ ! 287: � ! 288: \b -fkeep-inline-functions. ! 289: \b0 Preious versions of the compiler would eliminate unused static inline functions. Using this flag, you can make sure they get compiled into the image.\ ! 290: ! 291: \pard\tx1800\li1440\gray61\fc1\cf1 \ ! 292: ! 293: \pard\tx1800\tx2160\tx2520\tx2880\tx5780\fi-360\li1800\gray61\fc1\cf1 � More ! 294: \b Strict Objective-C Syntax Checking. ! 295: \b0 The compiler now is more strict with syntax checking, so you are not allowed to nest ! 296: \f3\fs24 @interface ! 297: \f0\fs28 and ! 298: \f3\fs24 @implementation ! 299: \f0\fs28 blocks. This is done to be able to check that the user allways remembers closing ! 300: \f3\fs24 @end ! 301: \f0\fs28 .\ ! 302: \ ! 303: � ! 304: \b C++ multiple virtual inheritance. ! 305: \b0 Improvements have been made to the C++ compiler so that the dispatch of virtual functions is right most of the times except for the following case.\ ! 306: ! 307: \pard\li1440\gray61\fc1\cf1 \ ! 308: ! 309: \pard\tx1840\tx2160\tx2520\tx2880\tx5780\f3\fs24\li2140\gray61\fc1\cf1 class A \{ void f(); \}\ ! 310: class B : public virtual A \{ virtual void f(); \}\ ! 311: class C : public virtual A \{ virtual void f(); \}\ ! 312: class D : public B, public C \{ virtual void f(); \}\ ! 313: class E : public D \{ virtual void f(); \}\ ! 314: ! 315: \pard\tx1820\tx2160\tx2520\tx2880\tx5780\li1820\gray61\fc1\cf1 \ ! 316: ! 317: \pard\tx1800\tx2160\tx2520\tx2880\tx5780\f0\fs28\fi-360\li1800\gray61\fc1\cf1 Consider the following calls,\ ! 318: \ ! 319: ! 320: \fi0\li2160 ! 321: \f3\fs24 foo() \{\ ! 322: E* e = new E;\ ! 323: B* b = e;\ ! 324: C* c = e;\ ! 325: D* d = e;\ ! 326: \ ! 327: c->f(); // Wrong - calls D::f() ! 328: \f0\fs28 \ ! 329: ! 330: \f3\fs24 b->f(); // Right - calls E::f()\ ! 331: d->f(); // Right - calls E::f()\ ! 332: \}\ ! 333: ! 334: \fi-360\li1800 \ ! 335: ! 336: \f0\fs28\fi0 However, if the above hierarchy is modified such that the non-virtual function ! 337: \f3\fs24 f ! 338: \f0\fs28 in A is made virtual, the dispatch works correctly. The workaround is therefore to make ! 339: \f3\fs24 f ! 340: \f0\fs28 virtual through out the hierarchy.\ ! 341: ! 342: \fi-360 \ ! 343: ! 344: \pard\tx1840\tx2160\tx2520\tx2880\tx5780\f3\fs24\li2140\gray61\fc1\cf1 class A \{ ! 345: \b virtual ! 346: \b0\i ! 347: \i0 void f(); \}\ ! 348: class B : public virtual A \{ virtual void f(); \}\ ! 349: class C : public virtual A \{ virtual void f(); \}\ ! 350: class D : public B, public C \{ virtual void f(); \}\ ! 351: class E : public D \{ virtual void f(); \}\ ! 352: ! 353: \pard\tx1800\tx2160\tx2520\tx2880\tx5780\fi-360\li1800\gray61\fc1\cf1 \ ! 354: ! 355: \f0\fs28\fi0 In any event, the compiler now warns if there is a posibility that wrong code is being generated:\ ! 356: ! 357: \fi-360 \ ! 358: ! 359: \pard\tx1840\tx2160\tx2520\tx2880\tx5780\f3\fs24\li2140\gray61\fc1\cf1 warning: method `A::f()' redeclared as `virtual B::f()'\ ! 360: ! 361: \pard\tx1800\tx2160\tx2520\tx2880\tx5780\fi-360\li1800\gray61\fc1\cf1 \ ! 362: ! 363: \f0\fs28\fi0 This warning is issued whenever a non-virtual method is redeclared in a subclass as virtual.\ ! 364: ! 365: \f3\fs24\fi-360 \ ! 366: ! 367: \f0\fs28 \ ! 368: ! 369: \pard\tx1800\li1440\gray61\fc1\cf1 \ ! 370: ! 371: \pard\tx0\tx2520\tx2880\tx3240\b\li720\gray61\fc1\cf1 Known Bugs and Limitations\ ! 372: ! 373: \pard\b0\li1440\gray61\fc1\cf1 \ ! 374: ! 375: \pard\tx1800\li1440\gray61\fc1\cf1 The following bugs or limitations are worth noting for the GNU C and C++ Compilers for Release 3.3, since they were not there for earlier releases.\ ! 376: \ ! 377: ! 378: \pard\tx1800\tx2160\tx2520\tx2880\tx5780\fi-360\li1800\gray61\fc1\cf1 � ! 379: \b Constant pointers (40775). ! 380: \b0 The C++ compiler does not handle const pointers, i.e. ` ! 381: \f3\fs24 *const ! 382: \f0\fs28 ' correctly. Occationally, this may cause an internal compiler error. Since this is only an optimization issue, this can be replaced by simply ` ! 383: \f3\fs24 * ! 384: \f0\fs28 '.\ ! 385: ! 386: \pard\li1440\gray61\fc1\cf1 \ ! 387: ! 388: \pard\tx1800\tx2160\tx2520\tx2880\tx5780\fi-360\li1800\gray61\fc1\cf1 � ! 389: \b Conditional expressions (39034). ! 390: \b0 The C++ compiler does not handle conditional expressions yielding an object or struct value correctly. Occationally, this may cause an internal compiler error. To fix it, just change the code to not use conditional expressions. ! 391: \pard\li1440\gray61\fc1\cf1 \ ! 392: \ ! 393: ! 394: \pard\tx1800\tx2160\tx2520\tx2880\tx5780\fi-360\li1800\gray61\fc1\cf1 � ! 395: \b Constant expressions (no bug number). ! 396: \b0 Some expression, such as the difference between the address of any two symbols are not properly recognized by the compiler as valid initializer values. There is currently no workaround for that. This is actually not a bug in ANSI-C sense (just a limitation), because the ANSI-C standard does not specify any behavior for this. ! 397: \pard\li1440\gray61\fc1\cf1 \ ! 398: ! 399: \pard\tx1800\tx2160\tx2520\tx2880\tx5780\fi-360\li1800\gray61\fc1\cf1 \ ! 400: � ! 401: \b Complex numbers (40546). ! 402: \b0 The GNU compiler is documented as supporting complex numbers. This part of the compiler is untested, and have been found to be errerous in some cases. It is not recommended that this is being used.\ ! 403: \ ! 404: � ! 405: \b Long doubles (41950). ! 406: \b0 Using immediate long doubles sometimes doesn't work. Using the form ! 407: \f3\fs24 23450.0L ! 408: \f0\fs28 which is used to write long doubles immediate values may cause the compiler to report an internal error.\ ! 409: \ ! 410: ! 411: \pard\li1440\gray61\fc1\cf1 \ ! 412: \ ! 413: ! 414: }
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.