Skip to content

R
riscv-gcc-1
Switch branch/tag
  1. 19 Jun, 2017 1 commit
  3. 18 Jun, 2017 7 commits
  5. 17 Jun, 2017 13 commits
  7. 16 Jun, 2017 19 commits
    • rs6000-c.c (altivec_overloaded_builtins): Add definitions for vec_float,… · be1418c7 
      rs6000-c.c (altivec_overloaded_builtins): Add definitions for vec_float, vec_float2, vec_floato, vec_floate built-ins.

gcc/ChangeLog:

2017-06-16  Carl Love  <cel@us.ibm.com>

	* config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Add
	definitions for vec_float, vec_float2, vec_floato,
	vec_floate built-ins.
	* config/rs6000/vsx.md (define_c_enum "unspec"): Add RTL code
	for instructions vsx_xvcvsxws vsx_xvcvuxwsp, float2, floato and
	floate.
	* config/rs6000/rs6000-builtin.def (FLOAT2_V2DI, FLOATE_V2DF,
	FLOATE_2DI, FLOATO_V2DF, FLOATEE_V2DI, XVCVSXWSP_V4SF,
	UNS_FLOATO_V2DI, UNS_FLOATE_V2DI): Add definitions.
	* config/altivec.md (define_insn "p8_vmrgew_<mode>",
	define_mode_attr VF_sxddp): Add V4SF type to p8_vmrgew.
	* config/rs6000/altivec.h (vec_float, vec_float2, vec_floate,
	vec_floato): Add builtin defines.
	* doc/extend.texi (vec_float, vec_float2, vec_floate, vec_floato):
	Update the built-in documentation file for the new built-in
	functions.

gcc/testsuite/ChangeLog:

2017-06-16  Carl Love  <cel@us.ibm.com>

	* gcc.target/powerpc/builtins-3-runnable.c (test_result_sp,
	main): Add runnable tests and test checker for vec_float,
	vec_float2, vec_floate and vec_floato builtins.

From-SVN: r249311
      Carl Love committed
    • [arm] Fix various tests · e3e266bf 
      
The neon-thumb2-move.c test was overriding the options that had been
detected as being necessary to enable Neon.  The result was that the
combination of the test's options and those auto-detected were not
compatible with neon leading to a test failure.  The correct fix here
is to stick with the options that dg-add-options arm_neon has worked
out.

The thumb2-slow-flash-data tests were relying (incorrectly) on a
particular FPU being enabled by default.  These tests are fixed by
adding +fp to the architecture selected.

	* gcc.target/arm/neon-thumb2-move.c (dg-options): Don't override
	the architecture options added by dg-add-options arm_neon.
	* gcc.target/arm/thumb2-slow-flash-data-2.c (dg-opitions): Add +fp
	to the architecture.
	* gcc.target/arm/thumb3-slow-flash-data-3.c (dg-opitions): Likewise.
	* gcc.target/arm/thumb4-slow-flash-data-3.c (dg-opitions): Likewise.
	* gcc.target/arm/thumb5-slow-flash-data-3.c (dg-opitions): Likewise.

From-SVN: r249310
      Richard Earnshaw committed
    • [arm] Mark -marm and -mthumb as being inverse options · 718a3eab 
      
-marm and -mthumb are opposites: one cancels out the other.  This patch
marks them as such so that the driver will eliminate all but the last
option on the command line.  This aids multilib selection which otherwise
can get confused if both are present.

	* config/arm/arm.opt (marm): Mark as the negative of of -mthumb.
	(mthumb): Mark as the negative of -marm.

From-SVN: r249309
      Richard Earnshaw committed
    • [arm][doc] Document changes to -mcpu, -mtune and -mfpu. · f54133ea 
      
This patch adds the remainder of the main documentation changes.  It
adds the changes for -mcpu, -mtune and -mfpu.  I've chosen to document
the extension options under -mcpu rather than under -mtune because,
while they are permitted with -mtune, they do not affect the behaviour
of the tuning done by the compiler.

I've also inverted the sense of the table (making the primary index
the extension name and then listing the CPU names to which it applies.
This is because the extensions are much more orthoganal in meaning
here and having a primary entry via the CPU name would lead to
enormous duplication.

Finally, it adds the relevant changes to -mfpu.  I haven't stated yet
that any setting of -mfpu other than 'auto' is deprecated, but that is
certainly the long-term goal of this patch series.

	* doc/invoke.texi (ARM Options, -mcpu): Document supported
	extension options.
	(ARM Options, -mtune): Document that this accepts the same
	extension options as -mcpu.
	(ARM Options, -mfpu): Document addition of -mfpu=auto.

