- linaro-toolchain - lists.linaro.org

Re: [PATCH v2] ARM: Block predication on atomics [PR111235]

by Ramana Radhakrishnan

+ linaro-toolchain as I don't understand the CI issues on patchwork. On Wed, Sep 27, 2023 at 8:40 PM Wilco Dijkstra <Wilco.Dijkstra(a)arm.com> wrote: > > Hi Ramana, > > > Hope this helps. > > Yes definitely! > > >> Passes regress/bootstrap, OK for commit? > > > > Target ? armhf ? --with-arch , -with-fpu , -with-float parameters ? > > Please be specific. > > I used --target=arm-none-linux-gnueabihf --host=arm-none-linux-gnueabihf > --build=arm-none-linux-gnueabihf --with-float=hard. However it seems that the > default armhf settings are incorrect. I shouldn't need the --with-float=hard since > that is obviously implied by armhf, and they should also imply armv7-a with vfpv3 > according to documentation. It seems to get confused and skip some tests. I tried > using --with-fpu=auto, but that doesn't work at all, so in the end I forced it like: > --with-arch=armv8-a --with-fpu=neon-fp-armv8. With this it runs a few more tests. Yeah that's a wart that I don't like. armhf just implies the hard float ABI and came into being to help distinguish from the Base PCS for some of the distros at the time (2010s). However we didn't want to set a baseline arch at that time given the imminent arrival of v8-a and thus the specification of --with-arch , --with-fpu and --with-float became second nature to many of us working on it at that time. I can see how it can be confusing. With the advent of fpu=auto , I thought this could be made better but that is a matter for another patch and another discussion. However until then do remember to baseline to --with-arch , --with-fpu and --with-float . Unfortunate but needed. If there is a bug with --with-fpu=auto , good to articulate it as I understand that to be the state of the art. Thank you for working through it. > > > Since these patterns touch armv8m.baseline can you find all the > > testcases in the testsuite and ensure no change in code for > > armv8m.baseline as that's unpredicated already and this patch brings > > this in line with the same ? Does the testsuite already cover these > > arch variants and are you satisfied that the tests in the testsuite > > can catch / don't make any additional code changes to the other > > architectures affected by this ? > > There are various v8-m(.base/.main) tests and they all pass. The generated > code is generally unchanged if there was no conditional execution. I made > the new UNSPEC_LDR/STR patterns support offsets so there is no difference > in generated code for relaxed loads/stores (since they used to use a plain > load/store which has an immediate offset). > > >> * onfig/arm/sync.md (arm_atomic_load<mode>): Add new pattern. > > > > Nit: s/onfig/config > > Fixed. Thanks > > >> (atomic_load<mode>): Always expand atomic loads explicitly. > >> (atomic_store<mode>): Always expand atomic stores explicitly. > > > > Nit: Change message to : > > Switch patterns to define_expand. > > Fixed. Thanks. > > > Largely looks ok though I cannot work out tonight if we need more v8-a > > or v8m-baseline specific tests for scan-assembler patterns. > > > > Clearly our testsuite doesn't catch it , so perhaps the OP could help > > validate this patch with their formal models to see if this fixes > > these set of issues and creates no new regressions ? Is that feasible > > to do ? > > Disabling conditional execution avoids the issue. It's trivial to verify that > atomics can no longer be conditionally executed (no "%?"). When this is > committed, we can run the random testing again to confirm the issue > is no longer present. Ok, thanks for promising to do so - I trust you to get it done. Please try out various combinations of -march v7ve, v7-a , v8-a with the tool as each of them have slightly different rules. For instance v7ve allows LDREXD and STREXD to be single copy atomic for 64 bit loads whereas v7-a did not . > > > -(define_insn "atomic_load<mode>" > > - [(set (match_operand:QHSI 0 "register_operand" "=r,r,l") > > +(define_insn "arm_atomic_load<mode>" > > + [(set (match_operand:QHSI 0 "register_operand" "=r,l") > > (unspec_volatile:QHSI > > - [(match_operand:QHSI 1 "arm_sync_memory_operand" "Q,Q,Q") > > - (match_operand:SI 2 "const_int_operand" "n,Pf,n")] ;; model > > + [(match_operand:QHSI 1 "memory_operand" "m,m")] > > > > Remind me again why is it safe to go from the Q constraint to the m > > constraint here and everywhere else you've done this ? > > That's because the relaxed loads/stores use LDR/STR wrapped in an > UNSPEC. To avoid regressions we have to use 'm' so that an immediate > offset can be merged into the memory access. This is because the instructions used here are ldr and str and the use of the 'm' constraint is considered safe. > > >> - VUNSPEC_LDA ; Represent a store-register-acquire. > >> + VUNSPEC_LDR ; Represent a load-register-relaxed. > >> + VUNSPEC_LDA ; Represent a load-register-acquire. > > > > Nit: LDA before LDR ? Though I suspect this list can be alphabetically > > ordered at another point of time. > > Swapped. Thanks > > > There are new tests added for v7-a , what happens with the output for > > v8-a and the changes for ldacq and other such instructions ? > > v7-a and v8-a generate the same instructions for relaxed load/store. > The acquire/release versions are identical except they are no longer > predicated. Basically the new patterns are not only significantly simpler, > they are now the same between the many ARM/Thumb-2/v7-a/v8-m/v8-a > combinations, so test coverage is much higher now. This is how these > patterns should have been designed all along. > > v2 follows below. > > Cheers, > Wilco > > > [PATCH v2] ARM: Block predication on atomics [PR111235] > > The v7 memory ordering model allows reordering of conditional atomic > instructions. To avoid this, make all atomic patterns unconditional. > Expand atomic loads and stores for all architectures so the memory access > can be wrapped into an UNSPEC. > > gcc/ChangeLog/ > PR target/111235 > * config/arm/constraints.md: Remove Pf constraint. > * config/arm/sync.md (arm_atomic_load<mode>): Add new pattern. > (arm_atomic_load_acquire<mode>): Likewise. > (arm_atomic_store<mode>): Likewise. > (arm_atomic_store_release<mode>): Likewise. > (atomic_load<mode>): Switch patterns to define_expand. > (atomic_store<mode>): Likewise. > (arm_atomic_loaddi2_ldrd): Remove predication. > (arm_load_exclusive<mode>): Likewise. > (arm_load_acquire_exclusive<mode>): Likewise. > (arm_load_exclusivesi): Likewise. > (arm_load_acquire_exclusivesi: Likewise. > (arm_load_exclusivedi): Likewise. > (arm_load_acquire_exclusivedi): Likewise. > (arm_store_exclusive<mode>): Likewise. > (arm_store_release_exclusivedi): Likewise. > (arm_store_release_exclusive<mode>): Likewise. > * gcc/config/arm/unspecs.md: Add VUNSPEC_LDR and VUNSPEC_STR. > > gcc/testsuite/ChangeLog/ > PR target/111235 > * gcc.dg/rtl/arm/stl-cond.c: Remove test. > * gcc.target/arm/atomic_loaddi_7.c: Fix dmb count. > * gcc.target/arm/atomic_loaddi_8.c: Likewise. > * gcc.target/arm/pr111235.c: Add new test. > > --- > > diff --git a/gcc/config/arm/constraints.md b/gcc/config/arm/constraints.md > index 05a4ebbdd67601d7b92aa44a619d17634cc69f17..d7c4a1b0cd785f276862048005e6cfa57cdcb20d 100644 > --- a/gcc/config/arm/constraints.md > +++ b/gcc/config/arm/constraints.md > @@ -36,7 +36,7 @@ > ;; in Thumb-1 state: Pa, Pb, Pc, Pd, Pe > ;; in Thumb-2 state: Ha, Pj, PJ, Ps, Pt, Pu, Pv, Pw, Px, Py, Pz, Rd, Rf, Rb, Ra, > ;; Rg, Ri > -;; in all states: Pf, Pg > +;; in all states: Pg > > ;; The following memory constraints have been used: > ;; in ARM/Thumb-2 state: Uh, Ut, Uv, Uy, Un, Um, Us, Up, Uf, Ux, Ul > @@ -239,13 +239,6 @@ (define_constraint "Pe" > (and (match_code "const_int") > (match_test "TARGET_THUMB1 && ival >= 256 && ival <= 510"))) > > -(define_constraint "Pf" > - "Memory models except relaxed, consume or release ones." > - (and (match_code "const_int") > - (match_test "!is_mm_relaxed (memmodel_from_int (ival)) > - && !is_mm_consume (memmodel_from_int (ival)) > - && !is_mm_release (memmodel_from_int (ival))"))) > - > (define_constraint "Pg" > "@internal In Thumb-2 state a constant in range 1 to 32" > (and (match_code "const_int") > diff --git a/gcc/config/arm/sync.md b/gcc/config/arm/sync.md > index 7626bf3c443285dc63b4c4367b11a879a99c93c6..2210810f67f37ce043b8fdc73b4f21b54c5b1912 100644 > --- a/gcc/config/arm/sync.md > +++ b/gcc/config/arm/sync.md > @@ -62,68 +62,110 @@ (define_insn "*memory_barrier" > (set_attr "conds" "unconditional") > (set_attr "predicable" "no")]) > > -(define_insn "atomic_load<mode>" > - [(set (match_operand:QHSI 0 "register_operand" "=r,r,l") > +(define_insn "arm_atomic_load<mode>" > + [(set (match_operand:QHSI 0 "register_operand" "=r,l") > (unspec_volatile:QHSI > - [(match_operand:QHSI 1 "arm_sync_memory_operand" "Q,Q,Q") > - (match_operand:SI 2 "const_int_operand" "n,Pf,n")] ;; model > + [(match_operand:QHSI 1 "memory_operand" "m,m")] > + VUNSPEC_LDR))] > + "" > + "ldr<sync_sfx>\t%0, %1" > + [(set_attr "arch" "32,any")]) > + > +(define_insn "arm_atomic_load_acquire<mode>" > + [(set (match_operand:QHSI 0 "register_operand" "=r") > + (unspec_volatile:QHSI > + [(match_operand:QHSI 1 "arm_sync_memory_operand" "Q")] > VUNSPEC_LDA))] > "TARGET_HAVE_LDACQ" > - { > - if (aarch_mm_needs_acquire (operands[2])) > - { > - if (TARGET_THUMB1) > - return "lda<sync_sfx>\t%0, %1"; > - else > - return "lda<sync_sfx>%?\t%0, %1"; > - } > - else > - { > - if (TARGET_THUMB1) > - return "ldr<sync_sfx>\t%0, %1"; > - else > - return "ldr<sync_sfx>%?\t%0, %1"; > - } > - } > - [(set_attr "arch" "32,v8mb,any") > - (set_attr "predicable" "yes")]) > + "lda<sync_sfx>\t%0, %C1" > +) > > -(define_insn "atomic_store<mode>" > - [(set (match_operand:QHSI 0 "memory_operand" "=Q,Q,Q") > +(define_insn "arm_atomic_store<mode>" > + [(set (match_operand:QHSI 0 "memory_operand" "=m,m") > + (unspec_volatile:QHSI > + [(match_operand:QHSI 1 "register_operand" "r,l")] > + VUNSPEC_STR))] > + "" > + "str<sync_sfx>\t%1, %0"; > + [(set_attr "arch" "32,any")]) > + > +(define_insn "arm_atomic_store_release<mode>" > + [(set (match_operand:QHSI 0 "arm_sync_memory_operand" "=Q") > (unspec_volatile:QHSI > - [(match_operand:QHSI 1 "general_operand" "r,r,l") > - (match_operand:SI 2 "const_int_operand" "n,Pf,n")] ;; model > + [(match_operand:QHSI 1 "register_operand" "r")] > VUNSPEC_STL))] > "TARGET_HAVE_LDACQ" > - { > - if (aarch_mm_needs_release (operands[2])) > - { > - if (TARGET_THUMB1) > - return "stl<sync_sfx>\t%1, %0"; > - else > - return "stl<sync_sfx>%?\t%1, %0"; > - } > - else > - { > - if (TARGET_THUMB1) > - return "str<sync_sfx>\t%1, %0"; > - else > - return "str<sync_sfx>%?\t%1, %0"; > - } > - } > - [(set_attr "arch" "32,v8mb,any") > - (set_attr "predicable" "yes")]) > + "stl<sync_sfx>\t%1, %C0") > + > + > +(define_expand "atomic_load<mode>" > + [(match_operand:QHSI 0 "register_operand") ;; val out > + (match_operand:QHSI 1 "arm_sync_memory_operand") ;; memory > + (match_operand:SI 2 "const_int_operand")] ;; model > + "" > +{ > + memmodel model = memmodel_from_int (INTVAL (operands[2])); > + > + if (TARGET_HAVE_LDACQ && !is_mm_relaxed (model)) > + { > + emit_insn (gen_arm_atomic_load_acquire<mode> (operands[0], operands[1])); > + DONE; > + } > + > + /* The seq_cst model needs a barrier before the load to block reordering with > + earlier accesses. */ > + if (is_mm_seq_cst (model)) > + expand_mem_thread_fence (model); > + > + emit_insn (gen_arm_atomic_load<mode> (operands[0], operands[1])); > + > + /* All non-relaxed models need a barrier after the load when load-acquire > + instructions are not available. */ > + if (!is_mm_relaxed (model)) > + expand_mem_thread_fence (model); > + > + DONE; > +}) > + > +(define_expand "atomic_store<mode>" > + [(match_operand:QHSI 0 "arm_sync_memory_operand") ;; memory > + (match_operand:QHSI 1 "register_operand") ;; store value > + (match_operand:SI 2 "const_int_operand")] ;; model > + "" > +{ > + memmodel model = memmodel_from_int (INTVAL (operands[2])); > + > + if (TARGET_HAVE_LDACQ && !is_mm_relaxed (model)) > + { > + emit_insn (gen_arm_atomic_store_release<mode> (operands[0], operands[1])); > + DONE; > + } > + > + /* All non-relaxed models need a barrier after the load when load-acquire > + instructions are not available. */ > + if (!is_mm_relaxed (model)) > + expand_mem_thread_fence (model); > + > + emit_insn (gen_arm_atomic_store<mode> (operands[0], operands[1])); > + > + /* The seq_cst model needs a barrier after the store to block reordering with > + later accesses. */ > + if (is_mm_seq_cst (model)) > + expand_mem_thread_fence (model); > + > + DONE; > +}) > > ;; An LDRD instruction usable by the atomic_loaddi expander on LPAE targets > > (define_insn "arm_atomic_loaddi2_ldrd" > [(set (match_operand:DI 0 "register_operand" "=r") > (unspec_volatile:DI > - [(match_operand:DI 1 "arm_sync_memory_operand" "Q")] > + [(match_operand:DI 1 "memory_operand" "m")] > VUNSPEC_LDRD_ATOMIC))] > "ARM_DOUBLEWORD_ALIGN && TARGET_HAVE_LPAE" > - "ldrd%?\t%0, %H0, %C1" > - [(set_attr "predicable" "yes")]) > + "ldrd\t%0, %H0, %1" > +) > > ;; There are three ways to expand this depending on the architecture > ;; features available. As for the barriers, a load needs a barrier > @@ -152,6 +194,11 @@ (define_expand "atomic_loaddi" > DONE; > } > > + /* The seq_cst model needs a barrier before the load to block reordering with > + earlier accesses. */ > + if (is_mm_seq_cst (model)) > + expand_mem_thread_fence (model); > + > /* On LPAE targets LDRD and STRD accesses to 64-bit aligned > locations are 64-bit single-copy atomic. We still need barriers in the > appropriate places to implement the ordering constraints. */ > @@ -160,7 +207,6 @@ (define_expand "atomic_loaddi" > else > emit_insn (gen_arm_load_exclusivedi (operands[0], operands[1])); > > - > /* All non-relaxed models need a barrier after the load when load-acquire > instructions are not available. */ > if (!is_mm_relaxed (model)) > @@ -446,54 +492,42 @@ (define_insn_and_split "atomic_nand_fetch<mode>" > [(set_attr "arch" "32,v8mb")]) > > (define_insn "arm_load_exclusive<mode>" > - [(set (match_operand:SI 0 "s_register_operand" "=r,r") > + [(set (match_operand:SI 0 "s_register_operand" "=r") > (zero_extend:SI > (unspec_volatile:NARROW > - [(match_operand:NARROW 1 "mem_noofs_operand" "Ua,Ua")] > + [(match_operand:NARROW 1 "mem_noofs_operand" "Ua")] > VUNSPEC_LL)))] > "TARGET_HAVE_LDREXBH" > - "@ > - ldrex<sync_sfx>%?\t%0, %C1 > - ldrex<sync_sfx>\t%0, %C1" > - [(set_attr "arch" "32,v8mb") > - (set_attr "predicable" "yes")]) > + "ldrex<sync_sfx>\t%0, %C1" > +) > > (define_insn "arm_load_acquire_exclusive<mode>" > - [(set (match_operand:SI 0 "s_register_operand" "=r,r") > + [(set (match_operand:SI 0 "s_register_operand" "=r") > (zero_extend:SI > (unspec_volatile:NARROW > - [(match_operand:NARROW 1 "mem_noofs_operand" "Ua,Ua")] > + [(match_operand:NARROW 1 "mem_noofs_operand" "Ua")] > VUNSPEC_LAX)))] > "TARGET_HAVE_LDACQ" > - "@ > - ldaex<sync_sfx>%?\\t%0, %C1 > - ldaex<sync_sfx>\\t%0, %C1" > - [(set_attr "arch" "32,v8mb") > - (set_attr "predicable" "yes")]) > + "ldaex<sync_sfx>\\t%0, %C1" > +) > > (define_insn "arm_load_exclusivesi" > - [(set (match_operand:SI 0 "s_register_operand" "=r,r") > + [(set (match_operand:SI 0 "s_register_operand" "=r") > (unspec_volatile:SI > - [(match_operand:SI 1 "mem_noofs_operand" "Ua,Ua")] > + [(match_operand:SI 1 "mem_noofs_operand" "Ua")] > VUNSPEC_LL))] > "TARGET_HAVE_LDREX" > - "@ > - ldrex%?\t%0, %C1 > - ldrex\t%0, %C1" > - [(set_attr "arch" "32,v8mb") > - (set_attr "predicable" "yes")]) > + "ldrex\t%0, %C1" > +) > > (define_insn "arm_load_acquire_exclusivesi" > - [(set (match_operand:SI 0 "s_register_operand" "=r,r") > + [(set (match_operand:SI 0 "s_register_operand" "=r") > (unspec_volatile:SI > - [(match_operand:SI 1 "mem_noofs_operand" "Ua,Ua")] > + [(match_operand:SI 1 "mem_noofs_operand" "Ua")] > VUNSPEC_LAX))] > "TARGET_HAVE_LDACQ" > - "@ > - ldaex%?\t%0, %C1 > - ldaex\t%0, %C1" > - [(set_attr "arch" "32,v8mb") > - (set_attr "predicable" "yes")]) > + "ldaex\t%0, %C1" > +) > > (define_insn "arm_load_exclusivedi" > [(set (match_operand:DI 0 "s_register_operand" "=r") > @@ -501,8 +535,8 @@ (define_insn "arm_load_exclusivedi" > [(match_operand:DI 1 "mem_noofs_operand" "Ua")] > VUNSPEC_LL))] > "TARGET_HAVE_LDREXD" > - "ldrexd%?\t%0, %H0, %C1" > - [(set_attr "predicable" "yes")]) > + "ldrexd\t%0, %H0, %C1" > +) > > (define_insn "arm_load_acquire_exclusivedi" > [(set (match_operand:DI 0 "s_register_operand" "=r") > @@ -510,8 +544,8 @@ (define_insn "arm_load_acquire_exclusivedi" > [(match_operand:DI 1 "mem_noofs_operand" "Ua")] > VUNSPEC_LAX))] > "TARGET_HAVE_LDACQEXD && ARM_DOUBLEWORD_ALIGN" > - "ldaexd%?\t%0, %H0, %C1" > - [(set_attr "predicable" "yes")]) > + "ldaexd\t%0, %H0, %C1" > +) > > (define_insn "arm_store_exclusive<mode>" > [(set (match_operand:SI 0 "s_register_operand" "=&r") > @@ -530,14 +564,11 @@ (define_insn "arm_store_exclusive<mode>" > Note that the 1st register always gets the > lowest word in memory. */ > gcc_assert ((REGNO (operands[2]) & 1) == 0 || TARGET_THUMB2); > - return "strexd%?\t%0, %2, %H2, %C1"; > + return "strexd\t%0, %2, %H2, %C1"; > } > - if (TARGET_THUMB1) > - return "strex<sync_sfx>\t%0, %2, %C1"; > - else > - return "strex<sync_sfx>%?\t%0, %2, %C1"; > + return "strex<sync_sfx>\t%0, %2, %C1"; > } > - [(set_attr "predicable" "yes")]) > +) > > (define_insn "arm_store_release_exclusivedi" > [(set (match_operand:SI 0 "s_register_operand" "=&r") > @@ -550,20 +581,16 @@ (define_insn "arm_store_release_exclusivedi" > { > /* See comment in arm_store_exclusive<mode> above. */ > gcc_assert ((REGNO (operands[2]) & 1) == 0 || TARGET_THUMB2); > - return "stlexd%?\t%0, %2, %H2, %C1"; > + return "stlexd\t%0, %2, %H2, %C1"; > } > - [(set_attr "predicable" "yes")]) > +) > > (define_insn "arm_store_release_exclusive<mode>" > - [(set (match_operand:SI 0 "s_register_operand" "=&r,&r") > + [(set (match_operand:SI 0 "s_register_operand" "=&r") > (unspec_volatile:SI [(const_int 0)] VUNSPEC_SLX)) > - (set (match_operand:QHSI 1 "mem_noofs_operand" "=Ua,Ua") > + (set (match_operand:QHSI 1 "mem_noofs_operand" "=Ua") > (unspec_volatile:QHSI > - [(match_operand:QHSI 2 "s_register_operand" "r,r")] > + [(match_operand:QHSI 2 "s_register_operand" "r")] > VUNSPEC_SLX))] > "TARGET_HAVE_LDACQ" > - "@ > - stlex<sync_sfx>%?\t%0, %2, %C1 > - stlex<sync_sfx>\t%0, %2, %C1" > - [(set_attr "arch" "32,v8mb") > - (set_attr "predicable" "yes")]) > + "stlex<sync_sfx>\t%0, %2, %C1") > diff --git a/gcc/config/arm/unspecs.md b/gcc/config/arm/unspecs.md > index 6a5b1f8f623b00dc014c9f829c591477f8faa9a1..4713ec840abae48ca70f418dbc0d4028ad4ad527 100644 > --- a/gcc/config/arm/unspecs.md > +++ b/gcc/config/arm/unspecs.md > @@ -221,8 +221,10 @@ (define_c_enum "unspecv" [ > VUNSPEC_SC ; Represent a store-register-exclusive. > VUNSPEC_LAX ; Represent a load-register-acquire-exclusive. > VUNSPEC_SLX ; Represent a store-register-release-exclusive. > - VUNSPEC_LDA ; Represent a store-register-acquire. > + VUNSPEC_LDA ; Represent a load-register-acquire. > + VUNSPEC_LDR ; Represent a load-register-relaxed. > VUNSPEC_STL ; Represent a store-register-release. > + VUNSPEC_STR ; Represent a store-register-relaxed. > VUNSPEC_GET_FPSCR ; Represent fetch of FPSCR content. > VUNSPEC_SET_FPSCR ; Represent assign of FPSCR content. > VUNSPEC_SET_FPSCR_NZCVQC ; Represent assign of FPSCR_nzcvqc content. > diff --git a/gcc/testsuite/gcc.dg/rtl/arm/stl-cond.c b/gcc/testsuite/gcc.dg/rtl/arm/stl-cond.c > deleted file mode 100644 > index e47ca6bf36dac500b90d80e52e150a19c95c7219..0000000000000000000000000000000000000000 > --- a/gcc/testsuite/gcc.dg/rtl/arm/stl-cond.c > +++ /dev/null > @@ -1,61 +0,0 @@ > -/* { dg-do compile { target arm*-*-* } } */ > -/* { dg-require-effective-target arm_arm_ok } */ > -/* { dg-require-effective-target arm_arch_v8a_ok } */ > -/* { dg-options "-O2 -marm" } */ > -/* { dg-add-options arm_arch_v8a } */ > - > -/* We want to test that the STL instruction gets the conditional > - suffix when under a COND_EXEC. However, COND_EXEC is very hard to > - generate from C code because the atomic_store expansion adds a compiler > - barrier before the insn, preventing if-conversion. So test the output > - here with a hand-crafted COND_EXEC wrapped around an STL. */ > - > -void __RTL (startwith ("final")) foo (int *a, int b) > -{ > -(function "foo" > - (param "a" > - (DECL_RTL (reg/v:SI r0)) > - (DECL_RTL_INCOMING (reg:SI r0)) > - ) > - (param "b" > - (DECL_RTL (reg/v:SI r1)) > - (DECL_RTL_INCOMING (reg:SI r1)) > - ) > - (insn-chain > - (block 2 > - (edge-from entry (flags "FALLTHRU")) > - (cnote 5 [bb 2] NOTE_INSN_BASIC_BLOCK) > - > - (insn:TI 7 (parallel [ > - (set (reg:CC cc) > - (compare:CC (reg:SI r1) > - (const_int 0))) > - (set (reg/v:SI r1) > - (reg:SI r1 )) > - ]) ;; {*movsi_compare0} > - (nil)) > - > - ;; A conditional atomic store-release: STLNE for Armv8-A. > - (insn 10 (cond_exec (ne (reg:CC cc) > - (const_int 0)) > - (set (mem/v:SI (reg/v/f:SI r0) [-1 S4 A32]) > - (unspec_volatile:SI [ > - (reg/v:SI r1) > - (const_int 3) > - ] VUNSPEC_STL))) ;; {*p atomic_storesi} > - (expr_list:REG_DEAD (reg:CC cc) > - (expr_list:REG_DEAD (reg/v:SI r1) > - (expr_list:REG_DEAD (reg/v/f:SI r0) > - (nil))))) > - (edge-to exit (flags "FALLTHRU")) > - ) ;; block 2 > - ) ;; insn-chain > - (crtl > - (return_rtx > - (reg/i:SI r0) > - ) ;; return_rtx > - ) ;; crtl > -) ;; function > -} > - > -/* { dg-final { scan-assembler "stlne" } } */ > diff --git a/gcc/testsuite/gcc.target/arm/atomic_loaddi_7.c b/gcc/testsuite/gcc.target/arm/atomic_loaddi_7.c > index 6743663f1e6831d3fc441e80fcfe3d761987970b..79e36edbb8fa86712b8d283b9a81b794610f4813 100644 > --- a/gcc/testsuite/gcc.target/arm/atomic_loaddi_7.c > +++ b/gcc/testsuite/gcc.target/arm/atomic_loaddi_7.c > @@ -6,4 +6,4 @@ > #include "atomic_loaddi_seq_cst.x" > > /* { dg-final { scan-assembler-times "ldrexd\tr\[0-9\]+, r\[0-9\]+, \\\[r\[0-9\]+\\\]" 1 } } */ > -/* { dg-final { scan-assembler-times "dmb\tish" 1 } } */ > +/* { dg-final { scan-assembler-times "dmb\tish" 2 } } */ > diff --git a/gcc/testsuite/gcc.target/arm/atomic_loaddi_8.c b/gcc/testsuite/gcc.target/arm/atomic_loaddi_8.c > index f7bd3e5a2b515d91418f5f4a7a8db00336a8b594..7241d361313997b0133056c1a3a7c1b546708e43 100644 > --- a/gcc/testsuite/gcc.target/arm/atomic_loaddi_8.c > +++ b/gcc/testsuite/gcc.target/arm/atomic_loaddi_8.c > @@ -6,4 +6,4 @@ > #include "atomic_loaddi_seq_cst.x" > > /* { dg-final { scan-assembler-times "ldrd\tr\[0-9\]+, r\[0-9\]+, \\\[r\[0-9\]+\\\]" 1 } } */ > -/* { dg-final { scan-assembler-times "dmb\tish" 1 } } */ > +/* { dg-final { scan-assembler-times "dmb\tish" 2 } } */ > diff --git a/gcc/testsuite/gcc.target/arm/pr111235.c b/gcc/testsuite/gcc.target/arm/pr111235.c > new file mode 100644 > index 0000000000000000000000000000000000000000..b06a5bfb8e294edf04ec9b7b6d8fe5d1ac73b1e7 > --- /dev/null > +++ b/gcc/testsuite/gcc.target/arm/pr111235.c > @@ -0,0 +1,39 @@ > +/* { dg-do compile } */ > +/* { dg-options "-O2" } */ > +/* { dg-require-effective-target arm_arch_v7a_ok } */ > +/* { dg-add-options arm_arch_v7a } */ > + > +#include <stdatomic.h> > + > +int t0 (int *p, int x) > +{ > + if (x > 100) > + x = atomic_load_explicit (p, memory_order_relaxed); > + return x + 1; > +} > + > +long long t1 (long long *p, int x) > +{ > + if (x > 100) > + x = atomic_load_explicit (p, memory_order_relaxed); > + return x + 1; > +} > + > +void t2 (int *p, int x) > +{ > + if (x > 100) > + atomic_store_explicit (p, x, memory_order_relaxed); > +} > + > +void t3 (long long *p, int x) > +{ > + if (x > 100) > + atomic_store_explicit (p, x, memory_order_relaxed); > +} > + > +/* { dg-final { scan-assembler-times "ldrexd\tr\[0-9\]+, r\[0-9\]+, \\\[r\[0-9\]+\\\]" 2 } } */ > +/* { dg-final { scan-assembler-not "ldrgt" } } */ > +/* { dg-final { scan-assembler-not "ldrdgt" } } */ > +/* { dg-final { scan-assembler-not "ldrexdgt" } } */ > +/* { dg-final { scan-assembler-not "strgt" } } */ > +/* { dg-final { scan-assembler-not "strdgt" } } */ Ok if no regressions but as you might get nagged by the post commit CI ... While it is not policy yet to look at these bots but given the enthusiasm at Cauldron for patchwork and pre-commit CI and because all my armhf boxes are boxed up, I decided to do something a bit novel ! I tried reviewing this via patchwork https://patchwork.sourceware.org/project/gcc/patch/PAWPR08MB8982A6AA40749B7… and notice that https://ci.linaro.org/job/tcwg_gcc_build--master-arm-precommit/2393/artifac… says nothing could be built. Possibly worth double checking the status for it being a false negative as to why the build failed. It was green on patchwork but remembering that Green is not Green for CI in patchwork I clicked on the afore mentioned ci.linaro.org link and see that it's actually broken. regards Ramana

2 years, 2 months

4
3
0 0

[ACTIVITY] report week ending 20 Oct

by Peter Maydell

Progress: * UM-2 [QEMU upstream maintainership] - post-holiday catchup on email and code review - respin and resend of a patch fixing a bug in rdma code - sent a target-arm pull request * QEMU-292 [ARMv8.3 FEAT_NV, Nested Virtualization] - did an initial read-through of the relevant portions of the Arm ARM to identify the work required here thanks -- PMM

2 years, 2 months

1
0
0 0

Re: [Linaro-TCWG-CI] llvmorg-18-init-8757-gfd311126349b: Failure on aarch64

by Nick Desaulniers

Thanks for the report. Looks like Nathan has reported this, too (as have Google3 folks): https://github.com/llvm/llvm-project/commit/fd311126349b8fe1684d62154a9fa5a… On Wed, Oct 18, 2023 at 7:31 PM <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. > > In CI config tcwg_kernel/llvm-master-aarch64-stable-defconfig after: > > | commit llvmorg-18-init-8757-gfd311126349b > | Author: Florian Hahn <flo(a)fhahn.com> > | Date: Tue Oct 17 19:17:40 2023 +0100 > | > | [VPlan] Insert Trunc/Exts for reductions directly in VPlan. > | > | Update the code to create Trunc/Ext recipes directly in > | adjustRecipesForReductions instead of fixing it up later in > | fixReductions. > | > | This explicitly models the required conversions and also makes sure they > | ... 2 lines of the commit log omitted. > > Results changed to > # reset_artifacts: > -10 > # build_abe binutils: > -9 > # build_kernel_llvm: > -5 > # build_abe qemu: > -2 > # linux_n_obj: > 8020 > # First few build errors in logs: > > # 00:12:40 clang: error: clang frontend command failed with exit code 134 (use -v to see invocation) > # 00:12:40 make[5]: *** [scripts/Makefile.build:243: drivers/platform/chrome/cros_ec_i2c.o] Error 1 > # 00:13:18 make[4]: *** [scripts/Makefile.build:480: drivers/platform/chrome] Error 2 > # 00:13:18 make[3]: *** [scripts/Makefile.build:480: drivers/platform] Error 2 > # 00:13:37 clang: error: clang frontend command failed with exit code 134 (use -v to see invocation) > # 00:13:37 make[7]: *** [scripts/Makefile.build:243: drivers/net/ethernet/intel/igb/igb_main.o] Error 1 > # 00:13:46 make[6]: *** [scripts/Makefile.build:480: drivers/net/ethernet/intel/igb] Error 2 > # 00:13:53 make[5]: *** [scripts/Makefile.build:480: drivers/net/ethernet/intel] Error 2 > # 00:16:54 make[4]: *** [scripts/Makefile.build:480: drivers/net/ethernet] Error 2 > # 00:16:54 make[3]: *** [scripts/Makefile.build:480: drivers/net] Error 2 > > From > # reset_artifacts: > -10 > # build_abe binutils: > -9 > # build_kernel_llvm: > -5 > # build_abe qemu: > -2 > # linux_n_obj: > 9166 > # linux build successful: > all > # linux boot successful: > boot > > The configuration of this build is: > CI config tcwg_kernel/llvm-master-aarch64-stable-defconfig > > -----------------8<--------------------------8<--------------------------8<-------------------------- > The information below can be used to reproduce a debug environment: > > Current build : https://ci.linaro.org/job/tcwg_kernel--llvm-master-aarch64-stable-defconfig… > Reference build : https://ci.linaro.org/job/tcwg_kernel--llvm-master-aarch64-stable-defconfig… > > Reproduce last good and first bad builds: https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/llvm/s… > > Full commit : https://github.com/llvm/llvm-project/commit/fd311126349b8fe1684d62154a9fa5a… > > Latest bug report status : https://linaro.atlassian.net/browse/LLVM-1007 > > List of configurations that regressed due to this commit : > * tcwg_kernel > ** llvm-master-aarch64-stable-defconfig > *** Failure > *** https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/llvm/s… > *** https://ci.linaro.org/job/tcwg_kernel--llvm-master-aarch64-stable-defconfig… -- Thanks, ~Nick Desaulniers

2 years, 2 months

2
1
0 0

[ACTIVITY] Report for week #41

by Thiago Jung Bauermann

Hello, # TCWG CI - Flakiness in gdb.base/gdb-sigterm.exp causes false positives on tcwg_check_gdb--master-arm-precommit, so started investigating its failures. - Investigated regressions reported by the CI: - GCC regression GNU-935: Not a real regression, just already existing failures being reported for a new version of the C++ standard. - linux-next regression GNU-936: Fixed in the newest linux-next tree. - GCC regression GNU-962: Opened GCC bug 111802 ("New analyser diagram failures since commit b365e9d57ad4"). - GCC regression GNU-965: Arm already opened GCC bug 111784 ("[14 Regression] aarch64: ldp_stp_{15,16,17,18}.c test failures since r14-4579.") about this issue. - GCC regression GNU-966: This problem has been fixed in trunk. - linux-next regression GNU-967: A patch was sent to fix the error. # [GNU-767] Support changing SVE vector length in remote debugging - Working on adapting gdbserver's regcache to support registers with a variable size. - Also enabling the target description XML to express vector register sizes in terms of another register. -- Thiago

2 years, 2 months

1
0
0 0

Re: WoA machines in the lab

by Lina Iyer

+ linaro-toolchain(a)lists.linaro.org Could someone help with this information in Maxim's absence ? Thanks, Lina On Tue, Oct 10 2023 at 10:07 -0600, Lina Iyer wrote: >Hi Maxim, > >Do you have a list of machines and who provided us with those machines >that we use for WoA projects? I see the list in [1] but not where we got >them from. Marcus from MS was asking for a list of MS provided machines >that we have in use. > >Thanks, >Lina > >[1]. >https://linaro.atlassian.net/wiki/spaces/TCWG/pages/22395192116/Accessing+W…

2 years, 2 months

1
0
0 0

Fwd: [Linaro-TCWG-CI] llvmorg-18-init-7933-ge13bed4c5f35: slowed down by 6% - 464.h264ref on aarch64 O2

by Maxim Kuvyrkov

Hi Dmitriy, Linaro Benchmarking CI has flagged several interesting code-speed and code-size regressions for your patch -- see [1]. In particular, could you check if below regressions can be avoided: - grew in size by 21% - 473.astar:[.] _ZN7way2obj12releasepointEii - slowed down by 61% - 505.mcf_r:[.] price_out_impl Both of these are for 32-bit ARM, but AArch64 also has code-speed and code-size regressions. Let me know if you need any assistance in reproducing these problems. [1] https://linaro.atlassian.net/browse/LLVM-1001 Kind regards, -- Maxim Kuvyrkov https://www.linaro.org > Begin forwarded message: > > From: ci_notify(a)linaro.org > Subject: [Linaro-TCWG-CI] llvmorg-18-init-7933-ge13bed4c5f35: slowed down by 6% - 464.h264ref on aarch64 O2 > Date: October 8, 2023 at 04:26:39 GMT+4 > To: maxim.kuvyrkov(a)linaro.org > Reply-To: linaro-toolchain(a)lists.linaro.org > > 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. > > In CI config tcwg_bmk-code_speed-spec2k6/llvm-aarch64-master-O2 after: > > | commit llvmorg-18-init-7933-ge13bed4c5f35 > | Author: Dmitriy Smirnov <dmitriy.smirnov(a)arm.com> > | Date: Fri Oct 6 11:15:00 2023 +0100 > | > | [PATCH] [llvm] [InstCombine] Canonicalise ADD+GEP > | > | This patch tries to canonicalise add + gep to gep + gep. > | > | Co-authored-by: Paul Walker <paul.walker(a)arm.com> > | > | Reviewed By: nikic > | ... 2 lines of the commit log omitted. > > the following benchmarks slowed down by more than 3%: > - slowed down by 6% - 464.h264ref - from 11126 to 11766 perf samples > the following hot functions slowed down by more than 15% (but their benchmarks slowed down by less than 3%): > - slowed down by 44% - 464.h264ref:[.] FastFullPelBlockMotionSearch - from 1531 to 2206 perf samples > > The configuration of this build is: > Below reproducer instructions can be used to re-build both "first_bad" and "last_good" cross-toolchains used in this bisection. Naturally, the scripts will fail when triggerring benchmarking jobs if you don\'t have access to Linaro TCWG CI. > > Configuration: > - Benchmark: > - Toolchain: Clang + Glibc + LLVM Linker > - Version: all components were built from their tip of trunk > - Target: aarch64-linux-gnu > - Compiler flags: O2 > - Hardware: NVidia TX1 4x Cortex-A57 > > This benchmarking CI is work-in-progress, and we welcome feedback and suggestions at linaro-toolchain(a)lists.linaro.org . In our improvement plans is to add support for SPEC CPU2017 benchmarks and provide "perf report/annotate" data behind these reports. > > -----------------8<--------------------------8<--------------------------8<-------------------------- > The information below can be used to reproduce a debug environment: > > Current build : https://ci.linaro.org/job/tcwg_bmk-code_speed-spec2k6--llvm-aarch64-master-… > Reference build : https://ci.linaro.org/job/tcwg_bmk-code_speed-spec2k6--llvm-aarch64-master-… > > Reproduce last good and first bad builds: https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/llvm/s… > > Full commit : https://github.com/llvm/llvm-project/commit/e13bed4c5f3544c076ce57e36d9a11e… > > Latest bug report status : https://linaro.atlassian.net/browse/LLVM-1001 > > List of configurations that regressed due to this commit : > * tcwg_bmk-code_speed-spec2k6 > ** llvm-aarch64-master-O2 > *** slowed down by 6% - 464.h264ref > *** https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/llvm/s… > *** https://ci.linaro.org/job/tcwg_bmk-code_speed-spec2k6--llvm-aarch64-master-…

2 years, 2 months

2
1
0 0

[ACTIVITY] Report for weeks #37 to #40

by Thiago Jung Bauermann

Hello, Attended two events in a row in September, so had a bit of a time crunch and the weekly report fell through the cracks... # TCWG CI - Investigated and fixed a few false positives in the GDB precommit CI which were caused by random failures in gdb.threads/process-dies-while-detaching.exp. Posted upstream and later committed patch fixing the testcase to be more stable. - After conversations during GNU Tools Cauldron and following Maxim's suggestion, changed Linaro's CI to use the read1 library while running the GDB testsuite to improve the stability of its results. - After review from Tom Tromey, posted v2 and later committed a patch which adds '--with-additional-debug-dirs' configure option. - Committed a couple of changes to our CI scripts which make sure that the kernel.yama.ptrace_scope and kernel.core_pattern sysctls have correct values for running the GDB testsuite. # [GNU-767] Support changing SVE vector length in remote debugging - Now that Luis pushed his SME and SME2 patches, merged current GDB main branch into my local branch. It builds but doesn't work yet. # GDB Upstream - Reviewed patch series "[PATCH v3 0/4] Dynamic properties of pointers". - Investigated upstream bugzilla "18898 - Cannot specify non-default list of directories as argument of --with-auto-load-dir on Windows", but concluded it's an autoconf limitation that isn't easy to fix. # Misc - Prepared for Linaro's Employees Meeting. - Attended GNU Tools Cauldron. - Took a few days of vacation. -- Thiago

2 years, 2 months

1
0
0 0

Re: [Linaro-TCWG-CI] 13 patches in glibc: FAIL: 7 regressions

by Maxim Kuvyrkov

Hi Arjun, Please ignore this report. We had a new machine added to the testing pool, and it behaved differently than the others. -- Maxim Kuvyrkov https://www.linaro.org > On Oct 4, 2023, at 22:30, 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. > > In CI config tcwg_glibc_check/master-arm after: > > | 13 patches in glibc > | Patchwork URL: https://patchwork.sourceware.org/patch/76970 > | 72a0ec189c Move 'rpc' routines from 'inet' into 'nss' > | e9e10ad39b Move 'protocols' routines from 'inet' into 'nss' > | e0694af485 Move 'networks' routines from 'inet' into 'nss' > | 547bcf6d44 Move 'netgroup' routines from 'inet' into 'nss' > | 6c43eb641a Move 'hosts' routines from 'inet' into 'nss' > | ... and 8 more patches in glibc > | ... applied on top of baseline commit: > | 1056e5b4c3 tunables: Terminate if end of input is reached (CVE-2023-4911) > > FAIL: 7 regressions > > regressions.sum: > === glibc tests === > > Running glibc:io ... > FAIL: io/tst-close_range > > Running glibc:misc ... > FAIL: misc/tst-epoll > FAIL: misc/tst-epoll-time64 > FAIL: misc/tst-mount > FAIL: misc/tst-process_mrelease > ... and 6 more entries > > You can find the failure logs in *.log.1.xz files in > - https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/802/artifa… . > The full lists of regressions and progressions are in > - https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/802/artifa… . > The list of [ignored] baseline and flaky failures are in > - https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/802/artifa… . > > > > -----------------8<--------------------------8<--------------------------8<-------------------------- > The information below can be used to reproduce a debug environment: > > Current build : https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/802/artifa… > Reference build : https://ci.linaro.org/job/tcwg_glibc_check--master-arm-build/650/artifact/a…

2 years, 2 months

1
0
0 0

Re: [Linaro-TCWG-CI] glibc patch #77093: FAIL: 5 regressions

by Maxim Kuvyrkov

Hi Joe, Please ignore this report. We had a new machine added to the testing pool, and it behaved differently than the others. -- Maxim Kuvyrkov https://www.linaro.org > On Oct 4, 2023, at 22:32, 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. > > In CI config tcwg_glibc_check/master-arm after: > > | glibc patch https://patchwork.sourceware.org/patch/77093 > | Author: Joe Ramsay <Joe.Ramsay(a)arm.com> > | Date: Wed Oct 4 11:58:09 2023 +0100 > | > | aarch64: Improve vecmath sin routines > | > | * Update ULP comment reflecting a new observed max in [-pi/2, pi/2] > | * Use the same polynomial in AdvSIMD and SVE, rather than FTRIG instructions > | * Improve register use near special-case branch > | > | Also use overloaded intrinsics for SVE. > | ... applied on top of baseline commit: > | 1056e5b4c3 tunables: Terminate if end of input is reached (CVE-2023-4911) > > FAIL: 5 regressions > > regressions.sum: > === glibc tests === > > Running glibc:io ... > FAIL: io/tst-close_range > > Running glibc:misc ... > FAIL: misc/tst-epoll > FAIL: misc/tst-epoll-time64 > FAIL: misc/tst-mount > FAIL: misc/tst-process_mrelease > ... and 2 more entries > > You can find the failure logs in *.log.1.xz files in > - https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/810/artifa… . > The full lists of regressions and progressions are in > - https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/810/artifa… . > The list of [ignored] baseline and flaky failures are in > - https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/810/artifa… . > > > > -----------------8<--------------------------8<--------------------------8<-------------------------- > The information below can be used to reproduce a debug environment: > > Current build : https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/810/artifa… > Reference build : https://ci.linaro.org/job/tcwg_glibc_check--master-arm-build/650/artifact/a…

2 years, 2 months

1
0
0 0

Re: [Linaro-TCWG-CI] glibc patch #77054: FAIL: 5 regressions

by Maxim Kuvyrkov

Hi Siddhesh, Please ignore this report. We had a new machine added to the testing pool, and it behaved differently than the others. -- Maxim Kuvyrkov https://www.linaro.org > On Oct 4, 2023, at 22:33, 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. > > In CI config tcwg_glibc_check/master-arm after: > > | glibc patch https://patchwork.sourceware.org/patch/77054 > | Author: Siddhesh Poyarekar <siddhesh(a)sourceware.org> > | Date: Tue Oct 3 16:11:50 2023 -0400 > | > | Make all malloc tunables SXID_ERASE > | > | The malloc tunables were made SXID_IGNORE to mimic the environment > | variables they aliased, in order to maintain compatibility. This > | allowed alteration of allocator behaviour across setuid boundaries, > | where a setuid program may ignore the tunable but its non-setuid child > | can read it and adjust allocator behaviour accordingly. > | ... 10 lines of the commit log omitted. > | ... applied on top of baseline commit: > | 1056e5b4c3 tunables: Terminate if end of input is reached (CVE-2023-4911) > > FAIL: 5 regressions > > regressions.sum: > === glibc tests === > > Running glibc:io ... > FAIL: io/tst-close_range > > Running glibc:misc ... > FAIL: misc/tst-epoll > FAIL: misc/tst-epoll-time64 > FAIL: misc/tst-mount > FAIL: misc/tst-process_mrelease > ... and 2 more entries > > You can find the failure logs in *.log.1.xz files in > - https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/806/artifa… . > The full lists of regressions and progressions are in > - https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/806/artifa… . > The list of [ignored] baseline and flaky failures are in > - https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/806/artifa… . > > > > -----------------8<--------------------------8<--------------------------8<-------------------------- > The information below can be used to reproduce a debug environment: > > Current build : https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/806/artifa… > Reference build : https://ci.linaro.org/job/tcwg_glibc_check--master-arm-build/650/artifact/a…

2 years, 2 months

1
0
0 0

Regarding installation

by Ashu Jain

We are installing SDK we need some details regarding linaro toolchain

2 years, 2 months

2
1
0 0

Re: [Linaro-TCWG-CI] binutils patch #76666: FAIL: 2 regressions

by Christophe Lyon

Hi, The error reported below was in fact caused by a bug in these tests, which has now been fixed. Sorry for the false alarm. Thanks On Tue, 26 Sept 2023 at 16:42, <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. > > In CI config tcwg_binutils_check/master-aarch64 after: > > | binutils patch https://patchwork.sourceware.org/patch/76666 > | Author: Arsen Arsenović <arsen(a)aarsen.me> > | Date: Tue Sep 26 02:17:33 2023 +0200 > | > | *: add modern gettext support > | > | ChangeLog: > | > | * .gitignore: Add '/gettext*'. > | * configure.ac (host_libs): Replace intl with gettext. > | (hbaseargs, bbaseargs, baseargs): Split baseargs into > {h,b}baseargs. > | ... 64 lines of the commit log omitted. > | ... applied on top of baseline commit: > | d86dbbea8a8 aarch64: Allow feature flags to occupy >64 bits > > FAIL: 2 regressions > > regressions.sum: > === binutils tests === > > Running binutils:binutils-all/ar.exp ... > FAIL: replacing non-deterministic member (wrong size, expected: 920) > FAIL: replacing SOURCE_DATE_EPOCH deterministic member (wrong size, > expected: 1096) > > === Results Summary === > > You can find the failure logs in *.log.1.xz files in > - > https://ci.linaro.org/job/tcwg_binutils_check--master-aarch64-precommit/376… > . > The full lists of regressions and progressions are in > - > https://ci.linaro.org/job/tcwg_binutils_check--master-aarch64-precommit/376… > . > The list of [ignored] baseline and flaky failures are in > - > https://ci.linaro.org/job/tcwg_binutils_check--master-aarch64-precommit/376… > . > > > > > -----------------8<--------------------------8<--------------------------8<-------------------------- > The information below can be used to reproduce a debug environment: > > Current build : > https://ci.linaro.org/job/tcwg_binutils_check--master-aarch64-precommit/376… > Reference build : > https://ci.linaro.org/job/tcwg_binutils_check--master-aarch64-build/302/art…

2 years, 3 months

1
0
0 0

Re: [Linaro-TCWG-CI] binutils patch #76704: FAIL: 2 regressions

by Christophe Lyon

Hi, The error reported below was in fact caused by a bug in these tests, which has now been fixed. Sorry for the false alarm. Thanks On Tue, 26 Sept 2023 at 16:38, <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. > > In CI config tcwg_binutils_check/master-aarch64 after: > > | binutils patch https://patchwork.sourceware.org/patch/76704 > | Author: Neal Frager <neal.frager(a)amd.com> > | Date: Tue Sep 26 13:46:37 2023 +0100 > | > | gas: microblaze: fixing constant range check issue > | > | The range check should be checking for the range > | ffffffff80000000..7fffffff, not ffffffff70000000. > | > | This patch has been tested for years of AMD Xilinx Yocto > | releases as part of the following patch set: > | ... 5 lines of the commit log omitted. > | ... applied on top of baseline commit: > | d86dbbea8a8 aarch64: Allow feature flags to occupy >64 bits > > FAIL: 2 regressions > > regressions.sum: > === binutils tests === > > Running binutils:binutils-all/ar.exp ... > FAIL: replacing non-deterministic member (wrong size, expected: 920) > FAIL: replacing SOURCE_DATE_EPOCH deterministic member (wrong size, > expected: 1096) > > === Results Summary === > > You can find the failure logs in *.log.1.xz files in > - > https://ci.linaro.org/job/tcwg_binutils_check--master-aarch64-precommit/379… > . > The full lists of regressions and progressions are in > - > https://ci.linaro.org/job/tcwg_binutils_check--master-aarch64-precommit/379… > . > The list of [ignored] baseline and flaky failures are in > - > https://ci.linaro.org/job/tcwg_binutils_check--master-aarch64-precommit/379… > . > > > > > -----------------8<--------------------------8<--------------------------8<-------------------------- > The information below can be used to reproduce a debug environment: > > Current build : > https://ci.linaro.org/job/tcwg_binutils_check--master-aarch64-precommit/379… > Reference build : > https://ci.linaro.org/job/tcwg_binutils_check--master-aarch64-build/302/art…

2 years, 3 months

1
0
0 0

Re: [Linaro-TCWG-CI] binutils patch #76687: FAIL: 2 regressions

by Christophe Lyon

Hi, The error reported below was in fact caused by a bug in these tests, which has now been fixed. Sorry for the false alarm. Thanks On Tue, 26 Sept 2023 at 16:38, <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. > > In CI config tcwg_binutils_check/master-aarch64 after: > > | binutils patch https://patchwork.sourceware.org/patch/76687 > | Author: YunQiang Su <yunqiang.su(a)cipunited.com> > | Date: Tue Sep 26 07:20:35 2023 -0400 > | > | GAS/MIPS: Fix testcase module-defer-warn2 for r2+ triples > | > | When gas is configured with --target=mipsisa32r2el-elf, > module-defer-warn2 > | will fail: > | > | /binutils-gdb/gas/testsuite/gas/mips/module-defer-warn2.s: > Assembler messages: > | /binutils-gdb/gas/testsuite/gas/mips/module-defer-warn2.s:2: > Error: `gp=64' used with a 32-bit processor > | ... 11 lines of the commit log omitted. > | ... applied on top of baseline commit: > | d86dbbea8a8 aarch64: Allow feature flags to occupy >64 bits > > FAIL: 2 regressions > > regressions.sum: > === binutils tests === > > Running binutils:binutils-all/ar.exp ... > FAIL: replacing non-deterministic member (wrong size, expected: 920) > FAIL: replacing SOURCE_DATE_EPOCH deterministic member (wrong size, > expected: 1096) > > === Results Summary === > > You can find the failure logs in *.log.1.xz files in > - > https://ci.linaro.org/job/tcwg_binutils_check--master-aarch64-precommit/378… > . > The full lists of regressions and progressions are in > - > https://ci.linaro.org/job/tcwg_binutils_check--master-aarch64-precommit/378… > . > The list of [ignored] baseline and flaky failures are in > - > https://ci.linaro.org/job/tcwg_binutils_check--master-aarch64-precommit/378… > . > > > > > -----------------8<--------------------------8<--------------------------8<-------------------------- > The information below can be used to reproduce a debug environment: > > Current build : > https://ci.linaro.org/job/tcwg_binutils_check--master-aarch64-precommit/378… > Reference build : > https://ci.linaro.org/job/tcwg_binutils_check--master-aarch64-build/302/art…

2 years, 3 months

1
0
0 0

Re: [Linaro-TCWG-CI] gcc patch #76638: FAIL: 12 regressions

by Jonathan Wakely

The <bits/version.h> header needs to be regenerated. The changes to the generated file were not in the diff posted to the mailing list (but are committed to git). On Mon, 25 Sept 2023 at 11:55, <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. > > In CI config tcwg_gcc_check/master-arm after: > > | gcc patch https://patchwork.sourceware.org/patch/76638 > | Author: Jonathan Wakely <jwakely(a)redhat.com> > | Date: Mon Sep 25 09:53:24 2023 +0100 > | > | libstdc++: Define C++23 std::forward_like (P2445R1) > | > | Tested x86_64-linux. Pushed to trunk. > | > | -- >8 -- > | > | libstdc++-v3/ChangeLog: > | ... 8 lines of the commit log omitted. > | ... applied on top of baseline commit: > | c25d6f15211 LoongArch: doc: Update -m[no-]explicit-relocs for r14-4160 > > FAIL: 12 regressions > > regressions.sum: > === libstdc++ tests === > > Running libstdc++:libstdc++-dg/conformance.exp ... > FAIL: 20_util/forward_like/1.cc -std=gnu++23 (test for excess errors) > FAIL: 20_util/forward_like/1.cc -std=gnu++26 (test for excess errors) > FAIL: 20_util/forward_like/2_neg.cc -std=gnu++23 (test for errors, line ) > FAIL: 20_util/forward_like/2_neg.cc -std=gnu++23 (test for errors, line 5) > FAIL: 20_util/forward_like/2_neg.cc -std=gnu++23 (test for errors, line 7) > FAIL: 20_util/forward_like/2_neg.cc -std=gnu++23 (test for excess errors) > FAIL: 20_util/forward_like/2_neg.cc -std=gnu++26 (test for errors, line ) > ... and 7 more entries > > You can find the failure logs in *.log.1.xz files in > - https://ci.linaro.org/job/tcwg_gcc_check--master-arm-precommit/3840/artifac… . > The full lists of regressions and progressions are in > - https://ci.linaro.org/job/tcwg_gcc_check--master-arm-precommit/3840/artifac… . > The list of [ignored] baseline and flaky failures are in > - https://ci.linaro.org/job/tcwg_gcc_check--master-arm-precommit/3840/artifac… . > > > > -----------------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-arm-precommit/3840/artifac… > Reference build : https://ci.linaro.org/job/tcwg_gcc_check--master-arm-build/1059/artifact/ar…

2 years, 3 months

2
2
0 0

[ACTIVITY] report week ending 27 Sep

by Peter Maydell

Progress (short week, three days): * UM-2 [QEMU upstream maintainership] - Sent a patch to fix a bug involving QEMU's PSCI emulation when QEMU is faking being EL3 firmware for a Linux guest - Sent patch to make our handling of the UNPREDICTABLE T32 LDM-of-single-register case match real hardware (some buggy software assumes this) - Patch review - Converted some more .txt files in our docs directory to rST * QEMU-486 [Support FEAT_RME guests in a board model] - JIRA cleanup to more clearly define what this epic is for, close out some redundant other epics and issues, and create or move some subtasks to be part of this epic -- PMM

2 years, 3 months

1
0
0 0

Re: [Linaro-TCWG-CI] gcc-14-4111-g6e92a6a2a72: 483.xalancbmk failed to build

by Maxim Kuvyrkov

Hi Patrick, Did you already get any bug reports for gcc-14-4111-g6e92a6a2a72 ? In our benchmarking we see that 483.xalancbmk (from SPEC CPU2006) fails to build on 32-bit ARM. Let me know if you need any help in reproducing and troubleshooting this. Thanks! -- Maxim Kuvyrkov https://www.linaro.org > On Sep 27, 2023, at 11:05, 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. > > In CI config tcwg_bmk-code_speed-spec2k6/gnu-arm-master-O3 after: > > | commit gcc-14-4111-g6e92a6a2a72 > | Author: Patrick Palka <ppalka(a)redhat.com> > | Date: Mon Sep 18 14:47:52 2023 -0400 > | > | c++: non-dependent assignment checking [PR63198, PR18474] > | > | This patch makes us recognize and check non-dependent simple assigments > | ahead of time, like we already do for compound assignments. This means > | the templated representation of such assignments will now usually have > | an implicit INDIRECT_REF (due to the reference return type), which the > | -Wparentheses code needs to handle. As a drive-by improvement, this > | ... 51 lines of the commit log omitted. > > the following benchmarks slowed down by more than 3%: > - 483.xalancbmk failed to build > > Below reproducer instructions can be used to re-build both "first_bad" and "last_good" cross-toolchains used in this bisection. Naturally, the scripts will fail when triggerring benchmarking jobs if you don\'t have access to Linaro TCWG CI. > > Configuration: > - Benchmark: > - Toolchain: GCC + Glibc + GNU Linker > - Version: all components were built from their tip of trunk > - Target: arm-linux-gnueabihf > - Compiler flags: O3 > - Hardware: NVidia TK1 4x Cortex-A15 > > This benchmarking CI is work-in-progress, and we welcome feedback and suggestions at linaro-toolchain(a)lists.linaro.org . In our improvement plans is to add support for SPEC CPU2017 benchmarks and provide "perf report/annotate" data behind these reports. > > -----------------8<--------------------------8<--------------------------8<-------------------------- > The information below can be used to reproduce a debug environment: > > Current build : https://ci.linaro.org/job/tcwg_bmk-code_speed-spec2k6--gnu-arm-master-O3-bu… > Reference build : https://ci.linaro.org/job/tcwg_bmk-code_speed-spec2k6--gnu-arm-master-O3-bu… > > 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/6e92a6a2a72d3b7a5e1b29042d8a6a43fe… > > Latest bug report status : https://linaro.atlassian.net/browse/GNU-951 > > List of configurations that regressed due to this commit : > * tcwg_bmk-code_speed-spec2k6 > ** gnu-arm-master-O3 > *** 483.xalancbmk failed to build > *** https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/gcc/sh… > *** https://ci.linaro.org/job/tcwg_bmk-code_speed-spec2k6--gnu-arm-master-O3-bu…

2 years, 3 months

1
1
0 0

Fwd: [Linaro-TCWG-CI] 2 patches in gdb: Failure

by Guinevere Larsen

Hello! I got 3 of these messages about a patch I have upstream, which seems excessive. I also just managed to grab an aarch64 box and test it and got no errors, so I'd appreciate someone double checking that those werent 3 false positives please. Thank you! Guinevere Larsen She/Her/Hers -------- Forwarded Message -------- Subject: [Linaro-TCWG-CI] 2 patches in gdb: Failure Date: Mon, 25 Sep 2023 05:37:49 +0000 (UTC) From: ci_notify(a)linaro.org Reply-To: linaro-toolchain(a)lists.linaro.org To: blarsen(a)redhat.com 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. In CI config tcwg_gdb_check/master-aarch64 after: | 2 patches in gdb | Patchwork URL: https://patchwork.sourceware.org/patch/76616 | ca7351280f6 gdb/infrun: simplify process_event_stop_test | 0e77782d402 gdb/record: print frame information when exiting a recursive call | ... applied on top of baseline commit: | be8e8313099 Automatic date update in version.in Results changed to # reset_artifacts: -10 # build_abe gdb -- --prefix /usr --disable install: # FAILED # build_abe dejagnu: # build_abe check_gdb --: # First few build errors in logs: # 00:10:07 /home/tcwg-build/workspace/tcwg_gnu_0/abe/snapshots/gdb.git~master/gdb/infrun.c:7012:17: error: ‘curr_frame_id’ was not declared in this scope; did you mean ‘outer_frame_id’? # 00:10:07 /home/tcwg-build/workspace/tcwg_gnu_0/abe/snapshots/gdb.git~master/gdb/infrun.c:7185:14: error: ‘curr_frame_id’ was not declared in this scope; did you mean ‘outer_frame_id’? # 00:10:07 /home/tcwg-build/workspace/tcwg_gnu_0/abe/snapshots/gdb.git~master/gdb/infrun.c:7185:31: error: ‘original_frame_id’ was not declared in this scope # 00:10:07 /home/tcwg-build/workspace/tcwg_gnu_0/abe/snapshots/gdb.git~master/gdb/infrun.c:7615:8: error: ‘curr_frame_id’ was not declared in this scope; did you mean ‘outer_frame_id’? # 00:10:07 /home/tcwg-build/workspace/tcwg_gnu_0/abe/snapshots/gdb.git~master/gdb/infrun.c:7615:25: error: ‘original_frame_id’ was not declared in this scope # 00:10:07 /home/tcwg-build/workspace/tcwg_gnu_0/abe/snapshots/gdb.git~master/gdb/infrun.c:7663:11: error: ‘curr_frame_id’ was not declared in this scope; did you mean ‘outer_frame_id’? # 00:10:07 /home/tcwg-build/workspace/tcwg_gnu_0/abe/snapshots/gdb.git~master/gdb/infrun.c:7663:28: error: ‘original_frame_id’ was not declared in this scope # 00:10:09 make[1]: *** [Makefile:1923: infrun.o] Error 1 # 00:10:09 make: *** [Makefile:12387: all-gdb] Error 2 # 00:09:18 /home/tcwg-build/workspace/tcwg_gnu_0/abe/snapshots/gdb.git~master/gdb/infrun.c:7012:17: error: ‘curr_frame_id’ was not declared in this scope; did you mean ‘outer_frame_id’? # 00:09:18 /home/tcwg-build/workspace/tcwg_gnu_0/abe/snapshots/gdb.git~master/gdb/infrun.c:7185:14: error: ‘curr_frame_id’ was not declared in this scope; did you mean ‘outer_frame_id’? # 00:09:18 /home/tcwg-build/workspace/tcwg_gnu_0/abe/snapshots/gdb.git~master/gdb/infrun.c:7185:31: error: ‘original_frame_id’ was not declared in this scope # 00:09:18 /home/tcwg-build/workspace/tcwg_gnu_0/abe/snapshots/gdb.git~master/gdb/infrun.c:7615:8: error: ‘curr_frame_id’ was not declared in this scope; did you mean ‘outer_frame_id’? # 00:09:18 /home/tcwg-build/workspace/tcwg_gnu_0/abe/snapshots/gdb.git~master/gdb/infrun.c:7615:25: error: ‘original_frame_id’ was not declared in this scope # 00:09:18 /home/tcwg-build/workspace/tcwg_gnu_0/abe/snapshots/gdb.git~master/gdb/infrun.c:7663:11: error: ‘curr_frame_id’ was not declared in this scope; did you mean ‘outer_frame_id’? # 00:09:18 /home/tcwg-build/workspace/tcwg_gnu_0/abe/snapshots/gdb.git~master/gdb/infrun.c:7663:28: error: ‘original_frame_id’ was not declared in this scope # 00:09:22 make[1]: *** [Makefile:1924: infrun.o] Error 1 # 00:09:43 make: *** [Makefile:12387: all-gdb] Error 2 From # reset_artifacts: -10 # build_abe gdb -- --prefix /usr --disable install: -2 # build_abe dejagnu: -1 # build_abe check_gdb --: 0 -----------------8<--------------------------8<--------------------------8<-------------------------- The information below can be used to reproduce a debug environment: Current build : https://ci.linaro.org/job/tcwg_gdb_check--master-aarch64-precommit/642/arti… Reference build : https://ci.linaro.org/job/tcwg_gdb_check--master-aarch64-build/326/artifact…

2 years, 3 months

2
3
0 0

[weekly][linaro] report week ending 22 Sep

by Peter Maydell

Progress: * UM-2 [QEMU upstream maintainership] - Implemented Neoverse N2 CPU model (easy as it's very similar to the Cortex-A710 we just implemented; but because it supports 48 bit physical addresses we can use it in the sbsa-ref board, so it's worth having both) - Wrote code to wire up the NS EL2 virtual timer IRQ on the virt board. This is part of FEAT_VHE, and we implemented the timer itself in the CPU ages ago, but forgot to ever wire up the interrupt line on the board models. Unfortunately doing this runs into a bug in EDK2 where it incorrectly asserts when it sees a dtb that reports the interrupt line. Leif Lindholm wrote patches to fix this in EDK2, but we'll need to update the QEMU testsuite and figure out how to communicate the need for an updated EDK2 to users. - Looked again at a long-standing missing feature in the virt board where it only has one UART. The main blocker for adding a second one has been odd EDK2 behaviour when the dtb tells it there are two UARTs. Investigated and wrote up exactly what it does to start a discussion about improving it. - Put together a target-arm pull request - Squashed a few -Wshadow warnings - Looking at a bug involving QEMU's PSCI emulation when QEMU is faking being EL3 firmware for a Linux guest * QEMU-530 [QEMU ARM v9.4 Baseline CPU for TCG] - Implemented and sent a patch for FEAT_HPMN0 (a very easy feature that makes MDCR_EL2.HPMN==0 valid) -- PMM

2 years, 3 months

1
0
0 0

Re: [EXT] [Linaro-TCWG-CI] basepoints/gcc-14-4038-gb975c0dc3be: Failure

by Andrew Pinski

I could not reproduce the bootstrap failure at -O3 on x86_64. I used --with-build-config=bootstrap-O3 . Maybe this is an arm (32?) only issue. Thanks, Andrew ________________________________________ From: ci_notify(a)linaro.org <ci_notify(a)linaro.org> Sent: Saturday, September 16, 2023 5:33 AM To: Andrew Pinski Cc: gcc-regression(a)gcc.gnu.org Subject: [EXT] [Linaro-TCWG-CI] basepoints/gcc-14-4038-gb975c0dc3be: Failure External Email ---------------------------------------------------------------------- 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. In CI config tcwg_bootstrap_build/master-arm-bootstrap_O3 after: | commit basepoints/gcc-14-4038-gb975c0dc3be | Author: Andrew Pinski <apinski(a)marvell.com> | Date: Thu Sep 14 14:47:04 2023 -0700 | | MATCH: Improve zero_one_valued_p for cases without range information | | I noticed we sometimes lose range information in forwprop due to a few | match and simplify patterns optimizing away casts. So the easier way | to these cases is to add a match for zero_one_valued_p wich mathes | a cast from another zero_one_valued_p. | This also adds the case of `x & zero_one_valued_p` as being zero_one_valued_p | ... 13 lines of the commit log omitted. Results changed to # reset_artifacts: -10 # true: 0 # build_abe bootstrap_O3: # FAILED # First few build errors in logs: # 00:30:42 xg++: internal compiler error: Segmentation fault signal terminated program cc1plus # 00:30:42 make[3]: *** [Makefile:1184: tree-ssa-loop-niter.o] Error 4 # 00:30:42 make[2]: *** [Makefile:5051: all-stage2-gcc] Error 2 # 00:30:42 make[1]: *** [Makefile:25871: stage2-bubble] Error 2 # 00:30:42 make: *** [Makefile:1090: all] Error 2 # 00:07:25 make[3]: [Makefile:1822: armv8l-unknown-linux-gnueabihf/bits/largefile-config.h] Error 1 (ignored) # 00:25:31 xg++: internal compiler error: Segmentation fault signal terminated program cc1plus # 00:25:31 make[3]: *** [Makefile:1184: tree-ssa-loop-niter.o] Error 4 # 00:30:14 make[2]: *** [Makefile:5051: all-stage2-gcc] Error 2 # 00:30:14 make[1]: *** [Makefile:25871: stage2-bubble] Error 2 # 00:30:14 make: *** [Makefile:1090: all] Error 2 From # reset_artifacts: -10 # true: 0 # build_abe bootstrap_O3: 1 -----------------8<--------------------------8<--------------------------8<-------------------------- The information below can be used to reproduce a debug environment: Current build : https://urldefense.proofpoint.com/v2/url?u=https-3A__ci.linaro.org_job_tcwg… Reference build : https://urldefense.proofpoint.com/v2/url?u=https-3A__ci.linaro.org_job_tcwg… Reproduce last good and first bad builds: https://urldefense.proofpoint.com/v2/url?u=https-3A__git.linaro.org_toolcha… Full commit : https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_gcc-2Dmirro… Latest bug report status : https://urldefense.proofpoint.com/v2/url?u=https-3A__linaro.atlassian.net_b… List of configurations that regressed due to this commit : * tcwg_bootstrap_build ** master-arm-bootstrap_O3 *** Failure *** https://urldefense.proofpoint.com/v2/url?u=https-3A__git.linaro.org_toolcha… *** https://urldefense.proofpoint.com/v2/url?u=https-3A__ci.linaro.org_job_tcwg…

2 years, 3 months

3
2
0 0

[Linaro-TCWG-CI] glibc-2.38.9000-125-g973fe93a56: FAIL: 1 regressions

by ci_notify＠linaro.org

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. In CI config tcwg_glibc_check/master-arm after: | commit glibc-2.38.9000-125-g973fe93a56 | Author: Siddhesh Poyarekar <siddhesh(a)sourceware.org> | Date: Fri Sep 15 13:51:12 2023 -0400 | | getaddrinfo: Fix use after free in getcanonname (CVE-2023-4806) | | When an NSS plugin only implements the _gethostbyname2_r and | _getcanonname_r callbacks, getaddrinfo could use memory that was freed | during tmpbuf resizing, through h_name in a previous query response. | | The backing store for res->at->name when doing a query with | ... 15 lines of the commit log omitted. FAIL: 1 regressions regressions.sum: === glibc tests === Running glibc:nss ... FAIL: nss/tst-nss-gai-hv2-canonname === Results Summary === You can find the failure logs in *.log.1.xz files in - https://ci.linaro.org/job/tcwg_glibc_check--master-arm-build/616/artifact/a… . The full lists of regressions and progressions are in - https://ci.linaro.org/job/tcwg_glibc_check--master-arm-build/616/artifact/a… . The list of [ignored] baseline and flaky failures are in - https://ci.linaro.org/job/tcwg_glibc_check--master-arm-build/616/artifact/a… . -----------------8<--------------------------8<--------------------------8<-------------------------- The information below can be used to reproduce a debug environment: Current build : https://ci.linaro.org/job/tcwg_glibc_check--master-arm-build/616/artifact/a… Reference build : https://ci.linaro.org/job/tcwg_glibc_check--master-arm-build/615/artifact/a… Reproduce last good and first bad builds: https://git.linaro.org/toolchain/ci/interesting-commits.git/plain/glibc/sha… Full commit : https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=973fe93a5675c42798b2… Latest bug report status : https://linaro.atlassian.net/browse/GNU-940 List of configurations that regressed due to this commit : * tcwg_glibc_check ** master-arm *** FAIL: 1 regressions *** https://git.linaro.org/toolchain/ci/interesting-commits.git/plain/glibc/sha… *** https://ci.linaro.org/job/tcwg_glibc_check--master-arm-build/616/

2 years, 3 months

1
0
0 0

[ACTIVITY] report week ending 15 Sep

by Peter Maydell

Progress: * UM-2 [QEMU upstream maintainership] - sent patches that re-sync our defined set of usermode hwcap bits and ID register bitmasks with what the Linux kernel currently has - code review * QEMU-530 [QEMU ARM v9.4 Baseline CPU for TCG] - FEAT_HBC: wrote and sent patch for this very simple feature - FEAT_MOPS: rolled v2 patchset based on review feedback * QEMU-486 [Update QEMU device models for FEAT_RME] - Looked at the SMMU spec to see (a) what realm-management related changes it needs and (b) where we are on the implementation of other features. Closed a few stale JIRA issues for features we've already implemented. - sent a patchset that advertises that we support SMMUv3.1-XNX (this is a no-op for our implementation) - investigated what the "expected" setup is for enforcing GPT checks on the GIC/ITS. Current front-runner is "the SMMU that's already in the system provides 'GPC checks only' for the accesses from these devices, as well as stage1/stage2 + GPT checks for PCI etc devices" (the term in the SMMU spec rev F.a is for a GPC-checks-only client device is "NoStreamID device") -- PMM

2 years, 3 months

1
0
0 0

Re: [Linaro-TCWG-CI] glibc patch #75959: FAIL: 1 regressions

by Siddhesh Poyarekar

On 2023-09-14 16:32, 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. > > In CI config tcwg_glibc_check/master-arm after: > > | glibc patch https://patchwork.sourceware.org/patch/75959 > | Author: Siddhesh Poyarekar <siddhesh(a)sourceware.org> > | Date: Thu Sep 14 06:13:02 2023 -0400 > | > | getaddrinfo: Fix use after free in getcanonname (CVE-2023-4806) > | > | When an NSS plugin only implements the _gethostbyname2_r and > | _getcanonname_r callbacks, getaddrinfo could use memory that was freed > | during tmpbuf resizing, through h_name in a previous query response. > | Fix this by copying h_name over and freeing it at the end. > | > | ... 3 lines of the commit log omitted. > | ... applied on top of baseline commit: > | 803f4073cc Add MOVE_MOUNT_BENEATH from Linux 6.5 to sys/mount.h > > FAIL: 1 regressions > > regressions.sum: > === glibc tests === > > Running glibc:nss ... > FAIL: nss/tst-nss-gai-hv2-canonname > > === Results Summary === > > You can find the failure logs in *.log.1.xz files in > - https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/703/artifa… . > The full lists of regressions and progressions are in > - https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/703/artifa… . > The list of [ignored] baseline and flaky failures are in > - https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/703/artifa… . > > > > -----------------8<--------------------------8<--------------------------8<-------------------------- > The information below can be used to reproduce a debug environment: > > Current build : https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/703/artifa… > Reference build : https://ci.linaro.org/job/tcwg_glibc_check--master-arm-build/612/artifact/a… Hello, I'm looking at the logs and all it has is: original exit status 127 running post-clean rsync for the new test. It looks like other NSS tests also fail in the same way. Is this a known issue on arm? Thanks, Sid

2 years, 3 months

4
4
0 0

Fwd: [Linaro-TCWG-CI] gcc patch #75644: FAIL: 2 regressions

by Jonathan Wakely

I think this is because the patch changes libstdc++-v3/include/bits/version.def which requires version.h to be regenerated, by running 'make update-version' in the objdir/$target/libstdc++-v3/include directory. The patch I sent to gcc-patches (which is archived in patchwork) doesn't have the updates to the generated files, but what I committed to git does have them. ---------- Forwarded message --------- From: <ci_notify(a)linaro.org> Date: Mon, 11 Sept 2023 at 21:00 Subject: [Linaro-TCWG-CI] gcc patch #75644: FAIL: 2 regressions To: <jwakely(a)redhat.com> 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. In CI config tcwg_gcc_check/master-aarch64 after: | gcc patch https://patchwork.sourceware.org/patch/75644 | Author: Jonathan Wakely <jwakely(a)redhat.com> | Date: Mon Sep 11 14:57:08 2023 +0100 | | libstdc++: Formatting std::thread::id and std::stacktrace (P2693R1) | | Tested aarch64-linux. Pushed to trunk. | | -- >8 -- | | New std::formatter specializations for C++23. | ... 18 lines of the commit log omitted. | ... applied on top of baseline commit: | 390fa3a78c8 libstdc++: Fix -Wunused-parameter warnings FAIL: 2 regressions regressions.sum: === libstdc++ tests === Running libstdc++:libstdc++-dg/conformance.exp ... FAIL: 19_diagnostics/stacktrace/output.cc (test for excess errors) FAIL: 19_diagnostics/stacktrace/version.cc (test for excess errors) === Results Summary === You can find the failure logs in *.log.1.xz files in - https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-precommit/2232/art… . The full lists of regressions and progressions are in - https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-precommit/2232/art… . The list of [ignored] baseline and flaky failures are in - https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-precommit/2232/art… . -----------------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-precommit/2232/art… Reference build : https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-build/926/artifact…

2 years, 3 months

1
1
0 0

[ACTIVITY] Report for week #36

by Thiago Jung Bauermann

Hello, # [GNU-767] Support changing SVE vector length in remote debugging - Continuing work on new approach to support changing SVE vector length in remote debugging. Fixed making native GDB work with the new approach using the DWARF location expression. Now porting the same approach to gdbserver, with an ad-hoc minimal location expression. # TCWG CI - Fixed GDB testsuite default timeout value, to make GDB check jobs for 32-bit ARM run in a less unreasonable time again. # Misc - Started preparation for future work on Guarded Control Stack for GDB. -- Thiago

2 years, 3 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain