![[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.