GNU Guile 2.1.5 released (beta)

GNU Guile 2.1.5 released (beta)

[Andy Wingo]

We are pleased to announce GNU Guile release 2.1.5.

Guile 2.1.5 is the fifth pre-release in what will eventually become the
2.2 release series.  We encourage you to test this release and provide
feedback to guile-devel@gnu.org.

This release improves Guile's parallelism and concurrency primitives,
with the goal of providing Guile users with the tools they need to build
custom concurrency and parallelism abstractions that suit their needs.
See the full NEWS below, for details.

The Guile web page is located at http://gnu.org/software/guile/, and
among other things, it contains a copy of the Guile manual and pointers
to more resources.

Guile is an implementation of the Scheme programming language, with
support for many SRFIs, packaged for use in a wide variety of
environments.  In addition to implementing the R5RS Scheme standard,
Guile includes a module system, full access to POSIX system calls,
networking support, multiple threads, dynamic linking, a foreign
function call interface, and powerful string processing.

Guile can run interactively, as a script interpreter, and as a Scheme
compiler to VM bytecode.  It is also packaged as a library so that
applications can easily incorporate a complete Scheme interpreter/VM.
An application can use Guile as an extension language, a clean and
powerful configuration language, or as multi-purpose "glue" to connect
primitives provided by the application.  It is easy to call Scheme code
From C code and vice versa.  Applications can add new functions, data
types, control structures, and even syntax to Guile, to create a
domain-specific language tailored to the task at hand.

Guile 2.1.5 can be installed in parallel with Guile 2.0.x; see
http://www.gnu.org/software/guile/manual/html_node/Parallel-Installations.html.

A more detailed NEWS summary follows these details on how to get the
Guile sources.

Here are the compressed sources:
  http://alpha.gnu.org/gnu/guile/guile-2.1.5.tar.gz   (17MB)
  http://alpha.gnu.org/gnu/guile/guile-2.1.5.tar.xz   (10MB)

Here are the GPG detached signatures[*]:
  http://alpha.gnu.org/gnu/guile/guile-2.1.5.tar.gz.sig
  http://alpha.gnu.org/gnu/guile/guile-2.1.5.tar.xz.sig

Use a mirror for higher download bandwidth:
  http://www.gnu.org/order/ftp.html

Here are the SHA256 checksums:

  53994fbb7d92be9b1abfd93526fd9b41aeafcbeb724bddd829f5408c6cc31534  guile-2.1.5.tar.gz
  f1194b61aaaabe158aa8ae59cc0f50e20e2796634c7f3223549db61338243e65  guile-2.1.5.tar.xz

