* [PATCH 0/2] RISC-V/testsuite: A couple of improvements for pr105314.c @ 2024-01-11 23:35 Maciej W. Rozycki 2024-01-11 23:35 ` [PATCH 1/2] RISC-V/testsuite: Widen coverage " Maciej W. Rozycki 2024-01-11 23:35 ` [PATCH 2/2] RISC-V/testsuite: Also verify if-conversion runs " Maciej W. Rozycki 0 siblings, 2 replies; 12+ messages in thread From: Maciej W. Rozycki @ 2024-01-11 23:35 UTC (permalink / raw) To: gcc-patches; +Cc: Andrew Waterman, Jim Wilson, Kito Cheng, Palmer Dabbelt Hi, Here's a pair of further pr105314.c changes I came up with in the course of recent RISC-V if-conversion work. It's not entirely clear to me what our policy is for Stages 3 and 4 when it comes to testsuite cleanups or improvements, but I think it's worth sharing these updates anyway. OK to apply, or shall I wait for Stage 1? Maciej ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH 1/2] RISC-V/testsuite: Widen coverage for pr105314.c 2024-01-11 23:35 [PATCH 0/2] RISC-V/testsuite: A couple of improvements for pr105314.c Maciej W. Rozycki @ 2024-01-11 23:35 ` Maciej W. Rozycki 2024-01-12 9:54 ` Kito Cheng 2024-01-11 23:35 ` [PATCH 2/2] RISC-V/testsuite: Also verify if-conversion runs " Maciej W. Rozycki 1 sibling, 1 reply; 12+ messages in thread From: Maciej W. Rozycki @ 2024-01-11 23:35 UTC (permalink / raw) To: gcc-patches The optimization levels pr105314.c is iterated over are needlessly overridden with "-O2", limiting the coverage of the test case to that level, perhaps with additional options the original optimization level has been supplied with. We could prevent the extra iterations other than "-O2" from being run, but the transformation made by if-conversion is also expected to happen at other optimization levels, so include them all, and also make sure no reverse-condition branch appears in output, moving the `dg-final' command to the bottom, as with most test cases. gcc/testsuite/ * gcc.target/riscv/pr105314.c: Replace `dg-options' command with `dg-skip-if'. Also reject "bne" with `dg-final'. --- Hi, Technically it's not a single self-contained change and it could be 3 instead, but I think there's little point in splitting it further. Maciej --- gcc/testsuite/gcc.target/riscv/pr105314.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) gcc-test-riscv-pr105314-levels.diff Index: gcc/gcc/testsuite/gcc.target/riscv/pr105314.c =================================================================== --- gcc.orig/gcc/testsuite/gcc.target/riscv/pr105314.c +++ gcc/gcc/testsuite/gcc.target/riscv/pr105314.c @@ -1,7 +1,6 @@ /* PR rtl-optimization/105314 */ /* { dg-do compile } */ -/* { dg-options "-O2" } */ -/* { dg-final { scan-assembler-not "\tbeq\t" } } */ +/* { dg-skip-if "" { *-*-* } { "-O0" "-Og" "-Os" "-Oz" } } */ long foo (long a, long b, long c) @@ -10,3 +9,5 @@ foo (long a, long b, long c) a = 0; return a; } + +/* { dg-final { scan-assembler-not "\\s(?:beq|bne)\\s" } } */ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/2] RISC-V/testsuite: Widen coverage for pr105314.c 2024-01-11 23:35 ` [PATCH 1/2] RISC-V/testsuite: Widen coverage " Maciej W. Rozycki @ 2024-01-12 9:54 ` Kito Cheng 0 siblings, 0 replies; 12+ messages in thread From: Kito Cheng @ 2024-01-12 9:54 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: gcc-patches LGTM On Fri, Jan 12, 2024 at 7:36 AM Maciej W. Rozycki <macro@embecosm.com> wrote: > > The optimization levels pr105314.c is iterated over are needlessly > overridden with "-O2", limiting the coverage of the test case to that > level, perhaps with additional options the original optimization level > has been supplied with. We could prevent the extra iterations other > than "-O2" from being run, but the transformation made by if-conversion > is also expected to happen at other optimization levels, so include them > all, and also make sure no reverse-condition branch appears in output, > moving the `dg-final' command to the bottom, as with most test cases. > > gcc/testsuite/ > * gcc.target/riscv/pr105314.c: Replace `dg-options' command with > `dg-skip-if'. Also reject "bne" with `dg-final'. > --- > Hi, > > Technically it's not a single self-contained change and it could be 3 > instead, but I think there's little point in splitting it further. > > Maciej > --- > gcc/testsuite/gcc.target/riscv/pr105314.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > gcc-test-riscv-pr105314-levels.diff > Index: gcc/gcc/testsuite/gcc.target/riscv/pr105314.c > =================================================================== > --- gcc.orig/gcc/testsuite/gcc.target/riscv/pr105314.c > +++ gcc/gcc/testsuite/gcc.target/riscv/pr105314.c > @@ -1,7 +1,6 @@ > /* PR rtl-optimization/105314 */ > /* { dg-do compile } */ > -/* { dg-options "-O2" } */ > -/* { dg-final { scan-assembler-not "\tbeq\t" } } */ > +/* { dg-skip-if "" { *-*-* } { "-O0" "-Og" "-Os" "-Oz" } } */ > > long > foo (long a, long b, long c) > @@ -10,3 +9,5 @@ foo (long a, long b, long c) > a = 0; > return a; > } > + > +/* { dg-final { scan-assembler-not "\\s(?:beq|bne)\\s" } } */ ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH 2/2] RISC-V/testsuite: Also verify if-conversion runs for pr105314.c 2024-01-11 23:35 [PATCH 0/2] RISC-V/testsuite: A couple of improvements for pr105314.c Maciej W. Rozycki 2024-01-11 23:35 ` [PATCH 1/2] RISC-V/testsuite: Widen coverage " Maciej W. Rozycki @ 2024-01-11 23:35 ` Maciej W. Rozycki 2024-01-12 9:53 ` Kito Cheng 2024-01-12 10:04 ` Andrew Pinski 1 sibling, 2 replies; 12+ messages in thread From: Maciej W. Rozycki @ 2024-01-11 23:35 UTC (permalink / raw) To: gcc-patches; +Cc: Andrew Waterman, Jim Wilson, Kito Cheng, Palmer Dabbelt Verify that if-conversion succeeded through noce_try_store_flag_mask, as per PR rtl-optimization/105314, tightening the test case and making it explicit. gcc/testsuite/ * gcc.target/riscv/pr105314.c: Scan the RTL "ce1" pass too. --- gcc/testsuite/gcc.target/riscv/pr105314.c | 2 ++ 1 file changed, 2 insertions(+) gcc-test-riscv-pr105314-rtl.diff Index: gcc/gcc/testsuite/gcc.target/riscv/pr105314.c =================================================================== --- gcc.orig/gcc/testsuite/gcc.target/riscv/pr105314.c +++ gcc/gcc/testsuite/gcc.target/riscv/pr105314.c @@ -1,6 +1,7 @@ /* PR rtl-optimization/105314 */ /* { dg-do compile } */ /* { dg-skip-if "" { *-*-* } { "-O0" "-Og" "-Os" "-Oz" } } */ +/* { dg-options "-fdump-rtl-ce1" } */ long foo (long a, long b, long c) @@ -10,4 +11,5 @@ foo (long a, long b, long c) return a; } +/* { dg-final { scan-rtl-dump-times "if-conversion succeeded through noce_try_store_flag_mask" 1 "ce1" } } */ /* { dg-final { scan-assembler-not "\\s(?:beq|bne)\\s" } } */ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] RISC-V/testsuite: Also verify if-conversion runs for pr105314.c 2024-01-11 23:35 ` [PATCH 2/2] RISC-V/testsuite: Also verify if-conversion runs " Maciej W. Rozycki @ 2024-01-12 9:53 ` Kito Cheng 2024-01-12 10:04 ` Andrew Pinski 1 sibling, 0 replies; 12+ messages in thread From: Kito Cheng @ 2024-01-12 9:53 UTC (permalink / raw) To: Maciej W. Rozycki Cc: gcc-patches, Andrew Waterman, Jim Wilson, Palmer Dabbelt LGTM On Fri, Jan 12, 2024 at 7:37 AM Maciej W. Rozycki <macro@embecosm.com> wrote: > > Verify that if-conversion succeeded through noce_try_store_flag_mask, as > per PR rtl-optimization/105314, tightening the test case and making it > explicit. > > gcc/testsuite/ > * gcc.target/riscv/pr105314.c: Scan the RTL "ce1" pass too. > --- > gcc/testsuite/gcc.target/riscv/pr105314.c | 2 ++ > 1 file changed, 2 insertions(+) > > gcc-test-riscv-pr105314-rtl.diff > Index: gcc/gcc/testsuite/gcc.target/riscv/pr105314.c > =================================================================== > --- gcc.orig/gcc/testsuite/gcc.target/riscv/pr105314.c > +++ gcc/gcc/testsuite/gcc.target/riscv/pr105314.c > @@ -1,6 +1,7 @@ > /* PR rtl-optimization/105314 */ > /* { dg-do compile } */ > /* { dg-skip-if "" { *-*-* } { "-O0" "-Og" "-Os" "-Oz" } } */ > +/* { dg-options "-fdump-rtl-ce1" } */ > > long > foo (long a, long b, long c) > @@ -10,4 +11,5 @@ foo (long a, long b, long c) > return a; > } > > +/* { dg-final { scan-rtl-dump-times "if-conversion succeeded through noce_try_store_flag_mask" 1 "ce1" } } */ > /* { dg-final { scan-assembler-not "\\s(?:beq|bne)\\s" } } */ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] RISC-V/testsuite: Also verify if-conversion runs for pr105314.c 2024-01-11 23:35 ` [PATCH 2/2] RISC-V/testsuite: Also verify if-conversion runs " Maciej W. Rozycki 2024-01-12 9:53 ` Kito Cheng @ 2024-01-12 10:04 ` Andrew Pinski 2024-01-12 13:59 ` Maciej W. Rozycki 1 sibling, 1 reply; 12+ messages in thread From: Andrew Pinski @ 2024-01-12 10:04 UTC (permalink / raw) To: Maciej W. Rozycki Cc: gcc-patches, Andrew Waterman, Jim Wilson, Kito Cheng, Palmer Dabbelt On Thu, Jan 11, 2024 at 3:37 PM Maciej W. Rozycki <macro@embecosm.com> wrote: > > Verify that if-conversion succeeded through noce_try_store_flag_mask, as > per PR rtl-optimization/105314, tightening the test case and making it > explicit. > > gcc/testsuite/ > * gcc.target/riscv/pr105314.c: Scan the RTL "ce1" pass too. I have an objection for this, if we are checking the RTL pass and not overall code generation, then maybe we change the testcase so that it is a RTL testcase instead. Especially when there might be improvements going into GCC 15 specifically targeting ifcvt on the gimple level (I am planning on doing some). Thanks, Andrew Pinski > --- > gcc/testsuite/gcc.target/riscv/pr105314.c | 2 ++ > 1 file changed, 2 insertions(+) > > gcc-test-riscv-pr105314-rtl.diff > Index: gcc/gcc/testsuite/gcc.target/riscv/pr105314.c > =================================================================== > --- gcc.orig/gcc/testsuite/gcc.target/riscv/pr105314.c > +++ gcc/gcc/testsuite/gcc.target/riscv/pr105314.c > @@ -1,6 +1,7 @@ > /* PR rtl-optimization/105314 */ > /* { dg-do compile } */ > /* { dg-skip-if "" { *-*-* } { "-O0" "-Og" "-Os" "-Oz" } } */ > +/* { dg-options "-fdump-rtl-ce1" } */ > > long > foo (long a, long b, long c) > @@ -10,4 +11,5 @@ foo (long a, long b, long c) > return a; > } > > +/* { dg-final { scan-rtl-dump-times "if-conversion succeeded through noce_try_store_flag_mask" 1 "ce1" } } */ > /* { dg-final { scan-assembler-not "\\s(?:beq|bne)\\s" } } */ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] RISC-V/testsuite: Also verify if-conversion runs for pr105314.c 2024-01-12 10:04 ` Andrew Pinski @ 2024-01-12 13:59 ` Maciej W. Rozycki 2024-01-16 14:22 ` Jeff Law 0 siblings, 1 reply; 12+ messages in thread From: Maciej W. Rozycki @ 2024-01-12 13:59 UTC (permalink / raw) To: Andrew Pinski Cc: gcc-patches, Andrew Waterman, Jim Wilson, Kito Cheng, Palmer Dabbelt On Fri, 12 Jan 2024, Andrew Pinski wrote: > > Verify that if-conversion succeeded through noce_try_store_flag_mask, as > > per PR rtl-optimization/105314, tightening the test case and making it > > explicit. > > > > gcc/testsuite/ > > * gcc.target/riscv/pr105314.c: Scan the RTL "ce1" pass too. > > I have an objection for this, if we are checking the RTL pass and not > overall code generation, then maybe we change the testcase so that it > is a RTL testcase instead. It's not clear to me what you mean by an "RTL testcase", i.e. how you'd see the testcase changed (or an additional one produced instead) and why, please elaborate. Right now we verify that branches are absent from output, but not how that happens. > Especially when there might be improvements going into GCC 15 > specifically targeting ifcvt on the gimple level (I am planning on > doing some). How are the improvements going to affect the testcase? If they make it no longer relevant (in which case a replacement testcase for the new arrangement will be needed) or require updates, then I think it's an expected situation: one of the purposes of the testsuite is to make sure we're in control and understand what the consequences of changes made are. It's not that the testsuite is cast in stone and not expected to change. I.e. if we expect noce_try_store_flag_mask no longer to trigger, then we'll see that in the test results (good!) and we can update the relevant test case(s). e.g. by reversing the pass criteria so that we're still in control. Maciej ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] RISC-V/testsuite: Also verify if-conversion runs for pr105314.c 2024-01-12 13:59 ` Maciej W. Rozycki @ 2024-01-16 14:22 ` Jeff Law 2024-01-16 15:33 ` Maciej W. Rozycki 0 siblings, 1 reply; 12+ messages in thread From: Jeff Law @ 2024-01-16 14:22 UTC (permalink / raw) To: Maciej W. Rozycki, Andrew Pinski Cc: gcc-patches, Andrew Waterman, Jim Wilson, Kito Cheng, Palmer Dabbelt On 1/12/24 06:59, Maciej W. Rozycki wrote: > On Fri, 12 Jan 2024, Andrew Pinski wrote: > >>> Verify that if-conversion succeeded through noce_try_store_flag_mask, as >>> per PR rtl-optimization/105314, tightening the test case and making it >>> explicit. >>> >>> gcc/testsuite/ >>> * gcc.target/riscv/pr105314.c: Scan the RTL "ce1" pass too. >> >> I have an objection for this, if we are checking the RTL pass and not >> overall code generation, then maybe we change the testcase so that it >> is a RTL testcase instead. > > It's not clear to me what you mean by an "RTL testcase", i.e. how you'd > see the testcase changed (or an additional one produced instead) and why, > please elaborate. Right now we verify that branches are absent from > output, but not how that happens. What I'm guessing Andrew is suggesting is the testcase be adjusted so that its source is RTL rather than C. With that framework you can skip most of the pipeline and make the test more stable if something changes earlier in the pipeline. There aren't a lot of great examples of this and the RTL parser is probably less stable than the gimple parser. But if you look in gcc.dg/rtl you should see examples. In theory you can take the RTL dump from a pass, massage it and feed it back into the compiler. Perhaps a good example is rtl/x86_64/ira.c > >> Especially when there might be improvements going into GCC 15 >> specifically targeting ifcvt on the gimple level (I am planning on >> doing some). > > How are the improvements going to affect the testcase? > > If they make it no longer relevant (in which case a replacement testcase > for the new arrangement will be needed) or require updates, then I think > it's an expected situation: one of the purposes of the testsuite is to > make sure we're in control and understand what the consequences of changes > made are. It's not that the testsuite is cast in stone and not expected > to change. > > I.e. if we expect noce_try_store_flag_mask no longer to trigger, then > we'll see that in the test results (good!) and we can update the relevant > test case(s). e.g. by reversing the pass criteria so that we're still in > control. I think Andrew's point is that we can still test that the pass does what we want when presented with RTL in a particular form and isolate the pass from depending on prior passes in the pipeline either creating or not destroying the particular form we want to ensure is properly handled. I don't have a strong opinion on this. I certainly see Andrew's point, but it's also the case that if some work earlier in the RTL or gimple pipeline comes along and compromises the test, then we'd see the failure and deal with it. It's pretty standard procedure. Jeff ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] RISC-V/testsuite: Also verify if-conversion runs for pr105314.c 2024-01-16 14:22 ` Jeff Law @ 2024-01-16 15:33 ` Maciej W. Rozycki 2024-01-24 11:26 ` Maciej W. Rozycki 0 siblings, 1 reply; 12+ messages in thread From: Maciej W. Rozycki @ 2024-01-16 15:33 UTC (permalink / raw) To: Jeff Law Cc: Andrew Pinski, gcc-patches, Andrew Waterman, Jim Wilson, Kito Cheng, Palmer Dabbelt On Tue, 16 Jan 2024, Jeff Law wrote: > > It's not clear to me what you mean by an "RTL testcase", i.e. how you'd > > see the testcase changed (or an additional one produced instead) and why, > > please elaborate. Right now we verify that branches are absent from > > output, but not how that happens. > What I'm guessing Andrew is suggesting is the testcase be adjusted so that its > source is RTL rather than C. With that framework you can skip most of the > pipeline and make the test more stable if something changes earlier in the > pipeline. > > There aren't a lot of great examples of this and the RTL parser is probably > less stable than the gimple parser. But if you look in gcc.dg/rtl you should > see examples. > > In theory you can take the RTL dump from a pass, massage it and feed it back > into the compiler. Perhaps a good example is rtl/x86_64/ira.c Thanks, I wasn't aware of this feature. > > How are the improvements going to affect the testcase? > > > > If they make it no longer relevant (in which case a replacement testcase > > for the new arrangement will be needed) or require updates, then I think > > it's an expected situation: one of the purposes of the testsuite is to > > make sure we're in control and understand what the consequences of changes > > made are. It's not that the testsuite is cast in stone and not expected > > to change. > > > > I.e. if we expect noce_try_store_flag_mask no longer to trigger, then > > we'll see that in the test results (good!) and we can update the relevant > > test case(s). e.g. by reversing the pass criteria so that we're still in > > control. > I think Andrew's point is that we can still test that the pass does what we > want when presented with RTL in a particular form and isolate the pass from > depending on prior passes in the pipeline either creating or not destroying > the particular form we want to ensure is properly handled. It makes sense to me. > I don't have a strong opinion on this. I certainly see Andrew's point, but > it's also the case that if some work earlier in the RTL or gimple pipeline > comes along and compromises the test, then we'd see the failure and deal with > it. It's pretty standard procedure. I'll be happy to add an RTL test case, also for my recent complementary cset-sext.c addition and maybe other if-conversion pieces recently added. I think that does not preclude arming pr105314.c with RTL scanning though. Maciej ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] RISC-V/testsuite: Also verify if-conversion runs for pr105314.c 2024-01-16 15:33 ` Maciej W. Rozycki @ 2024-01-24 11:26 ` Maciej W. Rozycki 2024-01-24 17:24 ` Jeff Law 0 siblings, 1 reply; 12+ messages in thread From: Maciej W. Rozycki @ 2024-01-24 11:26 UTC (permalink / raw) To: Jeff Law, Andrew Pinski Cc: gcc-patches, Andrew Waterman, Jim Wilson, Kito Cheng, Palmer Dabbelt On Tue, 16 Jan 2024, Maciej W. Rozycki wrote: > > I don't have a strong opinion on this. I certainly see Andrew's point, but > > it's also the case that if some work earlier in the RTL or gimple pipeline > > comes along and compromises the test, then we'd see the failure and deal with > > it. It's pretty standard procedure. > > I'll be happy to add an RTL test case, also for my recent complementary > cset-sext.c addition and maybe other if-conversion pieces recently added. > I think that does not preclude arming pr105314.c with RTL scanning though. I have made a buch of testcases as we discussed at the meeting last week and the RTL parser did not blow up, so I have now submitted them. See: <patches-gcc/https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643802.html> and the next two messages (threading broke with this submission for some reason, probably due to a glitch in my mail client I've seen from time to time; I guess it's not worth it to get the patch series resubmitted as they are independent from each other really and can be applied in any order). I haven't heard back from Andrew beyond his initial message, so it's not clear to me whether he maintains his objection in spite the arguments given. Andrew? Do we have consensus now to move forward with this change as posted? I'd like to get these patches ticked off ASAP. Maciej ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] RISC-V/testsuite: Also verify if-conversion runs for pr105314.c 2024-01-24 11:26 ` Maciej W. Rozycki @ 2024-01-24 17:24 ` Jeff Law 2024-01-26 21:49 ` Maciej W. Rozycki 0 siblings, 1 reply; 12+ messages in thread From: Jeff Law @ 2024-01-24 17:24 UTC (permalink / raw) To: Maciej W. Rozycki, Andrew Pinski Cc: gcc-patches, Andrew Waterman, Jim Wilson, Kito Cheng, Palmer Dabbelt On 1/24/24 04:26, Maciej W. Rozycki wrote: > On Tue, 16 Jan 2024, Maciej W. Rozycki wrote: > >>> I don't have a strong opinion on this. I certainly see Andrew's point, but >>> it's also the case that if some work earlier in the RTL or gimple pipeline >>> comes along and compromises the test, then we'd see the failure and deal with >>> it. It's pretty standard procedure. >> >> I'll be happy to add an RTL test case, also for my recent complementary >> cset-sext.c addition and maybe other if-conversion pieces recently added. >> I think that does not preclude arming pr105314.c with RTL scanning though. > > I have made a buch of testcases as we discussed at the meeting last week > and the RTL parser did not blow up, so I have now submitted them. See: > <patches-gcc/https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643802.html> > and the next two messages (threading broke with this submission for some > reason, probably due to a glitch in my mail client I've seen from time to > time; I guess it's not worth it to get the patch series resubmitted as > they are independent from each other really and can be applied in any > order). > > I haven't heard back from Andrew beyond his initial message, so it's not > clear to me whether he maintains his objection in spite the arguments > given. Andrew? > > Do we have consensus now to move forward with this change as posted? I'd > like to get these patches ticked off ASAP. I think it should move forward. I think having the RTL tests deals with Andrew's concern and the testcase adjustment has value as well. I ACK's the RTL tests a few minutes ago and we should consider the 1/2 and 2/2 of the original OK now as well. Thanks, Jeff ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] RISC-V/testsuite: Also verify if-conversion runs for pr105314.c 2024-01-24 17:24 ` Jeff Law @ 2024-01-26 21:49 ` Maciej W. Rozycki 0 siblings, 0 replies; 12+ messages in thread From: Maciej W. Rozycki @ 2024-01-26 21:49 UTC (permalink / raw) To: Jeff Law Cc: Andrew Pinski, gcc-patches, Andrew Waterman, Jim Wilson, Kito Cheng, Palmer Dabbelt On Wed, 24 Jan 2024, Jeff Law wrote: > > Do we have consensus now to move forward with this change as posted? I'd > > like to get these patches ticked off ASAP. > I think it should move forward. I think having the RTL tests deals with > Andrew's concern and the testcase adjustment has value as well. > > I ACK's the RTL tests a few minutes ago and we should consider the 1/2 and 2/2 > of the original OK now as well. I have committed both patch series now, thank you for your assistance and review. Maciej ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2024-01-26 21:49 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-01-11 23:35 [PATCH 0/2] RISC-V/testsuite: A couple of improvements for pr105314.c Maciej W. Rozycki 2024-01-11 23:35 ` [PATCH 1/2] RISC-V/testsuite: Widen coverage " Maciej W. Rozycki 2024-01-12 9:54 ` Kito Cheng 2024-01-11 23:35 ` [PATCH 2/2] RISC-V/testsuite: Also verify if-conversion runs " Maciej W. Rozycki 2024-01-12 9:53 ` Kito Cheng 2024-01-12 10:04 ` Andrew Pinski 2024-01-12 13:59 ` Maciej W. Rozycki 2024-01-16 14:22 ` Jeff Law 2024-01-16 15:33 ` Maciej W. Rozycki 2024-01-24 11:26 ` Maciej W. Rozycki 2024-01-24 17:24 ` Jeff Law 2024-01-26 21:49 ` Maciej W. Rozycki
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).