[MacPorts] #49227: gcc5 @5.2.0: fix gcj

[MacPorts]

#49227: gcc5 @5.2.0: fix gcj
------------------------------------+----------------------
  Reporter:  howarth.at.macports@…  |      Owner:  mww@…
      Type:  defect                 |     Status:  new
  Priority:  Normal                 |  Milestone:
 Component:  ports                  |    Version:  2.3.4
Resolution:                         |   Keywords:  haspatch
      Port:  gcc5                   |
------------------------------------+----------------------

Comment (by howarth.at.macports@…):

 Replying to [comment:10 jeremyhu@…]:
 > graziosi.angelo, you don't understand potential fallout to compiler
 changes.
 >
 > At worst, the compiler produces bad code and anything that it compiled
 needs to be recompiled.  We don't have a mechanism for triggering that, so
 we need to be extra careful taking toolchain changes.
 >
 > If upstream doesn't approve it, we should be even more cautious.
 [[BR]]
 I wouldn't hold my breath for a fix from the FSF gcc developers on this
 issue. The libjava development in FSF gcc (of which boehm-gc is part) is
 pretty much mothballed. There were vague preliminary discussions of
 upgrading the boehm-gc in FSF gcc to 7.2 from the current 6.6 back in 2011
 which never went anywhere...

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


 FYI, I don't expect upstream to accept this alignment hack as it is
 specific to darwin's use of a clang 3.7 or later compiled unwinder. Also
 note the comment in boehm-gc/include/private/gcconfig.h...

  * ALIGNMENT is the largest N, such that
  * all pointer are guaranteed to be aligned on N byte boundaries.
  * defining it to be 1 will always work, but perform poorly.

 Since the actual error seen in darwin15 is ....

 * 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

 setting the ALIGNMENT to 2 simply forces everything on a 16-bit alignment
 and avoids the problem with a reduction in performance. Considering that
 we don't even have a usable gcj on *ANY* gcc past 4.6 and that the
 proposed changes produce *no* regressions in the boehm-gc and libjava test
 suites, I can't see any reason not to use these changes for now.

-- 
Ticket URL: <https://trac.macports.org/ticket/49227#comment:12>
MacPorts <https://www.macports.org/>
Ports system for OS X