[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify guile-2.1.5.tar.gz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

  gpg --keyserver keys.gnupg.net --recv-keys FF478FB264DE32EC296725A3DDC0F5358812F8F2

and rerun the 'gpg --verify' command.

This release was bootstrapped with the following tools:
  Autoconf 2.69
  Automake 1.15
  Libtool 2.4.6
  Gnulib v0.1-800-g68b6ade
  Makeinfo 6.1


Changes in 2.1.5 (changes since the 2.1.4 alpha release):

* Notable changes
** Lightweight pre-emptive threading primitives

The compiler now inserts special "handle-interrupts" opcodes before each
call, return, and loop back-edge.  This allows the user to interrupt any
computation and to accurately profile code using interrupts.  It used to
be that interrupts were run by calling a C function from the VM; now
interrupt thunks are run directly from the VM.  This allows interrupts
to save a delimited continuation and, if the continuation was
established from the same VM invocation (the usual restriction), that
continuation can then be resumed.  In this way users can implement
lightweight pre-emptive threading facilities.

** with-dynamic-state in VM

Similarly, `with-dynamic-state' no longer recurses out of the VM,
allowing captured delimited continuations that include a
`with-dynamic-state' invocation to be resumed.  This is a precondition
to allow lightweight threading libraries to establish a dynamic state
per thread.

* Performance improvements
** Mutexes are now faster under contention

Guile implements its own mutexes, so that threads that are trying to
acquire a mutex can be interrupted.  These mutexes used to be quite
inefficient when many threads were trying to acquire them, causing many
spurious wakeups and contention.  This has been fixed.

* Incompatible changes
** Threading facilities moved to (ice-9 threads)

It used to be that call-with-new-thread and other threading primitives
were available in the default environment.  This is no longer the case;
they have been moved to (ice-9 threads) instead.  Existing code will not
break, however; we used the deprecation facility to signal a warning
message while also providing these bindings in the root environment for
the duration of the 2.2 series.

** SRFI-18 threads, mutexes, cond vars disjoint from Guile

When we added support for the SRFI-18 threading library in Guile 2.0, we
did so in a way that made SRFI-18 mutexes the same as Guile mutexes.
This was a mistake.  In Guile our goal is to provide basic,
well-thought-out, well-implemented, minimal primitives, on top of which
we can build a variety of opinionated frameworks.  Incorporating SRFI-18
functionality into core Guile caused us to bloat and slow down our core
threading primitives.  Worse, they became very hard to describe; they
did many things, did them poorly, and all that they did was never
adequately specified.

For all of these reasons we have returned to a situation where SRFI-18
concepts are implemented only in the `(srfi srfi-18)' module.  This
means that SRFI-18 threads are built on Guile threads, but aren't the
same as Guile threads; calling Guile `thread?' on a thread no longer
returns true.

We realize this causes inconvenience to users who use both Guile
threading interfaces and SRFI-18 interfaces, and we lament the change --
but we are better off now.  We hope the newly revised "Scheduling"
section in the manual compensates for the headache.

** Remove `lock-mutex' "owner" argument

Mutex owners are a SRFI-18 concept; use SRFI-18 mutexes instead.
Relatedly, `scm_lock_mutex_timed' taking the owner argument is now
deprecated; use `scm_timed_lock_mutex' instead.

** Remove `unlock-mutex' cond var and timeout arguments

It used to be that `unlock-mutex' included `wait-condition-variable'
functionality.  This has been deprecated; use SRFI-18 if you want this
behavior from `mutex-unlock!'.  Relatedly, `scm_unlock_mutex_timed' is
deprecated; use `scm_unlock_mutex' instead.

** Removed `unchecked-unlock' mutex flag

This flag was introduced for internal use by SRFI-18; use SRFI-18
mutexes if you need this behaviour.

** SRFI-18 mutexes no longer recursive

Contrary to specification, SRFI-18 mutexes in Guile were recursive.
This is no longer the case.

** Thread cleanup handlers removed

The `set-thread-cleanup!' and `thread-cleanup' functions that were added
in Guile 2.0 to support cleanup after thread cancellation are no longer
needed, since threads can declare cleanup handlers via `dynamic-wind'.

** Only threads created by Guile are joinable

`join-thread' used to work on "foreign" threads that were not created by
Guile itself, though their join value was always `#f'.  This is no
longer the case; attempting to join a foreign thread will throw an
error.

** Dynamic states capture values, not locations

Dynamic states used to capture the locations of fluid-value
associations.  Capturing the current dynamic state then setting a fluid
would result in a mutation of that captured state.  Now capturing a
dynamic state simply captures the current values, and calling
`with-dynamic-state' copies those values into the Guile virtual machine
instead of aliasing them in a way that could allow them to be mutated in
place.  This change allows Guile's fluid variables to be thread-safe.
To capture the locations of a dynamic state, capture a
`with-dynamic-state' invocation using partial continuations instead.

* New deprecations
** Arbiters deprecated

Arbiters were an experimental mutual exclusion facility from 20 years
ago that didn't survive the test of time.  Use mutexes or atomic boxes
instead.

** User asyncs deprecated

Guile had (and still has) "system asyncs", which are asynchronous
interrupts, and also had this thing called "user asyncs", which was a
trivial unused data structure.  Now that we have deprecated the old
`async', `async-mark', and `run-asyncs' procedures that comprised the
"user async" facility, we have been able to clarify our documentation to
only refer to "asyncs".

** Critical sections deprecated

Critical sections have long been just a fancy way to lock a mutex and
defer asynchronous interrupts.  Instead of SCM_CRITICAL_SECTION_START,
make sure you're in a "scm_dynwind_begin (0)" and use
scm_dynwind_pthread_mutex_lock instead, possibly also with
scm_dynwind_block_asyncs.

** `scm_make_mutex_with_flags' deprecated

Use `scm_make_mutex_with_kind' instead.  See "Mutexes and Condition
Variables" in the manual, for more.

** Dynamic roots deprecated

This was a facility that predated threads, was unused as far as we can
tell, and was never documented.  Still, a grep of your code for
dynamic-root or dynamic_root would not be amiss.

** `make-dynamic-state' deprecated

Use `current-dynamic-state' to get an immutable copy of the current
fluid-value associations.

* Bug fixes
** cancel-thread uses asynchronous interrupts, not pthread_cancel

See "Asyncs" in the manual, for more on asynchronous interrupts.

Re: GNU Guile 2.1.5 released (beta)

[Matt Wette]

> On Dec 7, 2016, at 11:55 AM, Andy Wingo <wingo@pobox.com> wrote:
> 
> We are pleased to announce GNU Guile release 2.1.5.
> 
> Guile 2.1.5 is the fifth pre-release in what will eventually become the
> 2.2 release series.  We encourage you to test this release and provide
> feedback to guile-devel@gnu.org.

I am building on my Mac running macOS 10.12.1, aka Sierra.  I will post my patches when I get through “make check”.  

As a heads-up:
1) macOS does not have clock_getcpuclockid(), stime.c line 833, so patch skips that check.
2) macOS mkostemp() (filesys.c line 1496) will fail if any non-supported bits are passed in open_flags, so patch masks out unsupported bits.

Make check is failing on test-language, so I will be chasing that down.

Matt

Re: GNU Guile 2.1.5 released (beta)

[Christopher Allan Webber]

Matt Wette writes:

>> On Dec 7, 2016, at 11:55 AM, Andy Wingo <wingo@pobox.com> wrote:
>> 
>> We are pleased to announce GNU Guile release 2.1.5.
>> 
>> Guile 2.1.5 is the fifth pre-release in what will eventually become the
>> 2.2 release series.  We encourage you to test this release and provide
>> feedback to guile-devel@gnu.org.
>
> I am building on my Mac running macOS 10.12.1, aka Sierra.  I will post my patches when I get through “make check”.  
>
> As a heads-up:
> 1) macOS does not have clock_getcpuclockid(), stime.c line 833, so patch skips that check.
> 2) macOS mkostemp() (filesys.c line 1496) will fail if any non-supported bits are passed in open_flags, so patch masks out unsupported bits.
>
> Make check is failing on test-language, so I will be chasing that down.
>
> Matt

Thanks for working on Guile portability!

Re: GNU Guile 2.1.5 released (beta)

[Matt Wette]

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


> On Dec 9, 2016, at 7:28 AM, Matt Wette <matt.wette@gmail.com> wrote:
> 
> 
>> On Dec 7, 2016, at 11:55 AM, Andy Wingo <wingo@pobox.com> wrote:
>> 
>> We are pleased to announce GNU Guile release 2.1.5.
>> 
>> Guile 2.1.5 is the fifth pre-release in what will eventually become the
>> 2.2 release series.  We encourage you to test this release and provide
>> feedback to guile-devel@gnu.org.
> 
> I am building on my Mac running macOS 10.12.1, aka Sierra.  I will post my patches when I get through “make check”.  
> 
> As a heads-up:
> 1) macOS does not have clock_getcpuclockid(), stime.c line 833, so patch skips that check.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23870 <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23870>

> 2) macOS mkostemp() (filesys.c line 1496) will fail if any non-supported bits are passed in open_flags, so patch masks out unsupported bits.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24862 <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24862>

> Make check is failing on test-language, so I will be chasing that down.


Progress so far: At the end of test-suite/standalone/test-language is

guile --no-auto-compile				\
      -l "$top_srcdir/module/ice-9/q.scm"	\
      --language=elisp				\
      -l "$srcdir/test-language.el"		\
      --language=ecmascript			\
      -l "$srcdir/test-language.js"		\
      --language=scheme				\
      -c 1

mwette$ guile --no-auto-compile --language=ecmascript -l $srcdir/test-language.js -c 1
(lldb) target create "/Users/mwette/proj/scheme/guile/guile-2.1.5/libguile/guile"
Current executable set to '/Users/mwette/proj/scheme/guile/guile-2.1.5/libguile/guile' (x86_64).
(lldb) settings set -- target.run-args  "--no-auto-compile" "--language=ecmascript" "-l" "/Users/mwette/proj/scheme/guile/guile-2.1.5/test-suite/standalone/test-language.js" "-c" "1"
(lldb) run
Process 92234 launched: '/Users/mwette/proj/scheme/guile/guile-2.1.5/libguile/guile' (x86_64)
Process 92234 stopped
* thread #1: tid = 0x132974, 0x00007fffad952f9c libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 252, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x2001000)
    frame #0: 0x00007fffad952f9c libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 252
libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell:
->  0x7fffad952f9c <+252>: vmovups %ymm0, (%rax)
    0x7fffad952fa0 <+256>: vmovups 0x20(%rsi), %ymm2
    0x7fffad952fa5 <+261>: addq   $0x40, %rsi
    0x7fffad952fa9 <+265>: subq   $0x80, %rdx
(lldb) up
frame #1: 0x00007fffad7fd42e libsystem_c.dylib`__memcpy_chk + 22
libsystem_c.dylib`__memcpy_chk:
    0x7fffad7fd42e <+22>: movq   %rbx, %rax
    0x7fffad7fd431 <+25>: addq   $0x8, %rsp
    0x7fffad7fd435 <+29>: popq   %rbx
    0x7fffad7fd436 <+30>: popq   %rbp(lldb) up
frame #2: 0x00000001000425eb guile`copy_and_align_elf_data(data="\x7fELF\x02\x01\x01?, len=6837) + 90 at loader.c:225
   222 	
   223 	  alignment = elf_alignment (data, len);
   224 	  copy = alloc_aligned (len, alignment);
-> 225 	  memcpy(copy, data, len);
   226 	
   227 	  return copy;
   228 	}
(lldb) 

Note: supplied lldb is only debugger that can be used on Sierra (unless security is disabled), it seems.

[-- Attachment #2: Type: text/html, Size: 14433 bytes --]

Re: GNU Guile 2.1.5 released (beta)

[Daniel Llorens]

On 10 Dec 2016, at 18:00, guile-devel-request@gnu.org wrote:

> Date: Sat, 10 Dec 2016 05:16:08 -0800
> From: Matt Wette <matt.wette@gmail.com>
> To: guile-devel@gnu.org
> Cc: Andy Wingo <wingo@pobox.com>
> Subject: Re: GNU Guile 2.1.5 released (beta)
> Message-ID: <3851AC25-3D0A-4F0E-8FD5-8606656C3A43@gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> 
>> On Dec 9, 2016, at 7:28 AM, Matt Wette <matt.wette@gmail.com> wrote:

...

>> Make check is failing on test-language, so I will be chasing that down.


FWIW this is the only test that fails on 10.9.5 and the backtrace looks identical too.

Re: GNU Guile 2.1.5 released (beta)

[Matt Wette]

On Dec 10, 2016, at 9:11 AM, Daniel Llorens <daniel.llorens@bluewin.ch> wrote:
> 
> 
>>> Make check is failing on test-language, so I will be chasing that down.
> 
> 
> FWIW this is the only test that fails on 10.9.5 and the backtrace looks identical too.

The problem appears in libguile/loader.c, alloc_aligned().  Check the value of “ret” I get after malloc and after the alignment.   I started looking at type size for uintptr_t vs char* but then got confused why guile is being compiled as x86_64, but my test programs are always x86

alignment=4096

/* This function leaks the memory that it allocates.  */
static char*
alloc_aligned (size_t len, unsigned alignment)
{
  char *ret;

  if (alignment == 8)
    {
      /* FIXME: Assert that we actually have an 8-byte-aligned malloc.  */
      ret = malloc (len);
    }
#if defined(HAVE_SYS_MMAN_H) && defined(MMAP_ANONYMOUS)
  else if (alignment == SCM_PAGE_SIZE)
    {
      ret = mmap (NULL, len, PROT_READ | PROT_WRITE, -1, 0);
      if (ret == MAP_FAILED)
        SCM_SYSERROR;
    }
#endif
  else
    {
      if (len + alignment < len)
        abort ();

      ret = malloc (len + alignment - 1);
ret=0x0000000104000000
      if (!ret)
        abort ();
      ret = (char *) ALIGN ((scm_t_uintptr) ret, alignment);
ret=0x0000000004000000
    }

  return ret;
}

Re: GNU Guile 2.1.5 released (beta)

[Matt Wette]

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


> On Dec 10, 2016, at 5:16 AM, Matt Wette <matt.wette@gmail.com> wrote:
> 
> 
>> On Dec 9, 2016, at 7:28 AM, Matt Wette <matt.wette@gmail.com <mailto:matt.wette@gmail.com>> wrote:
>> 
>> 
>>> On Dec 7, 2016, at 11:55 AM, Andy Wingo <wingo@pobox.com <mailto:wingo@pobox.com>> wrote:
>>> 
>>> We are pleased to announce GNU Guile release 2.1.5.
>>> 
>>> Guile 2.1.5 is the fifth pre-release in what will eventually become the
>>> 2.2 release series.  We encourage you to test this release and provide
>>> feedback to guile-devel@gnu.org <mailto:guile-devel@gnu.org>.
>> 
>> I am building on my Mac running macOS 10.12.1, aka Sierra.  I will post my patches when I get through “make check”.  

I believe the following, at line 195, in linguine/loader.c is a bug:

	#if defined(HAVE_SYS_MMAN_H) && defined(MMAP_ANONYMOUS)

Shouldn’t MMAP_ANONYMOUS actually be HAVE_MAP_ANONYMOUS?  I think this expression is otherwise never satisfied.

Matt


[-- Attachment #2: Type: text/html, Size: 2676 bytes --]

Re: GNU Guile 2.1.5 released (beta)

[Matt Wette]

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


> On Dec 9, 2016, at 7:28 AM, Matt Wette <matt.wette@gmail.com> wrote:
> 
> 
>> On Dec 7, 2016, at 11:55 AM, Andy Wingo <wingo@pobox.com> wrote:
>> 
>> We are pleased to announce GNU Guile release 2.1.5.
>> 
>> Guile 2.1.5 is the fifth pre-release in what will eventually become the
>> 2.2 release series.  We encourage you to test this release and provide
>> feedback to guile-devel@gnu.org.
> 
> I am building on my Mac running macOS 10.12.1, aka Sierra.  I will post my patches when I get through “make check”.  

Now getting through make check, but this, from threads.test, fails:

FAIL: threads.test: mutex-ownership: mutex with owner not retained (bug #27450)

        (pass-if "mutex with owner not retained (bug #27450)"
          (let ((g (make-guardian)))
            (g (let ((m (make-mutex))) (lock-mutex m) m))

            ;; Avoid false references to M on the stack.
            (clear-stale-stack-references)

            (gc) (gc)
            (let ((m (g)))
              (and (mutex? m)
                   (eq? (mutex-owner m) (current-thread)))))))

debbugs.gnu.org says 27450 does not exist.  My guess is the mutex m should be preserved by clear-stale-stack-references + gc but it is not.

Matt


[-- Attachment #2: Type: text/html, Size: 5841 bytes --]

Re: GNU Guile 2.1.5 released (beta)

[Matt Wette]

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


> On Dec 10, 2016, at 5:16 AM, Matt Wette <matt.wette@gmail.com> wrote:
> 
>> 
>> On Dec 9, 2016, at 7:28 AM, Matt Wette <matt.wette@gmail.com <mailto:matt.wette@gmail.com>> wrote:
>> 
>> 
>>> On Dec 7, 2016, at 11:55 AM, Andy Wingo <wingo@pobox.com <mailto:wingo@pobox.com>> wrote:
>>> 
>>> We are pleased to announce GNU Guile release 2.1.5.
>>> 
>>> Guile 2.1.5 is the fifth pre-release in what will eventually become the
>>> 2.2 release series.  We encourage you to test this release and provide
>>> feedback to guile-devel@gnu.org <mailto:guile-devel@gnu.org>.
>> 
>> I am building on my Mac running macOS 10.12.1, aka Sierra.  I will post my patches when I get through “make check”.  
>> 

Patches to date attached.  These address 
1) #23870 no clock_getcpuclockid
2) #24682 mkostemp
3) use of ALIGN needs cast in libguile/loader.c

Matt



[-- Attachment #2.1: Type: text/html, Size: 2140 bytes --]

[-- Attachment #2.2: patch-2.1.5-mwette161210a --]
[-- Type: application/octet-stream, Size: 1478 bytes --]

--- libguile/filesys.c-orig	2016-12-08 05:55:48.000000000 -0800
+++ libguile/filesys.c	2016-12-08 16:28:41.000000000 -0800
@@ -1492,6 +1492,10 @@
       mode_bits = scm_i_mode_bits (mode);
     }
 
+#ifdef __APPLE__
+  /* mkostemp() will fail on Mac OS 10.12 if any besides this used: */
+  open_flags &= (O_APPEND | O_SHLOCK | O_EXLOCK | O_CLOEXEC);
+#endif
   SCM_SYSCALL (rv = mkostemp (c_tmpl, open_flags));
   if (rv == -1)
     SCM_SYSERROR;
--- libguile/loader.c-orig	2016-12-10 18:19:34.000000000 -0800
+++ libguile/loader.c	2016-12-10 18:19:58.000000000 -0800
@@ -208,7 +208,7 @@
       ret = malloc (len + alignment - 1);
       if (!ret)
         abort ();
-      ret = (char *) ALIGN ((scm_t_uintptr) ret, alignment);
+      ret = (char *) ALIGN ((scm_t_uintptr) ret, (scm_t_uintptr) alignment);
     }
 
   return ret;
--- libguile/stime.c-orig	2016-12-08 05:48:31.000000000 -0800
+++ libguile/stime.c	2016-12-08 16:27:46.000000000 -0800
@@ -830,6 +830,11 @@
     get_internal_real_time = get_internal_real_time_posix_timer;
 
 #ifdef HAVE_POSIX_CPUTIME
+#ifdef __APPLE__
+  /* Darwin does not have clock_getcpuclockid(). Just do it anyway. */
+  if (clock_gettime (CLOCK_PROCESS_CPUTIME_ID, &posix_run_time_base) == 0)
+    get_internal_run_time = get_internal_run_time_posix_timer;
+#else
   {
     clockid_t dummy;
     
@@ -841,6 +846,7 @@
     else
       errno = 0;
   }
+#endif /* __APPLE__ */
 #endif /* HAVE_POSIX_CPUTIME */
 #endif /* HAVE_CLOCKTIME */
 

[-- Attachment #2.3: Type: text/html, Size: 257 bytes --]

Re: GNU Guile 2.1.5 released (beta)

[Matt Wette]

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

With patches I can compile and run “make check”.  But now I have one failure:t tests/numbers.test line 1663: (“#i1@-0” 1.0 -0.0).  

This wants the following to produce #t, but it does not:

scheme@(guile-user)> (define z (string->number "#i1@-0"))
scheme@(guile-user)> (eqv? (imag-part z) -0.0)
$7 = #f




[-- Attachment #2: Type: text/html, Size: 1578 bytes --]

Re: GNU Guile 2.1.5 released (beta)

[Matt Wette]

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


> On Dec 11, 2016, at 12:35 PM, Matt Wette <matt.wette@gmail.com> wrote:
> 
> With patches I can compile and run “make check”.  But now I have one failure:t tests/numbers.test line 1663: (“#i1@-0” 1.0 -0.0).  
> 
> This wants the following to produce #t, but it does not:
> 
> scheme@(guile-user)> (define z (string->number "#i1@-0"))
> scheme@(guile-user)> (eqv? (imag-part z) -0.0)
> $7 = #f
> 

Sorry to keep posting on this.  I will stop soon.  I seem to get different problems every time I build 2.1.5 on my Mac.  I am using some different config options (e.g., with and without —disable-shared) and different compilers.  The above issue does not show up with the current build.   Note the following separate builds that give different values for the above:

mwette$ pwd
/Users/mwette/proj/scheme/guile/guile-2.1.5
mwette$ meta/guile -c '(display (eqv? (imag-part (string->number "#i1@-0")) -0.0))'
#f

mwette$ pwd
/Users/mwette/proj/scheme/guile/guile-2.1.5-2
mwette$ meta/guile -c '(display (eqv? (imag-part (string->number "#i1@-0")) -0.0))'
#t





[-- Attachment #2: Type: text/html, Size: 5188 bytes --]

Re: GNU Guile 2.1.5 released (beta)

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Dec 11, 2016 at 05:25:19PM -0800, Matt Wette wrote:

[...]

> Sorry to keep posting on this.  I will stop soon.

[this from the peanut gallery: feel free to ignore]

Please don't! Even if I don't own a Mac, and even if I'll try to avoid
that in the future if I can: I do follow your postings with great
interest. Valuable lessons in portability. So thanks for them :-)

regards
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlhOhqIACgkQBcgs9XrR2kYktACfdqa2Y2+oLsdhRP2zoXMhW31z
mzIAn15XEhJ/r3cBO2bo8KPKXh8XwVKR
=0PTT
-----END PGP SIGNATURE-----

Re: GNU Guile 2.1.5 released (beta)

[Matt Wette]

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


> On Dec 11, 2016, at 7:17 AM, Matt Wette <matt.wette@gmail.com> wrote:
> 
> 
>> On Dec 9, 2016, at 7:28 AM, Matt Wette <matt.wette@gmail.com <mailto:matt.wette@gmail.com>> wrote:
>> 
>> 
>>> On Dec 7, 2016, at 11:55 AM, Andy Wingo <wingo@pobox.com <mailto:wingo@pobox.com>> wrote:
>>> 
>>> We are pleased to announce GNU Guile release 2.1.5.
>>> 
>>> Guile 2.1.5 is the fifth pre-release in what will eventually become the
>>> 2.2 release series.  We encourage you to test this release and provide
>>> feedback to guile-devel@gnu.org <mailto:guile-devel@gnu.org>.
>> 
>> I am building on my Mac running macOS 10.12.1, aka Sierra.  I will post my patches when I get through “make check”.  
> 
> Now getting through make check, but this, from threads.test, fails:
> 
> FAIL: threads.test: mutex-ownership: mutex with owner not retained (bug #27450)
> 
>         (pass-if "mutex with owner not retained (bug #27450)"
>           (let ((g (make-guardian)))
>             (g (let ((m (make-mutex))) (lock-mutex m) m))
> 
>             ;; Avoid false references to M on the stack.
>             (clear-stale-stack-references)
> 
>             (gc) (gc)
>             (let ((m (g)))
>               (and (mutex? m)
>                    (eq? (mutex-owner m) (current-thread)))))))
> 
> debbugs.gnu.org <http://debbugs.gnu.org/> says 27450 does not exist.  My guess is the mutex m should be preserved by clear-stale-stack-references + gc but it is not.
> 
> Matt
> 

Can someone confirm that this gets a PASS on other platforms, please?

FAIL: threads.test: mutex-ownership: mutex with owner not retained (bug #27450)



[-- Attachment #2: Type: text/html, Size: 6975 bytes --]

Re: GNU Guile 2.1.5 released (beta)

[Matt Wette]

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


> On Dec 12, 2016, at 5:45 AM, Matt Wette <matt.wette@gmail.com> wrote:
> 
> 
>> On Dec 11, 2016, at 7:17 AM, Matt Wette <matt.wette@gmail.com <mailto:matt.wette@gmail.com>> wrote:
>> 
>> 
>>> On Dec 9, 2016, at 7:28 AM, Matt Wette <matt.wette@gmail.com <mailto:matt.wette@gmail.com>> wrote:
>>> 
>>> 
>>>> On Dec 7, 2016, at 11:55 AM, Andy Wingo <wingo@pobox.com <mailto:wingo@pobox.com>> wrote:
>>>> 
>>>> We are pleased to announce GNU Guile release 2.1.5.
>>>> 
>>>> Guile 2.1.5 is the fifth pre-release in what will eventually become the
>>>> 2.2 release series.  We encourage you to test this release and provide
>>>> feedback to guile-devel@gnu.org <mailto:guile-devel@gnu.org>.
>>> 
>>> I am building on my Mac running macOS 10.12.1, aka Sierra.  I will post my patches when I get through “make check”.  
>> 
>> Now getting through make check, but this, from threads.test, fails:
>> 
>> FAIL: threads.test: mutex-ownership: mutex with owner not retained (bug #27450)
>> 
>>         (pass-if "mutex with owner not retained (bug #27450)"
>>           (let ((g (make-guardian)))
>>             (g (let ((m (make-mutex))) (lock-mutex m) m))
>> 
>>             ;; Avoid false references to M on the stack.
>>             (clear-stale-stack-references)
>> 
>>             (gc) (gc)
>>             (let ((m (g)))
>>               (and (mutex? m)
>>                    (eq? (mutex-owner m) (current-thread)))))))
>> 
>> debbugs.gnu.org <http://debbugs.gnu.org/> says 27450 does not exist.  My guess is the mutex m should be preserved by clear-stale-stack-references + gc but it is not.
>> 
>> Matt
>> 
> 
> Can someone confirm that this gets a PASS on other platforms, please?
> 
> FAIL: threads.test: mutex-ownership: mutex with owner not retained (bug #27450)
> 

I have conformed guile-2.1.5 gets through “make check” w/o any FAILs, including threads.test, on CentOS 7.3.1611, x86_64.




[-- Attachment #2: Type: text/html, Size: 7565 bytes --]

Re: GNU Guile 2.1.5 released (beta)

[dsmich]

---- Matt Wette <matt.wette@gmail.com> wrote: 
> 
> > On Dec 12, 2016, at 5:45 AM, Matt Wette <matt.wette@gmail.com> wrote:
> > 
> > 
> >> On Dec 11, 2016, at 7:17 AM, Matt Wette <matt.wette@gmail.com <mailto:matt.wette@gmail.com>> wrote:
> >> 
> >> 
> >>> On Dec 9, 2016, at 7:28 AM, Matt Wette <matt.wette@gmail.com <mailto:matt.wette@gmail.com>> wrote:
> >>> 
> >>> 
> >>>> On Dec 7, 2016, at 11:55 AM, Andy Wingo <wingo@pobox.com <mailto:wingo@pobox.com>> wrote:
> >>>> 
> >>>> We are pleased to announce GNU Guile release 2.1.5.
> >>>> 
> >>>> Guile 2.1.5 is the fifth pre-release in what will eventually become the
> >>>> 2.2 release series.  We encourage you to test this release and provide
> >>>> feedback to guile-devel@gnu.org <mailto:guile-devel@gnu.org>.
> >>> 
> >>> I am building on my Mac running macOS 10.12.1, aka Sierra.  I will post my patches when I get through “make check”.  
> >> 
> >> Now getting through make check, but this, from threads.test, fails:
> >> 
> >> FAIL: threads.test: mutex-ownership: mutex with owner not retained (bug #27450)
> >> 
> >>         (pass-if "mutex with owner not retained (bug #27450)"
> >>           (let ((g (make-guardian)))
> >>             (g (let ((m (make-mutex))) (lock-mutex m) m))
> >> 
> >>             ;; Avoid false references to M on the stack.
> >>             (clear-stale-stack-references)
> >> 
> >>             (gc) (gc)
> >>             (let ((m (g)))
> >>               (and (mutex? m)
> >>                    (eq? (mutex-owner m) (current-thread)))))))
> >> 
> >> debbugs.gnu.org <http://debbugs.gnu.org/> says 27450 does not exist.  My guess is the mutex m should be preserved by clear-stale-stack-references + gc but it is not.
> >> 
> >> Matt
> >> 
> > 
> > Can someone confirm that this gets a PASS on other platforms, please?
> > 
> > FAIL: threads.test: mutex-ownership: mutex with owner not retained (bug #27450)
> > 
> 
> I have conformed guile-2.1.5 gets through “make check” w/o any FAILs, including threads.test, on CentOS 7.3.1611, x86_64.


Also make check passes all tests on a Debian Jessie system.  x86_64

-Dale

Re: GNU Guile 2.1.5 released (beta)

[Freja Nordsiek]

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

Make check passes all tests on x86-64 Fedora 24.


Freja Nordsiek

On Dec 13, 2016 2:25 AM, <dsmich@roadrunner.com> wrote:

>
> ---- Matt Wette <matt.wette@gmail.com> wrote:
> >
> > > On Dec 12, 2016, at 5:45 AM, Matt Wette <matt.wette@gmail.com> wrote:
> > >
> > >
> > >> On Dec 11, 2016, at 7:17 AM, Matt Wette <matt.wette@gmail.com
> <mailto:matt.wette@gmail.com>> wrote:
> > >>
> > >>
> > >>> On Dec 9, 2016, at 7:28 AM, Matt Wette <matt.wette@gmail.com
> <mailto:matt.wette@gmail.com>> wrote:
> > >>>
> > >>>
> > >>>> On Dec 7, 2016, at 11:55 AM, Andy Wingo <wingo@pobox.com <mailto:
> wingo@pobox.com>> wrote:
> > >>>>
> > >>>> We are pleased to announce GNU Guile release 2.1.5.
> > >>>>
> > >>>> Guile 2.1.5 is the fifth pre-release in what will eventually become
> the
> > >>>> 2.2 release series.  We encourage you to test this release and
> provide
> > >>>> feedback to guile-devel@gnu.org <mailto:guile-devel@gnu.org>.
> > >>>
> > >>> I am building on my Mac running macOS 10.12.1, aka Sierra.  I will
> post my patches when I get through “make check”.
> > >>
> > >> Now getting through make check, but this, from threads.test, fails:
> > >>
> > >> FAIL: threads.test: mutex-ownership: mutex with owner not retained
> (bug #27450)
> > >>
> > >>         (pass-if "mutex with owner not retained (bug #27450)"
> > >>           (let ((g (make-guardian)))
> > >>             (g (let ((m (make-mutex))) (lock-mutex m) m))
> > >>
> > >>             ;; Avoid false references to M on the stack.
> > >>             (clear-stale-stack-references)
> > >>
> > >>             (gc) (gc)
> > >>             (let ((m (g)))
> > >>               (and (mutex? m)
> > >>                    (eq? (mutex-owner m) (current-thread)))))))
> > >>
> > >> debbugs.gnu.org <http://debbugs.gnu.org/> says 27450 does not
> exist.  My guess is the mutex m should be preserved by
> clear-stale-stack-references + gc but it is not.
> > >>
> > >> Matt
> > >>
> > >
> > > Can someone confirm that this gets a PASS on other platforms, please?
> > >
> > > FAIL: threads.test: mutex-ownership: mutex with owner not retained
> (bug #27450)
> > >
> >
> > I have conformed guile-2.1.5 gets through “make check” w/o any FAILs,
> including threads.test, on CentOS 7.3.1611, x86_64.
>
>
> Also make check passes all tests on a Debian Jessie system.  x86_64
>
> -Dale
>
>
>

[-- Attachment #2: Type: text/html, Size: 3967 bytes --]

Re: GNU Guile 2.1.5 released (beta)

[Matt Wette]

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

OK.  This is gonna be hard to trace down.

I am on a Mac running Sierra, 10.12.2.  At work I am running 10.9 I believe, and I see the same behavior.


If I compile with gcc 6.2 or gcc4.9, but no extra flags besides —prefix, I get the following failure:

FAIL: numbers.test: string->number: valid complex number strings

and trace this down to 

meta/guile -c '(display (eqv? (imag-part (string->number "#i1@-0")) -0.0))' => #f


If I add “-g” to CFLAGS & LDFLAGS, or just compile with CFLAGS=-O0 I get

FAIL: mutex-ownership: mutex with owner not retained (bug #27450)

Note the following modification from the above guardian test:

(define gg #f)

(let ((g (make-guardian)))
  (g (let ((m (make-mutex)))
       (lock-mutex m)
       (if (mutex? m) #t (display "0: not mutex\n"))
       m))
  
  (set! gg g)
  (simple-format #t "1: g=~S\n" g)
  
  ;; Avoid false references to M on the stack.
  (clear-stale-stack-references)
  
  (gc) (gc)
  (simple-format #t "2: g=~S\n" g)
  (let ((m (g)))
    (simple-format #t "3: g=~S\n" g)
    (and (mutex? m)
	 (eq? (mutex-owner m) (current-thread)))))

(gc)(gc)
(simple-format #t "9:gg=~S\n" gg)


The above generates
1: g=#<guardian 10228dba0 (reachable: 1 unreachable: 0)>
2: g=#<guardian 10228dba0 (reachable: 1 unreachable: 0)>
3: g=#<guardian 10228dba0 (reachable: 1 unreachable: 0)>
9:gg=#<guardian 10228dba0 (reachable: 0 unreachable: 1)>

I believe both 2 and 3 would ordinarily indicate the mutex unreachable.

Any ideas on how to chase this down?

Matt

[-- Attachment #2: Type: text/html, Size: 8704 bytes --]

Re: GNU Guile 2.1.5 released (beta)

[Matt Wette]

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


> On Dec 16, 2016, at 5:50 AM, Matt Wette <matt.wette@gmail.com> wrote:
> 
> OK.  This is gonna be hard to trace down.
> 
> I am on a Mac running Sierra, 10.12.2.  At work I am running 10.9 I believe, and I see the same behavior.
> 
> 
> If I compile with gcc 6.2 or gcc4.9, but no extra flags besides —prefix, I get the following failure:
> 
> FAIL: numbers.test: string->number: valid complex number strings
> 
> and trace this down to 
> 
> meta/guile -c '(display (eqv? (imag-part (string->number "#i1@-0")) -0.0))' => #f

I am now compiling with clang-3.9 and getting fatal errors.  Stay tuned …




[-- Attachment #2: Type: text/html, Size: 2600 bytes --]

Re: GNU Guile 2.1.5 released (beta)

[Christopher Allan Webber]

Matt Wette writes:

>> On Dec 16, 2016, at 5:50 AM, Matt Wette <matt.wette@gmail.com> wrote:
>> 
>> OK.  This is gonna be hard to trace down.
>> 
>> I am on a Mac running Sierra, 10.12.2.  At work I am running 10.9 I believe, and I see the same behavior.
>> 
>> 
>> If I compile with gcc 6.2 or gcc4.9, but no extra flags besides —prefix, I get the following failure:
>> 
>> FAIL: numbers.test: string->number: valid complex number strings
>> 
>> and trace this down to 
>> 
>> meta/guile -c '(display (eqv? (imag-part (string->number "#i1@-0")) -0.0))' => #f
>
> I am now compiling with clang-3.9 and getting fatal errors.  Stay tuned …

Is clang supported?  I didn't think it was.

Re: GNU Guile 2.1.5 released (beta)

[Matt Wette]

> On Dec 16, 2016, at 6:03 PM, Christopher Allan Webber <cwebber@dustycloud.org> wrote:
> 
> Matt Wette writes:
> 
>>> On Dec 16, 2016, at 5:50 AM, Matt Wette <matt.wette@gmail.com> wrote:
>>> 
>>> OK.  This is gonna be hard to trace down.
>>> 
>>> I am on a Mac running Sierra, 10.12.2.  At work I am running 10.9 I believe, and I see the same behavior.
>>> 
>>> 
>>> If I compile with gcc 6.2 or gcc4.9, but no extra flags besides —prefix, I get the following failure:
>>> 
>>> FAIL: numbers.test: string->number: valid complex number strings
>>> 
>>> and trace this down to 
>>> 
>>> meta/guile -c '(display (eqv? (imag-part (string->number "#i1@-0")) -0.0))' => #f
>> 
>> I am now compiling with clang-3.9 and getting fatal errors.  Stay tuned …
> 
> Is clang supported?  I didn't think it was.
> 

Maybe not, but it provides additional checks that may be catching something.   The error that is coming up is with respect to atomics in atomics-internal.h.  I believe C11 requires that the pointer arguments be _Atomic but they are not.  I am trying to build w/o the atomic routines (using clang), but will retry with gcc.

Re: GNU Guile 2.1.5 released (beta)

[Matt Wette]

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


> On Dec 7, 2016, at 11:55 AM, Andy Wingo <wingo@pobox.com> wrote:
> 
> We are pleased to announce GNU Guile release 2.1.5.
> 
> Guile 2.1.5 is the fifth pre-release in what will eventually become the
> 2.2 release series.  We encourage you to test this release and provide
> feedback to guile-devel@gnu.org.


--- libguile/numbers.c-orig     2016-11-21 13:56:23.000000000 -0800
+++ libguile/numbers.c  2016-12-17 07:10:26.000000000 -0800
@@ -9951,7 +9951,7 @@
   long n_size = scm_to_long (scm_integer_length (n));
   long d_size = scm_to_long (scm_integer_length (d));
 
-  if (abs (n_size - d_size) > 1)
+  if (labs (n_size - d_size) > 1)
     return (scm_difference (log_of_exact_integer (n),
                            log_of_exact_integer (d)));
   else if (scm_is_false (scm_negative_p (n)))


[-- Attachment #2: Type: text/html, Size: 4015 bytes --]

Re: GNU Guile 2.1.5 released (beta)

[Matt Wette]

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


> On Dec 20, 2016, at 7:00 AM, Matt Wette <matt.wette@gmail.com> wrote:
> 
> 
>> On Dec 7, 2016, at 11:55 AM, Andy Wingo <wingo@pobox.com <mailto:wingo@pobox.com>> wrote:
>> 
>> We are pleased to announce GNU Guile release 2.1.5.
>> 
>> Guile 2.1.5 is the fifth pre-release in what will eventually become the
>> 2.2 release series.  We encourage you to test this release and provide
>> feedback to guile-devel@gnu.org <mailto:guile-devel@gnu.org>.
> 

With the patch below I can get through all the tests on my Mac (macOS 10.12.2) if I use default flags (i.e., -g -O2) and gcc-4.9 (now verifying also w/ gcc-6.2).  The patch is a hack to get around an apparent optimization that thinks the sine of -0.0 is +0.0. 

Matt

--- libguile/numbers.c-orig     2016-11-21 13:56:23.000000000 -0800
+++ libguile/numbers.c  2016-12-20 14:43:58.000000000 -0800
@@ -9099,6 +9099,9 @@
 #undef FUNC_NAME
 
 SCM
+#ifdef __APPLE__
+__attribute__((optimize("O0")))
+#endif
 scm_c_make_polar (double mag, double ang)
 {
   double s, c;


[-- Attachment #2: Type: text/html, Size: 4723 bytes --]

Re: GNU Guile 2.1.5 released (beta)

[Matt Wette]

> On Dec 10, 2016, at 4:42 PM, Matt Wette <matt.wette@gmail.com> wrote:
> 
> On Dec 10, 2016, at 9:11 AM, Daniel Llorens <daniel.llorens@bluewin.ch> wrote:
>> 
>> 
>>>> Make check is failing on test-language, so I will be chasing that down.
>> 
>> 
>> FWIW this is the only test that fails on 10.9.5 and the backtrace looks identical too.
> 
> The problem appears in libguile/loader.c, alloc_aligned().  Check the value of “ret” I get after malloc and after the alignment.   I started looking at type size for uintptr_t vs char* but then got confused why guile is being compiled as x86_64, but my test programs are always x86
> 
> alignment=4096
> 
> /* This function leaks the memory that it allocates.  */
> static char*
> alloc_aligned (size_t len, unsigned alignment)
> {
>  char *ret;
> 
>  if (alignment == 8)
>    {
>      /* FIXME: Assert that we actually have an 8-byte-aligned malloc.  */
>      ret = malloc (len);
>    }
> #if defined(HAVE_SYS_MMAN_H) && defined(MMAP_ANONYMOUS)
>  else if (alignment == SCM_PAGE_SIZE)
>    {
>      ret = mmap (NULL, len, PROT_READ | PROT_WRITE, -1, 0);
>      if (ret == MAP_FAILED)
>        SCM_SYSERROR;
>    }
> #endif
>  else
>    {
>      if (len + alignment < len)
>        abort ();
> 
>      ret = malloc (len + alignment - 1);
> ret=0x0000000104000000
>      if (!ret)
>        abort ();
>      ret = (char *) ALIGN ((scm_t_uintptr) ret, alignment);
> ret=0x0000000004000000
>    }
> 
>  return ret;
> }

I posted a fix for this but wanted to respond in this thread.  I added “(scm_t_uintptr)” cast before the argument “alignment” to ALIGN.  Also, should MMAP_ANONYMOUS be HAVE_MAP_ANONYMOUS ???

Re: GNU Guile 2.1.5 released (beta)

[Andy Wingo]

On Sun 11 Dec 2016 16:42, Matt Wette <matt.wette@gmail.com> writes:

>  I am building on my Mac running macOS 10.12.1, aka Sierra. I will post my patches when I get through “make check”. 
>
> Patches to date attached. These address 
> 1) #23870 no clock_getcpuclockid
> 2) #24682 mkostemp
> 3) use of ALIGN needs cast in libguile/loader.c

Applied all these.  I also fixed that embarrassing MMAP_ANONYMOUS
thing.  Thank you very much!

Andy

Re: GNU Guile 2.1.5 released (beta)

[Andy Wingo]

Just a note -- your work here is really appreciated!  I know I'm a
verrrry async with patches but your work is indeed appreciated,
especially in the run-up to a 2.2.0 when I hope to have handled most all
these bugs.

Andy

On Mon 12 Dec 2016 02:25, Matt Wette <matt.wette@gmail.com> writes:

>  On Dec 11, 2016, at 12:35 PM, Matt Wette <matt.wette@gmail.com> wrote:
>
>  With patches I can compile and run “make check”. But now I have one failure:t tests/numbers.test line 1663: (“#i1@-0” 1.0 -0.0). 
>
>  This wants the following to produce #t, but it does not:
>
>  scheme@(guile-user)> (define z (string->number "#i1@-0"))
>  scheme@(guile-user)> (eqv? (imag-part z) -0.0)
>  $7 = #f
>
> Sorry to keep posting on this. I will stop soon. I seem to get different problems every time I build 2.1.5 on my Mac. I am using some different config options (e.g., with and without
> —disable-shared) and different compilers. The above issue does not show up with the current build. Note the following separate builds that give different values for the above:
>
> mwette$ pwd
> /Users/mwette/proj/scheme/guile/guile-2.1.5
> mwette$ meta/guile -c '(display (eqv? (imag-part (string->number "#i1@-0")) -0.0))'
> #f
>
> mwette$ pwd
> /Users/mwette/proj/scheme/guile/guile-2.1.5-2
> mwette$ meta/guile -c '(display (eqv? (imag-part (string->number "#i1@-0")) -0.0))'
> #t

Re: GNU Guile 2.1.5 released (beta)

[Andy Wingo]

On Tue 20 Dec 2016 23:58, Matt Wette <matt.wette@gmail.com> writes:

> With the patch below I can get through all the tests on my Mac (macOS 10.12.2) if I use default flags (i.e., -g -O2) and gcc-4.9 (now verifying also w/ gcc-6.2). The patch is a hack to
> get around an apparent optimization that thinks the sine of -0.0 is +0.0. 
>
> Matt
>
> --- libguile/numbers.c-orig 2016-11-21 13:56:23.000000000 -0800
> +++ libguile/numbers.c 2016-12-20 14:43:58.000000000 -0800
> @@ -9099,6 +9099,9 @@
> #undef FUNC_NAME
>
> SCM
> +#ifdef __APPLE__
> +__attribute__((optimize("O0")))
> +#endif
> scm_c_make_polar (double mag, double ang)
> {
> double s, c;

Aaah, thank you for tracking this one down!  So.  I assume that with GCC
(any version) everything is fine.  This is apparently an optimization in
LLVM.  But... is LLVM wrong, or are we wrong?  I guess LLVM is wrong,
right, since the result depends on the optimization level?  Surely we
should be able to produce a nice compiler bug report out of this :)

Andy

Re: GNU Guile 2.1.5 released (beta)

[Matt Wette]

> On Jan 8, 2017, at 3:01 PM, Andy Wingo <wingo@pobox.com> wrote:
> 
> On Tue 20 Dec 2016 23:58, Matt Wette <matt.wette@gmail.com> writes:
> 
>> With the patch below I can get through all the tests on my Mac (macOS 10.12.2) if I use default flags (i.e., -g -O2) and gcc-4.9 (now verifying also w/ gcc-6.2). The patch is a hack to
>> get around an apparent optimization that thinks the sine of -0.0 is +0.0. 
>> 
>> Matt
>> 
>> --- libguile/numbers.c-orig 2016-11-21 13:56:23.000000000 -0800
>> +++ libguile/numbers.c 2016-12-20 14:43:58.000000000 -0800
>> @@ -9099,6 +9099,9 @@
>> #undef FUNC_NAME
>> 
>> SCM
>> +#ifdef __APPLE__
>> +__attribute__((optimize("O0")))
>> +#endif
>> scm_c_make_polar (double mag, double ang)
>> {
>> double s, c;
> 
> Aaah, thank you for tracking this one down!  So.  I assume that with GCC
> (any version) everything is fine.  This is apparently an optimization in
> LLVM.  But... is LLVM wrong, or are we wrong?  I guess LLVM is wrong,
> right, since the result depends on the optimization level?  Surely we
> should be able to produce a nice compiler bug report out of this :)

I’m still not sure this is a bug.  I have a gut feeling there are some lingering issues on the Mac port.  I think this breaks w/ gcc also.  I will try again to verify.

Matt

Re: GNU Guile 2.1.5 released (beta)

[Matt Wette]

> On Jan 8, 2017, at 2:54 PM, Andy Wingo <wingo@pobox.com> wrote:
> 
> Just a note -- your work here is really appreciated!  I know I'm a
> verrrry async with patches but your work is indeed appreciated,
> especially in the run-up to a 2.2.0 when I hope to have handled most all
> these bugs.

And I really appreciate your work, as well as others (e.g., Ludo), on this project.

Matt