From-SVN: r249308
      Richard Earnshaw committed
    • [arm][doc] Document new -march= syntax. · 6d2f99aa 
      
This adds documentation for the new extension options to -march= on ARM.
I tried a number of different ways of formatting the information, but this
seems the best, given what can be achieved in texinfo format.

	* doc/invoke.texi (ARM Options, -march=): Document new syntax and
	permitted extensions.

From-SVN: r249307
      Richard Earnshaw committed
    • [arm] Add a few missing architecture extension options. · ffc12690 
      
Reviewing the list of options for the purposes of writing the
documentation revealed that a small number of options were missing.
Mostly these are aliases for existing options, but in a couple of
cases we lacked the ability to disable certain other options.

	* config/arm/arm-cpus.in (armv7): Add extension +nofp.
	(armv7-r): Add aliases vfpv3xd and vfpv3-d16.
	(armv8-m.main): Add option +nodsp.
	* config/arm/arm-cpu-cdata.h: Regenerated.

From-SVN: r249306
      Richard Earnshaw committed
    • [arm] Rework multilib support · be5c4e06 
      
It looks like the fuchsia port relied on inheriting the multilib rules from
the bare-metal port (the t-arm-elf makefile fragment), but that has now been
rewritten on the assuption that the base architecture is ARMv4t; fuchsia
has a base architecture of ARMv7-a.

To account for this, I've cloned the original t-arm-elf rules into a
new makefile fragment t-fuchsia and arranged for that to be used when
targetting this system.

	* config/arm/t-fuchsia: New file.
	* config.gcc (arm*-*-fuchsia*): Use it.

From-SVN: r249305
      Richard Earnshaw committed
    • [arm] Rework multlib builds for symbianelf · e61a3cdd 
      
Symbianelf used to build multilib for armv5t with softfp, but that
architecture doesn't really support floating point instructions.  This
patch reworks the multilib configuration to use armv5te as the base
when building for floating point.

I'm not sure just how useful the symbian port is these days, so this
has only been very lightly tested (checks that libgcc builds for all
multilib variants).  Perhaps we should consider deprecating this
config?

	* config/arm/t-symbian: Rewrite for new option infrastructure.

From-SVN: r249304
      Richard Earnshaw committed
    • [arm] reset all multilib variables · 99d6bcf7 
      
NB.  This configuration does not build in GCC-7 and doesn't build now either.

This patch resets a couple of multlib variables which previously were
not cleared.

It almost certainly needs further work to make it use the new option
framework correctly, but since the library configurations are already
clearly wrong, it's not clear what the changes need to be.  In
particular it tries to build a hard-float library for ARM7TDMI in both
ARM and thumb modes, but ARMv4t does not support any floating-point
instructions; furthermore, GCC has never supported a hard-float thumb1
library.

	* config/arm/t-phoenix (MULTILIB_REUSE): Clear variable.
	(MULTILIB_REQUIRED): Likewise.

From-SVN: r249303
      Richard Earnshaw committed
    • [arm] Ensure all multilib variables are reset · e1674337 
      
No real change, but for consistency reset all multilib related variables.

	* config/arm/t-linux-eabi (MULTILIB_EXCEPTIONS): Set to empty.
	(MULTILIB_RESUE): Likewise.
	(MULTILIB_MATCHES): Likewise.
	(MULTLIB_REQUIRED): Likewise.

From-SVN: r249302
      Richard Earnshaw committed
    • [arm] Update t-rtems for new option framework · d59ee314 
      
[This patch has only been fairly lightly tested (I've built a compiler
with all the relevant multilibs and smoke-tested a few combinations to
check that the tools still produce a sensible object file).]

This patch updates the RTEMS build to use the new option framework.
It tries as far as possible to keep the existing supported options,
but there are two necessary changes and one cleanup.  I've also
restructed the file slightly to make it slightly easier (IMO) to
understand.

Necessary changes:

1: ARMv4t does not support a hard-float ABI, the earliest supported
architecture with floating-point support is ARMv5te, so I've rebased
the original fpu/hard libraries to that revision of the architecture.

2: Similarly, the earliest version of the -m profile to support
hardware floating-point is armv7e-m (not armv7-m), so the base
architecture for m-profile with FP has been correspondingly updated.

Clean-up:

