Re: [PATCH, ARM] PR68674 Fix LTO support for neon builtin and error catching (ping)

[Kyrill Tkachov <kyrylo dot tkachov at foss dot arm dot com>]

On 06/01/16 16:04, Kyrill Tkachov wrote:
> Hi Christian,
>
> On 06/01/16 14:02, Christian Bruel wrote:
> > ping/respin https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01095.html.
> >
> > This patch fixes LTO for neon builtins defined with attribute target or in a pragma region.
> > It also fixes a few discrepancies due to the unavailability of the neon builtins and types at function startup. So we now set up the builtins even if not available in the current arch to allow the user to compile different fragments with 
> > target specific attributes. The check is done in arm_expand_builtin.
> >
> > The discussed chunk around arm_vector_mode_supported_p is now obsolete since https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01714.html.
> >
> > I also changed the error messages as suggested by Ramana
> >
> > New regression tests describing the different issues included. Tested with no new failures for arm-sim/\{,-mfpu=vfp,-mfpu=neon}{,-march=armv7-a\}.
>
> In my testing the new testcase gives an error
> about __ARM_NEON_FP being redefined. I think this has something to do with changing the the fpu state
> using the target pragmas.
> The locations it reports as the definition and redefinition of __ARM_NEON_FP is the final pop_options pragma in arm_neon.h
> and the target pragma "neon" in the testcase.

It seems that changing the arm_cpu_builtins code in arm-c.c to do:
  cpp_undef (pfile, "__ARM_NEON_FP");
  if (TARGET_NEON_FP)
    builtin_define_with_int_value ("__ARM_NEON_FP", TARGET_NEON_FP);

instead of:
  if (TARGET_NEON_FP)
    builtin_define_with_int_value ("__ARM_NEON_FP", TARGET_NEON_FP);
  else
    cpp_undef (pfile, "__ARM_NEON_FP");

fixes this. I guess we should be undefing any macros before redefining them.

Kyrill

> My compiler is configured with --with-float=hard --with-cpu=cortex-a57 --with-fpu=neon-fp-armv8.
>
> Any idea?
>
> Thanks,
> Kyrill
>
> > regards,