1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=ANSI_X3.4-1968">
<META name="GENERATOR" content="hevea 1.08">
<base target="main">
<script language="JavaScript">
<!-- Begin
function loadTop(url) {
parent.location.href= url;
}
// -->
</script>
<LINK rel="stylesheet" type="text/css" href="cil.css">
<TITLE>
Known Bugs and Limitations
</TITLE>
</HEAD>
<BODY >
<A HREF="cil011.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="ciltoc.html"><IMG SRC ="contents_motif.gif" ALT="Up"></A>
<A HREF="merger.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
<HR>
<H2 CLASS="section"><A NAME="htoc38">12</A> Known Bugs and Limitations</H2>
<UL CLASS="itemize"><LI CLASS="li-itemize">In the new versions of <TT>glibc</TT> there is a function
<TT>__builtin_va_arg</TT> that takes a type as its second argument. CIL
handles that through a slight trick. As it parses the function it changes a
call like:
<PRE CLASS="verbatim">
mytype x = __builtin_va_arg(marker, mytype)
</PRE>into
<PRE CLASS="verbatim">
mytype x;
__builtin_va_arg(marker, sizeof(mytype), &x);
</PRE>
The latter form is used internally in CIL. However, the CIL pretty printer
will try to emit the original code. <BR>
<BR>
Similarly, <TT>__builtin_types_compatible_p(t1, t2)</TT>, which takes
types as arguments, is represented internally as
<TT>__builtin_types_compatible_p(sizeof t1, sizeof t2)</TT>, but the
sizeofs are removed when printing.<BR>
<BR>
<LI CLASS="li-itemize">The implementation of <TT>bitsSizeOf</TT> does not take into account the
packing pragmas. However it was tested to be accurate on cygwin/gcc-2.95.3,
Linux/gcc-2.95.3 and on Windows/MSVC.<BR>
<BR>
<LI CLASS="li-itemize">We do not support tri-graph sequences (ISO 5.2.1.1).<BR>
<BR>
<LI CLASS="li-itemize">GCC has a strange feature called “extern inline”. Such a function can
be defined twice: first with the “extern inline” specifier and the second
time without it. If optimizations are turned off then the “extern inline”
definition is considered a prototype (its body is ignored). If optimizations
are turned on then the extern inline function is inlined at all of its
occurrences from the point of its definition all the way to the point where the
(optional) second definition appears. No body is generated for an extern
inline function. A body is generated for the real definition and that one is
used in the rest of the file. <BR>
<BR>
CIL will rename your extern inline function (and its uses) with the suffix
<TT>__extinline</TT>. This means that if you have two such definition, that do
different things and the optimizations are not on, then the CIL version might
compute a different answer !<BR>
<BR>
Also, if you have multiple extern inline declarations then CIL will ignore
but the first one. This is not so bad because GCC itself would not like it. <BR>
<BR>
<LI CLASS="li-itemize">There are still a number of bugs in handling some obscure features of
GCC. For example, when you use variable-length arrays, CIL turns them into
calls to <TT>alloca</TT>. This means that they are deallocated when the function
returns and not when the local scope ends. <BR>
<BR>
Variable-length arrays are not supported as fields of a struct or union.<BR>
<BR>
<LI CLASS="li-itemize">CIL cannot parse arbitrary <TT>#pragma</TT> directives. Their
syntax must follow gcc's attribute syntax to be understood. If you
need a pragma that does not follow gcc syntax, add that pragma's name
to <TT>no_parse_pragma</TT> in <TT>src/frontc/clexer.mll</TT> to indicate that
CIL should treat that pragma as a monolithic string rather than try
to parse its arguments.<BR>
<BR>
CIL cannot parse a line containing an empty <TT>#pragma</TT>.<BR>
<BR>
<LI CLASS="li-itemize">CIL only parses <TT>#pragma</TT> directives at the "top level", this is,
outside of any enum, structure, union, or function definitions.<BR>
<BR>
If your compiler uses pragmas in places other than the top-level,
you may have to preprocess the sources in a special way (sed, perl,
etc.) to remove pragmas from these locations.<BR>
<BR>
<LI CLASS="li-itemize">CIL cannot parse the following code (fixing this problem would require
extensive hacking of the LALR grammar):
<PRE CLASS="verbatim"><FONT COLOR=blue>
int bar(int ()); // This prototype cannot be parsed
int bar(int x()); // If you add a name to the function, it works
int bar(int (*)()); // This also works (and it is more appropriate)
</FONT></PRE><BR>
<BR>
<LI CLASS="li-itemize">CIL also cannot parse certain K&R old-style prototypes with missing
return type:
<PRE CLASS="verbatim"><FONT COLOR=blue>
g(); // This cannot be parsed
int g(); // This is Ok
</FONT></PRE><BR>
<BR>
<LI CLASS="li-itemize">CIL does not understand some obscure combinations of type specifiers
(“signed” and “unsigned” applied to typedefs that themselves contain a
sign specification; you could argue that this should not be allowed anyway):
<PRE CLASS="verbatim"><FONT COLOR=blue>
typedef signed char __s8;
__s8 unsigned uchartest; // This is unsigned char for gcc
</FONT></PRE><BR>
<BR>
<LI CLASS="li-itemize">The statement <TT>x = 3 + x ++</TT> will perform the increment of <TT>x</TT>
before the assignment, while <TT>gcc</TT> delays the increment after the
assignment. It turned out that this behavior is much easier to implement
than gcc's one, and either way is correct (since the behavior is unspecified
in this case). Similarly, if you write <TT>x = x ++;</TT> then CIL will perform
the increment before the assignment, whereas GCC and MSVC will perform it
after the assignment.
</UL>
<HR>
<A HREF="cil011.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="ciltoc.html"><IMG SRC ="contents_motif.gif" ALT="Up"></A>
<A HREF="merger.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
</BODY>
</HTML>
|
