Re: Compiling v1.8.5 on tru64 5.1b

Re: Compiling v1.8.5 on tru64 5.1b

[Neil Jerram]

[-- Attachment #1: Type: text/plain, Size: 3390 bytes --]

Didier Godefroy <ldg@ulysium.net> writes:

>>> cc: Error: eval.c, line 2363: In this statement, "*(SCM
>>> ...)0=(((SCM)((((0))<<8)+scm_tc8_isym)))" is not constant, but occurs in a
>>> context that requires a constant expression. (needconstexpr)
>>>     case (ISYMNUM (SCM_IM_AND)):
>> 
>> Are you using a somewhat dated compiler?  scm_tc8_isym is defined
>
> The compiler is the Tru64 v5.1b native:
>
> cc -V
> Compaq C V6.5-011 on Compaq Tru64 UNIX V5.1B (Rev. 2650)
> Compiler Driver V6.5-003 (sys) cc Driver

Circa 2003, as far as I make out from google.

> That's what we (tru64 users) always use for just about everything.
> Very few packages will force us to use gcc.

But is using GCC a major problem for you?  If it works, and the native
compiler doesn't, surely that's the easy solution?

(FWIW, Guile does build with a handful of modern compilers, e.g. the
Intel, Sun and IBM compilers, not just GCC.  So I really think that
this is more a problem of the Tru64 compiler being too old, rather
than of Guile being too GCC-dependent.)

> Ok, here is what it gives me now:
>
> cc -pthread -DHAVE_CONFIG_H -I.. -I.. -I.. -D_REENTRANT -O4 -g3
> -I/usr/local/gmp/include -I/usr/local/readline/include -c -MD error.c  -DPIC
> -o .libs/libguile_la-error.o
> cc: Warning: error.c, line 66: Non-void function "scm_error_scm" does not
> contain a return statement. (missingreturn)
> SCM_DEFINE (scm_error_scm, "scm-error", 5, 0, 0,
> ^

Problem here is the compiler not working out that the function will
never return.  Can fix this by adding "return SCM_UNSPECIFIED;" (which
will never actually be executed) at the end of scm_error_scm().

> cc: Error: eval.c, line 2363: In this statement, "*(SCM
> ...)0=(((SCM)((((0))<<8)+(4+0X0000000000000010))))" is not constant, but
> occurs in a context that requires a constant expression. (needconstexpr)
>     case (ISYMNUM (SCM_IM_AND)):
> ----------^

OK, please try building with -DSCM_DEBUG_TYPING_STRICTNESS=0.
(I think you can do this by running configure as:

 CFLAGS=-DSCM_DEBUG_TYPING_STRICTNESS=0 ./configure [your usual args]

It may also work to do 'make clean; make
CFLAGS=-DSCM_DEBUG_TYPING_STRICTNESS=0', but I'm not sure about that.)

Hopefully then the compiler will realize that the ISYMNUM(...)
expressions are constant!

>> problems?  Can you also tell us about your compiler, and if there is a
>> C preprocessor macro that can be used to detect it dynamically?
>
> I don't know much about c to handle this, maybe if you tell me what to look
> for, I can help. Maybe by looking at some other package to see how they
> handle it..

I guess we need to see first if it proves tractable to compile with
Tru64 (which is looking harder than I thought when I wrote the words
just above).  If it does, we can then look at how to formalize the
changes.

> And one more small detail, just in case you want to clean up some code,
> there are a bunch of info msgs from the compiler, just a bit before getting
> the errors:
>
> cc -pthread -DHAVE_CONFIG_H -I.. -I.. -I.. -D_REENTRANT -O4 -g3
> -I/usr/local/gmp/include -I/usr/local/readline/include -c -MD discouraged.c
> -DPIC -o .libs/libguile_la-discouraged.o
> cc: Info: discouraged.c, line 30: Extraneous semicolon. (extrasemi)
> DEFFROM (short, scm_short2num, scm_from_short);
> ----------------------------------------------^

Thanks, I've fixed those.  Patch attached.

    Neil


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Expand-DEFFROM-and-DEFTO-macros-in-discouraged.c.patch --]
[-- Type: text/x-diff, Size: 4737 bytes --]

