[build] Use autoconf to find out cl_word_alignment.
This way there's no need to define cl_word_alignment for every CPU. Also we
can stop exposing __$cpu__ macros in the public headers (for one our macros
conflict with compiler defined ones).
Richard Kreckel [Mon, 19 Oct 2020 08:36:57 +0000 (10:36 +0200)]
Replace unused macro with cl_unused.
It has become customary to use 'unused' within bitfields. Better avoid
this conflict. This fixes cross-compilation issues on several ARM-based
host platforms.
Richard Kreckel [Sat, 17 Oct 2020 22:23:28 +0000 (00:23 +0200)]
Assume types 'long long int' and 'long double' exist.
The C++11 standard requires in 3.9.1-2 that type 'long long int' exists
and in -8 that type 'long double' exists. So, remove macros HAVE_LONGLONG
and HAVE_LONGDOUBLE. Also, shamelessly update m4/param.m4, m4/intparam.m4,
and m4/floatparam.m4 with code from CLisp.
All this fixes several cross-compilation issues discovered by
Helmut Grohne <helmut@subdivi.de>.
Commit 2f799401454292 (`Replace typedef int[<negative>] trick with static_assert.`)
breaks cross compilation due to invalid `include/cln/intparam.h` header
produced by the configure script.
CL_INTPARAM_BITSIZE relies on integer multiplication overflow to find out
the bit size of various integer types. However singed integer overflow
is an undefined behavior. Apparently in some contexts GCC uses mod 2^N
arithmetics to evaluate the signed integer expressions. As a result
`typedef int[2*((T)((T)2 * ... * (T)2) == 0) - 1]` trick works with both
signed and unsigned integers (and gives the correct result).
Howerver GCC considers an expression involving an integer overflow as
a non-constant, and refuses to use it in `static_assert`:
As a result `static_assert((T)((T)2 * ... * (T)2) == 0, "")` never holds
since either 1) the condition can't possibly hold without an overflow,
or 2) GCC rejects the expression when the overflow occurs.
Keep using the old good `typedef int[negative]` in CL_INTPARAM_BITSIZE
to avoid the problem.
Bruno Haible [Sat, 26 Oct 2019 14:52:28 +0000 (16:52 +0200)]
Revamp and simplify autoconfiguration.
- New file autogen.sh.
- Put build scripts in build-aux/ not autoconf/.
- Install lib-*.m4 and config.rpath through gnulib module 'havelib'.
- Install 'test-driver' through automake.
YunQiang Su [Sun, 18 Mar 2018 11:05:51 +0000 (12:05 +0100)]
Support MIPS release 6.
MIPS release 6 is not full compatible with the previous releases, it removes
some instructions and changes encoding of some instruction.
the `multu' is included.
MIPS r6 drops `lo' and `hi' registers, and then removes `multu'/`mfhi'/`mflo'.
Instead it uses `mulu' to compute the low part and `muhu' to compute
the high part.
Richard Kreckel [Sat, 11 Oct 2014 22:03:21 +0000 (22:03 +0000)]
Fix floating-point input from decimal string.
A bug was introduced in 3480230e: The divide-and-conquer method multiplies
with a power of the base, but this power is one too much if there is a
decimal point. This may happen because digits_to_I(...) is also called
from read_float(...). As a result, the number containd spurious zeros
(in the base used for reading it).
Thanks to Thomas Luthe <tluthe@physik.uni-bielefeld.de>.
Richard Kreckel [Fri, 19 Sep 2014 20:40:20 +0000 (20:40 +0000)]
Use 8-byte word alignment on arm64.
The previous patch cb76b5eb used 4-byte word alignment.
Thanks to Peter Green and Hector Oron for pointing out that
8-byte alignment should be used (cf. Debian bug #757623).
While building Fedora 21 for AArch64 we found out that your software is
not building for us. Attached is a fix which adds this architecture in
all required places.
Richard Kreckel [Sat, 6 Oct 2012 20:44:34 +0000 (22:44 +0200)]
Fix integer input with leading zeros in power-of-two base.
Reading leading '0' characters in integers of base 2, 4, 8, 16, or 32
could result in a NUDS with leading zero digits. This is against the
rules. The result was a misbehaving cl_I down the road.
Thanks to Morgan Deters <mdeters@cs.nyu.edu> of the CVC4 team.
Richard Kreckel [Sun, 1 Apr 2012 20:38:54 +0000 (22:38 +0200)]
Detect s390x and sparc64 as 32-bit architectures.
CLN fails to build on s390x and sparc64 as it detects them as 32-bit
architectures, due to __s390__ and __sparc__ matching respectively both
s390 and s390x, and both sparc and sparc64. The patch below fixes the
issue. (Reported as Debian bug#639494.)
Richard Kreckel [Sat, 9 Apr 2011 08:04:39 +0000 (10:04 +0200)]
Support for MSVC.
This patch works around problems MSVC has with extern "C" declarations
inside namespace cln. As a result, it should work with MS 32-bit compiler
version 16.00.30319.01.
Fix the documentation build failure (wrong texinfo).
Building PDF, PostScript, and DVI versions of the documentation fails
with the following error message(s):
../../doc/cln.texi:1170: Argument of @asis has an extra }.
<inserted text>
@par
<to be read again>
}
According to texinfo maintainer @itemize @asis is illegal, one should
use @itemize @w{} instead.
See <http://lists.gnu.org/archive/html/bug-texinfo/2009-03/msg00016.html>.