[Qemu-devel] [Bug 1836078] [NEW] Regressions on arm-linux-gnueabihf target with some GCC tests

[Qemu-devel] [Bug 1836078] [NEW] Regressions on arm-linux-gnueabihf target with some GCC tests

[Christophe Lyon]

Public bug reported:

Hi,

After trying qemu master:
commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde
Merge: 68d7ff0 14f5d87
Author: Peter Maydell <email address hidden>
Date: Fri Jun 21 15:40:50 2019 +0100

even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496,
I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite.
I'm attaching a tarball containing several GCC tests (binaries), needed shared libs, and a short script to run all the tests.

All tests used to pass w/o error, but with a recent qemu, all of them
make qemu crash.

This was noticed with GCC master configured with
--target arm-none-linux-gnueabihf
--with-cpu cortex-a57
--with-fpu crypto-neon-fp-armv8

Thanks

** Affects: qemu
     Importance: Undecided
     Assignee: Alex Bennée (ajbennee)
         Status: In Progress


** Tags: arm testcase

** Attachment added: "qemu-4.0-regressions-arm-none-linux-gnueabihf.tar.xz"
   https://bugs.launchpad.net/bugs/1836078/+attachment/5276125/+files/qemu-4.0-regressions-arm-none-linux-gnueabihf.tar.xz

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1836078

Title:
  Regressions on arm-linux-gnueabihf target with some GCC tests

Status in QEMU:
  In Progress

Bug description:
  Hi,

  After trying qemu master:
  commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde
  Merge: 68d7ff0 14f5d87
  Author: Peter Maydell <email address hidden>
  Date: Fri Jun 21 15:40:50 2019 +0100

  even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496,
  I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite.
  I'm attaching a tarball containing several GCC tests (binaries), needed shared libs, and a short script to run all the tests.

  All tests used to pass w/o error, but with a recent qemu, all of them
  make qemu crash.

  This was noticed with GCC master configured with
  --target arm-none-linux-gnueabihf
  --with-cpu cortex-a57
  --with-fpu crypto-neon-fp-armv8

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1836078/+subscriptions

[Qemu-devel] [Bug 1836078] Re: Regressions on arm-linux-gnueabihf target with some GCC tests

[Alex Bennée]

** Tags added: arm testcase

** Changed in: qemu
       Status: New => In Progress

** Changed in: qemu
     Assignee: (unassigned) => Alex Bennée (ajbennee)

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1836078

Title:
  Regressions on arm-linux-gnueabihf target with some GCC tests

Status in QEMU:
  In Progress

Bug description:
  Hi,

  After trying qemu master:
  commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde
  Merge: 68d7ff0 14f5d87
  Author: Peter Maydell <email address hidden>
  Date: Fri Jun 21 15:40:50 2019 +0100

  even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496,
  I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite.
  I'm attaching a tarball containing several GCC tests (binaries), needed shared libs, and a short script to run all the tests.

  All tests used to pass w/o error, but with a recent qemu, all of them
  make qemu crash.

  This was noticed with GCC master configured with
  --target arm-none-linux-gnueabihf
  --with-cpu cortex-a57
  --with-fpu crypto-neon-fp-armv8

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1836078/+subscriptions

[Qemu-devel] [Bug 1836078] Re: Regressions on arm-linux-gnueabihf target with some GCC tests

[Alex Bennée]

I bisected the failure for all but the IEEE6 test to:

commit 602f6e42cfbfe9278be34e9b91d2ceb695837e02
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Thu Feb 28 10:55:16 2019 +0000

    target/arm: Use MVFR1 feature bits to gate A32/T32 FP16 instructions

    Instead of gating the A32/T32 FP16 conversion instructions on
    the ARM_FEATURE_VFP_FP16 flag, switch to our new approach of
    looking at ID register bits. In this case MVFR1 fields FPHP
    and SIMDHP indicate the presence of these insns.

    This change doesn't alter behaviour for any of our CPUs.

    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
    Message-id: 20190222170936.13268-2-peter.maydell@linaro.org

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1836078

Title:
  Regressions on arm-linux-gnueabihf target with some GCC tests

