future of sparc64 (was: Making C++11 a hard requirement for FreeBSD)

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

future of sparc64 (was: Making C++11 a hard requirement for FreeBSD)

Mark Linimon-2
On Thu, Oct 05, 2017 at 07:12:28PM -0500, A. Wilcox wrote:
> That doesn't change the fact that sparc64 still exists, and with Oracle
> laying off Solaris as well, FreeBSD becomes a "way out" for people
> heavily invested (DC full of sparc64 gear, or such).

I have thought for some time that we've been a "way out" for Solaris
sites wanting to keep ZFS and not deal with licensing issues, and have
worked to keep sparc64 alive.  (AFAIK FreeBSD is the only open source
sparc64/zfs solution?)

But here's the current problem.

All gccs > 4.9 fail to build.  Looking at the logs AFAICT the failure
is a floating-point exception as soon as the first built binary is run
during the internal testing.

Neither Marcel nor Gerald nor I have any insight on how to fix this.
Gerald does state that those gccs build on other OSes, so this is almost
certainly a FreBSD problem.

The default ports compiler has recently moved to gcc5 and then again
to gcc6.  The only reason gcc49 still exists in the Ports Collection is
specifically for sparc64 ports.

Recent llvms do not build.  I have no insight into that failure, either.

So, the long and short is, even with using gcc4.2.1 as an external
compiler, over time, fewer and fewer ports build as they adapt to the
newer compilers.

This is something I don't have the cycles to fix.  Unless someone else
can step up and fix the compilers, we're close to the end of feasibility.

In the meantime, I'll keep running package builds with gcc4.9 as long as
it produces some kind of useful results.

I'll be happy to discuss the build status of individual ports, but let's
have that on sparc64@ rather than arch@, please.

mcl
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: future of sparc64 (was: Making C++11 a hard requirement for FreeBSD)

Bruce Evans-4
On Mon, 9 Oct 2017, Peter Jeremy wrote:

> On 2017-Oct-07 19:06:29 +0000, "K. Macy" <[hidden email]> wrote:
>> My recollection of sparc64 from sun4v work was that unsupported operations
>> would trap in to the kernel which would in turn trap in to a user space
>> handler for floating point emulation.
>
> Yes.  I did some poking at that some time ago.  The userland package is
> basically a complete single/double/quad precision IEEE FP implementation
> (see /usr/src/lib/libc/sparc64/fpu).  I have a test suite for it but it
> hasn't been committed and I'd need to check if it's developed any bitrot.

No, the trap method is almost never used by default, and should never be
used since it is so slow.

sparc64 on the 1 sparc64 system that used to be in the FreeBSD cluster
uses soft-float for long doubles by default (this is the gcc default)
since "hardware" (actually usuallly or always emulated by trap handlers)
for long doubles is so slow.  Something like 6000 times slower for
"hard" (trapping) long doubles on old sparc64 vs not so old x86 (with
x86 clock speed about 6 times higher, and better pipelining).
Soft-float for long doubles is only about 4000 times slower.  Real
hard-float for doubles and floats is only about 20 times slower (much
the same as for integers).

The only advantage of "hard" float on sparc64 is that it is easier to
debug, provided the bug is not in the trap handlers when it is harder
to debug.

Soft-float has more chance of working on sparc64 since it is needed in
some cases.  The flag for the case where it is needed is -msoft-quad-float.
On x86, clang is too broken to even refuse to support -msoft-float -- clang
silently ignores this flag, so this flag non longer works in kern.mk where
it is supposed to stop the compiler using an FPU in the kernel.  gcc-4.2.1
only has this bug on amd64.  The i387 happens not to be used anyway in code
without float variables.  SSE is more generally useful so the -mno-sse*
flags to prevent using it are more needed.

Bruce
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: future of sparc64

Kurt Lidl-2
In reply to this post by Mark Linimon-2
On 10/7/17 1:41 PM, Mark Linimon wrote:

> On Thu, Oct 05, 2017 at 07:12:28PM -0500, A. Wilcox wrote:
>> That doesn't change the fact that sparc64 still exists, and with Oracle
>> laying off Solaris as well, FreeBSD becomes a "way out" for people
>> heavily invested (DC full of sparc64 gear, or such).
>
> I have thought for some time that we've been a "way out" for Solaris
> sites wanting to keep ZFS and not deal with licensing issues, and have
> worked to keep sparc64 alive.  (AFAIK FreeBSD is the only open source
> sparc64/zfs solution?)
>
> But here's the current problem.
>
> All gccs > 4.9 fail to build.  Looking at the logs AFAICT the failure
> is a floating-point exception as soon as the first built binary is run
> during the internal testing.

