2.0.11 on OS X 10.9 / Xcode 5.1

2.0.11 on OS X 10.9 / Xcode 5.1

[Taylan Ulrich Bayırlı/Kammer]

Hi,

On OS X 10.9 with Xcode 5.1, make fails unless -O0 is used; the output
of ./configure && make during the failure is here:

http://sprunge.us/PLGI

After a successful build with -O0, there are two failures during make
check:

FAIL: srfi-18.test: thread-terminate!: termination destroys non-started
thread

FAIL: srfi-18.test: thread-terminate!: termination destroys started
thread

Ask away for any additional information I can provide!

Taylan

Re: 2.0.11 on OS X 10.9 / Xcode 5.1

[Taylan Ulrich Bayırlı/Kammer]

taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:

> Hi,
>
> On OS X 10.9 with Xcode 5.1, make fails unless -O0 is used; the output
> of ./configure && make during the failure is here:
>
> http://sprunge.us/PLGI
>
> After a successful build with -O0, there are two failures during make
> check:
>
> FAIL: srfi-18.test: thread-terminate!: termination destroys non-started
> thread
>
> FAIL: srfi-18.test: thread-terminate!: termination destroys started
> thread
>
> Ask away for any additional information I can provide!
>
> Taylan

By the way, after installing GCC 4.8 from MacPorts and setting the CC
environment variable to use it (executable "gcc-mp-4.8"), the above
issues are resolved, but I get the following test failure now:

Running numbers.test
;;; ("#i1@-0" 1.0 -0.0)
FAIL: numbers.test: string->number: valid complex number strings

