Toolchain Info :
gcc 4.2.2 ( gcc 4.3 trunk tested with similar results)
glibc 2.6 ( glibc 2.7 tested with similar results)
Linux 2.6.18.6 , 32bit
binutils 2.18.50.0.3
I am trying to build Clisp with :
./configure \ --prefix=/usr \ --with-dynamic-ffi \ --with-module=wildcard \ --with-module=rawsock \ --with-module=clx/new-clx \ --with-module=pcre \ --with-module=zlib \ --build
This results in a weird build error :
gcc -mtune=native -march=i686 -O2 -pipe -fomit-frame-pointer -Igllib -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -O2 -fexpensive-optimizations -falign-functions=4 -DUNICODE -DDYNAMIC_FFI -I. -c spvw.c
In file included from lispbibl.d:321,
from spvw.d:24:
floatparam.h:18:2: error: #error "Unknown rounding mode for type double!"
If I run the same configure line again it doesn't give that error but now clisp crashes when compiling some file :
gcc -mtune=native -march=i686 -O2 -pipe -fomit-frame-pointer -Igllib -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -O2 -fexpensive-optimizations -falign-functions=4 -DUNICODE -DDYNAMIC_FFI -I. -x none spvw.o spvwtabf.o spvwtabs.o spvwtabo.o eval.o control.o encoding.o pathname.o stream.o socket.o io.o array.o hashtabl.o list.o package.o record.o weak.o sequence.o charstrg.o debug.o error.o misc.o time.o predtype.o symbol.o lisparit.o i18n.o foreign.o unixaux.o built.o ari80386.o gllib/uniwidth/width.o gllib/uniname/uniname.o gllib/localcharset.o modules.o libavcall.a libcallback.a /usr/lib/libreadline.so -lncurses -ldl -L/usr/lib -lsigsegv -L/usr/lib -lc -o lisp.run
./lisp.run -B . -N locale -E 1:1 -Efile UTF-8 -Eterminal UTF-8 -norc -m 1800KW -x "(and (load \"init.lisp\") (sys::%saveinitmem) (ext::exit)) (ext::exit t)"
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8
Welcome to GNU CLISP 2.43 (2007-11-18) <http://clisp.cons.org/>
Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2007
Type :h and hit Enter for context help.
*** - EXPORT: argument should be a symbol or a list of symbols, not
*** - Internal error: statement in file "io.d", line 7009 has been reached!!
Please see <http://clisp.cons.org/impnotes/faq.html#faq-bugs> for bug reporting instructions.
*** - EVAL: undefined function EXT::EXIT
Bye.
Logged In: YES
user_id=5735
Originator: NO
1. what happens when you remove "-mtune=native" and "-march=i686"?
2. what about "-fexpensive-optimizations"?
3. what about "-O2"?
please see "Hints for porting to new platforms:" in clisp/unix/PLATFORMS.
thanks.
Logged In: YES
user_id=557782
Originator: YES
Removing -O2 fixes the interpreter crash, this might either be a gcc bug or a clisp bug, need help to debug further :(.
First error about double rounding mode looks random, doesn't happen after trying twice, but happened at third try. Now the question is why there is a double rounding error, because this is just 32bit Linux 2.6 platform, nothing fancy.
Thank you.
Logged In: YES
user_id=5735
Originator: NO
it would be nice to figure out which file(s) is miscompiled.
you need to do a binary search, adding -O2 to some files' rules and seeing if CLISP builds.
the rounding may be related to the -mtune and -march parameters, especially if they do not specify your hardware correctly.
Logged In: YES
user_id=557782
Originator: YES
Ok I will do a binary search, but I don't still understand rounding error, the machine has a Intel (Conroe) cpu which is a i686.
Logged In: YES
user_id=557782
Originator: YES
Is there a small testcase that I can compile and test rounding mode? there is a m4 file for this check but I have no idea about m4 language.
Logged In: YES
user_id=5735
Originator: NO
please take a look at clisp/src/floatparam.c which actually generates the message
Logged In: YES
user_id=557782
Originator: YES
Following files are miscompiled with -O2 but works fine without it :
src/control.c
src/record.c
src/misc.c
src/predtype.c
If I build these files without -O2 compilation succeeds but 4 tests fail :
Form: (LET ((F (WITH-FOREIGN-STRING (FV E B "ABC") FV))) (VALIDP F))
CORRECT: NIL
CLISP : T
Form: (VALIDP FM)
CORRECT: NIL
CLISP : T
Form: (VALIDP FM)
CORRECT: NIL
CLISP : T
Form: (PROGN (SETF (VALIDP FM) NIL) (VALIDP FM))
CORRECT: NIL
CLISP : T
What shall we do now?
Thanks,
ismail
Logged In: YES
user_id=557782
Originator: YES
Ok after lots more testing here is an incomplete list of miscompiled at -O2 files :
src/control.c
src/error.c
src/eval.c
src/io.c
src/misc.c
src/predtype.c
src/record.c
src/symbol.c
src/weak.c
Unless you compile all of this without -O2 clisp won't build. After you recompile this test failures goes up to 17. Looks like all of clisp is miscompiled.
Logged In: YES
user_id=5735
Originator: NO
the file list is too long.
at any rate, the next step is to file a gcc bug report.
I think they will need a small code fragment with the resulting assembly and an explanation of why this is a gcc bug. unless you can read assembly well, this is a task for Bruno.
Logged In: YES
user_id=557782
Originator: YES
I can't really read ASM, I hope Bruno can create a small testcase.
Logged In: YES
user_id=377168
Originator: NO
You have much more experience with me with platform-specific bugs, but from the texts snippets IMHO it does not necessarily follow that there's a bug in the ASM generation part. It could be a problem at CPP stage, e.g. a case of a standard system /usr/include symbol overwriten by one of CLISP's (or configure's) preprocessor macros.
I'd recommend to first find out WHY does running configure twice produce different results each time. Esp. the case where it produces
error: #error "Unknown rounding mode for type double!"
This is not normal at all.
My experience is that I would not trust *.o files generated from a broken configuration.
Garbage in, garbage out. I'd only attempt generating *.o files after the configuration looks perfect.
IMHO, a crashing clisp -O2 but working -O0 is no necessary indication of a bug in gcc, esp. given the above potential for a broken configuration.
Logged In: YES
user_id=557782
Originator: YES
Ok fair enough but this is not an exotic platform, this is just i686 and I just checked glibc regression tests passes when compiled with the gcc on the system.
Anyway if I unset CFLAGS before building CLISP I got no configuration errors, so this is not a garbage in garbage out problem at all.
There are two unrelated problems. And it would be cool if you guys could try to reproduce this. gcc 4.2 is not hard to come by. You just try a Debian/Ubuntu Live CD.
Logged In: YES
user_id=5923
Originator: NO
These are two different problems indeed:
1) The floatparam thing. I don't reproduce it with gcc-4.2.1. So please investigate it.
2) lisp.run crashes. I do reproduce it with gcc-4.2.1, although with a different error message. Give me some time, and I can distill a gcc test case for it.
Additionally, I observe that the compilation of stream.d and io.d is very slow (18 minutes for one, more than 25 minutes for the other). This appears to be the same as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052 which should be fixed in gcc 4.2.3.
Logged In: YES
user_id=557782
Originator: YES
Hi Bruno,
To reproduce problem 1 can you try setting CFLAGS to -march=i686 -mtune=generic and try like that, also try a gcc 4.3 snapshot its compiling real fast but miscompiles somehow.
Logged In: YES
user_id=5923
Originator: NO
Ad problenm 2): gcc definitely miscompiles rehash_symtab in package.d.
Logged In: YES
user_id=557782
Originator: YES
Hi Bruno,
Firstly thanks for debugging this, about problem 1 are you able to reproduce it after setting CFLAGS to -march=i686 -mtune=generic? Else I will try to hunt it down.
Regards,
ismail
Logged In: YES
user_id=5923
Originator: NO
Ad 2) I registered this gcc bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34300
Ad 1) Ismail, can you please hunt it down?
Logged In: YES
user_id=557782
Originator: YES
Ok I will debug the first problem but the gcc bug says it works with gcc 4.3.0 but clisp fails with gcc trunk here.
Logged In: YES
user_id=557782
Originator: YES
I debugged problem 2 further and adding -fno-forward-propagate to the CFLAGS makes compilation happy up to :
[....]
;; Loading file clos-specializer1.fas ...
;; Loaded file clos-specializer1.fas
;; Loading file clos-class1.fas ...
;; Loaded file clos-class1.fas
;; Loading file clos-class2.fas ...
;; Loaded file clos-class2.fas
;; Loading file clos-class3.fas ...
*** - CHECKED-COMPUTE-CLASS-PRECEDENCE-LIST: symbol <T> has no value
Bye.
Not fully working but not bad at all I guess.
Logged In: YES
user_id=557782
Originator: YES
Even further debugging shows following code from symbol.c is miscompiled at -O2 :
==========================
#include "lispbibl.c"
LISPFUNNR(keywordp,1)
{ /* (KEYWORDP object), CLTL p. 170 */
{var object obj = popSTACK();
VALUES_IF(symbolp(obj) && keywordp(obj));
}}
==========================
Bruno do you think you could help me to get this code standalone somehow so I can report a gcc bug?
Logged In: YES
user_id=557782
Originator: YES
floatparam.h:18:2: error: #error "Unknown rounding mode for type double!"
error was due to a problem in glibc 2.7 now fixed. CLISP miscompilation however is still valid as of today's gcc trunk.
Happy new year,
ismail
Logged In: YES
user_id=29522
Originator: NO
Since Fedora rawhide now uses GCC 4.3, the clisp package
does not build anymore. Has there been some progress on
this issue?
Logged In: YES
user_id=5923
Originator: NO
Ad 1) The floatparam thing. I reproduced it with gcc-4.3-20080215 on
Linux/x86. It is not a "problem in glibc 2.7". It is simply that
the functions equal_float and equal_double were inlined by gcc and
implemented as comparison of 80-bit 'long double's. The program thus
determined that float and double have 64 mantissa bits...
Fixed in CVS HEAD and in clisp 2.43.1 and 2.44.1 (not yet released).
Logged In: YES
user_id=5923
Originator: NO
Ad 2) The gcc bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34300
that I filed for GCC 4.2 is still pending. The workaround for it is to
not use global register variables with this version of GCC.
This workaround also fixes the problems with the GCC 4.3-20080215
snapshot, although this snapshot does not miscompile the code snippet
from bug #34300. It must be another GCC bug.
In any case, the workaround has been included in clisp 2.43.1 and
2.44.1 (not yet released) and in clisp CVS HEAD.