Status in QEMU:
  In Progress

Bug description:
  Hi,

  After trying qemu master:
  commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde
  Merge: 68d7ff0 14f5d87
  Author: Peter Maydell <email address hidden>
  Date: Fri Jun 21 15:40:50 2019 +0100

  even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496,
  I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite.
  I'm attaching a tarball containing several GCC tests (binaries), needed shared libs, and a short script to run all the tests.

  All tests used to pass w/o error, but with a recent qemu, all of them
  make qemu crash.

  This was noticed with GCC master configured with
  --target arm-none-linux-gnueabihf
  --with-cpu cortex-a57
  --with-fpu crypto-neon-fp-armv8

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1836078/+subscriptions

[Qemu-devel] [Bug 1836078] Re: Regressions on arm-linux-gnueabihf target with some GCC tests

[Alex Bennée]

The IEEE6 test comes down to:

commit a15945d98d3a3390c3da344d1b47218e91e49d8b
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Tue Feb 5 16:52:42 2019 +0000

    target/arm: Make FPSCR/FPCR trapped-exception bits RAZ/WI

    The {IOE, DZE, OFE, UFE, IXE, IDE} bits in the FPSCR/FPCR are for
    enabling trapped IEEE floating point exceptions (where IEEE exception
    conditions cause a CPU exception rather than updating the FPSR status
    bits). QEMU doesn't implement this (and nor does the hardware we're
    modelling), but for implementations which don't implement trapped
    exception handling these control bits are supposed to be RAZ/WI.
    This allows guest code to test for whether the feature is present
    by trying to write to the bit and checking whether it sticks.

    QEMU is incorrectly making these bits read as written. Make them
    RAZ/WI as the architecture requires.

    In particular this was causing problems for the NetBSD automatic
    test suite.

    Reported-by: Martin Husemann <martin@netbsd.org>
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
    Message-id: 20190131130700.28392-1-peter.maydell@linaro.org

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1836078

Title:
  Regressions on arm-linux-gnueabihf target with some GCC tests

Status in QEMU:
  In Progress

Bug description:
  Hi,

  After trying qemu master:
  commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde
  Merge: 68d7ff0 14f5d87
  Author: Peter Maydell <email address hidden>
  Date: Fri Jun 21 15:40:50 2019 +0100

  even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496,
  I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite.
  I'm attaching a tarball containing several GCC tests (binaries), needed shared libs, and a short script to run all the tests.

  All tests used to pass w/o error, but with a recent qemu, all of them
  make qemu crash.

  This was noticed with GCC master configured with
  --target arm-none-linux-gnueabihf
  --with-cpu cortex-a57
  --with-fpu crypto-neon-fp-armv8

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1836078/+subscriptions

[Qemu-devel] [Bug 1836078] Re: Regressions on arm-linux-gnueabihf target with some GCC tests

[Alex Bennée]

In the ieee6 test case it is attempting to write OFE, bit [10] which:

    This bit is RW only if the implementation supports the trapping of
floating-point exceptions. In an implementation that does not support
floating-point exception trapping, this bit is RAZ/WI.

    When this bit is RW, it applies only to floating-point operations.
Advanced SIMD operations always use untrapped floating-point exception
handling in AArch32 state

This might be a broken test.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1836078

Title:
  Regressions on arm-linux-gnueabihf target with some GCC tests

Status in QEMU:
  In Progress

Bug description:
  Hi,

  After trying qemu master:
  commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde
  Merge: 68d7ff0 14f5d87
  Author: Peter Maydell <email address hidden>
  Date: Fri Jun 21 15:40:50 2019 +0100

  even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496,
  I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite.
  I'm attaching a tarball containing several GCC tests (binaries), needed shared libs, and a short script to run all the tests.

  All tests used to pass w/o error, but with a recent qemu, all of them
  make qemu crash.

  This was noticed with GCC master configured with
  --target arm-none-linux-gnueabihf
  --with-cpu cortex-a57
  --with-fpu crypto-neon-fp-armv8

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1836078/+subscriptions

[Qemu-devel] [PATCH for 4.1] target/arm: report ARMv8.2 FP16 for ARM -cpu max

