Created attachment 179503[details]
First version of a proposed patch
Let's hope this goes easier (and faster) than the update from GCC 4.8
to 4.9, with fewer broken ports out there, so that we can finally be
on a version of GCC that is before EOL again. :-)

Created attachment 179572[details]
Slightly revised version of the proposed patch (adding LANG_GCC_IS and adjust to cleanups to lang/gcc* ports)
(In reply to Antoine Brodin from comment #1)
> Update of LANG_GCC_IS is missing?
Yes, of course! Good eyes, Antoine. I had this hunch something was missing,
but could not realize what it was...

I am unsure if we still use libstdc++ but it may cause trouble on FreeBSD-10 starting with GCC5 since the old clang in base won't support support the new abi thing. My guess the exp-run is especially important on FreeBSD 10.x.
This said, why not jump directly to GCC6 instead of GCC5?

(In reply to Pedro F. Giffuni from comment #3)
> This said, why not jump directly to GCC6 instead of GCC5?
In my experience every GCC update runs into a number of broken ports
(usually software not compliant with C or C++ standards or those
"cleverly" using -Werror and then triggering new warnings).
While going from 4.9 to 6 would not double that number over going to 6,
I guess it would be at least 50% or more above. (See the dependencies in
PR 196712 for how much pain that last update was.)

Hmm, not much bustage thanks to DragonFly dogfooding GCC 5 before us.
(In reply to Pedro F. Giffuni from comment #3)
> why not jump directly to GCC6 instead of GCC5?
Why not GCC 7? exp-runs are slow and often contain false positives. Having more results at once would speed up fixing similar issues en masse using portmgr hatchet^W blanket, a win in the long run. If there're many misoptimizations or compiler crashes we can backtrack to GCC 6 or just temporarily pin those few ports to an older version.
(In reply to Gerald Pfeifer from comment #4)
> I guess it would be at least 50% or more above. (See the dependencies in
> PR 196712 for how much pain that last update was.)
Still peanuts compared to Clang/libc++ updates. ;)

(In reply to Jan Beich (mail not working) from comment #17)
> Hmm, not much bustage thanks to DragonFly dogfooding GCC 5 before us.
:).
> (In reply to Pedro F. Giffuni from comment #3)
>> why not jump directly to GCC6 instead of GCC5?
>
> Why not GCC 7? exp-runs are slow and often contain false positives. Having more
> results at once would speed up fixing similar issues en masse using portmgr
> hatchet^W blanket, a win in the long run. If there're many misoptimizations or
> compiler crashes we can backtrack to GCC 6 or just temporarily pin those few
> ports to an older version.
GCC version bumps are not fun so yes, it would be nicer to be a step ahead.
IMO, the criteria is that GCC 6 is the latest supported version.
GCC 7 is likely to be unstable enough upstream won't do any claims.

(In reply to commit-hook from comment #21)
> New revision: 433484
> URL: https://svnweb.freebsd.org/changeset/ports/433484
>
> Log:
> lang/gprolog: pass -O3 to unbreak with gcc5
That's a little surprising. Usually I would have expected this to be
fixed with a _lower_ optimization level (so -O1), not a higher, more
aggressive one.

(In reply to Jan Beich (mail not working) from comment #17)
> Why not GCC 7?
GCC 7 is still in development and its first release (GCC 7.1) is still
a few months out.
> exp-runs are slow and often contain false positives. Having more results
> at once would speed up fixing similar issues en masse using portmgr
> hatchet^W blanket, a win in the long run. If there're many misoptimizations
> or compiler crashes we can backtrack to GCC 6 or just temporarily pin those
> few ports to an older version.
You've done a great job fixing ports, even while this exp-run still has been
going on. Without that, things would look quite differently. THANK YOU!
Looking how close we are towards being ready for the update to GCC 5, versus
what https://gcc.gnu.org/gcc-6/porting_to.html describes in terms of changes,
I really prefer to go for the update "really soon now" as opposed to possibly
having to wait quite a bit longer. At least we'd then be on a version of GCC
that's not been EOLed.
If you are open to help again, I'd prepare an update to GCC 6 relatively
soon after the update to GCC 5 has gone in.

(In reply to Gerald Pfeifer from comment #22)
> Usually I would have expected this to be fixed with a _lower_ optimization level (so -O1),
Both -O1 and -O3 fix the hang but -O2 even manages to crash lang/gcc6 on i386.
gplc -c -C '-O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc6 -fno-strict-aliasing' machine.c
machine.c: In function 'Pl_M_Absolute_Path_Name':
machine.c:763:1: internal compiler error: Segmentation fault
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
compilation failed
(In reply to Gerald Pfeifer from comment #23)
> If you are open to help again, I'd prepare an update to GCC 6 relatively
> soon after the update to GCC 5 has gone in.
Yep, CC me. I'd like to drop bug 193528 workarounds and USE_GCC=yes ports unblocked on aarch64 once 6.3.1 is out.

(In reply to Antoine Brodin from comment #26)
>{"origin"=>"devel/hs-ncurses", "pkgname"=>"hs-ncurses-0.2.15", "phase"=>"build", "errortype"=>"???"}
FreeBSD Haskell team is unresponsive for about a year. Its IRC channel is silent and there is no activity in GitHub repo.
I think that this problem can be fixed by switching default compiler to base clang, but that would probably require another exp-run.

(In reply to Gerald Pfeifer from comment #22)
We've known about gprolog freezing for a long time now. I was excited to see the -O3 fix. Alas, it does not work for DragonFly's base gcc 5.4.1. It's still locking up in the same place.
I was also surprised -O3 would be the silver bullet.

It's probably out of scope, but shells/ksh93 doesn't build with gcc5 either. Since USE_GCC isn't set for this port, nobody sees it.
We see this error if gcc5 is used:
mamake: *** exit code 1 making lib/libast
So it fails to build libast which results in a linking failure much later.
Basically FYI - in theory ports gcc should be able to build most ports but I can understand if nobody wants to investigate further.

(In reply to 6yearold from comment #27)
"I think that this problem can be fixed by switching default compiler to base clang, but that would probably require another exp-run."
On what technical basis are recommending a change to base clang?
Secondly, between 400 and 500 ports are involved here, and exactly 1 doesn't build with gcc5. Switching the compiler base for a single port seems like a drastic first step to me.

(In reply to John Marino from comment #28)
To follow up, the dports framework was adding -O2 after this flag was set, changing it back to -O2 again. I adjusted the framework so that wouldn't happen, and now gprolog builds on DF with -O3.
I still don't really understand why, but I'll take it.

(In reply to John Marino from comment #30)
> On what technical basis are recommending a change to base clang?
I did some research and found that it has nothing to do with C compiler used. I put details into the relevant PR.
Would I be in position to decide such things, I'd remove all Haskell development packages from ports altogether and would only left lang/ghc and various haskell applications like stack and xmonad. Our current ports mostly duplicate work done on Haskell ecosystem side. I really doubt that when someone develop using Haskell on FreeBSD, he would really use ports instead of Haskell "native" tools like Cabal and Stack. But this is irrelevant to this PR anyways.

(In reply to 6yearold from comment #35)
Your proposal needs to include all CPAN, rubygems, and python ports that fall into the same category, then, no?
Nudge the Haskell team. They might be quiet but they are still around. My guess is they didn't set USE_GCC on a lark.

(In reply to John Marino from comment #36)
> Your proposal needs to include all CPAN, rubygems, and python ports that fall into the same category, then, no?
I can't say for these languages, as I haven't used them.
When Haskell ports were starting, Haskell package ecosystem was in such state, that you would quickly get into dependencies hell if you install packages globally (read /usr/local). Haskell ports were solving this problem by providing subset of all Haskell packages that are guaranteed to work together. But now
a) Haskell package manager has "sandbox" feature that allows to easily prepare whatever environment you need.
b) There is ports-like project that releases package sets with known-to-work-together versions.
So now ports are complete duplication of this work.
> Nudge the Haskell team. They might be quiet but they are still around.
Last post on maillist was October 2015. Last commit in the development repo was on February 2016. IRC channel is silent for 6 months. Even when the team was active, it was only pgj@, so there isn't a team even.

(In reply to Antoine Brodin from comment #40)
> Do not forget to copy files/patch-libc++ from gcc5 to fix the build
> with libc++ 4.0, and maybe the patch for aarch64 support too.
Yep, files/patch-libc++ has been in my local tree for two months
(exactly two months). :-)
As for aarch64, I plan on taking care of that very quickly after
the original commit. (It's not a regression, but will be a nice
addition.)

A commit references this bug:
Author: gerald
Date: Sat Apr 1 15:03:22 UTC 2017
New revision: 437437
URL: https://svnweb.freebsd.org/changeset/ports/437437
Log:
Update lang/gcc and hence the default version of GCC in the Ports
Collection (requested by USE_GCC=yes and various USES=compiler
invocations) from GCC 4.9.4 to GCC 5.4.
files/patch-arm-support and files/patch-gcc_system.h have become
obsolete. New patches files/patch-arm-unwind-cxx-support and
files/patch-libc++ help support arm targets and new libc++ in base.
ONLY_FOR_ARCHS now also includes arm.
A new option GRAPHITE_DESC, off by default for now, adds support for
Graphite loop optimizations.
Finally, conflicts with other lang/gcc* ports are adjusted suitably.
In terms of changes for users, this upgrade brings the following:
The default mode for C is now -std=gnu11 instead of -std=gnu89.
New warning options -Wc90-c99-compat and -Wc99-c11-compat may
prove useful on that front.
The C++ front end now has full C++14 language support including
C++14 variable templates, C++14 aggregates with non-static data
member initializers, C++14 extended constexpr, and more.
The Standard C++ Library (libstdc++) has full C++11 support and
experimental full C++14 support. It uses a new ABI by default.
There have been significant improvements to inter-procedural optimizations
and link-time optimization such as One Definition Rule based merging of C++
types as well as register allocation.
OpenMP 4.0 specification offloading features are now supported by the C,
C++, and Fortran compilers. Cilk Plus, an extension to the C and C++
languages to support data and task parallelism, has been added as well.
New warning options -Wswitch-bool, -Wlogical-not-parentheses,
-Wbool-compare and -Wsizeof-array-argument may prove useful as
may new preprocessor directives __has_include, __has_include_next,
and __has_attribute.
GCC can now be built as a shared library for embedding in other processes
(such as interpreters), suitable for Just-In-Time compilation to machine
code. This provides a C API and a C++ wrapper API.
Many code generation improvements for AArch64, ARM, support for
AVX-512{BW,DQ,VL,IFMA,VBMI} and Intel MPX on x86-64, and generally
improvements on many targets.
The Local Register Allocator (LRA) now contains a rematerialization
subpass and is able to reuse the PIC hard register on x86/x86-64 to
improve performance of position independent code.
https://gcc.gnu.org/gcc-5/changes.html has a more extensive set of
changes and https://gcc.gnu.org/gcc-5/porting_to.html has a solid
overview of issue you may encountering porting to this new version.
PR: 216707, 218125
Tested by: antoine (-exp runs)
Supported by: jbeich, tcberner, and others
Changes:
head/Mk/bsd.default-versions.mk
head/lang/gcc/Makefile
head/lang/gcc/distinfo
head/lang/gcc/files/patch-arm-support
head/lang/gcc/files/patch-arm-unwind-cxx-support
head/lang/gcc/files/patch-gcc_system.h
head/lang/gcc/files/patch-libc++
head/lang/gcc/pkg-descr
head/lang/gcc/pkg-plist
head/lang/gcc49/Makefile
head/lang/gcc5/Makefile
head/lang/gcc5-devel/Makefile

No objections including this in the quarterly branch, though given the
large number of dependent ports (cf. the next commit) may this be a little
intrusive/risky?
I am not planning to do this myself, though; if for no other reason, then
shortage of time.

(In reply to Jan Beich from comment #51)
> Gerald, can you file a bug for lang/gcc 5.4.0 -> 6.3.0 update? If there's
> no there's nothing to fix which postpones the update indefinitely.
I absolutely will, Jan.
It's just that there is another change to the lang/gcc* port(s) I am
planning that'll need an -exp run first, or I would have already started
the GCC 5 -> 6 upgrade.
Based on your request and the utter lack of _any_ negative feedback on
the update to GCC 5 (yeah!) I expedited this intermediary step and created
PR 218330 for an -exp run.