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.