Various patches against gmp-4.3.0
tg at gmplib.org
Wed May 6 10:06:54 CEST 2009
Michiel De Wilde <mdewilde.agilent at googlemail.com> writes:
> o dont_redefine_restrict_keyword.diffWindows does not like the
redefinition of "restrict" as it is being used in some win32 headers
> This is in an internal gmp file. Please explain why this can be a
A #define always changes a name on a global scope level. On Windows, some
win32 headers that get included use __declspec(restrict), which is now
changed to __declspec(__restrict), which is invalid. The problem does not
occur if you include the project name into the identifier that is being
redefined: "#define GMP_RESTRICT __restrict" instead of "#define restrict
__restrict" (and replace "restrict" by "GMP_RESTRICT" in the code).
Sorry, I don't see why this reasoning is relevant to the present
situation. I repeat: gmp-impl.h is an internal GMP file. Surely its
"global" effects should be quite limited. :-)
I understand that
can be a problem. Are you trying to say that we do that in GMP?
If you, as I suspect, are playing with GMP's internal interfaces, you're
onn your own.
Please: specify the exact actualy problem you're trying to solve, don't
just explain us the theory!
> o forgotten_extern_C.difffix for t-locale.cc where an extra extern
> "C" is needed
> Why is this needed?
Without the extern "C", the variable "point_string" is subject to C++ name
mangling: on win32 it becomes "?point_string@@3PADA", leaving an unresolved
Well, this is a C++ file, point_string is supposed to be a C++ variable,
so if your compiler mangles its use but not its declaration, it sounds
like a serious compiler problem.
o much_more_declspecs.diffin order to make a GMP dll and run the
> testsuite on it, a lot of functions need to be exported in the dll
> that currently aren't
> I don't see how gmp-impl.h needs this patching. Please explain!
We test the gmp dll with the full regression test set. These tests are
directly accessing functions declared in gmp-impl.h. If these functions are
not publically exposed in the dll, many tests will fail because they can't
access the functions.
Ah, so you *are* playing with GMP internals. Sorry, there are very good
reasons for not trying to make that easier.
IMO it is worse to disallow the regression suite to run than to expose these
functions publically in the dll (certainly because, by comparison, on
Linux/UNIX every function is visible anyway).
Not true. I have done work on e.g, GNU libc and it surely has internal
This has nothing whatsoever to do with testing. The GMP testsuite, and
the test programs in tests/devel test all GMP functions.
Besides that, the patch also corrects the __GMP_INLINE_PROTOTYPES handling
Yes, and the current snapshot has a fix for that.
I think there was an error with the "tfprintf" test from mpfr that only
appears when your system doesn't have a valid vprintf/vsnprintf (such as on
In the function that is being patched, a "goto next" is called to indicated
the end of a printf formatting item such as the "d" of "%d". A "break"
appears when detecting modifier characters within a formatting item, such as
the ".17" in "%.17f". As a "g" or and "f" is the final character of a
formatting item, there should be a "goto next" and not a "break".
It would be simpler for me to make sure the patch is needed if you sent
me a test case.
More information about the gmp-devel