[PowerPC] Refactor soft-float support, and enable PPC64 soft float
This change enables soft-float for PowerPC64, and also makes
soft-float disable all vector instruction sets for both 32-bit and
64-bit modes. This latter part is necessary because the PPC backend
canonicalizes many Altivec vector types to floating-point types, and
so soft-float breaks scalarization support for many operations. Both
for embedded targets and for operating-system kernels desiring
soft-float support, it seems reasonable that disabling hardware
floating-point also disables vector instructions (embedded targets
without hardware floating point support are unlikely to have Altivec,
etc. and operating system kernels desiring not to use floating-point
registers to lower syscall cost are unlikely to want to use vector
registers either). If someone needs this to work, we'll need to
change the fact that we promote many Altivec operations to act on
v4f32. To make it possible to disable Altivec when soft-float is
enabled, hardware floating-point support needs to be expressed as a
positive feature, like the others, and not a negative feature,
because target features cannot have dependencies on the disabling of
some other feature. So +soft-float has now become -hard-float.
Fixes PR26970.
Pull in r283061 from upstream clang trunk (by Hal Finkel):
[PowerPC] Enable soft-float for PPC64, and +soft-float -> -hard-float
Enable soft-float support on PPC64, as the backend now supports it.
Also, the backend now uses -hard-float instead of +soft-float, so set
the target features accordingly.
Fixes PR26970.
Reported by: Mark Millard
PR: 214433
[PowerPC] Add support for -mlongcall
The "long call" option forces the use of the indirect calling
sequence for all calls (even those that don't really need it). GCC
provides this option; This is helpful, under certain circumstances,
for building very-large binaries, and some other specialized use
cases.
Fixes PR19098.
Pull in r280041 from upstream clang trunk (by Hal Finkel):
[PowerPC] Add support for -mlongcall
Add support for GCC's PowerPC -mlongcall option; the backend supports
the corresponding target feature as of r280040.
Fixes PR19098.
positive diagnostics from -Wvarargs about enum parameters, e.g.:
cddl/contrib/opensolaris/lib/libnvpair/libnvpair.c:388:15: error: passing an object that undergoes default argument promotion to 'va_start' has undefined behavior
[-Werror,-Wvarargs]
va_start(ap, which);
^
cddl/contrib/opensolaris/lib/libnvpair/libnvpair.c:382:66: note: parameter of type 'enum nvlist_prtctl_fmt' is declared here
nvlist_prtctl_dofmt(nvlist_prtctl_t pctl, enum nvlist_prtctl_fmt which, ...)
^
FreeBSD uses LLVM's libunwind on FreeBSD/arm64 today (and we expect to
use it more widely in the future) and it requires the EH frame segment
in static binaries.
Reviewed by: dim
Obtained from: Clang commit r266123
MFC after: 3 days
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D7250
Make __FreeBSD_cc_version predefined macro configurable at build time
The `FreeBSDTargetInfo` class has always set the `__FreeBSD_cc_version`
predefined macro to a rather static value, calculated from the major OS
version.
In the FreeBSD base system, we will start incrementing the value of this
macro whenever we make any signifant change to clang, so we need a way
to configure the macro's value at build time.
Use `FREEBSD_CC_VERSION` for this, which we can define in the FreeBSD
build system using either the `-D` command line option, or an include
file. Stock builds will keep the earlier value.
Differential Revision: http://reviews.llvm.org/D20037
Follow-up commits will start using the __FreeBSD_cc_version to determine
whether a bootstrap compiler has to be built during buildworld.
Pass dwarf-version to cc1as.
Fix PR26999 - crashing in cc1as with any '*bsd' target.
This should fix possible crashes when using -g in combination with
-save-temps.
Fix PR26134: When substituting into default template arguments, keep
CurContext unchanged.
Or, do not set Sema's CurContext to the template declaration's when
substituting into default template arguments of said template
declaration.
If we do push the template declaration context on to Sema, and the
template declaration is at namespace scope, Sema can get confused and
try and do odr analysis when substituting into default template
arguments, even though the substitution could be occurring within a
dependent context.
I'm not sure why this was being done, perhaps there was concern that
if a default template argument referred to a previous template
parameter, it might not be found during substitution - but all
regression tests pass, and I can't craft a test that would cause it
to fails (if some one does, please inform me, and i'll craft a
different fix for the PR).
This patch removes a single line of code, but unfortunately adds more
than it removes, because of the tests. Some day I still hope to
commit a patch that removes far more lines than it adds, while
leaving clang better for it ;)
Sorry that r253590 ("Change the expression evaluation context from
Unevaluated to ConstantEvaluated while substituting into non-type
template argument defaults") caused the PR!
This fix will be merged to the upstream release_38 branch soon, but we
need it now, to fix a failure in the databases/sfcgal port.