I built gcc 6.0.4 (natively) on a sparc64 stable/11 a week ago.

I built the stable/11 kernel with that compiler (it required a one-line
change to the kernel sources), and have been running that on my sparc64
stable/11 gateway since I got it compiled.

The pkg'd binary for gcc 6.0.4 is here:

http://pkg.pix.net/FreeBSD:11:sparc64/gcc6-6.4.0_1.txz

-Kurt
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: future of sparc64

Kurt Lidl-2
On 10/9/17 5:32 PM, Kurt Lidl wrote:

> On 10/7/17 1:41 PM, Mark Linimon wrote:
>> On Thu, Oct 05, 2017 at 07:12:28PM -0500, A. Wilcox wrote:
>>> That doesn't change the fact that sparc64 still exists, and with Oracle
>>> laying off Solaris as well, FreeBSD becomes a "way out" for people
>>> heavily invested (DC full of sparc64 gear, or such).
>>
>> I have thought for some time that we've been a "way out" for Solaris
>> sites wanting to keep ZFS and not deal with licensing issues, and have
>> worked to keep sparc64 alive.  (AFAIK FreeBSD is the only open source
>> sparc64/zfs solution?)
>>
>> But here's the current problem.
>>
>> All gccs > 4.9 fail to build.  Looking at the logs AFAICT the failure
>> is a floating-point exception as soon as the first built binary is run
>> during the internal testing.
>
> I built gcc 6.0.4 (natively) on a sparc64 stable/11 a week ago.
>
> I built the stable/11 kernel with that compiler (it required a one-line
> change to the kernel sources), and have been running that on my sparc64
> stable/11 gateway since I got it compiled.
>
> The pkg'd binary for gcc 6.0.4 is here:
>
> http://pkg.pix.net/FreeBSD:11:sparc64/gcc6-6.4.0_1.txz
>
> -Kurt

As was pointed out, it was version 6.4.0, not 6.0.4.

Anyway - the link is correct.

-Kurt

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: future of sparc64

Mark Linimon-2
In reply to this post by Kurt Lidl-2
On Mon, Oct 09, 2017 at 05:32:54PM -0400, Kurt Lidl wrote:
> I built gcc 6.0.4 (natively) on a sparc64 stable/11 a week ago.

I guess I'm confused then.  It definitely fails on:

    FreeBSD 11.0-BETA4 Fri Aug 5 2016 [hidden email]

(I never updated it to 11.0R because I didn't think anything significant
changed between them.)

I'll try spinning up another machine when I finish my current road trip.

mcl
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: future of sparc64

Bill Sorenson
I've been able to get GCC 5 and 6 to build as well. I had to build 4.9, use
that to build 5 with a full bootstrap disabled and then use that to build
itself once more. There is definitely something wrong there.



On Mon, Oct 9, 2017 at 8:52 PM, Mark Linimon <[hidden email]> wrote:

> On Mon, Oct 09, 2017 at 05:32:54PM -0400, Kurt Lidl wrote:
> > I built gcc 6.0.4 (natively) on a sparc64 stable/11 a week ago.
>
> I guess I'm confused then.  It definitely fails on:
>
>     FreeBSD 11.0-BETA4 Fri Aug 5 2016 [hidden email]
>
> (I never updated it to 11.0R because I didn't think anything significant
> changed between them.)
>
> I'll try spinning up another machine when I finish my current road trip.
>
> mcl
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
> To unsubscribe, send any mail to "[hidden email]"
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: future of sparc64 (was: Making C++11 a hard requirement for FreeBSD)

Marius Strobl-2
In reply to this post by Mark Linimon-2
On Sat, Oct 07, 2017 at 12:41:24PM -0500, Mark Linimon wrote:
>
> All gccs > 4.9 fail to build.  Looking at the logs AFAICT the failure
> is a floating-point exception as soon as the first built binary is run
> during the internal testing.

The most plausible cause for that is executables and/or dynamic libraries
not installing the user trap handlers as specified by the libc 64 psABI,
i. e. not call __sparc_utrap_setup(). Do the ports GCCs use their own CRT
nowadays? Do they no longer link libc last? Please provide their linker
invocation. Also, please provide the backtrace of a minimal program
exhibiting that problem.

Marius

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
To unsubscribe, send any mail to "[hidden email]"