[Alex Bennée]

When we converted to using feature bits in 602f6e42cfbf we missed out
the fact (dp && arm_dc_feature(s, ARM_FEATURE_V8)) was supported for
-cpu max configurations. This caused a regression in the GCC test
suite. Fix this by setting the appropriate FP16 bits in mvfr1.FPHP.

Fixes: https://bugs.launchpad.net/qemu/+bug/1836078
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 target/arm/cpu.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index e75a64a25a..0a0a202fe3 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -2452,6 +2452,10 @@ static void arm_max_initfn(Object *obj)
             t = FIELD_DP32(t, ID_ISAR6, SPECRES, 1);
             cpu->isar.id_isar6 = t;
 
+            t = cpu->isar.mvfr1;
+            t = FIELD_DP32(t, MVFR1, FPHP, 2);     /* v8.2 FP16 */
+            cpu->isar.mvfr1 = t;
+
             t = cpu->isar.mvfr2;
             t = FIELD_DP32(t, MVFR2, SIMDMISC, 3); /* SIMD MaxNum */
             t = FIELD_DP32(t, MVFR2, FPMISC, 4);   /* FP MaxNum */
-- 
2.20.1

[Qemu-devel] [Bug 1836078] [PATCH for 4.1] target/arm: report ARMv8.2 FP16 for ARM -cpu max

[Alex Bennée]

When we converted to using feature bits in 602f6e42cfbf we missed out
the fact (dp && arm_dc_feature(s, ARM_FEATURE_V8)) was supported for
-cpu max configurations. This caused a regression in the GCC test
suite. Fix this by setting the appropriate FP16 bits in mvfr1.FPHP.

Fixes: https://bugs.launchpad.net/qemu/+bug/1836078
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 target/arm/cpu.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index e75a64a25a..0a0a202fe3 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -2452,6 +2452,10 @@ static void arm_max_initfn(Object *obj)
             t = FIELD_DP32(t, ID_ISAR6, SPECRES, 1);
             cpu->isar.id_isar6 = t;
 
+            t = cpu->isar.mvfr1;
+            t = FIELD_DP32(t, MVFR1, FPHP, 2);     /* v8.2 FP16 */
+            cpu->isar.mvfr1 = t;
+
             t = cpu->isar.mvfr2;
             t = FIELD_DP32(t, MVFR2, SIMDMISC, 3); /* SIMD MaxNum */
             t = FIELD_DP32(t, MVFR2, FPMISC, 4);   /* FP MaxNum */
-- 
2.20.1

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1836078

Title:
  Regressions on arm-linux-gnueabihf target with some GCC tests

Status in QEMU:
  In Progress

Bug description:
  Hi,

  After trying qemu master:
  commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde
  Merge: 68d7ff0 14f5d87
  Author: Peter Maydell <email address hidden>
  Date: Fri Jun 21 15:40:50 2019 +0100

  even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496,
  I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite.
  I'm attaching a tarball containing several GCC tests (binaries), needed shared libs, and a short script to run all the tests.

  All tests used to pass w/o error, but with a recent qemu, all of them
  make qemu crash.

  This was noticed with GCC master configured with
  --target arm-none-linux-gnueabihf
  --with-cpu cortex-a57
  --with-fpu crypto-neon-fp-armv8

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1836078/+subscriptions

Re: [Qemu-devel] [PATCH for 4.1] target/arm: report ARMv8.2 FP16 for ARM -cpu max

[Richard Henderson]

On 7/10/19 7:24 PM, Alex Bennée wrote:
> When we converted to using feature bits in 602f6e42cfbf we missed out
> the fact (dp && arm_dc_feature(s, ARM_FEATURE_V8)) was supported for
> -cpu max configurations. This caused a regression in the GCC test
> suite. Fix this by setting the appropriate FP16 bits in mvfr1.FPHP.
> 
> Fixes: https://bugs.launchpad.net/qemu/+bug/1836078
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>  target/arm/cpu.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/target/arm/cpu.c b/target/arm/cpu.c
> index e75a64a25a..0a0a202fe3 100644
> --- a/target/arm/cpu.c
> +++ b/target/arm/cpu.c
> @@ -2452,6 +2452,10 @@ static void arm_max_initfn(Object *obj)
>              t = FIELD_DP32(t, ID_ISAR6, SPECRES, 1);
>              cpu->isar.id_isar6 = t;
>  
> +            t = cpu->isar.mvfr1;
> +            t = FIELD_DP32(t, MVFR1, FPHP, 2);     /* v8.2 FP16 */

