bug-guile
[Top][All Lists]
Advanced

[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: Sat, 12 Dec 2020 17:30:00 -0500
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1

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
Also just before, there is:
/* But as external interface, we define SCM, which may, according to the
   desired level of type checking, be defined in several ways.  */
#if (SCM_DEBUG_TYPING_STRICTNESS == 2)
  typedef union SCM { struct { scm_t_bits n; } n; } SCM;
# define SCM_UNPACK(x) ((x).n.n)
# define SCM_PACK(x) ((SCM) { { (scm_t_bits) (x) } })
#elif (SCM_DEBUG_TYPING_STRICTNESS == 1)
/* This is the default, which provides an intermediate level of compile
   time type checking while still resulting in very efficient code.  */
  typedef struct scm_unused_struct { char scm_unused_field; } *SCM;

The fault on hppa appears to be at strictness 1.

Regards,
Dave

-- 
John David Anglin  dave.anglin@bell.net






reply via email to

[Prev in Thread] Current Thread [Next in Thread]