Home My Page Projects Code Snippets Project Openings SML/NJ
Summary Activity Forums Tracker Lists Tasks Docs Surveys News SCM Files

SCM Repository

[smlnj] Annotation of /sml/releases/release-110.39/ckit/HISTORY
ViewVC logotype

Annotation of /sml/releases/release-110.39/ckit/HISTORY

Parent Directory Parent Directory | Revision Log Revision Log


Revision 665 - (view) (download)
Original Path: sml/trunk/ckit/HISTORY

1 : dbm 597 ckit history
2 :     ============
3 :    
4 :     Release Changes
5 :     ===============
6 :    
7 :     Version 0.x, 14/Sept/99 (nch)
8 :     -----------------------------
9 :     1. BuildAst flags combined into compiler-mode and source-to-source-mode
10 :     (control of scaling, insertion of explicit coersions, reduction of assign ops
11 :     reduction of sizeof).
12 :    
13 :     BuildAst now contains the following flags and major modes (collections of
14 :     flags settings).
15 :    
16 :     (* control of buildAst modes *)
17 :     val insert_explicit_coersions : bool ref
18 :     (* Insert explicit casts at points where there are implicit type conversions.
19 :     If true, then reduce_assign_ops should also be set. *)
20 :     val insert_scaling : bool ref
21 :     (* Insert scaling computations at pointer arithmetic. *)
22 :     val reduce_sizeof : bool ref
23 :     (* Replace sizeof expressions by integer constants. *)
24 :     val reduce_assign_ops : bool ref
25 :     (* Replace assignops by simple ops and assignments. *)
26 :     val multi_file_mode : bool ref
27 :     (* Analysis mode -- allow repeated definitions. *)
28 :    
29 :     val multiFileMode: unit -> unit (* was called analysis mode *)
30 :     val compilerMode: unit -> unit
31 :     val sourceToSourceMode: unit -> unit
32 :    
33 :    
34 :     2. Warning for zero size arrays added.
35 :    
36 :     3. Error messages are now bounded.
37 :     Error now contains Error.errorsLimit and Error.warningsLimit
38 :     which can be used to limit the printing of errors and warnings.
39 :    
40 :     4. Array sizes and sizeof.
41 :     BuildAst now maintains the expressions used to define array sizes.
42 :     When printed out, these expressions are now printed.
43 :     This allows sizeof calculations to be maintained.
44 :    
45 :     Note: In principle we should do the same thing for expressions in enums
46 :     and in bitfields. However sizeof is fairly unlikely to be used in these
47 :     situations. If reduce_sizeof is false and a sizeof is encountered in these
48 :     situations, a warning message will be printed.
49 :    
50 :     5. Fixed build-ast so that if we get parse errors, we don't print type-checking
51 :     errors. The philosophy here is: first get file to parse, and only then worry
52 :     about semantic errors.
53 :    
54 :     6. Better error messages: We had mentioned capturing error messages in a
55 :     data-structure so that a filter could be installed to print out more meaningful
56 :     error messages (e.g. instead of "ENUM inserted"). This turns out to be a rather
57 :     complex exercise. The problematic error messages involving ENUM are generated
58 :     deep within ml-yacc, and dealing with these would require non-trivial rewriting
59 :     of ml-yacc (in fact I suspect that the only way to do this would be to have our
60 :     own version of ml-yacc).
61 :    
62 :     So, instead I hacked the ml-yacc specification to do slightly better error
63 :     recovery -- we now substiture "TYPE_NAME" for "ID" if there is an error
64 :     involving "ID" tokens.
65 :    
66 :     To see how this might help, recall that the problematic case is when you miss a
67 :     typedef (or the related hancock-thingy). For example, with a missing
68 :     definition of mytype, the declaration:
69 :    
70 :     mytype x;
71 :    
72 :     is tokenized as:
73 :    
74 :     ID ID;
75 :    
76 :     Now, what used to happen is that the parser would try to insert an ENUM token
77 :     (a random bad choice). Instead, the parser now tries to interpret the ID as a
78 :     TYPE_NAME, and so in effect we get:
79 :    
80 :     TYPE ID;
81 :    
82 :     and an error message:
83 :    
84 :     "foo.c": error: syntax error: replacing ID with TYPE_NAME
85 :    
86 :     I've experimented with some support for inserting heuristic help messages (an
87 :     extension to the Error struct). I think it is rather ad hoc, but let me know
88 :     how useful it is. The actual message that is printed now for the above scenario
89 :     is
90 :    
91 :     "file.c": error: syntax error: replacing ID with TYPE_NAME
92 :     Likely cause: missing typedef declaration.
93 :    
94 :     This message can be customized (it appears as a function call in the grammar
95 :     file), and others could be added.
96 :    
97 :     I've also configured build-ast so that when there are parser errors, error
98 :     reporting during type checking is switched off, since such type checking errors
99 :     tend to be quite confusing.
100 :    
101 :    
102 :     ----------------------------------------------------------------------
103 :     Version 1.0b1, 7/Dec/1999
104 :     -------------
105 :     Error interface changed.
106 :     Top level interfaces for build-ast changed.
107 :    
108 :    
109 :     ----------------------------------------------------------------------
110 :     Version 1.0b2, 13/Jan/2000
111 :     --------------
112 :     Bug fixes.
113 :     Revise regression test suite.
114 :    
115 :    
116 :     Version 1.0b3, 15/Mar/2000
117 :     -------------
118 :     Bug fixes: Bugs 1,3,5,6,7,9,10
119 :     Made sizes (Sizes.sizes) a record and parameterized makeAst on sizes.
120 :     Added various regression tests for bugs.
121 :    
122 :    
123 :     Version 1.0, 15/Mar/2000
124 :     -------------
125 :     * Bug fixes: Bugs 2, 4, 8, 12, 13
126 :     * Reworked size and alignment mechanism to support parameterization
127 :     (see src/ast/sizes[-sig].sml). A utility program (src/c-util/sizes.c)
128 :     can be used to generate sizes info for a given compiler/platform
129 :     combination.
130 :    
131 :    
132 :     ======================================================================
133 :     Bug fix history
134 :     ======================================================================
135 :    
136 :     Test: valid-programs/a40.c
137 :     Status: fixed 15/june/99
138 :     Fix: Changed (ty, ty, signedNum CT.INT, expop)
139 :     to (ty, ty, ty, expop)
140 :     in mulDivOp (build-ast.sml)
141 :     Also change similar code in integralOp.
142 :     Email:
143 :    
144 :     From: chandra@research.bell-labs.com (Satish Chandra)
145 :     Date: Fri, 21 May 1999 14:00:28 -0500
146 :    
147 :     Nevin:
148 :    
149 :     Have you already caught this one?
150 :    
151 :     File build-ast-fn.sml:
152 :    
153 :     Function mulDivOp in case PT.Binop, about line 1216 in my version:
154 :    
155 :     then (case usualBinaryCnv env (ty1, ty2) of
156 :     SOME ty => (ty, ty, signedNum CT.INT, expop)
157 :     ^^^^^^
158 :     If we were type checking a float multiplied by a float, we would
159 :     lose, right?
160 :    
161 :     The Wisconsin folks came up with this example, which does not
162 :     produce the correct adornments.
163 :    
164 :     float f = 5.6, f1;
165 :    
166 :     int main() {
167 :     f1 = f * f;
168 :    
169 :     return 0;
170 :     }
171 :    
172 :     -satish
173 :    
174 :     ---------------------------------------------------------------------------
175 :    
176 :     Test: valid-programs/a37.c
177 :     Status: fixed 15/june/99
178 :     Fix: added case "| ([CT.Void], nil) => (nil, nil)" to isAssignableL (type-util.sml)
179 :     Email:
180 :    
181 :     From: chandra@research.bell-labs.com (Satish Chandra)
182 :     Date: Tue, 25 May 1999 15:00:52 -0500
183 :    
184 :     A function with a 'void' argument as its only argument is basically
185 :     a function with no arguments. E.g.:
186 :    
187 :     void f(void);
188 :    
189 :     main()
190 :     {
191 :     f();
192 :     }
193 :    
194 :     We issue a Type Warning: function call has too few args
195 :    
196 :     I can go fix these things myself, but it will make it harder to
197 :     synchronize our changes. Please give me a call so we can make a plan
198 :     on how to go about it.
199 :    
200 :     -satish
201 :    
202 :     ------------------------------------------------------------------------------
203 :    
204 :     Test: valid-programs/a38.c
205 :     Status: fixed sometime in early june/99
206 :     Fix: fixed during major overhaul of frontend
207 :    
208 :     From: chandra@research.bell-labs.com (Satish Chandra)
209 :     Date: Thu, 03 Jun 1999 20:17:56 -0500
210 :    
211 :     When perform_type_checking is on, it complains about
212 :    
213 :     for(;;)
214 :    
215 :     as "condition of for statement is not scalar".
216 :    
217 :     The problem stems from the use of isScalar, without checking for EmptyExp
218 :     first.
219 :    
220 :     -satish
221 :    
222 :     -------------------------------------------------------------------------------
223 :    
224 :     Test: valid-programs/a39.c
225 :     Status: fixed sometime before 15/june/99 (probably before major frontend overhaul?)
226 :     Fix: seems to have been fixed as side-effect of some other bug-fix or code change.
227 :     Email:
228 :    
229 :     Date: Thu, 20 May 1999 09:16:37 -0400 (EDT)
230 :     From: Kathleen Fisher <kfisher@research.att.com>
231 :    
232 :    
233 :     There seems to be a bug involving the ++ operator.
234 :     The following does not work:
235 :     p->count[i]++ /* generates an error. */
236 :     p->count[i] = p->count[i]+1; /* OK */
237 :    
238 :     Kathleen
239 :    
240 :    
241 :     --------------------------- Sat Jul 31 18:36:00 1999 --------------------------
242 :    
243 :     Test: valid-programs/a60.c
244 :     Status: fixed 31/july/99
245 :     Fix: add case for TCInitializer so that if type is not core, then apply getCoreType
246 :     (Alternatively, we could impose the invarient that TCInitializer must be
247 :     applied only to core types, but this would be a pain becuase TCInitializer
248 :     has a number of recursive calls.)
249 :     Email:
250 :    
251 :     build-ast.sml (TCInitializer) does not appear to look into typedefs.
252 :     Therefore,
253 :    
254 :     typedef struct {int x,y; } point;
255 :    
256 :     point x = {2,3};
257 :    
258 :     fails to typecheck although gcc accepts it.
259 :    
260 :    
261 :     --------------------------- Sat Jul 31 19:12:59 1999 --------------------------
262 :    
263 :     Test: valid-programs/a61.c
264 :     Status: fixed 31/july/99
265 :     Fix: Shadow struct definitions were simply ignored. They generated nothing in
266 :     Ast, and in fact there was no way to represent these definitions.
267 :     The fix was to change the TypeDecal contructor from:
268 :    
269 :     TypeDecl of tid
270 :    
271 :     to
272 :    
273 :     TypeDecl of {shadow: {strct:bool} option, tid:tid}
274 :    
275 :     and then use TypeDecl{SOME{strct=true}, tid=....} to represent "struct x;"
276 :     TypeDecl{SOME{strct=false}, tid=....} to represent "union x;"
277 :    
278 :     Email:
279 :     Date: Thu, 29 Jul 1999 14:15:12 -0400
280 :     From: Fred Smith <fsmith@research.att.com
281 :     I couldn't figure out exactly why but the compiler does not seem to emit
282 :     anything for empty structure declarations such as
283 :    
284 :     struct t;
285 :    
286 :     although the code looks like it should. Instead it just omits them. In
287 :     one of the libraries we are using, a declaration like this is used to
288 :     hide implementation details. When omitted we get a lot of spurious
289 :     warnings from the C compiler.
290 :    
291 :    
292 :     --------------------------- Sat Jul 31 20:14:32 1999 --------------------------
293 :    
294 :     Test: valid-programs/a62.c
295 :     Status: fixed 31/july/99
296 :     Fix: Spurious casts were inserted in some cases because the eq test that was used by cast
297 :     did not deref typedefs (amongst other things).
298 :     The simple fix is to replace:
299 :    
300 :     if lookAid aid' = ty then expr (* DBM: gen. equality on types *)
301 :    
302 :     by
303 :    
304 :     if getCoreType(lookAid aid') = getCoreType ty then expr (* DBM: gen. equality on types *)
305 :    
306 :     in the code for wrapCast.
307 :    
308 :     Email:
309 :     Date: Thu, 29 Jul 1999 17:00:54 -0400
310 :     From: Fred Smith <fsmith@research.att.com>
311 :    
312 :     I ran some tests and a cast is being inserted whenever
313 :     a typedef occurs. In fact the following code:
314 :    
315 :     typedef struct { int x,y,z; } w;
316 :    
317 :     void main() {
318 :     w foo;
319 :     foo = foo;
320 :     }
321 :    
322 :     is compiled to
323 :     struct t12 { int x,y,z; };
324 :    
325 :     typedef struct t12 w_t13;
326 :     void main ()
327 :     {
328 :     w_t13 foo_p17;
329 :     foo_p17 = ((struct t12) foo_p17);
330 :     }
331 :     modulo formatting.
332 :    
333 :    
334 :     --------------------------- Sat Jul 31 20:24:30 1999 --------------------------
335 :    
336 :     Test: invalid-programs/r60.c
337 :     Status: fixed 31/july/99
338 :     Fix: Get rid of extra loc args in definitions of checkAssignableTys and checkAssign.
339 :    
340 :     Date: Fri, 30 Jul 1999 10:15:36 -0400
341 :     From: Fred Smith <fsmith@research.att.com>
342 :    
343 :     The following C program compiles and type-checks under Ckit but
344 :     obviously should not.
345 :    
346 :     struct w { int x,y,z; };
347 :    
348 :     void main() {
349 :     struct w foo;
350 :     float x;
351 :     x = foo;
352 :    
353 :     }
354 :    
355 :     It took me a long time to track this one down since the code looks
356 :     absolutely correct. The problem was that all calls to checkAssign in
357 :     build-ast.sml failed to pass in a location. Since checkAssign was being
358 :     used solely for its side-effect, both occurences were in contexts like
359 :     (one case preceded a ; )
360 :     val _ = checkAssign ....
361 :    
362 :    
363 :     --------------------------- Wed Sep 22 17:20:03 1999 --------------------------
364 :    
365 :     Test: valid-programs/a63.c
366 :     Status: fixed 22/Sept/99
367 :     Fix: apply preArgConv to parameter types before adding them to local symbol table
368 :    
369 :     The following C program does not type check under ckit and it should:
370 :    
371 :     void f();
372 :    
373 :     main () {
374 :     int y[4];
375 :     f(y);
376 :     }
377 :    
378 :     void f(int x[4]) {
379 :     int *y;
380 :     x = y;
381 :     x[3] = 1;
382 :     }
383 :    
384 :     C is a horrible language -- if you declare an array as an arg to a function,
385 :     then "array of type" is adjusted to "pointer to type".
386 :    
387 :    
388 :     --------------------------- Wed Sep 22 17:34:55 1999 --------------------------
389 :    
390 :     Test: invalid-programs/r62.c
391 :     Status: fixed 22/Sept/99
392 :     Fix: use lookLocalScope to check if parameter is locally defined before adding it.
393 :    
394 :     The following C program type checks under ckit and it should not:
395 :    
396 :     main () {
397 :     return(0);
398 :     }
399 :    
400 :     f(int x, int x) {
401 :     x = x;
402 :     }
403 :    
404 :    
405 :     --------------------------- Mon Sep 27 19:17:33 1999 --------------------------
406 :    
407 :     Test: not available
408 :     Status: fixed 27/Sept/99
409 :     Problem: Redeclarations did not inherit the pid of the previous declaration.
410 :    
411 :     e.g.
412 :    
413 :     extern int i;
414 :    
415 :     extern int i;
416 :    
417 :     would be allocated different pid's.
418 :     Bug was introduced during build-ast overhaul.
419 :    
420 :     Fix: checkIdRebinding now returns an extra parameter (a uid option).
421 :    
422 :    
423 :     --------------------------- Mon Sep 27 19:20:48 1999 --------------------------
424 :    
425 :     Test: not available
426 :     Status: fixed (see a64.c, a65.c below)
427 :     Problem: We don't check for non-constant expressions in non-simple initializers.
428 :    
429 :     int f(int j) {
430 :     int x[4] = {0,1,2,3}; /* this is ok */
431 :     int x[4] = {0,j,2*j,3*j}; /* this isn't */
432 :     }
433 :    
434 :     but our frontend currently gives an unhesitant thumbs up for this code.
435 :    
436 :    
437 :     --------------------------- Fri Oct 15 14:24:36 1999 --------------------------
438 :    
439 :     Test: not available
440 :     Status: fixed 15/Oct/99
441 :     Fix: in sizeof.sml, function computeFieldListStruct,
442 :     change foldr to foldl and reverse final list.
443 :     Problem:
444 :     > From: chandra@research.bell-labs.com (Satish Chandra)
445 :     > Date: Thu, 14 Oct 1999 22:30:05 -0500
446 :     >
447 :     > This has been quite a while, and the code might have changed much, but ...
448 :     >
449 :     > In function computeFieldListStruct, foldr computes offsets the wrong way.
450 :     > I think we need foldl, and later on reverse the accumulated list called
451 :     > "tab".
452 :    
453 :     --------------------------- Tue Sep 14 11:30:44 1999 --------------------------
454 :    
455 :     TEST: a64.c, a65.c
456 :     STATUS: fixed 12/jan/99
457 :     FIX: propagated isZeroExpr info for function args to checkFn (in type-utils),
458 :     so that zero test can be included when checking assignment of zero to
459 :     arg of pointer type.
460 :     EMAIL:
461 :     From: Kathleen Fisher <kfisher@research.att.com>
462 :     Date: Mon, 10 Jan 2000 15:28:02 -0500 (EST)
463 :    
464 :     The ckit compiler doesn't treat 0 as a legal function pointer. The
465 :     program:
466 :    
467 :     ***************************************************
468 :     void f(int(* goo)(int)){}
469 :    
470 :     void main(){
471 :     f(0);
472 :     }
473 :     ***************************************************
474 :    
475 :     gives the error message:
476 :    
477 :     "/fs/smaug/home4/kfisher/hancock/tests/suite/test.hc":4.2-6: error: Bad
478 :     function call: arg 1 has type int but fn parameter has type int (*) (int)
479 :    
480 :    
481 :     Kathleen
482 :    
483 :     --------------------------- Tue Jan 11 23:12:50 2000 --------------------------
484 :    
485 :     TEST: a66.c
486 :     STATUS: fixed 12/jan/99
487 :     FIX: Pretty-printer bug.
488 :     pp-ast-fn.sml:
489 :     changed the code for the e0 case of QuestionColon to
490 :     ; ppExpr {nested=true} aidinfo tidtab pps e0
491 :     EMAIL:
492 :     From: Alexey Loginov <alexey@cs.wisc.edu>
493 :     Date: Sun, 28 Nov 1999 12:43:16 -0600 (CST)
494 :     Hi Nevin and Dave,
495 :    
496 :     We found another bug that isn't fixed in the version of ckit you sent
497 :     us. I also didn't see it in the bug list. Expressions containing the
498 :     "?:" operator are not parenthesized correctly to account for its
499 :     right-associativity. (In the following program, lines 5 and 7 mean
500 :     the same thing but line 6 is different.)
501 :    
502 :     void main() {
503 :    
504 :     char a, b, c, d, e;
505 :    
506 :     a?b:c?d:e; /* Line 5. */
507 :     (a?b:c)?d:e; /* Line 6. */
508 :     a?b:(c?d:e); /* Line 7. */
509 :     }
510 :    
511 :    
512 :     Output C code:
513 :    
514 :     - ParseToAst.fileToC "/u/a/l/alexey/types/test/quest_col.c";
515 :    
516 :     void main ()
517 :     {
518 :     char a;
519 :     char b;
520 :     char c;
521 :     char d;
522 :     char e;
523 :     a ? b : c ? d : e;
524 :     a ? b : c ? d : e;
525 :     a ? b : c ? d : e;
526 :     }
527 :    
528 :    
529 :     Thanks,
530 :     -Alexey
531 :    
532 :     --------------------------- Tue Jan 11 23:12:52 2000 --------------------------
533 :    
534 :    
535 :     TEST: r64.c
536 :     STATUS: fixed 12/jan/00
537 :     FIX: Add check of initializers to see if const (only non-const
538 :     case is an object of dynamic storage duration (i.e. non-global, non-static).
539 :     Notion of const is complex -- need to recurse through arithmetic, ?-: etc.
540 :     (Long term issue: constant expressions should really be reduced to constants.)
541 :     EMAIL:
542 :     Date: Tue, 7 Dec 1999 17:22:48 -0500 (EST)
543 :     From: Kathleen Fisher <kfisher@research.att.com>
544 :    
545 :     The following code:
546 :    
547 :     struct foo_t{
548 :     int x;
549 :     int y;
550 :     };
551 :    
552 :     void f(int x0, int y0){
553 :     struct foo_t myfoo = {x0,y0};
554 :     }
555 :    
556 :     void main(){
557 :     f(0,0);
558 :     }
559 :    
560 :     passes through the ckit compiler without complaint, but cc reports the
561 :     following error:
562 :    
563 :     "bug.c", line 8: error(1028): expression must have a constant value
564 :     struct foo_t myfoo = {x0,y0};
565 :     ^
566 :    
567 :     "bug.c", line 8: error(1028): expression must have a constant value
568 :     struct foo_t myfoo = {x0,y0};
569 :    
570 :    
571 :     ======================================================================
572 :     Numbered Bugs
573 :     ======================================================================
574 :    
575 :     NUMBER: 1
576 :     SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
577 :     DATE: 2/10/00
578 :     TEST: regression/valid-programs/a211.c,a212.c,a213.c,a214.c,a215.c
579 :     STATUS: fixed 3/10/00 (nch)
580 :     DESCRIPTION:
581 :     Enum constants which were not assigned values in original source
582 :     are assigned 0 in output.
583 :    
584 :     - enum { e1,e2,e3 } e;
585 :    
586 :     --> enum t1 { e1=0, e2=0, e3=0 };
587 :     enum t1 e;
588 :    
589 :    
590 :     ----------------------------------------------------------------------
591 :     NUMBER: 2
592 :     SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
593 :     DATE: 2/10/00
594 :     TEST:
595 :     STATUS: fixed 3/31/00
596 :     DESCRIPTION:
597 :     functions returning function pointers. Function signal is a good
598 :     real-life example. It's mentioned in Harbison and Steele p. 270
599 :     or so (sorry I don't have the book with me).
600 :    
601 :     int (*fp(double))(float);
602 :    
603 :     --> int (*) (float) fp (double);
604 :    
605 :     which does not compile.
606 :    
607 :    
608 :     ----------------------------------------------------------------------
609 :     NUMBER: 3
610 :     SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
611 :     DATE: 2/10/00
612 :     TEST: regression/valid-programs/a216.c
613 :     STATUS: fixed 3/10/00
614 :     FIX: The problem was that the type for the second variable was array(const char),
615 :     and the code did not strip off the const inside the array constructor.
616 :     The fix was to add an extra case to look for qualifiers inside arrays in initializer-normalizer.
617 :     DESCRIPTION:
618 :     inconsistent interpretation of initialization of constant
619 :     character arrays:
620 :    
621 :     char c[] = "abcdefg";
622 :     const char cc[] = "abcdefg";
623 :    
624 :     --> char c[8]={97,98,99,100,101,102,103,0};
625 :     char const cc[1]={"abcdefg"};
626 :    
627 :    
628 :     ----------------------------------------------------------------------
629 :     NUMBER: 4
630 :     SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
631 :     DATE: 2/10/00
632 :     TEST: a232.c
633 :     STATUS: fixed 24/Mar/00
634 :     FIX:
635 :     The pretty-printer in fact has enough information to know
636 :     whether the original definition of a function was k&r or not:
637 :     just look at the function params and at the function type.
638 :     If the function type has no args, but the function has
639 :     params, then we have k&r style.
640 :     The case of FunctionDef in ppCoreExternalDecl now
641 :     has code to recognize this case and print out K&R defns.
642 :    
643 :     DESCRIPTION:
644 :     old style C function parameter declarations have different
645 :     semantics from new style (with respec to promotions) and
646 :     should be preserved.
647 :    
648 :     void foo(int);
649 :     void foo(c)
650 :     char c; { }
651 :    
652 :     --> compiles, but
653 :    
654 :     void foo(int);
655 :     void foo(char c) { }
656 :    
657 :     --> which is output by ckit, does not
658 :    
659 :    
660 :     ----------------------------------------------------------------------
661 :     NUMBER: 5
662 :     SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
663 :     DATE: 2/10/00
664 :     TEST: regression/valid-programs/a222.c (for both problems)
665 :     STATUS: fixed 3/10/00
666 :     FIX for 1: change default value of flag local_externs_ok to true
667 :     FIX for 2: changed checking code for initializations (build-ast.sml and initializer-normalizer.sml)
668 :     DESCRIPTION:
669 :     Inconvinient Warnings:
670 :    
671 :     - int foo() { extern int bar; }
672 :    
673 :     --> error: `extern' not allowed in local declarations
674 :    
675 :     - struct S s = t; (in general, struct S = <exp> where <exp> is
676 :     not of the form {...})
677 :    
678 :     --> error: badly formed union/struct initializer: expecting {
679 :    
680 :     COMMENT:
681 :     These last two errors don't seem to affect the output, so we just
682 :     ignore them. The others are causing problems on various utilities of
683 :     the GNU website. (We're ignoring the issues with the use of GNU C.)
684 :    
685 :     Local extern warning was fixed by making local_externs_ok contain true
686 :     in build-ast.sml. There remains a question about whether the semantics
687 :     is correct in all cases. (see regression/invalid-programs/r65.c, which
688 :     appears to be handled properly -- produces an error message.) [dbm, 3/10/00]
689 :    
690 :    
691 :     ----------------------------------------------------------------------
692 :     NUMBER: 6
693 :     SUBMITTER: John Reppy <jhr@research.bell-labs.com>
694 :     DATE: 2/10/00
695 :     TEST: none
696 :     STATUS: fixed
697 :     FIX: introduced a sizes record type in sizes-sig.sml, and parameterized
698 :     makeAst, SizeOf fns, and ParseToAst.fileAst' with respect to sizes.
699 :     The Sizes structure provides a default value Sizes.defaultSizes.
700 :     sizes-sig.sml and sizes.sml moved from variants(/ansic) to ast.
701 :     [Plan is to provide a structure containing a set of sizes values for
702 :     various platform/compiler combinations.]
703 :     Removed bogus stale sizes-sig.sml file (the real signature contains longlong and longdouble).
704 :     Fixed sizeof so that it now:
705 :     a) provides the standard functionality for bitfields of char and short;
706 :     b) has flags to modify the standard behaviour
707 :     We can now simulate the behaviour of cc, lcc and gcc (wrt e.g. alignment
708 :     issues for unnamed bitfields).
709 :    
710 :     DESCRIPTION:
711 :     The type metrics in the CKit are broken in several ways. First, it seems
712 :     that the SIZES signature does not include longlong or longdouble. Second,
713 :     the sizes are hard-coded in, instead of being ABI dependent. I'd recommend
714 :     replacing the Sizes structure with a record type:
715 :    
716 :     type metrics = {bits : int, align : int}
717 :    
718 :     type interface = {
719 :     charMetric : metrics,
720 :     shortMetric : metrics,
721 :     intMetric : metrics,
722 :     longMetric : metrics,
723 :     longlongMetric : metrics,
724 :     floatMetric : metrics,
725 :     doubleMetric : metrics,
726 :     longdoubleMetric : metrics,
727 :     pointerMetric : metrics,
728 :     structAlign : int,
729 :     bitFieldAlignment : int option
730 :     }
731 :    
732 :     For the IA32/SVID, the values should be
733 :    
734 :     char 8 8
735 :     short 16 16
736 :     int 32 32
737 :     long 32 32
738 :     long long 64 32
739 :     float 32 32
740 :     double 64 32
741 :     long double 96 32
742 :     pointer 32 32
743 :     struct align - 8
744 :    
745 :     One can probably write a small C program that generates this information.
746 :     [jhr has given one to nch -dbm]
747 :    
748 :     [dbm, 3/8/00] The ast/sizes-sig.sml version of SIZES doesn't include
749 :     longlong or longdouble, but the variants/sizes-sig.sml version does.
750 :     That seems to be the version used in (e.g.) variants/*/config.sml.
751 :    
752 :     The variants/sizes-sig.sml also defines a "layout" type corresponding
753 :     to John's "metrics". The ast version of SIZES does not seem to be
754 :     mentioned anywhere except in ast/sizes-sig.sml, where it is defined,
755 :     so it looks like this is an old, vestigial version that has been superceded
756 :     by the variants version.
757 :    
758 :     [dbm, 3/14/00] John still advocates using a record. He anticipates wanting
759 :     to switch target architectures dynamically (either by passing the record
760 :     as a value, or by setting a global value) in the midst of processing.
761 :    
762 :    
763 :     ----------------------------------------------------------------------
764 :     NUMBER: 7
765 :     SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
766 :     DATE: 2/18/00
767 :     TEST: regression/valid-programs/a224.c
768 :     STATUS: fixed 3/10/00 (see bug 9)
769 :     DESCRIPTION:
770 :     '\0' is treated as '0' and not as a null character. We didn't check
771 :     for any other special characters.
772 :    
773 :     INPUT:
774 :    
775 :     char c_null = '\0';
776 :     char c_zero = '0';
777 :    
778 :     int main () { return 0; }
779 :    
780 :     OUTPUT:
781 :    
782 :     char c_null=48;
783 :     char c_zero=48;
784 :     int main ()
785 :     {
786 :     return 0;
787 :     }
788 :    
789 :     COMMENT:
790 :     This is a special case of bug 9.
791 :    
792 :    
793 :     ----------------------------------------------------------------------
794 :     NUMBER: 8
795 :     SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
796 :     DATE: 2/18/00
797 :     TEST: a227.c
798 :     STATUS: fixed 24/Mar/00
799 :     FIX:
800 :     The problem was in type-util.sml,
801 :     where the function conditionalExp is used to type check conditional expressions.
802 :     The relevant case statement in the body of the function is
803 :     where both arguments (after usualUnaryCnv) have Pointer type.
804 :     In this case, composite is called -- the problem is that the
805 :     call to composite reverts to the original arguments ty1 and ty2 of the call
806 :     to conditionalExp, rather than the results of applying usualUnaryCnv.
807 :    
808 :     (Note that the function composite can not and should not
809 :     apply usualUnaryCnv to its arguments.)
810 :    
811 :     It turns out that this same error appears in three other places in the code
812 :     (in isEquable, isSubtractable and isComparable).
813 :    
814 :     With insert_explicit_coersions set to true, you now obtain:
815 :    
816 :     original program (a227.c):
817 :    
818 :     int main() {
819 :     int *ip;
820 :     int *jp;
821 :     int ia[3];
822 :     jp = (1 ? ia : ip);
823 :     }
824 :    
825 :     fileToC output:
826 :    
827 :     int main ()
828 :     {
829 :     int *ip;
830 :     int *jp;
831 :     int ia[3];
832 :     jp = (1 ? (int *) ia : ip);
833 :     }
834 :    
835 :    
836 :     DESCRIPTION:
837 :     "?:" operator typing.
838 :    
839 :     int *ip;
840 :     int *jp;
841 :     int ia[3];
842 :     jp = (1 ? ia : ip);
843 :    
844 :     --> error: Type Error: Unacceptable operands of question-colon.
845 :    
846 :     C semantics (we think):
847 :     --> jp = (1 ? (int *) ia : ip);
848 :     ^^^^^^^
849 :     (implicit cast of ia to pointer)
850 :    
851 :    
852 :     Current implementation:
853 :     --> jp = (1 ? ia : (int[3]) ip);
854 :     ^^^^^^^^
855 :     (implicit cast of ip to array)
856 :    
857 :     COMMENT:
858 :     Of course, code is still output correctly (without the implicit cast)
859 :     but since we actually use the implicit casts to materialize some
860 :     casts, we rely on their correctness.
861 :    
862 :    
863 :     ----------------------------------------------------------------------
864 :     NUMBER: 9
865 :     SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
866 :     DATE: 2/22/00
867 :     TEST: regression/valid-programs/a223.c
868 :     STATUS: fixed 3/10/00
869 :     DESCRIPTION:
870 :     To follow up on this [bug 8] I wanted to mention that it looks like ckit
871 :     handles '\ooo' in three different ways depending on the number of
872 :     octal digits. In C the number of digits can be 1-3 but ckit only
873 :     handles 3 digit numbers correctly. Two digit numbers are processed as
874 :     decimal numbers. Single digit numbers are processed as if '\' weren't
875 :     there (i.e. taken as ascii values).
876 :    
877 :     INPUT:
878 :    
879 :     char c_octal_0 = '\0';
880 :     char c_octal_51 = '\051';
881 :     char c_octal_60 = '\60';
882 :     char c_octal_7 = '\7';
883 :    
884 :     int main () { return 0; }
885 :    
886 :    
887 :     OUTPUT:
888 :    
889 :     char c_octal_0=48; /* Should be 0 */
890 :     char c_octal_51=41; /* Correct */
891 :     char c_octal_60=60; /* Should be 48 */
892 :     char c_octal_7=55; /* Should be 7 */
893 :     int main ()
894 :     {
895 :     return 0;
896 :     }
897 :    
898 :     Of course, '\0' is the most common of these. Do you have a time frame
899 :     for when you think the problems I mentioned before might be fixed?
900 :    
901 :     COMMENT:
902 :     [dbm] fixed by changing the rule in parser/grammar/c.lex to take 1 to 3
903 :     octal digits instead of exactly 3 ({1,3} replaced {3} as the modifier).
904 :    
905 :    
906 :     ----------------------------------------------------------------------
907 :     NUMBER: 10
908 :     SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
909 :     DATE: 2/23/00
910 :     TEST: regression/valid-programs/a226.c
911 :     STATUS: fixed 3/10/00
912 :     FIX: Stupid cut-and-paste problem: preincrements/predecrements were getting
913 :     transformed into postincrements/postdecrements in build-ast.sml.
914 :     DESCRIPTION:
915 :     preincrement and predecrement behavior
916 :    
917 :     INPUT:
918 :    
919 :     int main () {
920 :     int i = 10;
921 :    
922 :     int i1 = ++i;
923 :     int i2 = --i;
924 :    
925 :     return 0; }
926 :    
927 :    
928 :     OUTPUT:
929 :    
930 :     int main ()
931 :     {
932 :     int i=10;
933 :     int i1=i++;
934 :     int i2=i--;
935 :     return 0;
936 :     }
937 :    
938 :     COMMENT:
939 :    
940 :     ----------------------------------------------------------------------
941 :     NUMBER: 12
942 :     SUBMITTER: Kathleen Fisher <kfisher@research.att.com>
943 :     DATE: 3/15/00
944 :     TEST: a230.c
945 :     STATUS: fixed 24/Mar/00
946 :     FIX:
947 :     The bug was because the implementation of the non-default
948 :     behaviour of convert_function_args_to_pointers was not complete (there was
949 :     a missing case in isAssignable in type-utils.sml). To put it another way,
950 :     too much of the code was assuming that convert_function_args_to_pointers
951 :     was set to the standard value, and in particular, that certain coersions had
952 :     been performed *before* isAssignable was called. These coersions are not
953 :     performed when convert_function_args_to_pointers is false.
954 :    
955 :     DESCRIPTION:
956 :     We've run into a problem with ckit when we turn the flag
957 :     convert_function_args_to_pointers to false in the config.sml file.
958 :     The following program:
959 :    
960 :     ********************************************************
961 :     typedef int *windowTy[1];
962 :    
963 :     int f (windowTy w)
964 :     {
965 :     return 1;
966 :     }
967 :    
968 :     void main(){
969 :     windowTy w;
970 :     f (w);
971 :     }
972 :     ********************************************************
973 :    
974 :     compiles just fine using cc, but it generates the following
975 :     error if we compile it with ckit:
976 :    
977 :     "array-param.hc":11.3-8: error: Bad function call: arg 1 has type windowTy
978 :     but fn parameter has type windowTy
979 :    
980 :    
981 :     ----------------------------------------------------------------------
982 :     NUMBER: 13
983 :     SUBMITTER: Olivier Tardieu
984 :     DATE: 24/Mar/00
985 :     TEST: a301.c
986 :     STATUS: fixed 24/Mar/00
987 :     FIX:
988 :     ! should be type checked like || and && instead of like a simple
989 :     unary operator. Extra code (a function logicalOp1) has
990 :     been added to do this.
991 :    
992 :     DESCRIPTION:
993 :    
994 :     main() {
995 :     void* p;
996 :    
997 :     !p;
998 :     }
999 :    
1000 :     gives type error
1001 :     error: Type Error: operand of unary op ! must be a number.
1002 :    
1003 :    
1004 : nch 665 ----------------------------------------------------------------------
1005 :     NUMBER: 14
1006 :     SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
1007 :     DATE: 4/17/00
1008 :     TEST: a240.c
1009 :     STATUS: fixed 16/June/00
1010 :     FIX:
1011 :     There is a flag to control this behaviour in config.sml:
1012 :     Config.TypeCheckControl.convert_function_args_to_pointers
1013 :    
1014 :     It should be set to true for standard behaviour (but was set to false
1015 :     for some reason -- maybe temporarily for debugging something else, and then
1016 :     not reverted back to true??).
1017 :    
1018 :     This is actually an ambiguous case: a strict reading of the standard would
1019 :     suggest that this should be flagged as a type error, but most
1020 :     compilers allow it, so it is "standard".
1021 :    
1022 :     DESCRIPTION: array formals
1023 :    
1024 :     This one is similar to the ?: bug we reported earlier (Bug number 8).
1025 :    
1026 :     void foo(int a[]);
1027 :    
1028 :     int main() {
1029 :     int * ip;
1030 :     foo(ip);
1031 :     }
1032 :    
1033 :     Output:
1034 :    
1035 :     "tt.c":5.3-10: error: Bad function call:
1036 :     arg 1 has type int * but fn parameter has type int []
1037 :    
1038 :     Correct C output is still produced but the implicit type of ip inside
1039 :     the call to foo has int array type. This is a problem for our
1040 :     instrumentation.
1041 :    
1042 :    

root@smlnj-gforge.cs.uchicago.edu
ViewVC Help
Powered by ViewVC 1.0.0