On 2024-11-06 19:06, Richard Earnshaw (lists) wrote:
On 06/11/2024 13:50, Torbjorn SVENSSON wrote:
On 2024-11-06 14:04, Richard Earnshaw (lists) wrote:
On 06/11/2024 12:23, Torbjorn SVENSSON wrote:
On 2024-11-06 12:26, Richard Earnshaw (lists) wrote:
On 06/11/2024 07:44, Christophe Lyon wrote:
On Wed, 6 Nov 2024 at 07:20, Torbjörn SVENSSON
<torbjorn.svens...@foss.st.com> wrote:
While the regression was reported on GCC15, I'm sure that same
regression will be seen on GCC14 when it's tested in the
arm-linux-gnueabihf configuration.
Ok for trunk and releases/gcc-14?
--
This fixes reported regression at
https://linaro.atlassian.net/browse/GNU-1407.
gcc/testsuite/ChangeLog:
* gcc.target/arm/pr68620.c: Use effective-target arm_fp.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svens...@foss.st.com>
---
gcc/testsuite/gcc.target/arm/pr68620.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/arm/pr68620.c
b/gcc/testsuite/gcc.target/arm/pr68620.c
index 6e38671752f..1ed84f4ac75 100644
--- a/gcc/testsuite/gcc.target/arm/pr68620.c
+++ b/gcc/testsuite/gcc.target/arm/pr68620.c
@@ -1,8 +1,10 @@
/* { dg-do compile } */
/* { dg-skip-if "-mpure-code supports M-profile without Neon only" { *-*-* } {
"-mpure-code" } } */
/* { dg-require-effective-target arm_arch_v7a_ok } */
-/* { dg-options "-mfp16-format=ieee -mfpu=auto -mfloat-abi=softfp" } */
+/* { dg-require-effective-target arm_fp_ok } */
+/* { dg-options "-mfp16-format=ieee -mfpu=auto" } */
/* { dg-add-options arm_arch_v7a } */
+/* { dg-add-options arm_fp } */
So... this partially reverts your previous patch (bringing back
arm_fp). What is the problem now?
Yeah, that sounds wrong. arm_fp_ok tries to find options to add to the basic
testsuite options, but it can't be combined with arm_arch_v7a as that picks a
totally different set of flags for the architecture.
The problem is that for arm-linux-gnueabihf, we cannot use -mfloat-abi=softfp
as there is no multilib available for that ABI, or at least that's my
interpretation of below error message.
This is the output from the CI run:
Executing on host:
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/armv8l-unknown-linux-gnueabihf/bin/armv8l-unknown-linux-gnueabihf-gcc
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/gcc/testsuite/gcc.target/arm/pr68620.c
-fdiagnostics-plain-output -mfp16-format=ieee -mfpu=auto
-mfloat-abi=softfp -mcpu=unset -march=armv7-a+fp -S -o pr68620.s (timeout = 600)
spawn -ignore SIGHUP
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/armv8l-unknown-linux-gnueabihf/bin/armv8l-unknown-linux-gnueabihf-gcc
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/gcc/testsuite/gcc.target/arm/pr68620.c
-fdiagnostics-plain-output -mfp16-format=ieee -mfpu=auto -mfloat-abi=softfp
-mcpu=unset -march=armv7-a+fp -S -o pr68620.s
In file included from /usr/include/features.h:510,
from
/usr/include/arm-linux-gnueabihf/bits/libc-header-start.h:33,
from /usr/include/stdint.h:26,
from
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/armv8l-unknown-linux-gnueabihf/lib/gcc/armv8l-unknown-linux-gnueabihf/15.0.0/include/stdint.h:11,
from
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/armv8l-unknown-linux-gnueabihf/lib/gcc/armv8l-unknown-linux-gnueabihf/15.0.0/include/arm_fp16.h:34,
from
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/armv8l-unknown-linux-gnueabihf/lib/gcc/armv8l-unknown-linux-gnueabihf/15.0.0/include/arm_neon.h:41,
from
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/gcc/testsuite/gcc.target/arm/pr68620.c:7:
/usr/include/arm-linux-gnueabihf/gnu/stubs.h:7:11: fatal error:
gnu/stubs-soft.h: No such file or directory
compilation terminated.
compiler exited with status 1
output is:
In file included from /usr/include/features.h:510,
from
/usr/include/arm-linux-gnueabihf/bits/libc-header-start.h:33,
from /usr/include/stdint.h:26,
from
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/armv8l-unknown-linux-gnueabihf/lib/gcc/armv8l-unknown-linux-gnueabihf/15.0.0/include/stdint.h:11,
from
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/armv8l-unknown-linux-gnueabihf/lib/gcc/armv8l-unknown-linux-gnueabihf/15.0.0/include/arm_fp16.h:34,
from
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/armv8l-unknown-linux-gnueabihf/lib/gcc/armv8l-unknown-linux-gnueabihf/15.0.0/include/arm_neon.h:41,
from
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/gcc/testsuite/gcc.target/arm/pr68620.c:7:
/usr/include/arm-linux-gnueabihf/gnu/stubs.h:7:11: fatal error:
gnu/stubs-soft.h: No such file or directory
compilation terminated.
comp_output (pruned) is:
In file included from /usr/include/features.h:510,
from
/usr/include/arm-linux-gnueabihf/bits/libc-header-start.h:33,
from /usr/include/stdint.h:26,
from
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/armv8l-unknown-linux-gnueabihf/lib/gcc/armv8l-unknown-linux-gnueabihf/15.0.0/include/stdint.h:11,
from
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/armv8l-unknown-linux-gnueabihf/lib/gcc/armv8l-unknown-linux-gnueabihf/15.0.0/include/arm_fp16.h:34,
from
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/armv8l-unknown-linux-gnueabihf/lib/gcc/armv8l-unknown-linux-gnueabihf/15.0.0/include/arm_neon.h:41,
from
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/gcc/testsuite/gcc.target/arm/pr68620.c:7:
/usr/include/arm-linux-gnueabihf/gnu/stubs.h:7:11: fatal error:
gnu/stubs-soft.h: No such file or directory
compilation terminated.
FAIL: gcc.target/arm/pr68620.c (test for excess errors)
So, if we cannot use arm_fp, what can we use instead to check if it needs
-mfloat-abi=softfp or -mfloat-abi=hard?
Kind regards,
Torbjörn
Ah, got you. Interestingly my ubuntu armhf instalation has booth stubs-soft.h
and stubs-hard.h even though it's a hard-float environment, so I wouldn't see
this error. I'm not sure if that's something ubuntu has fixed, or whether it's
because the tcwg install is slightly non-standard.
Technically this isn't a multilib - because we aren't linking, but I see where
you're coming from. I need to think a bit about this one. What we really need
is some way of checking if stdint.h works in a soft-fp environment; we might
need a new check for this in target-supports.exp.
An alternative is to add an entry in the list that is arm_arch_v7a_softfp and then do
dg-require-effective-target on it, but then it will not be tested for HF only-targets. Is
this a good enough compromise? We could also go the other way and do the "hard"
way, but either way, one of them would not be tested in that case.
Let me know what you think.
It's the same problem in the attr-neon* patch that I have in parallell to this
one, but I'll wait for this one to have a way forward before working more on
that one.
Kind regards,
Torbjörn
I think the attached is probably a better approach here. It tries to find just
the correct ABI flags to add while remaining compatible with the platform.
It's not perfect: the compiler doesn't really support -mfloat-abi=softfp
correctly when generating thumb1 code, but that's a different bug.
I think I'm missing something here.
As far as I can tell, your approach is more or less identical to the
arm_fp_ok check. The only difference is that you are including stdint.h,
while arm_fp_ok checks that __ARM_FP is defined. From my point of view,
they are both a bit flawed here.
Wouldn't it be better to just add the include of stdint.h to arm_fp_ok?
For easier reference, this is the implementation of arm_fp_ok in GCC15:
proc check_effective_target_arm_fp_ok_nocache { } {
global et_arm_fp_flags
set et_arm_fp_flags ""
if { [check_effective_target_arm32] } {
foreach flags {"" "-mfloat-abi=softfp" "-mfloat-abi=hard"} {
if { [check_no_compiler_messages_nocache arm_fp_ok object {
#ifndef __ARM_FP
#error __ARM_FP not defined
#endif
} "$flags"] } {
set et_arm_fp_flags $flags
return 1
}
}
}
return 0
}
When evaluating arm_libc_fp_abi_ok in the pr68620.c test case with your
patch, that's still in the context of what multilib flags that might
have been passed to dejagnu and not in the armv7-a context, right?
To me, it feels like the way we use dg-require-effective-target to check
various flags is not implemented in a way that would allow you to switch
target in a test case. Are we trying to achive something that is not
possible with the current design of the dg- comments?
Kind regards,
Torbjörn
