bug-guile
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: guile-1.8.5 test failures


From: Peter O'Gorman
Subject: Re: guile-1.8.5 test failures
Date: Sun, 8 Jun 2008 10:26:38 -0500
User-agent: Mutt/1.5.17 (2007-11-01)

On Wed, Jun 04, 2008 at 10:07:04PM -0500, Peter O'Gorman wrote:
> On Mon, Jun 02, 2008 at 09:50:27PM +0200, Ludovic Courtès wrote:
> > > 3. Fix build error on Tru64 Unix with the DEC compiler, which does not 
> > > like
> > >    the non-constant expression in case: statements, and on irix which does
> > >    not like the non-constant expression in the initializers in read.c and
> > >    print.c. (yes, I know - yuck).
> > 
> > But these are constants!
> 
> I'll look into this again.

Ok, turned out that the compiler was complaining about the 0?0=0:x
construct, it looked at the 0=0 and decided that it was not okay to have
that as an argument to the case statement. It was easy to figure that
out once I tried compiling preprocessed source, the caret pointed right
at the "0=" and said:

In this statement, "0=0" is not constant, but occurs in a context that requires 
a constant expression. (needconstexpr)

Attempting with -DSCM_DEBUG_TYPING_STRICTNESS=0 also failed, complaining
about int being the expected return type, but void* being passed.

Peter

Index: libguile/tags.h
===================================================================
--- libguile/tags.h.orig        2008-06-06 15:43:41.000000000 +0000
+++ libguile/tags.h     2008-06-06 16:18:14.000000000 +0000
@@ -114,7 +114,17 @@
   compiled, and does generate a warning when used with the wrong
   pointer type.
  */
+ /* The Tru64 Unix compiler and HP compiler have issues with case
+ * (0?0=0:x), the compilers see 0=0 and dislike the non-constant
+ * expression in a case statement, so for them no type-checking is
+ * performed. Note that the case to scm_t_bits is required, if we just
+ * define SCM_UNPACK(x) (x) we get errors about returning a pointer
+ * when an int was expected */
+#if defined __DECC || defined __HP_cc
+#   define SCM_UNPACK(x) (scm_t_bits)(x)
+#else
 #   define SCM_UNPACK(x) ((scm_t_bits) (0? (*(SCM*)0=(x)): x))
+#endif
 
 /*
   There is no typechecking on SCM_PACK, since all kinds of types




reply via email to

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