On 2020-12-12 5:21 p.m., John David Anglin wrote: > On 2020-12-12 4:26 p.m., John Paul Adrian Glaubitz wrote: >> I assume the crash has got something to do how values are packed and unpacked >> into the SCM object type. I have not been able to find the problem yet >> myself, >> unfortunately which is why I am reporting this issue here. > I see this in scm.h: > > /* The 0?: constructions makes sure that the code is never executed, and > that there is no performance hit. However, the alternative is > compiled, and does generate a warning when used with the wrong > pointer type. We use a volatile pointer type to avoid warnings from > clang. > > The Tru64 and ia64-hp-hpux11.23 compilers fail on `case (0?0=0:x)' > statements, so for them type-checking is disabled. */ > # if defined __DECC || defined __HP_cc > # define SCM_UNPACK(x) ((scm_t_bits) (x)) > # else > # define SCM_UNPACK(x) ((scm_t_bits) (0? (*(volatile SCM *)0=(x)): x)) > # endif I don't believe this is a problem.
We need to investigate why scm_sum is passed "x=x@entry=0x0". SCM_BIGP (x) will fault on it. Maybe SP_REF is broken. Regards, Dave -- John David Anglin dave.ang...@bell.net
