gcc7, libgcc: broken on powerpc and "HOW TO RUN TEST SUITE ON GCC"

[mojca (Mojca Miklavec)]

gcc7 seems to be broken on PPC

In file included from /path/to/gcc-7-20170226/libgcc/unwind-dw2.c:1728:0:
/path/to/gcc-7-20170226/libgcc/unwind.inc: In function '_Unwind_RaiseException':
/path/to/gcc-7-20170226/libgcc/unwind.inc:136:1: error: unrecognizable insn:
 }
 ^
(jump_insn/f 193 192 194 14 (parallel [
            (return)
            (use (symbol_ref:SI ("*eh_rest_world_r10")))
            (clobber (reg:SI 11 r11))
            (set (reg:SI 70 cr2)
                (mem/c:SI (plus:SI (reg/f:SI 1 r1)
                        (const_int 4 [0x4])) [30  S4 A8]))

See: ​https://build.macports.org/builders/ports-10.5_ppc_legacy-builder/builds/28045

I submitted a bug report upstream: ​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80865

[ccorn]

As indicated in ​Bugzilla 80865, the ​patches mentioned in Comment 1 let the build succeed. Whether the result is usable, I cannot say yet.

[ccorn]

This now applies to the gcc7 port as well as its libgcc subport, as introduced in MacPorts commit ff4c4bd.

[ccorn]

Portfile changes for use with the patch mentioned in GCC Bugzilla 80865

[mojca (Mojca Miklavec)]

I'm adding the two of you to CC in case you are able to test the changes. (Or we could commit and hope that the buildbot attempt succeeds.)

ccorn: you diff only includes the patch for the Portfile, not the patch itself (but of course the patch itself can be taken from bugzilla).

[ryandesign (Ryan Carsten Schmidt)]

What kind of testing would be useful? I could see if the port builds on PowerPC with that patch. The port doesn't have a test phase.

[kencu (Ken)]

I'm happy to try a build in the morning as well. I saw this but was hesitating... this means changing libgcc to libgcc7 as well, correct?

I haven't yet read much about how libgcc changes in gcc7, but I did see there is a libstdc++.6.dylib in it, so I guess it's a "drop in" replacement for that file at least (plenty of software on my 10.5 PPC box is built with gcc6 or clang-3.8 and links against libstdc++), as does all the cxx11 1.1 PortGroup stuff.

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

I'm happy to try a build in the morning as well. I saw this but was hesitating... this means changing libgcc to libgcc7 as well, correct?

No... what makes you think that?

The version of one of the gcc libraries changed in gcc 7.x. Therefore, since libgcc contains that new version, a new libgcc6 port had to be created to provide the older version of the library for use by gcc 6.x and earlier. The ports should be correctly handling all these details already so nothing about that needs to be changed for this ticket.

[kencu (Ken)]

Thanks, good to know.

There is that "clang test suite" of 500 applications I used to test clang 3.8 on PPC; I wonder if something similar exists for gcc, or if that clang suite can be used to test gcc...

[mojca (Mojca Miklavec)]

I would say that at the moment it would already help to test whether the compiler itself builds at all and provide feedback to the upstream ticket.

Current sources don't build at all.

Running a test suite would of course be nice to reveal other potential problems, but getting the build to succeed in the first place seems most important right now. If the build succeeds, you could more easily test a couple of random ports with it.

[ccorn]

Both gcc7 and its subport libgcc get built successfully with the mentioned ​patch-darwin-ppc-2017-01-msg02971.diff which comprises Iain Sandoe's Darwin/PPC patches.

A tiny bit of ad-hoc testing reveals no more than the ages-old problem (at least on my apple-darwin9-powerpc G5) that C++ programs indirectly linked to both GCC's and the native C++ runtime libs tend to crash on exit. E.g. octave-gui. That can be avoided by using -static-libgcc when linking. There used to be an ancient patchfile for the GCC ports forcing that, but it was controversial and removed from the GCC 4.7+ ports if I recall correctly. I have kept the patch in a private git branch of the ports tree and applied it without problems ever since. (If you folks have no such problems, I'd like to hear about that.)

I have now applied that force-static-libgcc patch to the GCC7 port. Both libgcc and gcc7 still build fine; and octave-gui does not crash on exit any longer. Furthermore, my handful of C++11 feature tests works. The boost port (privately patched to allow GCC) also builds fine, and my few tests with Boost.Threads work. Superficially, things look nice.

[kencu (Ken)]

I haven't built it yet (that machine is still upgrading outdated ports this morning) but it sounds like this patch will be a go and we'll sort out the dust later if any.

I'll have to think about this: indirectly linked to both GCC's and the native C++ runtime libs tend to crash on exit.

There is a way to build libgcc with default abi 4 so that software built with newer GCCs would be compatible with the systems libstdc++ even if the ABI4 flag is not passed in during the build (like it is with the cxx11 1.1 PortGroup). I suspect the issue could lie in there...

This is the block I usually will add to the libgcc Portfile (gcc6 before, gcc7 now) to accomplish that default. Several unix distros do this same thing as well I notice. It basically does for all builds what the cxx flags in the cxx11 1.1 PortGroup does on a case by case basis. To me it makes sense; in case you want to build a port one-off with gcc6 or gcc7 specified on the command line, it will have the right ABI (4).

default_variants +defaultabi4
variant defaultabi4 description "use gcc4 compatible ABI" {
    configure.args-append --with-default-libstdcxx-abi=gcc4-compatible
}

[kencu (Ken)]

I haven't had any major issues with Boost though. The stock MacPorts version works OK for me. Sometimes you have to add the -fvisibility-hidden flag to ports that use boost, though, at least so far that's what I've done.

[kencu (Ken)]

It took a while to build this, but I have it built now (both gcc7 and libgcc). It builds through without errors, and I compiled my favourite c++11 test port, aria2 and that builds and works correctly so far.

I then rebuilt libgcc with my +defaultabi4 variant, so it would always use the "correct" ABI for this system; that also built though correctly.

To me, this looks good to go.

Thanks to everyone for your efforts; it's a real bonus having gcc7 on PPC. If we / I / somebody can ever fix the "exceptions" problem, clang-3.8 for PPC will be a full-bore go as well, which would be something special too (I backported Marcus' macports-libstdc++ fixes into clang-3.8 so it can work on PPC like the cxx11 1.1 PortGroup does already on clang-3.9+).

[kencu (Ken)]

There is a testsuite for gcc7 <​https://gcc.gnu.org/install/test.html>, and all the prerequisites for it are available in MacPorts (minor tweak needed to install port:expect prior to building port:dejagnu).

The test command from that website is cd objdir; make -k check which perhaps could be part of the gcc7 Portfile.

I haven't added a test suite to a Port before, certainly not somthing as complicated as gcc7. Here is a block from git that is probably pretty close to what gcc7 would need, I would think:

test.run            yes
test.cmd            make
test.target         test
test.dir            ${worksrcpath}
pre-test {
    eval test.args  ${build.args}
}

I wonder if could it be as easy as adding this block, then changing the test.cmd to make -k, the test.target to check, and setting the test.dir to ${workpath}/build

• I added the following to the Portfile. Not 100% sure this is correct, but port lint --nitpick liked it, and it at least has started. Tell you in about two days how it turns out :> .

  ############## TESTING infrastructure #########
  
  test.args-append    -k
  test.run            yes
  test.cmd            make
  test.target         check
  test.dir            ${workpath}/build
  
  ################################################
  

I suppose there is probably a depends_test port:dejagnu port:expect that exists if I were to go looking for it. Addition: Testing suite also requires port:autogen to be installed. NB: autogen requires guile which is presently broken on PPC, and requires the version one prior to the current version to install.

Once built, it is possible to manually go into the build directory and sudo make -k check.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #54795.

[kencu (Ken)]

The test suite for gcc7 takes a long time to run. Here are the final results - I should specify that this is with the default ABI set to 4 (as we use it in MacPorts, to be compatible with the older system libstdc++ ABI).

All fixinclude tests pass

		=== gcc Summary ===

# of expected passes		99768
# of unexpected failures	187
# of unexpected successes	3
# of expected failures		319
# of unresolved testcases	29
# of unsupported tests		3328

		=== g++ Summary ===

# of expected passes		100673
# of unexpected failures	37
# of expected failures		378
# of unresolved testcases	2
# of unsupported tests		4484

		=== gfortran Summary ===

# of expected passes		44541
# of unexpected failures	12
# of unexpected successes	6
# of expected failures		112
# of unsupported tests		224

		=== objc Summary ===

# of expected passes		5616
# of unexpected failures	2
# of unsupported tests		78

		=== obj-c++ Summary ===

# of expected passes		3114
# of unexpected failures	2
# of expected failures		2
# of unresolved testcases	1
# of unsupported tests		62

		=== libstdc++ Summary ===

# of expected passes		10594
# of unexpected failures	110
# of expected failures		66
# of unsupported tests		695

		=== libgomp Summary ===

# of expected passes		5067
# of unexpected failures	3
# of unsupported tests		382

		=== libitm Summary ===

# of expected passes		1
# of unexpected failures	21
# of unresolved testcases	21
# of unsupported tests		2

		=== libatomic Summary ===

# of expected passes		44
# of unsupported tests		5

[kencu (Ken)]

full run of gcc7 test suite (ABI4 set as default)

[kencu (Ken)]

gcc7 summary of test results (email usually sent to gcc admins)

[ballapete (Peter "Pete" Dyballa)]

It worked for me too, after 36 hours, to build libgcc 7.2.0. Now port is builging libgcc 6.4.0 once more…

[ballapete (Peter "Pete" Dyballa)]

Replying to ballapete:

It worked for me too, after 36 hours, to build libgcc 7.2.0. Now port is builging libgcc 6.4.0 once more…

It's on PCC Leopard, Mac OS X 10.5.8.

[ballapete (Peter "Pete" Dyballa)]

The same failure as #54795 in happens on PCC Tiger, Mac OS X 10.4.11.

[ballapete (Peter "Pete" Dyballa)]

Main.log from PPC Tiger

[kencu (Ken)]

Well - there are about 1000 unexpected failures in the test suite above, out of 260,000 tests.

At the moment, the build of libgcc is broken, and so these systems are stuck in limbo.

I wonder how many test failures there might be in gcc6 if we were to run that? Perhaps I will do just that :>

Are we in agreement that this should go ahead and get committed, and we'll improve things further if we can, when we can?

[ballapete (Peter "Pete" Dyballa)]

With the patches mentioned in gcc_test_suite_email_sent.txt the build of libgcc @7.2.0 succeeded.

[kencu (Ken)]

some further results, for you to compare to the ones above:

gcc7 test suite on Intel/x86_64 (Sierra): about 250 unexpected failures out of 260,000 tests (log attached).

gcc6 test suite on PPC/10.5: about 260 unexpected failures in 250,000 tests (log attached).

[kencu (Ken)]

gcc7 on 10.12 Sierra x8664

[kencu (Ken)]

gcc6 test suite on 10.5 Leopard PPC

[kencu (Ken)]

how to run and summarize these tests, using gcc7 as an example.

Install the dependencies as above: sudo port -v install dejagnu autogen expect, then:

sudo port -v build gcc7

cd `port work gcc7`/build

sudo make -k check

sudo chmod -R a+rw .

sudo /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc7/gcc7/work/gcc-7.2.0/contrib/test_summary -m YOURUSERNAME@localhost |sh

check your mail mail and save it to disk, e.g. s 1 ~/Desktop/gcc7.test.suite.summary.txt

[ccorn]

Following kencu's proposal, I am currently rebuilding libgcc7 and gcc7 with the +defaultabi4 variant, and I intend to run the testsuite after port build. Expect this to take several days.

I have made another variant for the force-static-libgcc patch used by me so far. Whereas +defaultabi4 tries to avoid incompatibilities by choosing a specific ABI, +staticlibgcc tries to make both ABIs coexist peacefully. Both variants can be combined, which might be useful on platforms where the GCC4 ABI is not the native one, if you want to try it anyway.

Following the criterion employed by PortGroup cxx11 1.1, if {os.major} < 13, variant +defaultabi4 will be set by default unless +staticlibgcc has been selected.

Attaching the port diff covering the Portfile and all patchfiles. I have tried to make appropriate distinctions between what is specific to PPC, what is specific to Darwin, and what is specific to particular versions of Darwin.

In the hope of making the expensive testsuite run a little more interesting, I have added other patches that I consider safe. One ignores -freorder_blocks_and_partition instead of issuing a warning when it is used on Darwin. The other avoids use of a fixed-size buffer (and thus buffer overflow) when assembling a label. Both patch proposals can be found at ​GCC Bugzilla 81033. The buffer patch there also uses a macro DECL_ASSEMBLER_NAME instead of DECL_NAME, but that change seems to have some Objective-C fallout if I understand the feedback correctly. Therefore I only use the portion that gets rid of the fixed-size buffer.

[ccorn]

gcc7 build fix, ABI-related variants, plus another couple of Darwin-specific patches which look like they cannot break anything.

[mojca (Mojca Miklavec)]

Ken, are you willing to commit the changes, please? We can continue discussing the test cases after that (either here or in a separate ticket or upstream). I don't see any major problem with the failures if they even fail on Sierra. Sure, they need to be fixed at some point, but let's get the compiler working to start with.

[kencu (Ken)]

will do

[kencu (Ken)]

In af4d2ca57fa6539494fdee7e1f17fb9b963922c2/macports-ports:

libgcc and gcc7: enable build on 10.4 and 10.5 PPC

closes: #54215
no revbump: changes do not affect build on systems
that currently can build libgcc and gcc7

[kencu (Ken)]

Sure hope that all went as smoothly as I think it did -- hate to mess up the primary compiler. Looks good here -- see if the buildbots approve. I did not revbump it - the changes were almost all in the PPC files, and the very few other changes were guarded by availability blocks, so it not appear to me that any already-built files would change.

ccom: I left the compiler build as generic as possible for now. Neither the defaultABI4 variant nor others included. MacPorts is not at all keen on static libraries in general, so that would have to be approved by a broader group before it would included (not likely, I think). The other patches you found might well be of use, but I don't have the full time and skills to investigate them in the detail needed at present, and there is time pressure to get this compiler working for everyone. Happy to debate/look over these with some of our compiler experts, and of course include them if they should be included. -- Ken

[mojca (Mojca Miklavec)]

Here's a ​link to the build.

My suggestion would be to either create a new ticket for tracking the rest of the problems or change this one from "build broken" to "tracking failed tests" (using a better name of course).

[ballapete (Peter "Pete" Dyballa)]

With the latest Portfile and patches from gcc7-buildfix+abi-variants+safepatches-p3.diff​ libgcc7 built. Now make check is running…

[ballapete (Peter "Pete" Dyballa)]

It's on PPC Tiger, Mac OS X 10.4.11.

[ballapete (Peter "Pete" Dyballa)]

Not enough disk space! Continuing with 4.3 GB of free disk space…

[ryandesign (Ryan Carsten Schmidt)]

Does this issue affect gcc8/libgcc-devel or gcc6 or earlier?

[kencu (Ken)]

gcc6 is good and solid and pretty much is the current go-to on PPC, at least until the excess build errors on gcc7 are ironed out.

I have not built lower gcc versions recently, but they should not be affected.

gcc8/libgcc-devel have not tested by me so far on PPC.

[ccorn]

For completeness, a comparison of gcc7 test summaries:

1. kencu's vs mine (both +defaultabi)
2. +defaultabi vs. +staticlibgcc.

Ingredients and methods

I used the above-mentioned gcc7-buildfix+abi-variants+safepatches-p3.diff and commands essentially equivalent to

( set -xe   # print commands before execution, exit on errors
  for variant in +defaultabi4+universal +staticlibgcc+universal; do
    for port in libgcc7 gcc7; do
      sudo port build $port $variant
      workdir=$(port work $port $variant)
      ( cd "$workdir/build"
        sudo -u macports make -k check 2>&1 | \
        tee ~-/check-$port$variant.log
        sudo -u macports ../gcc-7.2.0/contrib/test_summary | \
        sed '/^cat <</d;/^EOF$/,$d' | \
        tee ~-/summary-$port$variant.log )
      sudo port install $port $variant
    done
  done
) && echo "All done."

Universal archs are ppc and ppc64 here.

Thereafter, for easier comparison, I sed-ed the created logfiles and replaced build-specific stuff (MacPorts paths, user, dates, version+variants) with generic terms (/PREFIX, /WORKDIR, USER, DATE, VERSION).

Results

libgcc tests had the same results as the corresponding gcc7 tests, except for 6 vs. 8 C11 atomic timeout failures in the gcc testsuite with the +defaultabi variant. That difference may be spurious.

I will focus on the gcc7 test summaries here.

Comparing test summaries on a PPC G5 Leopard (Darwin 9):

• --- gcc7 +defaultabi4 (ppc) by kencu, using Iain Sandoe's build fixes
• +++ gcc7 +defaultabi4+universal (ppc and ppc64) by ccorn, using the build fixes and the "safe" patches

There are diffs, and I cannot say with certainty where they come from.

• g++ tests:
  • 13 less failures
  • 30 more supported tests
  • 1 more unresolved case turned into a pass
  • thus 44 more passes
• gcc tests:
  • 8 additional failures: C11 atomics, program timeout
  • 12 unresolved cases (no executable) turned into passes
  • thus 4 more passes
• obj-c++ tests:
  • 1 unresolved case (no executable) turned into a pass
• libitm tests:
  • 3 more expected failures
  • 18 more passes
  • all 21 unresolved cases (no executable) resolved
• libstdc++ tests:
  • 104 failures turned into passes

Attaching the diff -U1000 -b, covering the summaries completely.

Comparing test summaries on a PPC G5 Leopard (Darwin 9), +universal comprising ppc and ppc64, using the build fixes and the "safe" patches:

• --- gcc7 +defaultabi4+universal by ccorn
• +++ gcc7 +staticlibgcc+universal by ccorn

No diffs except the following, but those seem strange:

• g++ tests:
  • 24 more failures: exception handling, ext/cleanup
• libstdc++ tests:
  • 33 more passes
  • Number of unsupported tests down by 18
  • Identical failure counts
  • The sums of the test counts do not match.

                    === libstdc++ Summary ===
     
    -# of expected passes           10698
    +# of expected passes           10731
     # of unexpected failures       6
     # of expected failures         66
    -# of unsupported tests         695
    +# of unsupported tests         677
    

That seems to indicate that +staticlibgcc makes g++ fail more often, yet makes libstdc++ succeed more often, however without reducing the failure count. I am puzzled.

Attaching the diff -U1000, covering the summaries completely.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In c347ac662f932c0db8b15ec982eb4a563174bcfc/macports-ports:

compilers PG: update default GCC version (6->7)

Until #54215 is fully resolved,
keep the default GCC at version 6 on PowerPC systems.

[mojca (Mojca Miklavec)]

Isn't the compiler working well enough already? Not that I tested, but I cannot imagine getting absolutely all the tests fixed.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to mojca:

Isn't the compiler working well enough already? Not that I tested, but I cannot imagine getting absolutely all the tests fixed.

I may not have followed this ticket closely enough.
If gcc7 is working, then it should be the default for the compilers PortGroup.
I have no way of testing, however.

[kencu (Ken)]

gcc7 has 1000 unexpected failures on PPC, gcc6 has 260, out of about 250,000 tests in total. so gcc6 is somewhat more reliable, but the percentages are small in the end.

I would leave the default compiler as gcc6 for now on PPC, myself, esp for the cxx11 portgroup.

gcc7 will turn up more compiler errors due to increasing strictness, has more failures, and so far, no benefit I know of.

[ccorn]

I agree that gcc6 should remain default, although the contrast with gcc7 is not that stark in my tests. For me, the point is that the buildfix itself seems to have introduced its own problems.

Meanwhile, I have added the variant defs for +defaultabi4 and +staticlibgcc to the gcc6 Portfile, rebuilt libgcc6 and rebuilt and tested gcc6.

With gcc6, things are clearer: The variant +staticlibgcc causes 24 g++ exception-handling testsuite failures not encountered with +defaultabi4, no other differences. Attaching the diff. This result makes me favor +defaultabi4 over +staticlibgcc.

Comparing test summaries of

• --- gcc6+defaultabi4+universal
• +++ gcc7+defaultabi4+universal

and counting diff patterns yields:

-FAIL: 21
+FAIL: 111
-UNRESOLVED: 1
+UNRESOLVED: 12
-WARNING: 1
-XPASS: 1
+XPASS: 3

That's about one hundred more failures. Attaching the summary diff.

I also made an incomplete attempt to backport some of the patches in patch-darwin-ppc-2017-01-msg02971.diff (the gcc7 buildfix) to gcc6. This resulted in 15 additional gcc6 testsuite failures, see (yet another) attached diff. And those failures are present in the gcc7 test summaries too. I am tempted to conclude that the buildfix is not clean (unless the tests themselves are broken).

So the gcc7 build is still in murky waters. gcc6 should remain default compiler.

[ballapete (Peter "Pete" Dyballa)]

Here on Mac OS X 10.5.8 make check ends early after almost 50 GB of core dumps with a switch to German:

Running /opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/gcc-7.2.0/libatomic/testsuite/libatomic.c/c.exp ...

		=== libatomic Summary ===

# of expected passes		44
# of unsupported tests		5
make[4]: Verzeichnis „/opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/build/ppc-apple-darwin9/libatomic/testsuite“ wird verlassen
make[3]: Verzeichnis „/opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/build/ppc-apple-darwin9/libatomic/testsuite“ wird verlassen
make[3]: Verzeichnis „/opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/build/ppc-apple-darwin9/libatomic“ wird betreten
true  DO=all multi-do # make
make[3]: Verzeichnis „/opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/build/ppc-apple-darwin9/libatomic“ wird verlassen
make[2]: Verzeichnis „/opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/build/ppc-apple-darwin9/libatomic“ wird verlassen
make[1]: Das Ziel „check-target“ wurde wegen Fehlern nicht aktualisiert.
make[1]: Verzeichnis „/opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/build“ wird verlassen
make: *** [Makefile:2300: do-check] Fehler 2
make: Das Ziel „check“ wurde wegen Fehlern nicht aktualisiert.
117378.625u 30818.226s 64:26:11.87 63.8%	0+0k 18164+182959io 230331pf+0w

[ccorn]

Here on Mac OS X 10.5.8 make check ends early after almost 50 GB of core dumps

The ending of make -k check with error 2 after the libatomic tests also happens in the other test logs posted here. That seems to be nothing out of the ordinary. However, even my universal builds leave no more than 2.5 GiB in the build tree.

[ccorn]

I have now analyzed the effects of the four patches proposed with patch-darwin-ppc-2017-01-msg02971.diff.

• Patch 1/4 copies stack alignment changes previously applied to aix.h. This seems to cause 15 additional testsuite failures involving gcc/testsuite/gcc.dg/builtin-apply4.c and gcc/testsuite/gcc.dg/torture/stackalign/builtin-apply-4.c. The failures are related to the builtins around ​__builtin_apply as defined in gcc/builtins.c. I'd leave that patch out.
• Patch 2/4 turns out to be necessary and sufficient for the non-Ada build to succeed. If you want a minimal patchset, stick to that one.
• Patch 3/4 seems reasonable (marking longjmp noreturn), but does not contribute changes to the test summary.
• Patch 4/4 looks reasonable (selecting Darwin thread headers), but is Ada-related, thus irrelevant here.

Attaching the gcc7 testsuite log diff showing the removal of alignment test failures when only patch 2 is used.

Therefore, I recommend to remove patch 1 and keep patch 2. Patch 3 and patch 4 can be left to upstream judgement.

[ccorn]

One more remark to the experimental defaultabi4 and staticlibgcc variants: On my G5 (Darwin 9/PPC), +defaultabi4 does not prevent the previously described crashes (or rather endless unwind loops) of e.g. octave-gui and the botan-linked monotone. I still have to use +staticlibgcc to get those ports running fine.

I have run tests for gcc6 and gcc7 with both variants enabled together. The test results do not differ from those with +staticlibgcc alone. As described earlier, this means 24 more g++ testsuite failures than without +staticlibgcc. (I had entertained the dim hope that +defaultabi4 would make those test failures go away, but alas.) On the other hand I can use monotone and octave-gui again, which is what counts for me.

[ccorn]

A minimal patchset has now been ​incorporated upstream. The next release of the GCC 7 series therefore should no longer need ​our fix.

[kencu (Ken)]

Thanks for all your work on this, Christian!