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

[Christian Bruel <christian dot bruel at st dot com>]

On 01/06/2016 05:23 PM, Kyrill Tkachov wrote:
> 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.

humm, just tried with the command line -mfloat-abi=hard -mcpu=cortex-a57 
-mfpu=neon-fp-armv8 instead of the configure options. don't see this 
error on the new testcases, which one is it ?

> 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.I

I don't know, If we are going from v7 to v8, the __ARM_NEON_FP value 
indeed changes. The question is whether we want to hide this to the user ?

If this is a warning with the test due to a contrived code, not the 
semantic of the macro definition. maybe just add a dg-prune or -Wp,-w in 
the test ?


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