The comment is wrong.  This is not full v8.2 FP16 support (which would be value
3, plus a change to SIMDHP), but v8.0 support for double<->half conversions.

Otherwise,
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>


r~

Re: [Qemu-devel] [PATCH for 4.1] target/arm: report ARMv8.2 FP16 for ARM -cpu max

[Alex Bennée]

Richard Henderson <richard.henderson@linaro.org> writes:

> On 7/10/19 7:24 PM, Alex Bennée wrote:
>> When we converted to using feature bits in 602f6e42cfbf we missed out
>> the fact (dp && arm_dc_feature(s, ARM_FEATURE_V8)) was supported for
>> -cpu max configurations. This caused a regression in the GCC test
>> suite. Fix this by setting the appropriate FP16 bits in mvfr1.FPHP.
>>
>> Fixes: https://bugs.launchpad.net/qemu/+bug/1836078
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> ---
>>  target/arm/cpu.c | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/target/arm/cpu.c b/target/arm/cpu.c
>> index e75a64a25a..0a0a202fe3 100644
>> --- a/target/arm/cpu.c
>> +++ b/target/arm/cpu.c
>> @@ -2452,6 +2452,10 @@ static void arm_max_initfn(Object *obj)
>>              t = FIELD_DP32(t, ID_ISAR6, SPECRES, 1);
>>              cpu->isar.id_isar6 = t;
>>
>> +            t = cpu->isar.mvfr1;
>> +            t = FIELD_DP32(t, MVFR1, FPHP, 2);     /* v8.2 FP16 */
>
> The comment is wrong.  This is not full v8.2 FP16 support (which would be value
> 3, plus a change to SIMDHP), but v8.0 support for double<->half
> conversions.

Good catch - will fix in v2.
>
> Otherwise,
> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
>
>
> r~


--
Alex Bennée

[Qemu-devel] [Bug 1836078] Re: [PATCH for 4.1] target/arm: report ARMv8.2 FP16 for ARM -cpu max

[Alex Bennée]

Richard Henderson <richard.henderson@linaro.org> writes:

> On 7/10/19 7:24 PM, Alex Bennée wrote:
>> When we converted to using feature bits in 602f6e42cfbf we missed out
>> the fact (dp && arm_dc_feature(s, ARM_FEATURE_V8)) was supported for
>> -cpu max configurations. This caused a regression in the GCC test
>> suite. Fix this by setting the appropriate FP16 bits in mvfr1.FPHP.
>>
>> Fixes: https://bugs.launchpad.net/qemu/+bug/1836078
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> ---
>>  target/arm/cpu.c | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/target/arm/cpu.c b/target/arm/cpu.c
>> index e75a64a25a..0a0a202fe3 100644
>> --- a/target/arm/cpu.c
>> +++ b/target/arm/cpu.c
>> @@ -2452,6 +2452,10 @@ static void arm_max_initfn(Object *obj)
>>              t = FIELD_DP32(t, ID_ISAR6, SPECRES, 1);
>>              cpu->isar.id_isar6 = t;
>>
>> +            t = cpu->isar.mvfr1;
>> +            t = FIELD_DP32(t, MVFR1, FPHP, 2);     /* v8.2 FP16 */
>
> The comment is wrong.  This is not full v8.2 FP16 support (which would be value
> 3, plus a change to SIMDHP), but v8.0 support for double<->half
> conversions.

Good catch - will fix in v2.
>
> Otherwise,
> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
>
>
> r~


--
Alex Bennée

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1836078

Title:
  Regressions on arm-linux-gnueabihf target with some GCC tests

Status in QEMU:
  In Progress