From 0d185db93e484bda87c0d3c441db3b804148413f Mon Sep 17 00:00:00 2001
From: Neil Jerram <neil@ossau.uklinux.net>
Date: Tue, 13 May 2008 00:00:34 +0100
Subject: [PATCH] Expand DEFFROM and DEFTO macros in discouraged.c

* discouraged.c: Expand DEFFROM and DEFTO macros, to avoid
compiler warnings about excess semicolons.  (Reported by Didier
Godefroy.)
---
 THANKS                 |    1 +
 libguile/ChangeLog     |    6 ++
 libguile/discouraged.c |  145 +++++++++++++++++++++++++++++++++++++++--------
 3 files changed, 127 insertions(+), 25 deletions(-)

diff --git a/THANKS b/THANKS
index 3a9797f..e6128b5 100644
--- a/THANKS
+++ b/THANKS
@@ -37,6 +37,7 @@ For fixes or providing information which led to a fix:
         Charles Gagnon
           Peter Gavin
            Eric Gillespie, Jr
+         Didier Godefroy
            John Goerzen
            Mike Gran
          Szavai Gyula
diff --git a/libguile/ChangeLog b/libguile/ChangeLog
index dec6dcd..730a61b 100644
--- a/libguile/ChangeLog
+++ b/libguile/ChangeLog
@@ -1,3 +1,9 @@
+2008-05-12  Neil Jerram  <neil@ossau.uklinux.net>
+
+	* discouraged.c: Expand DEFFROM and DEFTO macros, to avoid
+	compiler warnings about excess semicolons.  (Reported by Didier
+	Godefroy.)
+
 2008-05-08  Neil Jerram  <neil@ossau.uklinux.net>
 
 	* throw.c (scm_ithrow): For IA64 add a return statement, to
diff --git a/libguile/discouraged.c b/libguile/discouraged.c
index 1b5794a..07663e0 100644
--- a/libguile/discouraged.c
+++ b/libguile/discouraged.c
@@ -23,33 +23,128 @@
 
 #if (SCM_ENABLE_DISCOURAGED == 1)
 
-#define DEFFROM(t,f1,f2) SCM f1(t x) { return f2 (x); }
-#define DEFTO(t,f1,f2)   t f1(SCM x, unsigned long pos, const char *s_caller) \
-                           { return f2 (x); }
-
-DEFFROM (short, scm_short2num, scm_from_short);
-DEFFROM (unsigned short, scm_ushort2num, scm_from_ushort);
-DEFFROM (int, scm_int2num, scm_from_int);
-DEFFROM (unsigned int, scm_uint2num, scm_from_uint);
-DEFFROM (long, scm_long2num, scm_from_long);
-DEFFROM (unsigned long, scm_ulong2num, scm_from_ulong);
-DEFFROM (size_t, scm_size2num, scm_from_size_t);
-DEFFROM (ptrdiff_t, scm_ptrdiff2num, scm_from_ssize_t);
-
-DEFTO (short, scm_num2short, scm_to_short);
-DEFTO (unsigned short, scm_num2ushort, scm_to_ushort);
-DEFTO (int, scm_num2int, scm_to_int);
-DEFTO (unsigned int, scm_num2uint, scm_to_uint);
-DEFTO (long, scm_num2long, scm_to_long);
-DEFTO (unsigned long, scm_num2ulong, scm_to_ulong);
-DEFTO (size_t, scm_num2size, scm_to_size_t);
-DEFTO (ptrdiff_t, scm_num2ptrdiff, scm_to_ssize_t);
+SCM
+scm_short2num (short x)
+{
+  return scm_from_short (x);
+}
+
+SCM
+scm_ushort2num (unsigned short x)
+{
+  return scm_from_ushort (x);
+}
+
+SCM
+scm_int2num (int x)
+{
+  return scm_from_int (x);
+}
+
+SCM
+scm_uint2num (unsigned int x)
+{
+  return scm_from_uint (x);
+}
+
+SCM
+scm_long2num (long x)
+{
+  return scm_from_long (x);
+}
+
+SCM
+scm_ulong2num (unsigned long x)
+{
+  return scm_from_ulong (x);
+}
+
+SCM
+scm_size2num (size_t x)
+{
+  return scm_from_size_t (x);
+}
+
+SCM
+scm_ptrdiff2num (ptrdiff_t x)
+{
+  return scm_from_ssize_t (x);
+}
+
+short
+scm_num2short (SCM x, unsigned long pos, const char *s_caller)
+{
+  return scm_to_short (x);
+}
+
+unsigned short
+scm_num2ushort (SCM x, unsigned long pos, const char *s_caller)
+{
+  return scm_to_ushort (x);
+}
+
+int
+scm_num2int (SCM x, unsigned long pos, const char *s_caller)
+{
+  return scm_to_int (x);
+}
+
+unsigned int
+scm_num2uint (SCM x, unsigned long pos, const char *s_caller)
+{
+  return scm_to_uint (x);
+}
+
+long
+scm_num2long (SCM x, unsigned long pos, const char *s_caller)
+{
+  return scm_to_long (x);
+}
+
+unsigned long
+scm_num2ulong (SCM x, unsigned long pos, const char *s_caller)
+{
+  return scm_to_ulong (x);
+}
+
+size_t
+scm_num2size (SCM x, unsigned long pos, const char *s_caller)
+{
+  return scm_to_size_t (x);
+}
+
+ptrdiff_t
+scm_num2ptrdiff (SCM x, unsigned long pos, const char *s_caller)
+{
+  return scm_to_ssize_t (x);
+}
 
 #if SCM_SIZEOF_LONG_LONG != 0
