URL
https://opencores.org/ocsvn/openrisc_2011-10-31/openrisc_2011-10-31/trunk
Go to most recent revision |
Details |
Compare with Previous |
View Log
Line No. |
Rev |
Author |
Line |
1 |
330 |
jeremybenn |
/* The following is written to tickle a specific bug in the macro
|
2 |
|
|
table code (now hopefully fixed), which doesn't insert new included
|
3 |
|
|
files in the #including file's list in the proper place. They
|
4 |
|
|
should be sorted by the number of the line which #included them, in
|
5 |
|
|
increasing order, but the sense of the comparison was reversed, so
|
6 |
|
|
the list ends up being built backwards. This isn't a problem by
|
7 |
|
|
itself, but the code to pick new, non-conflicting line numbers for
|
8 |
|
|
headers alleged to be #included at the same line as some other
|
9 |
|
|
header assumes that the list's line numbers are in ascending order.
|
10 |
|
|
|
11 |
|
|
So, given the following input, lineinc1.h gets added to lineinc.c's
|
12 |
|
|
#inclusion list first, at line 10. When the debug info reader
|
13 |
|
|
tries to add lineinc2.h at line 10 as well, the code will notice the
|
14 |
|
|
duplication --- since there's only one extant element in the list,
|
15 |
|
|
it'll find it --- and insert it after lineinc1.h, with line 11.
|
16 |
|
|
Since the code is putting the list in order of descending
|
17 |
|
|
#inclusion line number, the list is now out of order. When we try
|
18 |
|
|
to #include lineinc3.h at line 11, we won't notice the duplication. */
|
19 |
|
|
|
20 |
|
|
#line 10
|
21 |
|
|
#include "lineinc1.h"
|
22 |
|
|
#line 10
|
23 |
|
|
#include "lineinc2.h"
|
24 |
|
|
#line 11
|
25 |
|
|
#include "lineinc3.h"
|
26 |
|
|
|
27 |
|
|
int
|
28 |
|
|
main (int argc, char **argv)
|
29 |
|
|
{
|
30 |
|
|
}
|
© copyright 1999-2024
OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.