Bug description:
  Hi,

  After trying qemu master:
  commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde
  Merge: 68d7ff0 14f5d87
  Author: Peter Maydell <email address hidden>
  Date: Fri Jun 21 15:40:50 2019 +0100

  even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496,
  I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite.
  I'm attaching a tarball containing several GCC tests (binaries), needed shared libs, and a short script to run all the tests.

  All tests used to pass w/o error, but with a recent qemu, all of them
  make qemu crash.

  This was noticed with GCC master configured with
  --target arm-none-linux-gnueabihf
  --with-cpu cortex-a57
  --with-fpu crypto-neon-fp-armv8

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1836078/+subscriptions

[Qemu-devel] [PATCH v2 for 4.1] target/arm: report ARMv8-A FP support for AArch32 -cpu max

[Alex Bennée]

When we converted to using feature bits in 602f6e42cfbf we missed out
the fact (dp && arm_dc_feature(s, ARM_FEATURE_V8)) was supported for
-cpu max configurations. This caused a regression in the GCC test
suite. Fix this by setting the appropriate bits in mvfr1.FPHP to
report ARMv8-A with FP support (but not ARMv8.2-FP16).

Fixes: https://bugs.launchpad.net/qemu/+bug/1836078
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
---
 target/arm/cpu.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index e75a64a25a..ad164a773b 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -2452,6 +2452,10 @@ static void arm_max_initfn(Object *obj)
             t = FIELD_DP32(t, ID_ISAR6, SPECRES, 1);
             cpu->isar.id_isar6 = t;
 
+            t = cpu->isar.mvfr1;
+            t = FIELD_DP32(t, MVFR1, FPHP, 2);     /* v8.0 FP support */
+            cpu->isar.mvfr1 = t;
+
             t = cpu->isar.mvfr2;
             t = FIELD_DP32(t, MVFR2, SIMDMISC, 3); /* SIMD MaxNum */
             t = FIELD_DP32(t, MVFR2, FPMISC, 4);   /* FP MaxNum */
-- 
2.20.1

[Qemu-devel] [Bug 1836078] [PATCH v2 for 4.1] target/arm: report ARMv8-A FP support for AArch32 -cpu max

[Alex Bennée]

When we converted to using feature bits in 602f6e42cfbf we missed out
the fact (dp && arm_dc_feature(s, ARM_FEATURE_V8)) was supported for
-cpu max configurations. This caused a regression in the GCC test
suite. Fix this by setting the appropriate bits in mvfr1.FPHP to
report ARMv8-A with FP support (but not ARMv8.2-FP16).

Fixes: https://bugs.launchpad.net/qemu/+bug/1836078
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
---
 target/arm/cpu.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index e75a64a25a..ad164a773b 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -2452,6 +2452,10 @@ static void arm_max_initfn(Object *obj)
             t = FIELD_DP32(t, ID_ISAR6, SPECRES, 1);
             cpu->isar.id_isar6 = t;
 
+            t = cpu->isar.mvfr1;
+            t = FIELD_DP32(t, MVFR1, FPHP, 2);     /* v8.0 FP support */
+            cpu->isar.mvfr1 = t;
+
             t = cpu->isar.mvfr2;
             t = FIELD_DP32(t, MVFR2, SIMDMISC, 3); /* SIMD MaxNum */
             t = FIELD_DP32(t, MVFR2, FPMISC, 4);   /* FP MaxNum */
-- 
2.20.1

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1836078

Title:
  Regressions on arm-linux-gnueabihf target with some GCC tests

Status in QEMU:
  In Progress

Bug description:
  Hi,

  After trying qemu master:
  commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde
  Merge: 68d7ff0 14f5d87
  Author: Peter Maydell <email address hidden>
  Date: Fri Jun 21 15:40:50 2019 +0100

  even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496,
  I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite.
  I'm attaching a tarball containing several GCC tests (binaries), needed shared libs, and a short script to run all the tests.

  All tests used to pass w/o error, but with a recent qemu, all of them
  make qemu crash.

  This was noticed with GCC master configured with
  --target arm-none-linux-gnueabihf
  --with-cpu cortex-a57
  --with-fpu crypto-neon-fp-armv8

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1836078/+subscriptions

