On 06/01/16 17:13, Christian Bruel wrote:
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 ?
The full command line for me is:
arm-none-eabi-gcc -fno-diagnostics-show-caret -fdiagnostics-color=never -flto
-mfloat-abi=hard -c -specs=aprofile-validation.specs -Wa,-mno-warn-deprecated
-o c_lto_pr65837-attr_0.o pr65837-attr_0.c
But, as I said, I have it configured in the way I mentioned earlier.
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 ?
Well, the user explicitly changed the fpu level with the pragma in the
testcase, which rightly has the effect of
changing the value of some predefines. I don't think warning is appropriate
here, as long as the predefine
has the right value in the right pragma scope.
Thanks,
Kyrill
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,
