Bug 66848 - boehm-gc fails test suite on x86_64-apple-darwin15
Summary: boehm-gc fails test suite on x86_64-apple-darwin15
Status: RESOLVED WONTFIX
Alias: None
Product: gcc
Classification: Unclassified
Component: boehm-gc (show other bugs)
Version: 5.2.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL: https://gcc.gnu.org/ml/gcc-patches/20...
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-12 13:59 UTC by Jack Howarth
Modified: 2018-01-10 14:58 UTC (History)
8 users (show)

See Also:
Host: x86_64-apple-darwin15
Target: x86_64-apple-darwin15
Build: x86_64-apple-darwin15
Known to work:
Known to fail:
Last reconfirmed: 2015-12-12 00:00:00


Attachments
x86_64-apple-darwin14 binaries that reproduce regressions on x86_64-apple-darwin15 (370.54 KB, application/octet-stream)
2015-07-12 14:02 UTC, Jack Howarth
Details
bzip2 compressed log of gctest walk in lldb from main (29.17 KB, application/octet-stream)
2015-07-12 15:59 UTC, Jack Howarth
Details
bzip2 compressed log of thread_leak_test walk in lldb from main (29.29 KB, application/octet-stream)
2015-07-12 16:09 UTC, Jack Howarth
Details
bzip2 compressed log of staticrootstest walk in lldb from main (1.95 KB, application/octet-stream)
2015-07-12 16:16 UTC, Jack Howarth
Details
proposed patch to suppress PR66848 on darwin (397 bytes, patch)
2015-12-21 20:48 UTC, Jack Howarth
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jack Howarth 2015-07-12 13:59:32 UTC
The boehm-gc test suite in FSF gcc shows regressions at -m32/-m64 when run on x86_64-apple-darwin15...

WARNING: program timed out.
FAIL: boehm-gc.c/gctest.c -O2 execution test
FAIL: boehm-gc.c/thread_leak_test.c -O2 execution test

FAIL: boehm-gc.lib/staticrootstest.c -O2 execution test

The same regressions are seen when running the boehm-gc test suite binaries and libraries, built entirely on x86_64-apple-darwin14, on x86_64-apple-darwin15. Replacing the libunwind.dylib on x86_64-apple-darwin15 with one from x86_64-apple-darwin14 eliminates the boehm-gc test suite regressions.

This issue has been opened as radr://21372179, "the FSF boehm-gc library built on
10.10 fails to pass its tests on 10.11". The Apple programmers claim the sources for libunwind.dylib are unchanged between darwin14 and darwin15. The only difference is the use of the darwin15 SDK and the Xcode 7 clang compilers. They believe the optimizations applied by the newer clang compiler are safe (which seems to be supported by the fact that upstream boehm-gc from http://www.hboehm.info/gc/ shows no test suite failures when built and run under x86_64-apple-darwin15 with Xcode 7). Rather, they suspect we are tripping over a latent bug in the FSF gcc boehm-gc sources.
Comment 1 Jack Howarth 2015-07-12 14:02:30 UTC
Created attachment 35957 [details]
x86_64-apple-darwin14 binaries that reproduce regressions on x86_64-apple-darwin15
Comment 2 Jack Howarth 2015-07-12 15:47:24 UTC
The seg fault in the thread_leak_test back traces as...