Re: [Qemu-devel] [PATCH v2 for 4.1] target/arm: report ARMv8-A FP support for AArch32 -cpu max

[Peter Maydell]

On Thu, 11 Jul 2019 at 11:37, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> When we converted to using feature bits in 602f6e42cfbf we missed out
> the fact (dp && arm_dc_feature(s, ARM_FEATURE_V8)) was supported for
> -cpu max configurations. This caused a regression in the GCC test
> suite. Fix this by setting the appropriate bits in mvfr1.FPHP to
> report ARMv8-A with FP support (but not ARMv8.2-FP16).
>
> Fixes: https://bugs.launchpad.net/qemu/+bug/1836078
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
> ---
>  target/arm/cpu.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/target/arm/cpu.c b/target/arm/cpu.c
> index e75a64a25a..ad164a773b 100644
> --- a/target/arm/cpu.c
> +++ b/target/arm/cpu.c
> @@ -2452,6 +2452,10 @@ static void arm_max_initfn(Object *obj)
>              t = FIELD_DP32(t, ID_ISAR6, SPECRES, 1);
>              cpu->isar.id_isar6 = t;
>
> +            t = cpu->isar.mvfr1;
> +            t = FIELD_DP32(t, MVFR1, FPHP, 2);     /* v8.0 FP support */
> +            cpu->isar.mvfr1 = t;
> +
>              t = cpu->isar.mvfr2;
>              t = FIELD_DP32(t, MVFR2, SIMDMISC, 3); /* SIMD MaxNum */
>              t = FIELD_DP32(t, MVFR2, FPMISC, 4);   /* FP MaxNum */
> --
> 2.20.1



Applied to target-arm.next, thanks.

-- PMM

[Qemu-devel] [Bug 1836078] Re: [PATCH v2 for 4.1] target/arm: report ARMv8-A FP support for AArch32 -cpu max

[Peter Maydell]

On Thu, 11 Jul 2019 at 11:37, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> When we converted to using feature bits in 602f6e42cfbf we missed out
> the fact (dp && arm_dc_feature(s, ARM_FEATURE_V8)) was supported for
> -cpu max configurations. This caused a regression in the GCC test
> suite. Fix this by setting the appropriate bits in mvfr1.FPHP to
> report ARMv8-A with FP support (but not ARMv8.2-FP16).
>
> Fixes: https://bugs.launchpad.net/qemu/+bug/1836078
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
> ---
>  target/arm/cpu.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/target/arm/cpu.c b/target/arm/cpu.c
> index e75a64a25a..ad164a773b 100644
> --- a/target/arm/cpu.c
> +++ b/target/arm/cpu.c
> @@ -2452,6 +2452,10 @@ static void arm_max_initfn(Object *obj)
>              t = FIELD_DP32(t, ID_ISAR6, SPECRES, 1);
>              cpu->isar.id_isar6 = t;
>
> +            t = cpu->isar.mvfr1;
> +            t = FIELD_DP32(t, MVFR1, FPHP, 2);     /* v8.0 FP support */
> +            cpu->isar.mvfr1 = t;
> +
>              t = cpu->isar.mvfr2;
>              t = FIELD_DP32(t, MVFR2, SIMDMISC, 3); /* SIMD MaxNum */
>              t = FIELD_DP32(t, MVFR2, FPMISC, 4);   /* FP MaxNum */
> --
> 2.20.1


Applied to target-arm.next, thanks.

-- PMM

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1836078

Title:
  Regressions on arm-linux-gnueabihf target with some GCC tests

Status in QEMU:
  In Progress

Bug description:
  Hi,

  After trying qemu master:
  commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde
  Merge: 68d7ff0 14f5d87
  Author: Peter Maydell <email address hidden>
  Date: Fri Jun 21 15:40:50 2019 +0100

  even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496,
  I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite.
  I'm attaching a tarball containing several GCC tests (binaries), needed shared libs, and a short script to run all the tests.

  All tests used to pass w/o error, but with a recent qemu, all of them
  make qemu crash.

  This was noticed with GCC master configured with
  --target arm-none-linux-gnueabihf
  --with-cpu cortex-a57
  --with-fpu crypto-neon-fp-armv8

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1836078/+subscriptions

