No repro with GCC 5.3.1-2, 2015-12-07 either. I seem to have everything matching, toolchain-wise.
On 07.01.2016 22:53, Kaz Kylheku wrote:
No repro with 32 bit txr-121 (or private current HEAD) built and run on 64 bit Fedora 23, oops!
In gdb, I see those aforementioned "funny" addresses: the stack and some dynamic allocations are at the high end of the 32 bit address space, courtesy of the 64 bit kernel underneath.
GCC is version 5.1.1 built on 20150618.
I configured using
./configure --platform-cflags=-m32 --platform-ldflags=-m32
These variables are there for that sort of thing: CPU tuning, ABI selection and whatnot.
I'm guessing that on the build machine, this is baked into your GCC used for 32 bit packages, so you don't have to tell every package to add -m32 to its CFLAGS.
(It would be good to know the exact compiler specs there: /path/to/package/building/gcc -dumpspecs)
On 07.01.2016 13:51, Kaz Kylheku wrote:
The type mismatch at match.c:3923 means that things are so foobared that the syntax of the program itself is corrupt.
But what is ultimately failing is almost certainly the std_output expression, which is a macro that performs a symbolic lookup to fetch the current location of the dynamically scoped variable. The rest of default_arg is just pointer comparisons.
It could be useful to see just what the heck is wrong with object 0xf7db4f5c; why isn't it a CONS, as expected?
We can see its contents with:
(gdb) p *obj
in the obj_print stack frame.
These are funny addresses, by the way; the program is using addresses right through 0xFFFFFXXX. Where the heck is the kernel hiding? This must be a 32 bit build on a 64 bit system, right?
If so, that is different from what I tried; I have a 32 bit Fedora 23 VM.
Thanks a lot.
(text/plain)