# lldb ./thread_leak_test
(lldb) target create "./thread_leak_test"
Current executable set to './thread_leak_test' (x86_64).
(lldb) r
Process 35899 launched: './thread_leak_test' (x86_64)
Process 35899 stopped
* thread #2: tid = 0x20cc95, 0x000000010000c48b libgcjgc.1.dylib`GC_mark_from(mark_stack_top=0x00000001000b1430, mark_stack=0x00000001000b1000, mark_stack_limit=0x00000001000c1000) + 283 at mark.c:759, stop reason = EXC_BAD_ACCESS (code=1, address=0x7fff7f95a158)
    frame #0: 0x000000010000c48b libgcjgc.1.dylib`GC_mark_from(mark_stack_top=0x00000001000b1430, mark_stack=0x00000001000b1000, mark_stack_limit=0x00000001000c1000) + 283 at mark.c:759
   756 		for(;;) {
   757 		  PREFETCH((ptr_t)limit - PREF_DIST*CACHE_LINE_SIZE);
   758 		  GC_ASSERT(limit >= current_p);
-> 759 		  deferred = *limit;
   760 		  FIXUP_POINTER(deferred);
   761 		  limit = (word *)((char *)limit - ALIGNMENT);
   762 		  if ((ptr_t)deferred >= least_ha && (ptr_t)deferred <  greatest_ha) {
(lldb) bt
* thread #2: tid = 0x20cc95, 0x000000010000c48b libgcjgc.1.dylib`GC_mark_from(mark_stack_top=0x00000001000b1430, mark_stack=0x00000001000b1000, mark_stack_limit=0x00000001000c1000) + 283 at mark.c:759, stop reason = EXC_BAD_ACCESS (code=1, address=0x7fff7f95a158)
  * frame #0: 0x000000010000c48b libgcjgc.1.dylib`GC_mark_from(mark_stack_top=0x00000001000b1430, mark_stack=0x00000001000b1000, mark_stack_limit=0x00000001000c1000) + 283 at mark.c:759
    frame #1: 0x000000010000db66 libgcjgc.1.dylib`GC_mark_some(cold_gc_frame=0x0000700000080d6c) + 518 at mark.c:378
    frame #2: 0x00000001000054d8 libgcjgc.1.dylib`GC_stopped_mark(stop_func=0x00000001000051c0) + 120 at alloc.c:531
    frame #3: 0x0000000100005d31 libgcjgc.1.dylib`GC_try_to_collect_inner(stop_func=0x00000001000051c0) + 145 at alloc.c:378
    frame #4: 0x0000000100005ffc libgcjgc.1.dylib`GC_try_to_collect(stop_func=0x00000001000051c0) + 92 at alloc.c:781
    frame #5: 0x0000000100006070 libgcjgc.1.dylib`GC_gcollect + 16 at alloc.c:794
    frame #6: 0x0000000100000d18 thread_leak_test`test + 72
    frame #7: 0x00000001000145c4 libgcjgc.1.dylib`GC_start_routine(arg=<unavailable>) + 244 at pthread_support.c:1301
    frame #8: 0x00007fff9e60fc8f libsystem_pthread.dylib`_pthread_body + 131
    frame #9: 0x00007fff9e60fc0c libsystem_pthread.dylib`_pthread_start + 168
    frame #10: 0x00007fff9e60d3f5 libsystem_pthread.dylib`thread_start + 13
(lldb)
Comment 3 Jack Howarth 2015-07-12 15:49:13 UTC
The seg fault in staticrootstexst back traces as...

# lldb ./staticrootstest
(lldb) target create "./staticrootstest"
Current executable set to './staticrootstest' (x86_64).
(lldb) r
Process 35905 launched: './staticrootstest' (x86_64)
dyld: Library not loaded: /nowhere/libstaticrootslib.1.dylib
  Referenced from: /sw/src/fink.build/gcc5-5.1.1-1/darwin_objdir/x86_64-apple-darwin14.4.0/boehm-gc/testsuite/.libs/./staticrootstest
  Reason: image not found
Process 35905 stopped
* thread #1: tid = 0x20cf25, 0x00007fff5fc01075 dyld`dyld_fatal_error + 1, stop reason = EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0)
    frame #0: 0x00007fff5fc01075 dyld`dyld_fatal_error + 1
dyld`dyld_fatal_error:
->  0x7fff5fc01075 <+1>: nop    

dyld`dyldbootstrap::start:
    0x7fff5fc01076 <+0>: pushq  %rbp
    0x7fff5fc01077 <+1>: movq   %rsp, %rbp
    0x7fff5fc0107a <+4>: pushq  %r15
(lldb) bt
* thread #1: tid = 0x20cf25, 0x00007fff5fc01075 dyld`dyld_fatal_error + 1, stop reason = EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0)
  * frame #0: 0x00007fff5fc01075 dyld`dyld_fatal_error + 1
    frame #1: 0x00007fff5fc040d1 dyld`dyld::halt(char const*) + 77
    frame #2: 0x00007fff5fc060e6 dyld`dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 4086
    frame #3: 0x00007fff5fc01276 dyld`dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*) + 512
    frame #4: 0x00007fff5fc01036 dyld`_dyld_start + 54
(lldb)
Comment 4 Jack Howarth 2015-07-12 15:50:41 UTC
The gctest hang backtraces as...

# lldb ./gctest
(lldb) target create "./gctest"
Current executable set to './gctest' (x86_64).
(lldb) r
Process 35911 launched: './gctest' (x86_64)
Switched to incremental mode
Emulating dirty bits with mprotect/signals
thread_get_state failed in forward_exception
Process 35911 stopped
* thread #2: tid = 0x20d116, 0x00007fff8e6c4076 libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT
    frame #0: 0x00007fff8e6c4076 libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
->  0x7fff8e6c4076 <+10>: jae    0x7fff8e6c4080            ; <+20>
    0x7fff8e6c4078 <+12>: movq   %rax, %rdi
    0x7fff8e6c407b <+15>: jmp    0x7fff8e6bf0df            ; cerror_nocancel
    0x7fff8e6c4080 <+20>: retq   
(lldb) bt
* thread #2: tid = 0x20d116, 0x00007fff8e6c4076 libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT
  * frame #0: 0x00007fff8e6c4076 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff9e61163d libsystem_pthread.dylib`pthread_kill + 90
    frame #2: 0x00007fff95d5783b libsystem_c.dylib`abort + 129
    frame #3: 0x0000000100022e29 libgcjgc.1.dylib`GC_abort(msg=<unavailable>) + 57 at misc.c:1081
(lldb)
Comment 5 Jack Howarth 2015-07-12 15:59:26 UTC
Created attachment 35958 [details]
bzip2 compressed log of gctest walk in lldb from main
Comment 6 Jack Howarth 2015-07-12 16:09:42 UTC
Created attachment 35959 [details]
bzip2 compressed log of thread_leak_test walk in lldb from main
Comment 7 Jack Howarth 2015-07-12 16:16:55 UTC
Created attachment 35960 [details]
bzip2 compressed log of staticrootstest walk in lldb from main
Comment 8 Jack Howarth 2015-07-14 02:51:04 UTC
Note that radr://21372179 has been closed by Apple as "behaves as expected' so that they believe the bug lies in the FSF gcc boehm-gc code.
Comment 9 Jack Howarth 2015-09-23 16:06:40 UTC
Note that the earliest upstream boehm-gc release which builds and passes make check on 10.11 is gc-7.2.tar.gz from http://www.hboehm.info/gc/gc_source/. Diffing the current boehm-gc sources in gcc trunk suggests that the current FSF boehm-gc is based on 7.1 (for at least mach_dep.c, etc).
Comment 10 Jack Howarth 2015-10-11 15:54:29 UTC
FYI, the earliest upstream boehm-gc which builds and passes make check on 10.11 under the Apple clang 7.0 compiled system unwinder is gc-7.2alpha6.
Comment 11 Jack Howarth 2015-10-11 19:45:01 UTC
Changing...

--- gcc-5.2.0.orig/boehm-gc/include/private/gcconfig.h	2013-12-21 15:42:39.000000000 -0500
+++ gcc-5.2.0/boehm-gc/include/private/gcconfig.h	2015-10-11 15:41:26.000000000 -0400
@@ -1041,10 +1041,10 @@
 #   define MACH_TYPE "I386"
 #   if defined(__LP64__) || defined(_WIN64)
 #     define CPP_WORDSZ 64
-#     define ALIGNMENT 8
+#     define ALIGNMENT 2
 #   else
 #     define CPP_WORDSZ 32
-#     define ALIGNMENT 4
+#     define ALIGNMENT 2
 			/* Appears to hold for all "32 bit" compilers	*/
 			/* except Borland.  The -a4 option fixes 	*/
 			/* Borland.					*/
@@ -2005,10 +2005,10 @@
 # ifdef X86_64
 #   define MACH_TYPE "X86_64"
 #   ifdef __ILP32__
-#     define ALIGNMENT 4
+#     define ALIGNMENT 2
 #     define CPP_WORDSZ 32
 #   else
-#     define ALIGNMENT 8
+#     define ALIGNMENT 2
 #     define CPP_WORDSZ 64
 #   endif
 #   ifndef HBLKSIZE

suppress the failures in the boehm-gc test suite on darwin15's unwinder (as well as using ALIGNMENT 1). Note that ALIGNMENT 4 on 64-bit doesn't suppress the boehm-gc test suite failures.
Comment 12 mrs@gcc.gnu.org 2015-10-14 16:39:04 UTC
Is this just a partial import from upstream?  If so, I think we should just check it in and call the issue solved.
Comment 13 Jack Howarth 2015-10-14 21:17:22 UTC
(In reply to mrs@gcc.gnu.org from comment #12)
> Is this just a partial import from upstream?  If so, I think we should just
> check it in and call the issue solved.

   No, the patch shown is an ugly hack of reducing the alignment to 2 (or 1) which merely suppresses the breakage of boehm-gc (and thus gcj) under the Apple Clang 7.0 compiled libunwind.dylib on darwin15. The newer upstream boehm-gc uses the same alignments as gcc's boehm-gc but doesn't suffer the test suite failures.
   All I can say at the moment is that the bug seems to be alignment related. However it is unclear to me if the bug actually lies in gcc's current boehm-gc or whether the breakage really lies in the Apple Clang 7.0 optimizations to the system unwinder and that the newer upstream boehm-gc merely makes the bug go latent. Apple claims these new optimizations to the unwinder are valid but I really doubt that the bug has been truly examined in depth to validate that .
Comment 14 Jack Howarth 2015-10-15 19:25:57 UTC
I finally got around to rebuilding the Apple open source release of libunwind-35.3 from 10.10.5 under Xcode 7 on 10.10.5. The results are rather interesting as the default build is a Debug one compiled at -O0. The debug build of libunwind.dylib produces a binary which exhibits the same breakage in the boehm-gc test suite binaries built on darwin14 as is seen on darwin15 with the optimized system libunwind.dylib. This makes it much more likely that the issue isn't an optimization bug in Apple Clang 7.0 but rather a linker bug in Xcode 7. Unfortunately, it is impossible to test that by linking the Xcode 7 build under the Xcode 6 linker because the Xcode 7 build uses the 10.11 SDK on 10.10 which needs a linkage on libc++abi.tbd and thus requires the new linker with the .tbd support.

FYI, The .tbd files are new "text-based stub libraries", that provide a much more compact version of the stub libraries for use in the SDK, and help to significantly reduce its download size.
Comment 15 Jack Howarth 2015-10-15 19:37:01 UTC
(In reply to Jack Howarth from comment #14)
> I finally got around to rebuilding the Apple open source release of
> libunwind-35.3 from 10.10.5 under Xcode 7 on 10.10.5. The results are rather
> interesting as the default build is a Debug one compiled at -O0. The debug
> build of libunwind.dylib produces a binary which exhibits the same breakage
> in the boehm-gc test suite binaries built on darwin14 as is seen on darwin15
> with the optimized system libunwind.dylib. This makes it much more likely
> that the issue isn't an optimization bug in Apple Clang 7.0 but rather a
> linker bug in Xcode 7. Unfortunately, it is impossible to test that by
> linking the Xcode 7 build under the Xcode 6 linker because the Xcode 7 build
> uses the 10.11 SDK on 10.10 which needs a linkage on libc++abi.tbd and thus
> requires the new linker with the .tbd support.
> 
> FYI, The .tbd files are new "text-based stub libraries", that provide a much
> more compact version of the stub libraries for use in the SDK, and help to
> significantly reduce its download size.

Nick,
     Are there any changes in the default behavior of the linker from Xcode 6.4 to 7.0 which I can revert in my Xcode 7 build of libunwind-35.3 on 10.10.5 with linker flags?
          Jack
Comment 16 Jeremy Huddleston Sequoia 2015-10-15 20:43:43 UTC
(In reply to Jack Howarth from comment #14)
> I finally got around to rebuilding the Apple open source release of
> libunwind-35.3 from 10.10.5 under Xcode 7 on 10.10.5. The results are rather
> interesting as the default build is a Debug one compiled at -O0. The debug
> build of libunwind.dylib produces a binary which exhibits the same breakage
> in the boehm-gc test suite binaries built on darwin14 as is seen on darwin15
> with the optimized system libunwind.dylib. This makes it much more likely
> that the issue isn't an optimization bug in Apple Clang 7.0 but rather a
> linker bug in Xcode 7.

I don't see how you come to that conclusion.  All I see are these data points:

libunwind-35.3 built against the 10.10 SDK with Xcode6-era clang and Xcode6-era linker produces a libunwind.dylib that does not exhibit this problem.

libunwind-35.3 built against the 10.11 SDK with Xcode7-era clang and Xcode7-era linker produces a libunwind.dylib that exhibits this problem.

I suggest you try using the Xcode 7 linker with the Xcode 6 compiler and 10.10 SDK.  If you hypothesis is correct, it should fail.  You can do that by just copying Xcode7's linker to Xcode6.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld (make sure you backup the old one of course).


> Unfortunately, it is impossible to test that by
> linking the Xcode 7 build under the Xcode 6 linker because the Xcode 7 build
> uses the 10.11 SDK on 10.10 which needs a linkage on libc++abi.tbd and thus
> requires the new linker with the .tbd support.

Well then I suggest you similarly test using the Xcode 7 compiler with the Xcode 7 linker and the 10.10 SDK to rule out the SDK as a factor and then test using the Xcode 7 compiler with the Xcode 6 linker and the 10.10 SDK.

> FYI, The .tbd files are new "text-based stub libraries", that provide a much
> more compact version of the stub libraries for use in the SDK, and help to
> significantly reduce its download size.
Comment 17 Jack Howarth 2015-10-16 01:47:54 UTC
Okay, I have verified on 10.10 that llvm.org clang 3.6 builds a libunwind.dylib which doesn't show the boehm-gc test suite regressions but when libunwind.dylib is built with llvm.org clang 3.7, it does. According to Jeremy, the commit in llvm which tickled this regression in boehm-gc is...

http://llvm.org/viewvc/llvm-project?view=revision&revision=226751

which caused the symbol ordering to change and resulted in the linker moving stuff out of __bss into __data.
Comment 18 Jack Howarth 2015-10-16 06:42:13 UTC
The upstream commit...

https://github.com/ivmai/bdwgc/commit/faef04e7cb3741163dfdf65900ef5d2a0530be0f

2011-02-09 Ivan Maidanski <ivmai@mail.ru>
	* src/atomic_ops.c (AO_USE_NO_SIGNALS, AO_USE_NANOSLEEP): New
	macros.
	* src/atomic_ops.c (AO_USE_WIN32_PTHREADS): Imply
	AO_USE_NO_SIGNALS.
	* src/atomic_ops.c: Don't include signal.h if AO_USE_NO_SIGNALS.
	* src/atomic_ops.c: Include time.h if AO_USE_NANOSLEEP.
	* src/atomic_ops.c (AO_locks, AO_pause): Reformat the code.
	* src/atomic_ops.c (AO_pause): Use nanosleep() if
	AO_USE_NANOSLEEP.
	* src/atomic_ops.c (all_sigs, initialized,
	AO_compare_and_swap_emulation,
	AO_compare_double_and_swap_double_emulation): Use
	AO_USE_NO_SIGNALS instead of AO_USE_WIN32_PTHREADS.

potentially could contain useful change for darwin. This is the specific commit in between the 7.2alpha4 and 7.2alpha6 releases which eliminates the test suite failures on darwin. The caveat is that these failures are for all darwin and not just darwin15.
Comment 19 Jack Howarth 2015-10-18 16:45:55 UTC
This thread...

http://www.hpl.hp.com/hosted/linux/mail-archives/gc/2011-April/004472.html

suggests that the boehm-gc is older than I suspected (as it claims gcc's copy is based on the 6.6 release). As far as I can tell, the proposal to update gcc's boehm-gc to 7.2 never progressed past initial discussions.

http://www.hpl.hp.com/hosted/linux/mail-archives/gc/2011-April/004516.html

The thread pretty much dies off at that point.
Comment 20 Jack Howarth 2015-10-18 16:57:19 UTC
Also, the one commonality in all of the boehm-gc regressions on darwin15 (against the Apple Clang 7.0 compiled libunwind.dylib) is instances of...

* thread #1: tid = 0x20dbb8, 0x00007fff93f37148 libdyld.dylib`dyld_stub_binder, queue = 'com.apple.main-thread', stop reason = instruction step into
    frame #0: 0x00007fff93f37148 libdyld.dylib`dyld_stub_binder
libdyld.dylib`dyld_stub_binder:
->  0x7fff93f37148 <+0>:  pushq  %rbp
    0x7fff93f37149 <+1>:  testq  $0xf, %rsp
    0x7fff93f37150 <+8>:  jne    0x7fff93f372da            ; stack_not_16_byte_aligned_error


errors. The fact that hacking the ALIGNMENT setting in boehm-gc/include/private/gcconfig.h to use 2 eliminates the regressions would seem to make sense then as this would be forcing everything to be 16-bit aligned.
Comment 21 Dominique d'Humieres 2015-12-12 18:35:50 UTC
Confirmed.

I also get 20 failures for the libjava tests

WARNING: program timed out.
FAIL: TestClosureGC run
WARNING: program timed out.
FAIL: libjava.jar/TestClosureGC.jar execution - gij test
WARNING: program timed out.
FAIL: FileHandleGcTest execution - source compiled test
WARNING: program timed out.
FAIL: FileHandleGcTest -findirect-dispatch execution - source compiled test
WARNING: program timed out.
FAIL: FileHandleGcTest -O3 execution - source compiled test
WARNING: program timed out.
FAIL: FileHandleGcTest -O3 -findirect-dispatch execution - source compiled test
WARNING: program timed out.
FAIL: PR18699 execution - source compiled test
WARNING: program timed out.
FAIL: PR18699 -findirect-dispatch execution - source compiled test
WARNING: program timed out.
FAIL: PR18699 -O3 execution - source compiled test
WARNING: program timed out.
FAIL: PR18699 -O3 -findirect-dispatch execution - source compiled test
WARNING: program timed out.
FAIL: PR36252 execution - source compiled test
WARNING: program timed out.
FAIL: PR36252 -findirect-dispatch execution - source compiled test
WARNING: program timed out.
FAIL: PR36252 -O3 execution - source compiled test
WARNING: program timed out.
FAIL: PR36252 -O3 -findirect-dispatch execution - source compiled test
WARNING: program timed out.
FAIL: md5test execution - source compiled test
WARNING: program timed out.
FAIL: md5test -findirect-dispatch execution - source compiled test
WARNING: program timed out.
FAIL: md5test -O3 execution - source compiled test
WARNING: program timed out.
FAIL: md5test -O3 -findirect-dispatch execution - source compiled test
WARNING: program timed out.
FAIL: TestEarlyGC execution - source compiled test
WARNING: program timed out.
FAIL: TestLeak execution - source compiled test

for both -m32 and -m64. Are they related?
Comment 22 Jack Howarth 2015-12-13 20:53:50 UTC
(In reply to Dominique d'Humieres from comment #21)
> 
> for both -m32 and -m64. Are they related?

Yes. If you apply the ugly hack from comment 11, you will find that it fixes both the boehm-gc test suite regressions as well as those in the libjava test suite (which are due to the breakage in boehm-gc used by libjava).
Comment 23 Dominique d'Humieres 2015-12-20 12:44:06 UTC
> Yes. If you apply the ugly hack from comment 11, you will find that it fixes
> both the boehm-gc test suite regressions as well as those in the libjava test
> suite (which are due to the breakage in boehm-gc used by libjava).

Yes it does. This should probably also be done for the 5 branch (I see the same failures).
Comment 24 ro@CeBiTec.Uni-Bielefeld.DE 2015-12-20 12:57:20 UTC
> --- Comment #23 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
>> Yes. If you apply the ugly hack from comment 11, you will find that it fixes
>> both the boehm-gc test suite regressions as well as those in the libjava test
>> suite (which are due to the breakage in boehm-gc used by libjava).
>
> Yes it does. This should probably also be done for the 5 branch (I see the same
> failures).

For me (on Mac OS X 10.11.1), the hack fixes the boehm-gc failures, but
the libjava ones remain.

	Rainer
Comment 25 Jack Howarth 2015-12-21 04:27:07 UTC
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #24)
> > --- Comment #23 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> >> Yes. If you apply the ugly hack from comment 11, you will find that it fixes
> >> both the boehm-gc test suite regressions as well as those in the libjava test
> >> suite (which are due to the breakage in boehm-gc used by libjava).
> >
> > Yes it does. This should probably also be done for the 5 branch (I see the same
> > failures).
> 
> For me (on Mac OS X 10.11.1), the hack fixes the boehm-gc failures, but
> the libjava ones remain.
> 
> 	Rainer

Did you remember to install the patched build before attempting to run the libjava test suite? System Integrity Protection on 10.11 will make any usage of DYLD_LIBRARY_PATH by the test suite non-functional so any previously installed libraries will be used instead of those in the current build directory.

Native configuration is x86_64-apple-darwin15.3.0

		=== libjava tests ===


Running target unix/-m32
FAIL: PR16923.c compilation

		=== libjava Summary for unix/-m32 ===

# of expected passes		2580
# of unexpected failures	1
# of expected failures		4

Running target unix/-m64
FAIL: Throw_2 execution - source compiled test
FAIL: Throw_2 -findirect-dispatch execution - source compiled test
FAIL: Throw_2 -O3 execution - source compiled test
FAIL: Throw_2 -O3 -findirect-dispatch execution - source compiled test

		=== libjava Summary for unix/-m64 ===

# of expected passes		2574
# of unexpected failures	4
# of expected failures		4
# of untested testcases		4

		=== libjava Summary ===

# of expected passes		5154
# of unexpected failures	5
# of expected failures		8
# of untested testcases		4

Compiler version: gcc libjava 
Platform: x86_64-apple-darwin15.3.0
configure flags: --prefix=/sw --prefix=/sw/lib/gcc6 --mandir=/sw/share/man --infodir=/sw/lib/gcc6/info --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw --with-system-zlib --program-suffix=-fsf-6 --with-build-config=bootstrap-debug
Comment 26 Jack Howarth 2015-12-21 20:48:59 UTC
Created attachment 37100 [details]
proposed patch to suppress PR66848 on darwin

The attached proposed patch suppresses PR66848 on darwin until either the underlying bug in the v6.6 based boehm-gc is fixed or boehm-gc in gcc is rebased on 7.2 or later which doesn't suffer from this bug.
Comment 27 ro@CeBiTec.Uni-Bielefeld.DE 2016-01-04 14:21:29 UTC
> --- Comment #25 from Jack Howarth <howarth.at.gcc at gmail dot com> ---
[...]
> Did you remember to install the patched build before attempting to run the
> libjava test suite? System Integrity Protection on 10.11 will make any usage of

No, I've never done that before and try to avoid it if at all possible
on any platform.

> DYLD_LIBRARY_PATH by the test suite non-functional so any previously installed
> libraries will be used instead of those in the current build directory.

I wasn't aware of that: what a pity this is an system-wide
all-or-nothing setting without any way to override it e.g. per session
with appropriate privilege: makes the system sort of useless for
combined development and desktop use ;-(

After disabling SIP, I get the same results as you do with your patch.

Thanks.
        Rainer
Comment 28 Jack Howarth 2016-01-04 21:00:48 UTC
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #27)
> > --- Comment #25 from Jack Howarth <howarth.at.gcc at gmail dot com> ---
> [...]
> > Did you remember to install the patched build before attempting to run the
> > libjava test suite? System Integrity Protection on 10.11 will make any usage of
> 
> No, I've never done that before and try to avoid it if at all possible
> on any platform.
> 
> > DYLD_LIBRARY_PATH by the test suite non-functional so any previously installed
> > libraries will be used instead of those in the current build directory.
> 
> I wasn't aware of that: what a pity this is an system-wide
> all-or-nothing setting without any way to override it e.g. per session
> with appropriate privilege: makes the system sort of useless for
> combined development and desktop use ;-(
> 

Iain suggested that the required changes for supporting SIP will be along the lines of...

a) make all libs @rpath/xxx
b) add @loader_path as an rpath to all libs with a local dep.
c) add @executable_path/../lib; <path/to/current/install/dir/>../lib as rpaths to exes.

> After disabling SIP, I get the same results as you do with your patch.
> 
> Thanks.
>         Rainer
Comment 29 Iain Sandoe 2016-01-04 21:03:58 UTC
(In reply to Jack Howarth from comment #28)
> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #27)
> > > --- Comment #25 from Jack Howarth <howarth.at.gcc at gmail dot com> ---

> Iain suggested that the required changes for supporting SIP will be along
> the lines of...
> 
> a) make all libs @rpath/xxx
> b) add @loader_path as an rpath to all libs with a local dep.
> c) add @executable_path/../lib; <path/to/current/install/dir/>../lib as
> rpaths to exes.

I have a draft for a patch to do this - will try and stick it somewhere useful soon.
Comment 30 Jack Howarth 2016-01-04 22:08:44 UTC
(In reply to Iain Sandoe from comment #29)
> (In reply to Jack Howarth from comment #28)
> > (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #27)
> > > > --- Comment #25 from Jack Howarth <howarth.at.gcc at gmail dot com> ---
> 
> > Iain suggested that the required changes for supporting SIP will be along
> > the lines of...
> > 
> > a) make all libs @rpath/xxx
> > b) add @loader_path as an rpath to all libs with a local dep.
> > c) add @executable_path/../lib; <path/to/current/install/dir/>../lib as
> > rpaths to exes.
> 
> I have a draft for a patch to do this - will try and stick it somewhere
> useful soon.

It certainly would be worthwhile getting some level of support for SIP in gcc 6 as we really don't want to encourage users to disable that feature.
Comment 31 Eric Gallager 2016-01-07 05:01:01 UTC
(In reply to Jack Howarth from comment #30)
> 
> It certainly would be worthwhile getting some level of support for SIP in
> gcc 6 as we really don't want to encourage users to disable that feature.

Why wouldn't we want to encourage users to disable it? Does it actually do anything useful? Judging by this thread, it seems more like an unnecessary hassle to me, and further justification for my decision to stay on an old version of OS X that isn't encumbered by such hassles...
Comment 32 Jack Howarth 2016-01-07 18:30:35 UTC
(In reply to Eric Gallager from comment #31)
> (In reply to Jack Howarth from comment #30)
> > 
> > It certainly would be worthwhile getting some level of support for SIP in
> > gcc 6 as we really don't want to encourage users to disable that feature.
> 
> Why wouldn't we want to encourage users to disable it? Does it actually do
> anything useful? Judging by this thread, it seems more like an unnecessary
> hassle to me, and further justification for my decision to stay on an old
> version of OS X that isn't encumbered by such hassles...

Note that the SIP issues with the gcc build machinery are entirely orthogonal to this bug report. However, while SIP can currently be disabled from the Recovery Partition under OS X, I suspect that option will eventually be removed in a future OS X release.
Comment 33 Eric Gallager 2017-10-10 15:30:28 UTC
gcc no longer carries its own copy of the boehm-gc sources. Is there any reason to keep this bug open?
Comment 34 Eric Gallager 2018-01-10 13:03:07 UTC
(In reply to Eric Gallager from comment #33)
> gcc no longer carries its own copy of the boehm-gc sources. Is there any
> reason to keep this bug open?

WAITING on a response
Comment 35 Andrew Haley 2018-01-10 14:58:47 UTC
Boehm GC is gone from GCC sources.