Right now it concatenates it with the existing options and then appends
it to that list, fix it to simply append it as is, same as it is done
with the other variables.
Tested by running the following command which includes gcc options:
$ make check RUNTESTFLAGS="--tool_opts '-Werror'"
Without this patch, all the tests fail. With it, the test succeed.
Inspecting the logs shows that -Werror was indeed used when compiling
the test sources.
libffi on 32-bit x86 now supports closures for all supported ABIs.
Thus, rewrite the last remaining duplicated-by-ABI test (closure_stdcall
and closure_thiscall) to use the generic ABI_NUM/ABI_ATTR mechanism.
This eliminates all the *_win32.c tests in favor of the tests they were
branched from, and expands test coverage to run many more tests on
stdcall, thiscall, and fastcall.
This same mechanism also supports testing any other target that has
multiple ABIs.
This commons up code from libffi.call/call.exp and
libffi.special/special.exp, unifies the optimization option matrix
between the two, and makes it easier to add more axes to the matrix
in the future.
Linux supports the stdcall calling convention, either via functions
explicitly declared with the stdcall attribute, or via code compiled
with -mrtd which effectively makes stdcall the default.
This introduces FFI_STDCALL, FFI_THISCALL, and FFI_FASTCALL on
non-Windows x86-32 platforms, as non-default calling conventions.
testsuite/libffi.call/closure_stdcall.c and
testsuite/libffi.call/closure_thiscall.c include inline assembly to save
the stack pointer before and after the call, and compare the values.
However, compilers can and do leave the stack in different states for
these two pieces of inline assembly, such as by saving a temporary value
on the stack across the call; observed with gcc -Os, and verified as
spurious through careful inspection of disassembly.
The test case testsuite/libffi.call/many_win32.c can spuriously fail due
to excess floating-point precision. Instrumenting it with some printf
calls shows differences well above FLT_EPSILON. (Note when
instrumenting it that multiple computations of the difference, such as
one in a print and another in the conditional, may produce different
results.)
Rather than complicating the test suite with architecture-specific flags
to avoid excess precision, just simplify the floating-point computation
to avoid a dependency on potential excess precision.
The test case testsuite/libffi.call/many.c can spuriously fail due to
excess floating-point precision. Instrumenting it with some printf
calls shows differences well above FLT_EPSILON. (Note when
instrumenting it that multiple computations of the difference, such as
one in a print and another in the conditional, may produce different
results.)
Rather than complicating the test suite with architecture-specific flags
to avoid excess precision, just simplify the floating-point computation
to avoid a dependency on potential excess precision.
code, and makes it possible to link code compiled with different
options to those used to compile libffi. For example, a
-mlong-double-128 libffi can be used with -mlong-double-64 code.
Using the return value area as a place to pass parameters wasn't such
a good idea, causing a failure of cls_ulonglong.c. I didn't see this
when running the mainline gcc libffi testsuite because that version of
the test is inferior to the upstreamm libffi test.
Using NUM_FPR_ARG_REGISTERS rather than NUM_FPR_ARG_REGISTERS64 meant
that a parameter save area could be allocated before it was strictly
necessary. Wrong but harmless. Found when splitting apart ffi.c
into 32-bit and 64-bit support.
fpr area and the parameter save area, necessary when the backend
doesn't know if a function argument corresponds to the ellipsis
arguments of a variadic function. This patch adds powerpc support for
variadic functions, and changes the code to only pass fp in the ABI
mandated area. ELFv2 needs this change since the parameter save area
may not exist there.
This also fixes two faulty tests that used a non-variadic function
cast to call a variadic function, and spuriously reasoned that this is
somehow necessary for static functions..