1: For greater consistency I've changed the
-mcpu=cortex-m7/-mfpu=fpv5-d16/-mhard-float to
-march=armv7e-m+fp.dp/-mhard-float.  The built-in -mcpu rewrite rules
take care of mapping the existing option sets onto the architecture
string to ensure compatibility.

Since the existing rule set does not contain any MULTILIB_REUSE rules,
I have not added any here this time around, but it would be worth the
maintainers of this file considering whether adding some rules would
make their toolchain more friendly to users.

Finally, I've added lines to reset all the multilib variables at the
head of the file.  I found during testing that some definitions from
t-arm-elf were leaking through and causing unexpected behviour.

	* config/arm/t-rtems: Rewrite for new option framework.

From-SVN: r249301
      Richard Earnshaw committed
    • [arm] Rewrite t-rmprofile multilib specification · 42093880 
      
This is the R- & M-profile equivalent of the previous A-profile
multilib rewrite.  Additionally this patch adds some top-level rules
to help find suitable multilibs for general cases when certain
libraries are not built, or when building for legacy cores.

gcc:

	* config/arm/t-aprofile (v7_a_nosimd_variants, v7_a_simd_variants)
	(v7ve_nosimd_variatns, v7ve_vfpv3_simd_variants)
	(v7ve_vfpv4_simd_variants, v8_a_nosimd_variants, v8_a_simd_variants)
	(v8_1_a_simd_variants, v8_2_a_simd_variants): Move to ...
	* config/arm/t-multilib: ... here.
	(MULTILIB_OPTIONS): Add armv7 and armv7+fp architectures.
	(MULTILIB_MATCHES): Use armv7 libraries for armv7-r.  Also use for
	armv7-a and armv8*-a when A-profile libraries have not been built.
	* config/arm/t-rmprofile: Rewrite.

gcc/testsuite:
	* gcc.target/arm/multilib.exp (rmprofile): New tests when rm-profile
	multilibs have been built.

From-SVN: r249300
      Richard Earnshaw committed
    • [arm] Use -march=armv7-a+fp when testing hard-float · c5742a17 
      
Some tests explicitly test with -march=armv7-a and -mfloat-abi=hard.
However, with the new -mfpu=auto code, this architectural specifiction
lacks any floating-point capabilities.  To rectify this, change the
architecture to armv7-a+fp.

gcc/testsuite:

	* gcc.dg/pr59418.c: On ARM, change architecture to armv7-a+fp.
	* gcc.target/arm/pr51915.c: Likewise.
	* gcc.target/arm/pr52006.c: Likewise.
	* gcc.target/arm/pr53187.c: Likewise.

From-SVN: r249299
      Richard Earnshaw committed
    • [arm] Allow explicit periods to be escaped in · fa0b638f 
      
The MULTILIB_REUSE mapping rules are built up using periods to
represent the placement of '=' signs in the command line syntax.  This
presents a problem if the option contains an explicit period because
that is translated unconditionally.  The result is that it is not
currently possible to write a reuse rule that would match the
ARMv8-M mainline architecture:

	-march=armv8-m.main

To fix this, this patch allows an explicit period to be escaped by writing
\. and by then preserving the period into the generated multilib header.

	* genmultilib (multilib_reuse): Allow an explicit period to be escaped
	with a backslash.  Remove the backslash after substituting unescaped
	periods.
	* doc/fragments.texi (MULTILIB_REUSE): Document it.

From-SVN: r249298
      Richard Earnshaw committed
    • [arm] Explicitly set .fpu in cmse_nonsecure_call.S · f0cd49c5 
      
This file is missing a .fpu directive and was relying on the compiler
driver passing through a -mfpu= command line option.  When the FPU is
auto, that will not be passed through correctly, so set something
suitable within the file itself.

libgcc:
	 * config/arm/cmse_nonsecure_call.S: Explicitly set the FPU.

From-SVN: r249297
      Richard Earnshaw committed
    • [arm] Rewrite t-aprofile using new selector methodology · 93aa40fe 
      
Now that the default FPU is 'auto' we can finally rewrite (and
simplify) the rules for mapping compiler options to multilibs.  We
no-longer need to know the specific CPU, since the driver will
construct a suitable -march flag for us; this greatly simplifies the
overall logic.  This patch rewrites the library list for A-profile
cores.  We use various Make extention rules to simplify the logic even
further.

A couple of minor tweaks to the configure script and to the main
driver ensures that we always know the setting of -mfloat-abi and
-marm/-mthumb.  Again, this helps simplify the logic further.  The
change to arm_target_thumb_only relies on the fact that this routine
is only called if neither -marm nor -mthumb has been previously
selected or specified by the user.

