On 18/11/14 11:30, Mantas Mikaitis wrote:
> Incorrect predefinitions for certain target architectures. E.g. arm7-m
> does not contain NEON but the defintion __ARM_NEON_FP was switched on.
> Similarly with armv6 and even armv2.
>
> This patch fixes the predefines for each of the different chips
> containing certain types of the FPU implementations.
>
> Tests:
>
> Tested on arm-none-linux-gnueabi and arm-none-linux-gnueabihf without
> any new regression.
>
> Manually compiled for various targets and all correct definitions were
> present.
>
> Is this patch ok for trunk?
>
> Mantas
>
> gcc/Changelog:
>
> * config/arm/arm.h (TARGET_NEON_FP): Removed conditional definition,
> define to zero if !TARGET_NEON.
> (TARGET_CPU_CPP_BUILTINS): Added second condition before defining
> __ARM_FP macro.
>
>
> ARM_DEFS.patch
>
>
> diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
> index ff4ddac..325fea9 100644
> --- a/gcc/config/arm/arm.h
> +++ b/gcc/config/arm/arm.h
> @@ -118,7 +118,7 @@ extern char arm_arch_name[];
> if (TARGET_VFP) \
> builtin_define ("__VFP_FP__"); \
> \
> - if (TARGET_ARM_FP) \
> + if (TARGET_ARM_FP && !TARGET_SOFT_FLOAT) \
Wouldn't it be better to factor this into TARGET_ARM_FP? It seems odd
that that macro returns a set of values based on something completely
unavailable for the current compilation. That would also then mirror
the behaviour of TARGET_NEON_FP (see below) and make the internal macros
more consistent.
> builtin_define_with_int_value ( \
> "__ARM_FP", TARGET_ARM_FP); \
> if (arm_fp16_format == ARM_FP16_FORMAT_IEEE) \
> @@ -2350,10 +2350,9 @@ extern int making_const_table;
> /* Set as a bit mask indicating the available widths of floating point
> types for hardware NEON floating point. This is the same as
> TARGET_ARM_FP without the 64-bit bit set. */
> -#ifdef TARGET_NEON
> -#define TARGET_NEON_FP \
> - (TARGET_ARM_FP & (0xff ^ 0x08))
> -#endif
> +#define TARGET_NEON_FP \
> + (TARGET_NEON ? (TARGET_ARM_FP & (0xff ^ 0x08)) \
> + : 0)
>
> /* The maximum number of parallel loads or stores we support in an ldm/stm
> instruction. */
>
R.