The issue seems to be that (imag-part #i1@-0) => 0.0 instead of -0.0, so
it's not just `string->number' but also the reader, or something deeper;
possibly related to the fact that I upgraded GNU MP before doing this
recompilation (I upgraded all outdated MacPorts packages).  I'm now on
GMP 6.0.0.

Taylan

Re: 2.0.11 on OS X 10.9 / Xcode 5.1

[Taylan Ulrich Bayırlı/Kammer]

taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:

> taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:
>
>> Hi,
>>
>> On OS X 10.9 with Xcode 5.1, make fails unless -O0 is used; the output
>> of ./configure && make during the failure is here:
>>
>> http://sprunge.us/PLGI
>>
>> After a successful build with -O0, there are two failures during make
>> check:
>>
>> FAIL: srfi-18.test: thread-terminate!: termination destroys non-started
>> thread
>>
>> FAIL: srfi-18.test: thread-terminate!: termination destroys started
>> thread
>>
>> Ask away for any additional information I can provide!
>>
>> Taylan
>
> By the way, after installing GCC 4.8 from MacPorts and setting the CC
> environment variable to use it (executable "gcc-mp-4.8"), the above
> issues are resolved, but I get the following test failure now:
>
> Running numbers.test
> ;;; ("#i1@-0" 1.0 -0.0)
> FAIL: numbers.test: string->number: valid complex number strings
>
> The issue seems to be that (imag-part #i1@-0) => 0.0 instead of -0.0, so
> it's not just `string->number' but also the reader, or something deeper;
> possibly related to the fact that I upgraded GNU MP before doing this
> recompilation (I upgraded all outdated MacPorts packages).  I'm now on
> GMP 6.0.0.
>
> Taylan

To be more succinct, simply entering #i1@-0 at the REPL evaluates to
1.0+0.0i instead of 1.0-0.0i.

Re: 2.0.11 on OS X 10.9 / Xcode 5.1

[Greg Troxel]

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


taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:

> taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:
>
>> On OS X 10.9 with Xcode 5.1, make fails unless -O0 is used; the output
>> of ./configure && make during the failure is here:
>>
>> http://sprunge.us/PLGI
>>
>> After a successful build with -O0, there are two failures during make
>> check:
>>
>> FAIL: srfi-18.test: thread-terminate!: termination destroys non-started
>> thread
>>
>> FAIL: srfi-18.test: thread-terminate!: termination destroys started
>> thread
>
> By the way, after installing GCC 4.8 from MacPorts and setting the CC
> environment variable to use it (executable "gcc-mp-4.8"), the above
> issues are resolved, but I get the following test failure now:

So it seems that either there's a bug in clang, or a bug in guile that
causes problems when compiled with clang (which has different aggressive
optimizations than gcc).  Based on anecdotes from many other packages,
it seems more likely than not that it's a guile bug.

It would be interesting to bisect compilation of guile with 2 compilers,
or to compile with clang with optimization turned way down.

[-- Attachment #2: Type: application/pgp-signature, Size: 180 bytes --]

Re: 2.0.11 on OS X 10.9 / Xcode 5.1

[Mark H Weaver]

taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:

> By the way, after installing GCC 4.8 from MacPorts and setting the CC
> environment variable to use it (executable "gcc-mp-4.8"), the above
> issues are resolved, but I get the following test failure now:
>
> Running numbers.test
> ;;; ("#i1@-0" 1.0 -0.0)
> FAIL: numbers.test: string->number: valid complex number strings
>
> The issue seems to be that (imag-part #i1@-0) => 0.0 instead of -0.0

What does (sin -0.0) evaluate to?

My first guess is that at the C level, sin(-0.0) => 0.0 on your system,
although IEEE 754 and C11 (F.10.1.6) specify that sin(-0.0) => -0.0.

If my guess is incorrect, then please put a breakpoint in
'scm_c_make_polar' and see what's going wrong.  Both 'ang' and 's'
should be -0.0, and then it should pass -0.0 as the second argument to
'scm_c_make_rectangular'.

    Thanks,
      Mark

Re: 2.0.11 on OS X 10.9 / Xcode 5.1

[Taylan Ulrich Bayirli/Kammer]

Mark H Weaver <mhw@netris.org> writes:

> What does (sin -0.0) evaluate to?
>
> My first guess is that at the C level, sin(-0.0) => 0.0 on your system,
> although IEEE 754 and C11 (F.10.1.6) specify that sin(-0.0) => -0.0.
>
> If my guess is incorrect, then please put a breakpoint in
> 'scm_c_make_polar' and see what's going wrong.  Both 'ang' and 's'
> should be -0.0, and then it should pass -0.0 as the second argument to
> 'scm_c_make_rectangular'.
>
>     Thanks,
>       Mark

Update:

(As mentioned on IRC, (sin -0.0) evaluates to -0.0, also via sin() on
the C level in a minimal test-case compiled with the same compiler.
However...)

While trying to get the MacPorts-provided GCC 4.8 to build Guile with
debugging symbols (and not succeeding), I noticed that adding -g or
-ggdb to CFLAGS hides the issue, making #i1@-0 => 1.0-0.0i.  It seems to
be enough to recompile numbers.c (I touch it and re-run make with or
without CFLAGS+="-g").

Interestingly even with -g or -ggdb the ".debug_info" of the installed
guile executable is empty as per dwarfdump(1).  I wonder if, by the time
I actually manage to build with debug symbols, I'll be able to reproduce
the bug.

I wonder if I should concentrate on getting Guile to build with the
native compiler of OS X 10.9 / Xcode 5.1 instead (clang).  I don't have
too much time for Guile at work anyway, and otherwise no OS X system.

Taylan

Re: 2.0.11 on OS X 10.9 / Xcode 5.1

[Mark H Weaver]

Taylan Ulrich Bayirli/Kammer <taylanbayirli@gmail.com> writes:

> Mark H Weaver <mhw@netris.org> writes:
>
>> What does (sin -0.0) evaluate to?
>>
>> My first guess is that at the C level, sin(-0.0) => 0.0 on your system,
>> although IEEE 754 and C11 (F.10.1.6) specify that sin(-0.0) => -0.0.
>>
>> If my guess is incorrect, then please put a breakpoint in
>> 'scm_c_make_polar' and see what's going wrong.  Both 'ang' and 's'
>> should be -0.0, and then it should pass -0.0 as the second argument to
>> 'scm_c_make_rectangular'.
>>
>>     Thanks,
>>       Mark
>
> Update:
>
> (As mentioned on IRC, (sin -0.0) evaluates to -0.0, also via sin() on
> the C level in a minimal test-case compiled with the same compiler.
> However...)
>
> While trying to get the MacPorts-provided GCC 4.8 to build Guile with
> debugging symbols (and not succeeding), I noticed that adding -g or
> -ggdb to CFLAGS hides the issue, making #i1@-0 => 1.0-0.0i.  It seems to
> be enough to recompile numbers.c (I touch it and re-run make with or
> without CFLAGS+="-g").

Are you passing any optimization flags?  There are some, such as -Ofast,
-ffast-math, -funsafe-math-optimizations, -fno-signed-zeros,
-fassociative-math, and maybe some others that might result in this bug.

Otherwise, I suspect that there's some optimization bug in the compiler
you're using.  What exact version of GCC are you using?  These problems
don't seem to be happening with GCC 4.8.2 on GNU/Linux systems.

     Thanks,
       Mark

Re: 2.0.11 on OS X 10.9 / Xcode 5.1

[Taylan Ulrich Bayirli/Kammer]

Mark H Weaver <mhw@netris.org> writes:

> Are you passing any optimization flags?  There are some, such as -Ofast,
> -ffast-math, -funsafe-math-optimizations, -fno-signed-zeros,
> -fassociative-math, and maybe some others that might result in this bug.

I don't pass any flags to ./configure or make, other than --prefix to
./configure.

I have several *PATH environment variables exported, but I guess that
wouldn't be relevant.

> Otherwise, I suspect that there's some optimization bug in the compiler
> you're using.  What exact version of GCC are you using?  These problems
> don't seem to be happening with GCC 4.8.2 on GNU/Linux systems.

bash-3.2$ gcc-mp-4.8 --version
gcc-mp-4.8 (MacPorts gcc48 4.8.2_0) 4.8.2


That aside, I noticed that passing CFLAGS+="-g" to make ends up
inhibiting the passing of -O2 to gcc-mp-4.8, so surely the issue lies
somewhere in there.  The -g flag is passed by default anyway, so the
only effect of the CFLAGS+="-g" on make is to inhibit -O2 after all.

I also figured out the problem with debug symbols: apparently the ld on
OS X doesn't carry over debug info from .o files to a generated .dylib
file.  Instead, one later runs dsymutil(1) on the .dylib file, which
gathers the debug info from the .o files and puts them into a .dSYM
directory; gdb even loads this automatically when it's in the standard
location.

The next roadblock I hit is that when I run gdb on the guile executable,
it doesn't seem to realize that the libguile dylib is loaded, so still
lacks the debug symbols from it.  (When I enter "info sharedlibrary" it
says "No shared libraries loaded at this time" although the Guile REPL
and all runs, so libguile is obviously loaded.)  I'll continue tomorrow
if I have time again at work.

Taylan

Re: 2.0.11 on OS X 10.9 / Xcode 5.1

[Taylan Ulrich Bayirli/Kammer]

Taylan Ulrich Bayirli/Kammer <taylanbayirli@gmail.com> writes:

> The next roadblock I hit is that when I run gdb on the guile
> executable, it doesn't seem to realize that the libguile dylib is
> loaded, so still lacks the debug symbols from it.  (When I enter "info
> sharedlibrary" it says "No shared libraries loaded at this time"
> although the Guile REPL and all runs, so libguile is obviously
> loaded.)  I'll continue tomorrow if I have time again at work.

Update:

I gave up on gdb on OS X and tried the native lldb, which essentially
worked but failed to print relevant stack variables (maybe because of
-O2).  I resorted to printf debugging, but at least had immediate
success!

I can reproduce the problem with the following minimal program, compiled
with -O1 (not necessarily -O2):

/* BEGIN */
#include <stdio.h>
#include <math.h>

int main (int argc)
{
  double ang = 0, s, c;

  /* Prevent constant-propagation. */
  /* (Program must be called with no arguments.) */
  if (argc == 1)
    ang = -0.0;

  s = sin (ang);
  c = cos (ang); /* This line is needed to reproduce. */

  printf("%f\n", s); /* Prints "0.000000". */

  return c /* Prevent c from being optimized out. */;
}
/* END */

I don't know why `c' and/or the `cos (ang)' call are needed, but I fail
to reproduce the bug after only slight, seemingly irrelevant changes.

With the native clang on the system, the bug can't be reproduced.

Channel #gcc on Freenode suggested trying out -m32 vs. -m64, and
-mfpmath=387 vs. -mfpmath=sse, but the bug persists with all
combinations.

I also tried out other GCC packages of MacPorts: GCC 4.3 through 4.9 all
have the bug.  The plain GCC 4.2 package is not supported on recent OS X
versions.  Apple-patched GCC 4.2 does *not* have the bug.  (There are no
more recent Apple-patched GCC versions.)

I suppose I should move this to the GCC mailing list?

Taylan

Re: 2.0.11 on OS X 10.9 / Xcode 5.1

[Mark H Weaver]

Taylan Ulrich Bayirli/Kammer <taylanbayirli@gmail.com> wrote:
> Running numbers.test
> ;;; ("#i1@-0" 1.0 -0.0)
> FAIL: numbers.test: string->number: valid complex number strings
> 
> The issue seems to be that (imag-part #i1@-0) => 0.0 instead of -0.0,

Taylan and I did some more debugging on IRC, and we determined that this
is ultimately caused by a bug in the 'cexp' function in MacOS X's math
library.  The first two rules given in C11 G.6.3.1 imply that
cexp(0.0-0.0i) must return 1.0-0.0i, but on MacOS the result is
1.0+0.0i.

     Mark