A new testsuite module is added to check the libraries generated.  The
new tests are only run if the compiler is configured with the relevant
multilibs enabled.

gcc:
	* config.gcc: (arm*-*-*): When building a-profile libraries, force
	the driver to pass through the default setting of -mfloat-abi.
	* common/config/arm/arm-common.c (arm_target_thumb_only): Return -marm
	rather than NULL.
	* config/arm/t-multilib (MULTILIB_REUSE): Initialize to empty.
	(all_feat_combs): New rule.
	(MULTILIB_OPTIONS): Use explicit ARM and Thumb directories.  Rework
	default libraries.
	* config/arm/t-aprofile: Rewrite.

gcc/testsuite:
	* gcc.target/arm/multilibs.exp: New file.

From-SVN: r249296
      Richard Earnshaw committed
    • [arm] Make 'auto' the default FPU selection option. · 11389610 
      
Finally, we can make 'auto' the default choice for the FPU option.  It's
still possible to override this during configure, but we will eventually
deprecate that, moving to the new cpu/architecture selection mechanism.

	* config/arm/arm.h (FPUTYPE_AUTO): Define.
	* config/arm/arm.c (arm_option_override): Use FPUTYPE_AUTO if the
	fpu is not specified by the user/command-line.
	* config/arm/bpabi.h (FPUTYPE_DEFAULT): Delete.
	* config/arm/netbsd-elf.h (FPUTYPE_DEFAULT): Delete.
	* config/arm/linux-elf.h (FPUTYPE_DEFAULT): Delete.
	* config/arm/vxworks.h (FPUTYPE_DEFAULT): Delete.
	* common/config/arm/arm-common.c (arm_canon_arch_option): Use
	FPUTYPE_AUTO insted of FPUTYPE_DEFAULT.

From-SVN: r249295
      Richard Earnshaw committed
    • [genmultilib] Update basic multilib configuration · aaf8008c 
      
The standard arm-eabi configuration comes with a basic set of multilibs that
are suitable mostly for simple testing of the compiler in various
configurations.  We try to keep the number of libraries build small so
that build times do not become too onerous.

Using the new auto-fp selection code we can now cover all supported
architectures except for those with single-precision only FP units with
just 4 multilibs.  This is done with the rewrite of t-arm-elf.  Now that we
canonicalize -mcpu into suitable -march definitions we don't need to match
CPU names to architectures any more; the driver will do this for us.

I also noticed whilst writing this patch that the existing MULTILIB_DEFAULTS
setting in the compiler was causing more problems than it was worth; and
furthermore was simply wrong if the compiler is ever configured with
--with-mode, --with-float or --with-endian.  The remaining options also
pertained to pre-eabi builds and aren't interesting today either.  It
seemed best to just delete the definition entirely.

	* config/arm/elf.h (MULTILIB_DEFAULTS): Delete.
	* config/arm/t-arm-elf: Rewritten.

From-SVN: r249294
      Richard Earnshaw committed
    • [arm] Make -mfloat-abi=softfp work when there are no · 2e17e319 
      
Before this patch series it wasn't really possible to not have an FPU;
it was always there, even if the hardware didn't really support it.
Now that we have -mfpu=auto, the concept of not having an FPU becomes
real.  Consequently, when the -mfloat-abi switch is set to softfp
doing the Right Thing is much more important.  In this case we have a
soft-float ABI, but can use FP instructions if they are available.
To support this we have to separate out TARGET_HARD_FLOAT into two
use cases: one where the instructions exist and one when they don't.
We preserve the original meaning of TARGET_HARD_FLOAT (but add an extra
check) of meaning that we are generating HW FP instructions, and add a
new macro for the special case when use of FP instructions is permitted,
but might not be available at this time (the distinction is important
because they might be enabled by an attribute during the compilation).
TARGET_SOFT_FLOAT continues to be the exact inverse of TARGET_HARD_FLOAT,
but we now define it as such.

	* config/arm/arm.h (TARGET_HARD_FLOAT): Also check that we
	have some floating-point instructions.
	(TARGET_SOFT_FLOAT): Define as inverse of TARGET_HARD_FLOAT.
	(TARGET_MAYBE_HARD_FLOAT): New macro.
	* config/arm/arm-builtins.c (arm_init_builtins): Use
	TARGET_MAYBE_HARD_FLOAT.
	* config/arm/arm.c (arm_option_override): Use TARGET_HARD_FLOAT_ABI.

From-SVN: r249293
      Richard Earnshaw committed