Upstream bug submitted as https://llvm.org/pr22997

http://llvm.org/pr22408
Addressed in LLVM here: http://llvm.org/viewvc/llvm-project?rev=231227&view=rev

We should drop this line.

I don't think the an old copyright applies to this file.

aside, SYSCALL_COMPAT seems to be poorly documented in our infrastructure

This file looks like a good candidate for treatment similar to trivial-getcontextx.c. That can happen after committing this though, along with the ones already in libc/arch/{mips,powerpc,powerpc64,sparc,arm}/__vdso_gettc.c

We define it to be variant I in lib/libc/gen/tls.c?

The changes in this file seem like they ought to be committed independently right now.

Remove old copyright from file with no content

this file is new content

It was mostly guess work for me, I should update it based on the above contrib tool.

Do we want to include links link this in comments here, and elsewhere, until the issues are resolved? There's way too much black voo-doo magic in these files anyway...

This is good... NOT. We need something more generic. Falls into the category of "well, one more isn't so bad" until you one more yourself into a list like this...

Another instance of where we need a generic IEEE thing, rather than copies of the IEEE thing...

We should fix the arm version you copied...

This is bogus, unless we have soft floats...

And I'm not sure the copyright applies...

It is a big bucket we put the dead hand of the past into. :)

For new architectures, though, we should look seriously at not supporting this at all. Or at least supporting it only for things from 10.x and up. Most of these compat things are quite old.

The thread stuff is for running on systems < 8.0.

This list is for stuff pre FreeBSD 7! Do we really need it? No.

As much as I hate to suggest it, I'd be inclined to tag aarch64 in src.conf as an arch where SYSCALL_COMPAT should be no.

2014 or 2015? I'd be inclined to go with 2015 across the board for any truly new files since they were all published in 2015 or the second half of 2014 for the first time.

Some of the new files have copyright 2014 you, others have it copyright FF with your name as developed by. What makes some one, and other another?

below you have comments that say it is variant II? Which is it?

#if 1

it seems, no?

Shouldn't this always be defined by the compiler?

That makes sense.

(There's a chance this one will be addressed in the immediate future though.)

Yes, we should run the referenced tool on both 32- and 64-bit arm, and update as necessary.

Would we put it in BROKEN_OPTIONS, and then delete the list here?

Andy did a bunch of arm64 work as a volunteer early on, before joining the overall Foundation-sponsored project.

What would you suggest? If I understand correctly, quad/Makefile.inc should be included for 32-bit archs, other than mips32?

IIRC, we have similar constructs elsewhere in the tree. I think we need to centralize. mipsn32, btw, is a 64-bit API despite its name...

Link should be: http://llvm.org/pr22997

I wasn't able to find an equivalent one in any Makefile* under lib libexec bin sbin usr.bin usr.sbin

extra blank line at EOF

extra blank line at EOF

Addressed by D2175

Addressed by D2175

Oops, commented in the wrong location: not addressed by D2175.

This one is addressed by D2175

Make sure the \ line up.

This is wrong unless we have soft float. It needs to be 0..3 for the current FP mode we're running in.

Maybe it is time to make this !defined(vax)

I think you should just delete this. We don't support FreeBSD 5, 6, or 7 aarch64 images. So compat here isn't needed, and really is counter productive.

They do, just not in this interface

Feel free to fix in head

Just to confirm, this is intentionally reverted, we don't want these bits for arm64?

@imp doesn't like this, but I don't see a straightforward "nicer" way

It's a bit strange - my understanding: the ABI specifies long double is 128-bit quad precision, but there's no hardware support. So long double is soft float, while float/double is hard.

@imp says
This is bogus, unless we have soft floats...

We have hard float for float and double. The ABI specifies long double is 128-bit quad precision, but there is no hardware support, so we have soft float there.

@imp, would we make SYSCAL_COMPAT a BROKEN_OPTIONS for aarch64?

In D2152 I proposed handling this like trivial-getcontextx.c. I see @kostikbel accepted it (I hadn't noticed until just now).

@imp can you confirm this is what you had in mind?

It was committed in https://svnweb.freebsd.org/changeset/base/280993

It needs to return a value depending on the rounding mode, I still need to add the asm to get this.

Fixed in diff 4610

Don't delete this here. It's fine, even if it is broken.

You don't need this.

I'd suggest we put SYSCALL_COMPAT on its own with a comment, since it isn't really "broken" per se, but just not applicable.

# Pre-SYSCALL_COMPAT FreeBSD releases did not support arm64, so the option has no purpose.
BROKEN_OPTIONS+=SYSCALL_COMPAT