[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#45214: guile segfaults on 32-bit big-endian targets
From: |
John David Anglin |
Subject: |
bug#45214: guile segfaults on 32-bit big-endian targets |
Date: |
Mon, 8 Feb 2021 18:24:58 -0500 |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 |
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.anglin@bell.net
- bug#45214: guile segfaults on 32-bit big-endian targets,
John David Anglin <=