-DEFFROM (long long, scm_long_long2num, scm_from_long_long);
-DEFFROM (unsigned long long, scm_ulong_long2num, scm_from_ulong_long);
-DEFTO   (long long, scm_num2long_long, scm_to_long_long);
-DEFTO   (unsigned long long, scm_num2ulong_long, scm_to_ulong_long);
+
+SCM
+scm_long_long2num (long long x)
+{
+  return scm_from_long_long (x);
+}
+
+SCM
+scm_ulong_long2num (unsigned long long x)
+{
+  return scm_from_ulong_long (x);
+}
+
+long long
+scm_num2long_long (SCM x, unsigned long pos, const char *s_caller)
+{
+  return scm_to_long_long (x);
+}
+
+unsigned long long
+scm_num2ulong_long (SCM x, unsigned long pos, const char *s_caller)
+{
+  return scm_to_ulong_long (x);
+}
+
 #endif
 
 SCM
-- 
1.5.4.2

Re: Compiling v1.8.5 on tru64 5.1b

[Ludovic Courtès]

Hi,

Neil Jerram <neil@ossau.uklinux.net> writes:

> --- a/libguile/ChangeLog
> +++ b/libguile/ChangeLog
> @@ -1,3 +1,9 @@
> +2008-05-12  Neil Jerram  <neil@ossau.uklinux.net>
> +
> +	* discouraged.c: Expand DEFFROM and DEFTO macros, to avoid
> +	compiler warnings about excess semicolons.  (Reported by Didier
> +	Godefroy.)

Why didn't you just remove the trailing semicolons?  :-)

Thanks,
Ludovic.

Re: Compiling v1.8.5 on tru64 5.1b

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

> Hi,
>
> Neil Jerram <neil@ossau.uklinux.net> writes:
>
>> --- a/libguile/ChangeLog
>> +++ b/libguile/ChangeLog
>> @@ -1,3 +1,9 @@
>> +2008-05-12  Neil Jerram  <neil@ossau.uklinux.net>
>> +
>> +	* discouraged.c: Expand DEFFROM and DEFTO macros, to avoid
>> +	compiler warnings about excess semicolons.  (Reported by Didier
>> +	Godefroy.)
>
> Why didn't you just remove the trailing semicolons?  :-)

Because that messes up Emacs's C mode indentation.

I agree that that's an Emacs bug - as opposed to a bug with the code
as it was - but in the end I thought "hey, this is discouraged code,
so probably no one will ever touch it again, so does it really matter
whether we keep those DEFFROM and DEFTO macros or not?"

I spent a little time first, looking for a way of customizing
C mode to make it think that DEFFROM and DEFTO are always top-level;
but couldn't find one.

Regards,
     Neil

Re: Compiling v1.8.5 on tru64 5.1b

[Ludovic Courtès]

Hi,

Neil Jerram <neil@ossau.uklinux.net> writes:

> I agree that that's an Emacs bug - as opposed to a bug with the code
> as it was - but in the end I thought "hey, this is discouraged code,
> so probably no one will ever touch it again, so does it really matter
> whether we keep those DEFFROM and DEFTO macros or not?"

OK, that sounds reasonable.

Thanks,
Ludovic.