[Qemu-devel] [Bug 1836078] Re: Regressions on arm-linux-gnueabihf target with some GCC tests

[Christophe Lyon]

I confirm this patch fixes the problem I reported.
Thanks!

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1836078

Title:
  Regressions on arm-linux-gnueabihf target with some GCC tests

Status in QEMU:
  In Progress

Bug description:
  Hi,

  After trying qemu master:
  commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde
  Merge: 68d7ff0 14f5d87
  Author: Peter Maydell <email address hidden>
  Date: Fri Jun 21 15:40:50 2019 +0100

  even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496,
  I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite.
  I'm attaching a tarball containing several GCC tests (binaries), needed shared libs, and a short script to run all the tests.

  All tests used to pass w/o error, but with a recent qemu, all of them
  make qemu crash.

  This was noticed with GCC master configured with
  --target arm-none-linux-gnueabihf
  --with-cpu cortex-a57
  --with-fpu crypto-neon-fp-armv8

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1836078/+subscriptions

[Qemu-devel] [Bug 1836078] Re: Regressions on arm-linux-gnueabihf target with some GCC tests

[Alex Bennée]

I think the ieee6 test is due to a broken runtime:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314

** Bug watch added: GCC Bugzilla #78314
   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1836078

Title:
  Regressions on arm-linux-gnueabihf target with some GCC tests

Status in QEMU:
  In Progress

Bug description:
  Hi,

  After trying qemu master:
  commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde
  Merge: 68d7ff0 14f5d87
  Author: Peter Maydell <email address hidden>
  Date: Fri Jun 21 15:40:50 2019 +0100

  even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496,
  I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite.
  I'm attaching a tarball containing several GCC tests (binaries), needed shared libs, and a short script to run all the tests.

  All tests used to pass w/o error, but with a recent qemu, all of them
  make qemu crash.

  This was noticed with GCC master configured with
  --target arm-none-linux-gnueabihf
  --with-cpu cortex-a57
  --with-fpu crypto-neon-fp-armv8

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1836078/+subscriptions

[Qemu-devel] [Bug 1836078] Re: Regressions on arm-linux-gnueabihf target with some GCC tests

[Alex Bennée]

** Changed in: qemu
       Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1836078

Title:
  Regressions on arm-linux-gnueabihf target with some GCC tests

Status in QEMU:
  Fix Committed

Bug description:
  Hi,

  After trying qemu master:
  commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde
  Merge: 68d7ff0 14f5d87
  Author: Peter Maydell <email address hidden>
  Date: Fri Jun 21 15:40:50 2019 +0100

  even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496,
  I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite.
  I'm attaching a tarball containing several GCC tests (binaries), needed shared libs, and a short script to run all the tests.

  All tests used to pass w/o error, but with a recent qemu, all of them
  make qemu crash.

  This was noticed with GCC master configured with
  --target arm-none-linux-gnueabihf
  --with-cpu cortex-a57
  --with-fpu crypto-neon-fp-armv8

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1836078/+subscriptions

[Qemu-devel] [Bug 1836078] Re: Regressions on arm-linux-gnueabihf target with some GCC tests

[Thomas Huth]

https://git.qemu.org/?p=qemu.git;a=commitdiff;h=45b1a243b81a7c9ae562

** Changed in: qemu
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1836078

Title:
  Regressions on arm-linux-gnueabihf target with some GCC tests

Status in QEMU:
  Fix Released

Bug description:
  Hi,

  After trying qemu master:
  commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde
  Merge: 68d7ff0 14f5d87
  Author: Peter Maydell <email address hidden>
  Date: Fri Jun 21 15:40:50 2019 +0100

  even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496,
  I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite.
  I'm attaching a tarball containing several GCC tests (binaries), needed shared libs, and a short script to run all the tests.

  All tests used to pass w/o error, but with a recent qemu, all of them
  make qemu crash.

  This was noticed with GCC master configured with
  --target arm-none-linux-gnueabihf
  --with-cpu cortex-a57
  --with-fpu crypto-neon-fp-armv8

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1836078/+subscriptions