summaryrefslogtreecommitdiff
path: root/usr.bin/mandoc/read.c
diff options
context:
space:
mode:
authorMiod Vallat <miod@cvs.openbsd.org>2012-11-16 22:05:44 +0000
committerMiod Vallat <miod@cvs.openbsd.org>2012-11-16 22:05:44 +0000
commit1fbd71f002e2646b3919903fcdc12497d52918e8 (patch)
treea3cce722a1cf7a70102b9a44768c9a5306221b0b /usr.bin/mandoc/read.c
parent2d9ef402c34515c0a59c6ab7b72cf6b989fb35eb (diff)
Rewrite the varags implementation again (third time's the charm), the upstream
varagrs implementation being utterly wrong. This is the same logic as the one I wrote for gcc 2.95, with a few more optimizations whenever possible (such as not outputting instructions to fill fields of the __va_list struct we know won't be accessed, now that we have total control of the struct in the compiler). It should now be possible to mix varags code compiled by gcc 2.95, with code compiled with gcc 3, with the following exception: as I have finally found and fixed the buglet causing all arguments to be passed on the stack if any of the named arguments (before varargs) is a struct of 32 bytes or more passed by value, such a (pretty uncommon) case will not be interoperable. One such case can be found as va-arg-4.c in gcc's testsuite. With these changes, all the following varargs exercizers from gcc's testsuite now pass when compiled with the in-tree gcc 3: gcc.c-torture/execute/920625-1.c gcc.c-torture/execute/931004-10.c gcc.c-torture/execute/931004-12.c gcc.c-torture/execute/931004-14.c gcc.c-torture/execute/931004-4.c gcc.c-torture/execute/931004-6.c gcc.c-torture/execute/931004-8.c gcc.c-torture/execute/strct-varg-2.c gcc.c-torture/execute/va-arg-1.c gcc.c-torture/execute/va-arg-2.c gcc.c-torture/execute/va-arg-4.c gcc.c-torture/execute/va-arg-5.c gcc.c-torture/execute/va-arg-6.c as well as the few others of my own I had been using while working on gcc 2.95 more than 8 years ago.
Diffstat (limited to 'usr.bin/mandoc/read.c')
0 files changed, 0 insertions, 0 deletions