Progress:
* UM-2 [QEMU upstream maintainership]
- patch-review queue has filled up again; reviewed at least some patches
ready for an arm pullreq
- another KVM Forum PC meeting
* QEMU-530 [QEMU ARMv9.5 Baseline CPU for TCG]
- realized that FEAT_AFP means we need to refactor our FPCR/FPSR
implementation, because it adds new AArch64-only bits that aren't
visible in the AArch32 FPSCR format. (QEMU for historical reasons
implemented FPCR and FPSR as masked views of FPSCR; now we need
to switch to having FPSCR be a view of the FPCR/FPSR data.)
Wrote the necessary refactoring and sent patchseries out for review.
-- PMM
I think we need to revert this.
I got this email from linaro/gcc-regressions:
[Linaro-TCWG-CI] gcc-15-1649-g19f630e6ae8d: FAIL: 2 regressions on aarch64
regressions.sum:
=== gcc tests ===
Running gcc:gcc.misc-tests/gcov.exp ...
FAIL: gcc.misc-tests/gcov-23.c (internal compiler error: in operator[],
at vec.h:910)
FAIL: gcc.misc-tests/gcov-23.c (test for excess errors)
This did not reproduce on my machine, but I took a quick look at the
hash-map implementation. hash_map.put calls
hash_table.find_slot_with_hash, which calls hash_table.expand, which
does move+destroy. auto_vec is not really move-aware which leads to a
double-free.
The fix is either to make auto_vec move-aware (and more like C++'s
std::vector) or revert this patch and apply the original version with an
explicit release.
OK?
Thanks,
Jørgen
On 6/25/24 12:23, Jan Hubicka wrote:
>> The value vec objects are destroyed on exit, but release still needs to
>> be called explicitly.
>>
>> gcc/ChangeLog:
>>
>> * tree-profile.cc (find_conditions): Release vectors before
>> return.
> I wonder if you turn
> hash_map<int_hash<unsigned, 0>, vec<basic_block>> exprs;
> to
> hash_map<int_hash<unsigned, 0>, auto_vec<basic_block>> exprs;
> Won't hash_map destructor take care of this by itself?
>
> Honza
>> ---
>> gcc/tree-profile.cc | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc
>> index e4bb689cef5..18f48e8d04e 100644
>> --- a/gcc/tree-profile.cc
>> +++ b/gcc/tree-profile.cc
>> @@ -919,6 +919,9 @@ find_conditions (struct function *fn)
>> if (!have_post_dom)
>> free_dominance_info (fn, CDI_POST_DOMINATORS);
>>
>> + for (auto expr : exprs)
>> + expr.second.release ();
>> +
>> cov->m_masks.safe_grow_cleared (2 * cov->m_index.last ());
>> const size_t length = cov_length (cov);
>> for (size_t i = 0; i != length; i++)
>> --
>> 2.39.2
>>
Hi,
I am looking into these regressions.
Regards,
Surya
On 26/06/24 7:51 am, ci_notify(a)linaro.org wrote:
> Dear contributor, our automatic CI has detected problems related to your patch(es). Please find some details below. If you have any questions, please follow up on linaro-toolchain(a)lists.linaro.org mailing list, Libera's #linaro-tcwg channel, or ping your favourite Linaro toolchain developer on the usual project channel.
>
> We appreciate that it might be difficult to find the necessary logs or reproduce the issue locally. If you can't get what you need from our CI within minutes, let us know and we will be happy to help.
>
> We track this report status in https://linaro.atlassian.net/browse/GNU-1270 , please let us know if you are looking at the problem and/or when you have a fix.
>
> In gcc_check master-aarch64 after:
>
> | commit gcc-15-1619-g3b9b8d6cfdf5
> | Author: Surya Kumari Jangala <jskumari(a)linux.ibm.com>
> | Date: Tue Jun 25 08:37:49 2024 -0500
> |
> | ira: Scale save/restore costs of callee save registers with block frequency
> |
> | In assign_hard_reg(), when computing the costs of the hard registers, the
> | cost of saving/restoring a callee-save hard register in prolog/epilog is
> | taken into consideration. However, this cost is not scaled with the entry
> | block frequency. Without scaling, the cost of saving/restoring is quite
> | small and this can result in a callee-save register being chosen by
> | ... 14 lines of the commit log omitted.
>
> FAIL: 4 regressions
>
> regressions.sum:
> === g++ tests ===
>
> Running g++:g++.target/aarch64/sve/acle/aarch64-sve-acle.exp ...
> FAIL: gcc.target/aarch64/sve/acle/general/cpy_1.c -march=armv8.2-a+sve -moverride=tune=none check-function-bodies dup_x0_m
> === gcc tests ===
>
> Running gcc:gcc.dg/dg.exp ...
> FAIL: gcc.dg/pr10474.c scan-rtl-dump pro_and_epilogue "Performing shrink-wrapping"
>
> Running gcc:gcc.target/aarch64/sve/acle/aarch64-sve-acle.exp ...
> ... and 5 more entries
>
> You can find the failure logs in *.log.1.xz files in
> - https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-build/2235/artifac…
> The full lists of regressions and progressions as well as configure and make commands are in
> - https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-build/2235/artifac…
> The list of [ignored] baseline and flaky failures are in
> - https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-build/2235/artifac…
>
> The configuration of this build is:
> CI config tcwg_gcc_check master-aarch64
>
> -----------------8<--------------------------8<--------------------------8<--------------------------
> The information below can be used to reproduce a debug environment:
>
> Current build : https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-build/2235/artifac…
> Reference build : https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-build/2234/artifac…
>
> Reproduce last good and first bad builds: https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/gcc/sh…
>
> Full commit : https://github.com/gcc-mirror/gcc/commit/3b9b8d6cfdf59337f4b7ce10ce92a98044…
>
> List of configurations that regressed due to this commit :
> * tcwg_gcc_check
> ** master-aarch64
> *** FAIL: 4 regressions
> *** https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/gcc/sh…
> *** https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-build/2235/artifac…
Hi Matthias,
Looking at [1], we are seeing this error only for bare-metal 32-bit ARM target, which, I believe, is not a configuration that compiler explorer supports. The specific configurations are either soft-float, or target ARM cores without NEON (aka no SIMD FPU).
Maybe the test should be guarded on the target supporting vectorization? I.e., maybe add
// { dg-require-effective-target vect_int }
?
[1] https://linaro.atlassian.net/browse/GNU-1265
--
Maxim Kuvyrkov
https://www.linaro.org
> On Jun 21, 2024, at 19:03, Matthias Kretz via Gcc-regression <gcc-regression(a)gcc.gnu.org> wrote:
>
> Hi,
>
> I looked into this and still don't understand how to reproduce it.
>
> The issue as logged in libstdc++.log is a call from
> find_last_set(simd_mask<int, _VecBuiltin<16>>) to
> _MaskImplNeonMixin::_S_to_bits, which calls vpadd_s32 with two
> [[gnu::vector_size(8)]] int arguments. The CI compiler complains "error:
> cannot convert '__vector(2) int' to 'int32x2_t'".
>
> Why is that an error on your side and not on any compiler I have at hand?
>
> https://compiler-explorer.com/z/88WhcM7Kb not an error here.
>
> In any case, the new test only exposes an existing issue in the <experimental/
> simd> implementation (or its interaction with some variants of GCC?). The
> change did not introduce a new bug to libstdc++.
>
> Best,
> Matthias
>
>
> On Friday, 21 June 2024 17:00:23 GMT+2 ci_notify(a)linaro.org wrote:
>> Dear contributor, our automatic CI has detected problems related to your
>> patch(es). Please find some details below. If you have any questions,
>> please follow up on linaro-toolchain(a)lists.linaro.org mailing list,
>> Libera's #linaro-tcwg channel, or ping your favourite Linaro toolchain
>> developer on the usual project channel.
>>
>> We appreciate that it might be difficult to find the necessary logs or
>> reproduce the issue locally. If you can't get what you need from our CI
>> within minutes, let us know and we will be happy to help.
>>
>> We track this report status in https://linaro.atlassian.net/browse/GNU-1265
>> , please let us know if you are looking at the problem and/or when you have
>> a fix.
>> In arm-eabi v7-a softfp after:
>> | commit gcc-15-1500-g1340ddea015
>> | Author: Matthias Kretz <m.kretz(a)gsi.de>
>> | Date: Fri Jun 14 15:11:25 2024 +0200
>> |
>> | libstdc++: Fix find_last_set(simd_mask) to ignore padding bits
>> |
>> | With the change to the AVX512 find_last_set implementation, the
>> | change
>> | to AVX512 operator!= is unnecessary. However, the latter was not
>> | producing optimal code and unnecessarily set the padding bits. In
>> | theory, the compiler could determine that with the new !=
>> | implementation, the bit operation for clearing the padding bits is a
>> |
>> | ... 13 lines of the commit log omitted.
>>
>> FAIL: 2 regressions
>>
>> regressions.sum:
>> === libstdc++ tests ===
>>
>> Running libstdc++:libstdc++-dg/conformance.exp ...
>> FAIL: experimental/simd/pr115454_find_last_set.cc -mfpu=neon -ffast-math -O2
>> -Wno-psabi (test for excess errors) UNRESOLVED:
>> experimental/simd/pr115454_find_last_set.cc -mfpu=neon -ffast-math -O2
>> -Wno-psabi compilation failed to produce executable
>>
>>
>> You can find the failure logs in *.log.1.xz files in
>> -
>> https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-arm_v7a_softfp_e
>> abi-build/512/artifact/artifacts/00-sumfiles/ The full lists of regressions
>> and progressions as well as configure and make commands are in -
>> https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-arm_v7a_softfp_e
>> abi-build/512/artifact/artifacts/notify/ The list of [ignored] baseline and
>> flaky failures are in
>> -
>> https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-arm_v7a_softfp_e
>> abi-build/512/artifact/artifacts/sumfiles/xfails.xfail
>>
>> The configuration of this build is:
>> CI config tcwg_gnu_embed_check_gcc arm-eabi -marm -march=armv7-a
>> -mfpu=vfpv3-d16 -mfloat-abi=softfp
>>
>> -----------------8<--------------------------8<--------------------------8<-
>> ------------------------- The information below can be used to reproduce a
>> debug environment:
>>
>> Current build :
>> https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-arm_v7a_softfp_e
>> abi-build/512/artifact/artifacts Reference build :
>> https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-arm_v7a_softfp_e
>> abi-build/511/artifact/artifacts
>>
>> Reproduce last good and first bad builds:
>> https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/gcc/sh
>> a1/1340ddea0158de3f49aeb75b4013e5fc313ff6f4/tcwg_gnu_embed_check_gcc/master-
>> arm_v7a_softfp_eabi/reproduction_instructions.txt
>>
>> Full commit :
>> https://github.com/gcc-mirror/gcc/commit/1340ddea0158de3f49aeb75b4013e5fc31
>> 3ff6f4
>>
>> List of configurations that regressed due to this commit :
>> * tcwg_gnu_embed_check_gcc
>> ** master-arm_v7a_softfp_eabi
>> *** FAIL: 2 regressions
>> ***
>> https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/gcc/sh
>> a1/1340ddea0158de3f49aeb75b4013e5fc313ff6f4/tcwg_gnu_embed_check_gcc/master-
>> arm_v7a_softfp_eabi/details.txt ***
>> https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-arm_v7a_softfp_e
>> abi-build/512/artifact/artifacts
>
>
> --
> ──────────────────────────────────────────────────────────────────────────
> Dr. Matthias Kretz https://mattkretz.github.io
> GSI Helmholtz Center for Heavy Ion Research https://gsi.de
> std::simd
> ──────────────────────────────────────────────────────────────────────────
Progress:
* UM-2 [QEMU upstream maintainership]
+ code review and target-arm pullreq
+ Coverity gardening: triage of new issues; update of component definitions
+ respin of "allow a second UART in virt machine" patchset from last year
+ KVM Forum programme committee work
-- PMM
Hello Linaro Toolchain Working Group,
clang-arm64-windows-msvc cannot checkout LLVM because of this error:
fatal: Unable to create
'C:/Users/tcwg/llvm-worker/clang-arm64-windows-msvc/llvm/.git/index.lock':
File exists.
Looks like it needs some love and care. Could you look at this, please?
Thanks
Galina