Open jpellegrini opened 7 years ago
gnooth
commented
7 years ago There were a lot of changes after 0.0.0.291, but no new release.
I suggest you try again with the current GitHub source. I managed to build from that on a 64-bit Ubuntu system in December 2015.
-Peter
jpellegrini
commented
7 years ago Ok -- I just tried the sources from GitHub, and there seems to be some small issue in numbers.cpp (see below).
J.
g++ -Wall -fno-exceptions -fno-omit-frame-pointer -c -g -DNDEBUG -O2 -march=k8 -m64 numbers.cpp
numbers.cpp: In function ‘long int abs(long int)’:
numbers.cpp:35:23: error: ‘long int abs(long int)’ conflicts with a previous declaration
inline long abs(long x)
^
In file included from /usr/include/c++/6/stdlib.h:36:0,
from numbers.cpp:19:
/usr/include/c++/6/cstdlib:172:3: note: previous declaration ‘long int std::abs(long int)’
abs(long __i) { return __builtin_labs(__i); }
^~~
numbers.cpp: In function ‘Value SYS_truncate_2(Value, Value)’:
numbers.cpp:2912:29: error: call of overloaded ‘abs(long int&)’ is ambiguous
long n_abs = abs(n);
^
In file included from /usr/include/c++/6/cstdlib:75:0,
from /usr/include/c++/6/stdlib.h:36,
from numbers.cpp:19:
/usr/include/stdlib.h:735:12: note: candidate: int abs(int)
extern int abs (int __x) __THROW __attribute__ ((__const__)) __wur;
^~~
In file included from /usr/include/c++/6/stdlib.h:36:0,
from numbers.cpp:19:
/usr/include/c++/6/cstdlib:185:3: note: candidate: __int128 std::abs(__int128)
abs(__GLIBCXX_TYPE_INT_N_0 __x) { return __x >= 0 ? __x : -__x; }
^~~
/usr/include/c++/6/cstdlib:180:3: note: candidate: long long int std::abs(long long int)
abs(long long __x) { return __builtin_llabs (__x); }
^~~
/usr/include/c++/6/cstdlib:172:3: note: candidate: long int std::abs(long int)
abs(long __i) { return __builtin_labs(__i); }
^~~
In file included from /usr/include/c++/6/math.h:36:0,
from numbers.cpp:21:
/usr/include/c++/6/cmath:103:5: note: candidate: constexpr typename __gnu_cxx::__enable_if<std::__is_integer<_Tp>::__value, double>::__type std::abs(_Tp) [with _Tp = long int; typename __gnu_cxx::__enable_if<std::__is_integer<_Tp>::__value, double>::__type = double]
abs(_Tp __x)
^~~
/usr/include/c++/6/cmath:95:3: note: candidate: constexpr long double std::abs(long double)
abs(long double __x)
^~~
/usr/include/c++/6/cmath:91:3: note: candidate: constexpr float std::abs(float)
abs(float __x)
^~~
/usr/include/c++/6/cmath:85:3: note: candidate: constexpr double std::abs(double)
abs(double __x)
^~~
numbers.cpp:35:13: note: candidate: long int abs(long int)
inline long abs(long x)
^~~
numbers.cpp:2913:29: error: call of overloaded ‘abs(long int&)’ is ambiguous
long d_abs = abs(d);
^
In file included from /usr/include/c++/6/cstdlib:75:0,
from /usr/include/c++/6/stdlib.h:36,
from numbers.cpp:19:
/usr/include/stdlib.h:735:12: note: candidate: int abs(int)
extern int abs (int __x) __THROW __attribute__ ((__const__)) __wur;
^~~
In file included from /usr/include/c++/6/stdlib.h:36:0,
from numbers.cpp:19:
/usr/include/c++/6/cstdlib:185:3: note: candidate: __int128 std::abs(__int128)
abs(__GLIBCXX_TYPE_INT_N_0 __x) { return __x >= 0 ? __x : -__x; }
^~~
/usr/include/c++/6/cstdlib:180:3: note: candidate: long long int std::abs(long long int)
abs(long long __x) { return __builtin_llabs (__x); }
^~~
/usr/include/c++/6/cstdlib:172:3: note: candidate: long int std::abs(long int)
abs(long __i) { return __builtin_labs(__i); }
^~~
.
. ;;; and the usual cascade of C++ errors follows :-)
.I see what happened -- in numbers.cpp, there is this:
inline long abs(long x)
{
return (x >= 0) ? x : -x;
}which seems to be declared also in stdlib.h.
I could come up with a patch if it's OK for you -- but there are two ways to fix it, as I see: one is to keep the definition above, but change the function name to something that does not conflict with standard library names (like, for example, "long_abs"); the other is to remove the definition and switch to the standard function -- which, for long ints, is called "labs". The second option seems cleaner, but the first one may be more efficient because of the inline declaration.
J.
jpellegrini
commented
7 years ago So -- I have renamed the inline function to long_abs (and substituted all calls to it), and it compiled. However, XCL segfaults when running the tests in the ansi-tests directory:
$ gdb ../xcl
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ../xcl...done.
(gdb) run
Starting program: /home/jeronimo/xcl/xcl
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
XCL 0.0.0.291 (x86-64) built Thu May 25 08:58:08 -03 2017
Copyright (C) 2006-2011 Peter Graves
Startup completed in 0.71 seconds.
Type ":help" for a list of available commands.
CL-USER(1): (load "doit.lsp")
Program received signal SIGSEGV, Segmentation fault.
symbol_macro_p (value=1439830018) at SymbolMacro.hpp:39
39 && the_typed_object(value)->widetag() == WIDETAG_SYMBOL_MACRO);
(gdb)
where
#0 symbol_macro_p (value=1439830018) at SymbolMacro.hpp:39
#1 eval (form=93825000304839, env=env@entry=0x555555cfaa20, thread=thread@entry=0x5555559cedc0) at eval.cpp:182
#2 0x00005555555f5df1 in eval_call (function=0x5555559bf0a0, args=93824999637265, env=env@entry=0x555555cfaa20, thread=thread@entry=0x5555559cedc0) at eval.cpp:242
#3 0x00005555555f5cba in eval (form=93824999637233, env=env@entry=0x555555cfaa20, thread=thread@entry=0x5555559cedc0) at eval.cpp:216
#4 0x0000555555607085 in CL_let (args=93824999679297, env=0x555555cfaa20, thread=0x5555559cedc0) at let.cpp:67
#5 0x00005555555f5b50 in eval (form=93824999679281, env=env@entry=0x555555cfaa20, thread=thread@entry=0x5555559cedc0) at eval.cpp:199
#6 0x00005555555768f3 in CL_progn (args=93824999679249, env=env@entry=0x555555cfaa20, thread=0x5555559cedc0) at lisp.cpp:495
#7 0x00005555555f3521 in Closure::execute (this=0x555555ce1210, arg1=1439830018, arg2=93825005341585) at Closure.cpp:584
#8 0x00005555564c0e2f in ?? ()
#9 0x00007fffffff7f18 in ?? ()
#10 0x00005555564c0e07 in ?? ()
#11 0x00005555561d4b91 in ?? ()
#12 0x00007fffffff7f70 in ?? ()
#13 0x00005555559cedc0 in ?? ()
#14 0x00005555555a069d in Thread::execute (this=0x5555559cedc0, function=0x555555d21000, numargs=<optimized out>, args=0x7fffffff7f90) at Thread.cpp:648
Backtrace stopped: previous frame inner to this frame (corrupt stack?)I just committed the change you suggested to numbers.cpp, which seems to fix the build. Thanks!
On 64-bit Debian a fresh build of xcl segfaults for me in symbol_macro_p when I try to do rebuild-lisp, with a backtrace very similar to yours.
So clearly there are bugs.
I stopped working on xcl in 2011. To the best of my recollection it worked well enough then to run rebuild-lisp and then make it through the ansi-tests with roughly the expected number of failures.
My Ubuntu build from 2015 has the .xcl files to prove that it made it through rebuild-lisp, but when I tried to run the ansi-tests just now it segfaulted after compiling numbers-aux.lisp, which happens before any actual tests are run. I don't think I bothered to run the tests in 2015.
I tried going back in time to commit 423754691704811c1c4e174b8082190bccf36426 and building that with a patched numbers.cpp, but it didn't help.
I don't have the time or commitment these days to work on this problem with the seriousness that it would be likely to require. Since 2011 I've basically just looked at xcl now and then to steal bits of my old code.
I'll try to answer any questions I know the answer to.
Good luck!
-Peter
jpellegrini
commented
5 years ago Some news:
Besides the problem with SymbolMacro.hpp, XCL it loops forever a condition is signalled.
In stack.lisp, some function seems to be using the stack-entry-* accessors on NIL (not a structure), so another condition is signalled, etc, until the maximum number of nested conditions is reached.
But before a condition is signalled, some simple things do work.
I'll try to look more into this later.
J.
jpellegrini
commented
5 years ago I also collected some compilaition warnings, just in case they're useful for debugging these things (except for unused variables warnings).
J.
modules/objfmts/elf/elf.c: In function ‘elf_set_arch’:
modules/objfmts/elf/elf.c:102:34: warning: passing argument 3 of ‘yasm_symrec_add_data’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
&elf_march->ssyms[i]);
^~~~~~~~~~~~~~~~~~~~
In file included from ./libyasm.h:60,
from modules/objfmts/elf/elf.c:31:
./libyasm/symrec.h:427:55: note: expected ‘void *’ but argument is of type ‘const elf_machine_ssym * const’ {aka ‘const struct <anonymous> * const’}
/*@only@*/ /*@null@*/ void *data);set_d.c: In function ‘mpfr_set_d’:
set_d.c:242:5: warning: iteration 0x8000000000000000 invokes undefined behavior [-Waggressive-loop-optimizations]
MPN_ZERO (tmpmant, k);
^~~~~~~~
set_d.c:242:5: note: within this loop
set_d.c:239:5: warning: iteration 0x8000000000000000 invokes undefined behavior [-Waggressive-loop-optimizations]
MPN_COPY (tmpmant + k, tmpmant, i);
^~~~~~~~
set_d.c:239:5: note: within this loopsub1sp.c: In function ‘mpfr_sub1sp’:
sub1sp.c:808:21: warning: ‘*’ in boolean context, suggest ‘&&’ instead [-Wint-in-bool-context]
MPFR_RET (inexact * MPFR_INT_SIGN (a));
mpfr-impl.h:752:4: note: in definition of macro ‘MPFR_RET’
(I) ? ((__gmpfr_flags |= MPFR_FLAGS_INEXACT), (I)) : 0
^add1sp.c: In function ‘mpfr_add1sp’:
add1sp.c:383:21: warning: ‘*’ in boolean context, suggest ‘&&’ instead [-Wint-in-bool-context]
MPFR_RET (inexact * MPFR_INT_SIGN (a));
mpfr-impl.h:752:4: note: in definition of macro ‘MPFR_RET’
(I) ? ((__gmpfr_flags |= MPFR_FLAGS_INEXACT), (I)) : 0
^set_z_exp.c: In function ‘mpfr_set_z_2exp’:
set_z_exp.c:179:17: warning: ‘*’ in boolean context, suggest ‘&&’ instead [-Wint-in-bool-context]
MPFR_RET (inex*sign_z);
mpfr-impl.h:752:4: note: in definition of macro ‘MPFR_RET’
(I) ? ((__gmpfr_flags |= MPFR_FLAGS_INEXACT), (I)) : 0
^
Hello, I am trying to compile XCL 0.0.0.291, but it fails when linking. gcc complains about duplicated symbols. I'm attaching the output here.
I am using gcc 6.3.0 on a 64-bit Linux system (Debian testing).
Thanks, J.