Jiufu Guo via Gcc-patches writes:
> Hi,
>
> Segher Boessenkool writes:
>
>> On Tue, Apr 11, 2023 at 05:40:09PM +0800, Kewen.Lin wrote:
>>> on 2023/4/11 17:14, guojiufu wrote:
>>> > Thanks for raising this concern.
>>> > The behavior to check about bif on FLOAT128_HW and emit an error message
Hi,
Segher Boessenkool writes:
> On Tue, Apr 11, 2023 at 05:40:09PM +0800, Kewen.Lin wrote:
>> on 2023/4/11 17:14, guojiufu wrote:
>> > Thanks for raising this concern.
>> > The behavior to check about bif on FLOAT128_HW and emit an error message
>> > for
>> > requirements on quad-precision is
Am Mittwoch, dem 12.04.2023 um 00:32 + schrieb Joseph Myers:
> On Tue, 11 Apr 2023, Martin Uecker via Gcc-patches wrote:
>
> > Ok, here is another attempt on fixing issues with size expression.
> > Not all are regressions, but it does not make sense to try to split
> > it up.
>
> This
Hi,
This patch xfails a float128 comparison test case on powerpc64 that
fails due to a longstanding issue with floating-point compares.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58684 for more
information.
The patch passed regression test on Power Linux platforms.
Thanks
Gui
On 4/10/23 01:10, Jakub Jelinek wrote:
On Sat, Apr 08, 2023 at 06:25:32PM -0600, Jeff Law wrote:
On 4/6/23 08:21, Eric Botcazou wrote:
So, perhaps just in the return op0; case add further code for
WORD_REGISTER_OPERATIONS and sub-word modes which will call nonzero_bits
again for the word
On Tue, 11 Apr 2023, Martin Uecker via Gcc-patches wrote:
> Ok, here is another attempt on fixing issues with size expression.
> Not all are regressions, but it does not make sense to try to split
> it up.
This wording implies this is version 2 or later of the patch, could you
please give a
This is a carry over from PR 108139.
When we have a PHI node which has 2 arguments and one is undefined, we
create an equivalence between the LHS and the non-undefined PHI
argument. THis allows us to perform certain optimizations.
The problem is, when we are evaluating range-on-entry in the
On 4/11/23 17:09, juzhe.zh...@rivai.ai wrote:
I don't want to seperate VSETVL PASS into 2 seperate PASS.
I want make everything cleaner.
Well, two pass vsetvl might actually be cleaner. But as I've noted
before, now is not the time to debate the vsetvl implementation detail.
We've got much
I don't want to seperate VSETVL PASS into 2 seperate PASS.
I want make everything cleaner.
Another example is VSETVL PASS can do the branch prediction:
https://godbolt.org/z/K44r98E5v
In function "f", you can see we put the hoist vsetvl from a more likely block
(i !=cond) outside the loop,
then
Jakub,
for avoidance of doubt, your version is fine.
nathan
On 4/11/23 18:06, Nathan Sidwell wrote:
On 4/11/23 04:12, Jakub Jelinek wrote:
Hi!
When working on the PR109040 fix, I wanted to test it on some
WORD_REGISTER_OPERATIONS target and tried sparc-solaris on GCC Farm.
My bootstrap
On 4/11/23 04:12, Jakub Jelinek wrote:
Hi!
When working on the PR109040 fix, I wanted to test it on some
WORD_REGISTER_OPERATIONS target and tried sparc-solaris on GCC Farm.
My bootstrap failed in comparison failure on cp/module.o, because
Solaris date doesn't support the -r option and one
On 4/11/23 02:55, Richard Biener wrote:
Just to throw in a comment here - I think you should present LCM
with something it can identify as the same for compatible vsetvl and
then it should just work? OTOH if "compatible" is not transitive
that's not possible (but then I can't quickly make
On 4/11/23 14:10, Palmer Dabbelt wrote:
These functions are NOPs on the soft-float ABIs. Since we're already
forcing the ISA, let's just force the ABI too.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/xtheadfmv-fmv.c: Force the ilp32d ABI.
---
This one is also in the testing queue.
On 4/11/23 13:03, Palmer Dabbelt wrote:
The test case that was added is rv64i-specific, as there's better ways
to generate this code on rv32i (where the long/int cast is a NOP) and on
rv64i_zba (where we have word shifts). This renames the original test
case and adds two more for those
On 4/11/23 04:21, Jakub Jelinek wrote:
Hi!
This patch was what I've tried first before the currently committed
PR109386 fix. Still, I think it is the right thing until we have proper
full set of VREL_* relations for NANs (though it would be really nice
if op1_op2_relation could be passed
These functions are NOPs on the soft-float ABIs. Since we're already
forcing the ISA, let's just force the ABI too.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/xtheadfmv-fmv.c: Force the ilp32d ABI.
---
This one is also in the testing queue. OK for trunk?
---
Dear all,
the testcase in the PR by Gerhard exhibited a mis-treatment of
the function decl of the entry master if the function result
had a pointer attribute and the translation unit was compiled
with -ff2c. We actually should not use the peculiar special
treatment for default-real functions in
Hi!
On 2022-12-06T14:47:26+, Gaius Mulley via Gcc-patches
wrote:
> This patch set consists of the libgm2 makefile, autoconf sources
> necessary to build the libm2pim, libm2iso, libm2min, libm2cor
> and libm2log.
Notice:
> --- /dev/null 2022-08-24 16:22:16.88870 +0100
> +++
The test case that was added is rv64i-specific, as there's better ways
to generate this code on rv32i (where the long/int cast is a NOP) and on
rv64i_zba (where we have word shifts). This renames the original test
case and adds two more for those targets.
gcc/testsuite/ChangeLog:
PR
On Tue, Apr 11, 2023 at 11:47 AM Martin Uecker via Gcc-patches
wrote:
>
>
>
> Ok, here is another attempt on fixing issues with size expression.
> Not all are regressions, but it does not make sense to try to split
> it up.
They might be regressions still from pre gimple (3.4 and before),
though
Ok, here is another attempt on fixing issues with size expression.
Not all are regressions, but it does not make sense to try to split
it up.
Martin
Fix ICEs related to VM types in C [PR106465, PR107557, PR108424,
PR109450]
Size expressions were sometimes lost and not
On 4/9/23 23:07, Lin Sinan via Gcc-patches wrote:
From: Sinan Lin
there is no need to split an xori/ori with an small constant. take the test
case `int foo(int idx) { return idx|3; }` as an example,
rv64im_zba generates:
ori a0,a0,3
ret
but, rv64im_zba_zbs generates:
On 4/10/23 14:59, Philipp Tomsich wrote:
On Mon, 10 Apr 2023 at 17:57, Jeff Law wrote:
On 4/9/23 23:07, Lin Sinan via Gcc-patches wrote:
From: Sinan Lin
there is no need to split an xori/ori with an small constant. take the test
case `int foo(int idx) { return idx|3; }` as an example,
On Tue, Apr 11, 2023 at 05:40:09PM +0800, Kewen.Lin wrote:
> on 2023/4/11 17:14, guojiufu wrote:
> > Thanks for raising this concern.
> > The behavior to check about bif on FLOAT128_HW and emit an error message for
> > requirements on quad-precision is added in gcc12. This is why gcc12 fails to
>
On Tue, 11 Apr 2023 at 15:59, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk perhaps?
Yes, this is only for C++23 so OK for trunk now.
The auto(x) uses mean this won't work with older versions of Clang,
but that's OK. I already introduced that
On Tue, 11 Apr 2023 at 15:58, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk/12?
OK for all, thanks.
(This hasn't been approved by LWG yet, but it should be soon.)
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges
Tested on x86_64-pc-linux-gnu, does this look OK for trunk perhaps?
libstdc++-v3/ChangeLog:
* include/std/ranges (__cpp_lib_ranges_enumerate): Define
for C++23.
(__detail::__range_with_movable_reference): Likewise.
(enumerate_view): Likewise.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/12?
libstdc++-v3/ChangeLog:
* include/std/ranges (lazy_split_view::_OuterIter::_OuterIter):
Propagate _M_trailing_empty in the const-converting constructor
as per LWG 3904.
*
Hi Jerry, all,
On 4/11/23 02:43, Jerry D via Gcc-patches wrote:
On 4/10/23 1:49 PM, Harald Anlauf via Fortran wrote:
Dear all,
when comparing formal and actual arguments of a procedure, there was no
check of rank for derived types from intrinsic module ISO_C_BINDING.
This could lead to a
On Thu, 26 Jan 2023, Jason Merrill wrote:
> On 1/25/23 15:35, Patrick Palka wrote:
> > On Tue, 17 Jan 2023, Jason Merrill wrote:
> >
> > > On 1/9/23 14:25, Patrick Palka via Gcc-patches wrote:
> > > > On Mon, 9 Jan 2023, Patrick Palka wrote:
> > > >
> > > > > On Wed, 5 Oct 2022, Patrick Palka
Hi Yanzhang:
Thanks, applied to trunk now, and also congrats for your first patch on GCC!
On Tue, Apr 11, 2023 at 8:00 PM Wang, Yanzhang wrote:
>
> Hi Kito, Juzhe, Jeff,
>
> Thanks for your kindly reviews. I have modified based on the comments and ran
> the testsuite on my local. Could you
On Tue, 11 Apr 2023 at 14:17, Richard Biener wrote:
>
> On Wed, Apr 5, 2023 at 10:39 AM Prathamesh Kulkarni via Gcc-patches
> wrote:
> >
> > Hi,
> > For the following test:
> >
> > svint32_t f(svint32_t v)
> > {
> > return svrev_s32 (svrev_s32 (v));
> > }
> >
> > We generate 2 rev instructions
Let me give more explanation why RISC-V vector need so many modes than AArch64.
The following will use "RVV" as an abbreviation for "RISC-V Vector"
instructions.
There are two key points here:
- RVV has a concept called LMUL - you can understand that as register
grouping, we can group up to 8
Hi, Joseph,
This is the 2nd ping to the 6th version of the patch -:)
Please let me know if you have any further comments on the patch, and whether
it’s Okay to commit it to trunk?
Thanks a lot for the help.
Qing
Begin forwarded message:
From: Qing Zhao via Gcc-patches
Hi, Jakub,
This is the 2nd ping to the 6th version of the patches -:)
Please let me know if you have any further comments on this patch, and whether
it’s Okay to commit it to trunk?
Thanks a lot for the help.
Qing
Begin forwarded message:
From: Qing Zhao via Gcc-patches
Hi, Joseph and Jakub,
This is the 2nd ping to the 6th version of the patches -:)
Please let me know if you have any further comments on the patches, and whether
it’s Okay to commit them to trunk?
Thanks a lot for the help.
Qing
Begin forwarded message:
From: Qing Zhao
"juzhe.zh...@rivai.ai" writes:
> Hi, Richards.
> Kindly Ping this patch.
> This is the most important patch for RVV auto-vectorization support.
> Bootstraped on X86 has passed.
Can it wait for GCC 14? It doesn't seem like stage 4 material.
Also, pinging after 5 days seems a bit soon. It's
Hi, Richards.
Kindly Ping this patch.
This is the most important patch for RVV auto-vectorization support.
Bootstraped on X86 has passed.
Feel free to comments.
Thanks.
juzhe.zh...@rivai.ai
From: juzhe.zhong
Date: 2023-04-07 09:47
To: gcc-patches
CC: richard.sandiford; rguenther;
Hi Kito, Juzhe, Jeff,
Thanks for your kindly reviews. I have modified based on the comments and ran
the testsuite on my local. Could you please take another look ? If any more
comments please let me know.
Thanks
Yanzhang
> -Original Message-
> From: Wang, Yanzhang
> Sent: Tuesday,
From: Yanzhang Wang
This patch registers a riscv specific function to
TARGET_ZERO_CALL_USED_REGS instead of default in targhooks.cc. It will
clean gpr and vector relevant registers.
PR 109104
gcc/ChangeLog:
* config/riscv/riscv-protos.h (emit_hard_vlmax_vsetvl):
*
Oh, sorry for didn't explain this clearly.
In this example, the "vle32" should be using same VL as "vadd" that I didn't
mention.
But we do have other instructions doesn't care about VL operand. So let me
explain more clearly.
Same example I repeated again:
Loop:
{
bb 0:
vsetvl VL, e8,mf8,TA
Commit r13-7137 fixes thethe dump issue with -m32, cf. attachment.
Tobias
On 09.04.23 00:11, haochen.jiang via Gcc-patches wrote:
Fortran: Fix dg directives and remove trailing whitespaces in testsuite
caused
FAIL: gfortran.dg/gomp/affinity-clause-1.f90 -O scan-tree-dump-times
On Tue, Apr 11, 2023 at 11:19 AM juzhe.zh...@rivai.ai
wrote:
>
> No, we can only pass "available" to LCM.
> Passing "compatible" to LCM can not work for us.
>
> LCM can only help for eliminate vsetvls can not help for fuse vsetvls.
>
> For example:
>
> bb 0:
> vsetvl e8,mf8
> vadd (Demand SEW =
9 bit (512 modes) mode should be enough for RVV.
In the future, I would expect we will have BF16 vector, FP16 vector,.. matrix
modes.
And I think it will not be more 512 modes in the future.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-04-11 19:11
To: Richard Biener
CC:
Richard Biener writes:
> On Tue, 11 Apr 2023, Richard Sandiford wrote:
>
>> writes:
>> > ARM SVE has?svint8_t, svint8x2_t, svint8x3_t, svint8x4_t
>> > As far as I known, they don't have tuple type for partial vector.
>>
>> Yeah, there are no separate types for partial vectors, but there
>> are
On Tue, 11 Apr 2023, Richard Sandiford wrote:
> writes:
> > ARM SVE has?svint8_t, svint8x2_t, svint8x3_t, svint8x4_t
> > As far as I known, they don't have tuple type for partial vector.
>
> Yeah, there are no separate types for partial vectors, but there
> are separate modes. E.g. VNx2QI is a
On Tue, Apr 11, 2023 at 06:25:58PM +0800, juzhe.zh...@rivai.ai wrote:
> Explicit sets multiple VNx1SImode with multiple dest operand and let RA to
> assign them with continguous regsiters
> will make RTL patterns in RVV hard to maintain.
Not necessarily. It can be handled through define_subst.
On Tue, 11 Apr 2023, Jakub Jelinek wrote:
> On Wed, Apr 05, 2023 at 02:11:08PM +0200, Richard Biener wrote:
> > Ok, but maybe there?s a gimple_build overload that meanwhile implements
> > the desired semantics? It would probably need to specify the valueization
> > hook to follow SSA edges
gcc/Changelog:
* gcc/config/arm/arm.cc(arm_print_asm_arch_directives): fix compatability
typo
* gcc/fortran/gfortran.texi(intrinsics): fix compatability typo
* gcc/fortran/invoke.texi(-fdec-math): fix compatability typo
* gcc/m2/gm2-compiler/M2Base.def(CannotCheckTypeInPass3): fix
Explicit sets multiple VNx1SImode with multiple dest operand and let RA to
assign them with continguous regsiters
will make RTL patterns in RVV hard to maintain.
Assume we have a new pattern flag to tell RA assign continguous registers for
multiple dest operand, and RA can handle this:
in RVV,
Richard Earnshaw writes:
> On 11/04/2023 10:46, Richard Sandiford via Gcc-patches wrote:
>> writes:
>>> ARM SVE has：svint8_t, svint8x2_t, svint8x3_t, svint8x4_t
>>> As far as I known, they don't have tuple type for partial vector.
>>
>> Yeah, there are no separate types for partial vectors, but
On Tue, Apr 11, 2023 at 05:46:15PM +0800, juzhe.zh...@rivai.ai wrote:
> I am not sure whether aggregate type without a tuple mode can work for us.
> Here is the example:
>
> We already had a vector type "vint8mf8_t", the corresponding mode is
> VNx1SImode.
>
> Now we have an intrinsic as
May RTX code grow faster than machine mode ?
Since RTX code grows target independent wheras
machine mode grows target dependent.
In the future, we may easily have more and more targets that some target may
have a lot of machine mode.
Maybe Richard Sandiford suggestion is a good idea to fix it?
Richard Biener via Gcc-patches writes:
> On Mon, Mar 27, 2023 at 6:02 PM Kevin Lee wrote:
>>
>> This patch is a proper fix to the previous patch
>> https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614463.html
>> vect_grouped_store_supported checks if the count is a power of 2, but
>> doesn't
On 11/04/2023 10:46, Richard Sandiford via Gcc-patches wrote:
writes:
ARM SVE has：svint8_t, svint8x2_t, svint8x3_t, svint8x4_t
As far as I known, they don't have tuple type for partial vector.
Yeah, there are no separate types for partial vectors, but there
are separate modes. E.g.
On Tue, Apr 11, 2023 at 10:46:25AM +0100, Richard Sandiford wrote:
> I agree with all the comments about the danger of growing the number of
> modes too much. But it looks like rtx_def should be easy to rearrange.
> Unless I'm missing something, there are less than 256 rtx codes at
> present. So
writes:
> ARM SVE has：svint8_t, svint8x2_t, svint8x3_t, svint8x4_t
> As far as I known, they don't have tuple type for partial vector.
Yeah, there are no separate types for partial vectors, but there
are separate modes. E.g. VNx2QI is a partial vector of QIs,
with each QI stored in a 64-bit
I am not sure whether aggregate type without a tuple mode can work for us.
Here is the example:
We already had a vector type "vint8mf8_t", the corresponding mode is VNx1SImode.
Now we have an intrinsic as following:
vint8mf8x2_t test_vlseg2e8_v_i8mf8(const int8_t *base, size_t vl) {
return
Hi Evandro,
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Evandro
> Menezes via Gcc-patches
> Sent: Friday, April 7, 2023 11:34 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Evandro Menezes ; Richard Sandiford
>
> Subject: [PATCH] aarch64:
Hi Jeff,
on 2023/4/11 17:14, guojiufu wrote:
> Hi Kewen,
>
> Thanks a lot for your very helpful comments!
>
> On 2023-04-10 17:26, Kewen.Lin wrote:
>> Hi Jeff,
>>
>> on 2023/4/10 10:09, Jiufu Guo via Gcc-patches wrote:
>>> Hi,
>>>
>>> In this test case (float128-cmp2-runnable.c), the
On Mon, Mar 27, 2023 at 6:02 PM Kevin Lee wrote:
>
> This patch is a proper fix to the previous patch
> https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614463.html
> vect_grouped_store_supported checks if the count is a power of 2, but
> doesn't check the size of the GET_MODE_NUNITS.
> This
On Thu, Apr 6, 2023 at 3:58 PM Martin Liška wrote:
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed after stage1 opens?
Did we release a compiler with version 1? If not we might want to sneak
this in before 13.1 ...
Up to Honza.
Thanks,
On Wed, Apr 5, 2023 at 11:53 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 4/5/23 14:10, Andrew MacLeod via Gcc-patches wrote:
> > When a statement is first processed, any SSA_NAMEs that are dependencies
> > are cached for quick future access.
> >
> > if we ;later rewrite the statement (say
No, we can only pass "available" to LCM.
Passing "compatible" to LCM can not work for us.
LCM can only help for eliminate vsetvls can not help for fuse vsetvls.
For example:
bb 0:
vsetvl e8,mf8
vadd (Demand SEW = 8, LMUL = MF8)
bb 1:
vsetvl e32 mf2
vle32 (Demand RATIO (SEW/LMUL) = 64, so
On Mon, Apr 10, 2023 at 11:14:46PM +0800, juzhe.zh...@rivai.ai wrote:
> ARM SVE has：svint8_t, svint8x2_t, svint8x3_t, svint8x4_t
> As far as I known, they don't have tuple type for partial vector.
> However, for RVV not only has vint8m1_t, vint8m1x2_t, vint8m1x3_t,
> vint8m1x4_t, vint8m1x5_t,
Hi Kewen,
Thanks a lot for your very helpful comments!
On 2023-04-10 17:26, Kewen.Lin wrote:
Hi Jeff,
on 2023/4/10 10:09, Jiufu Guo via Gcc-patches wrote:
Hi,
In this test case (float128-cmp2-runnable.c), the instruction
xscmpexpqp is used to support a few builtins e.g.
On Wed, Apr 5, 2023 at 4:06 PM wrote:
>
> Hi everyone,
>
> This patchset contains around 80 commits concerning the Rust frontend.
>
> We have been hard at work trying to get the Rust core library to
> compile, and hope to push more commits in the coming days as we try
> and upstream a more recent
On 4/11/23 10:21, Jakub Jelinek wrote:
Hi!
This patch was what I've tried first before the currently committed
PR109386 fix. Still, I think it is the right thing until we have proper
full set of VREL_* relations for NANs (though it would be really nice
if op1_op2_relation could be passed
On Wed, Apr 5, 2023 at 3:53 PM wrote:
>
> >> So fusion in this context is really about identifying cases where two
> >> configuration settings are equivalent and you "fuse" them together.
> >> Presumably this is only going to be possible when the vector insns are
> >> just doing data movement
On Wed, 5 Apr 2023, Andre Vieira (lists) wrote:
> Hi,
>
> The original patch to fix this PR broke the if-conversion of calls into
> IFN_MASK_CALL. This patch restores that original behaviour and makes sure the
> tests added earlier specifically test inbranch SIMD clones.
OOps.
> Bootstrapped
On Wed, Apr 5, 2023 at 10:39 AM Prathamesh Kulkarni via Gcc-patches
wrote:
>
> Hi,
> For the following test:
>
> svint32_t f(svint32_t v)
> {
> return svrev_s32 (svrev_s32 (v));
> }
>
> We generate 2 rev instructions instead of nop:
> f:
> rev z0.s, z0.s
> rev z0.s, z0.s
On Tue, 4 Apr 2023, David Malcolm wrote:
> Richi, Jakub: I can probably self-approve this, but it's technically a
> new feature. OK if I push this to trunk in stage 4? I believe it's
> low risk, and is very useful for benchmarking -fanalyzer.
Please wait for stage1 at this point. One comment
On Mon, Apr 3, 2023 at 11:03 AM Martin Liška wrote:
>
> Hi.
>
> The patch propagates noreturn attribute for MV functions. However, I noticed
> we've got the following ICE when we do the same for TREE_READONLY attr:
>
> $ cat tc.c
> double bar()
On Mon, Apr 3, 2023 at 10:46 AM Martin Liška wrote:
>
> The revision r13-259-g76db543db88727 moved a condition from one
> file to another, but now we do not drop x_flag_var_tracking_assignments
> as it was done before the mentioned revision.
>
> Patch can bootstrap on x86_64-linux-gnu and
Hi!
This patch was what I've tried first before the currently committed
PR109386 fix. Still, I think it is the right thing until we have proper
full set of VREL_* relations for NANs (though it would be really nice
if op1_op2_relation could be passed either type of the comparison
operands, or
On Tue, 4 Apr 2023, Jan Hubicka wrote:
> > On Tue, Apr 04, 2023 at 01:21:40AM +0200, Jan Hubicka via Gcc-patches wrote:
> > > It is however really side case and I am worried about dropping
> > > pure/const from builtin declarations...
> >
> > Yeah, that can certainly break stuff. See e.g. the
On Tue, 4 Apr 2023, Jan Hubicka wrote:
> > On Tue, 28 Mar 2023, Richard Biener wrote:
> >
> > > When adjusting calls to reflect instrumentation we failed to handle
> > > calls to aliases since they appear to have no body. Instead resort
> > > to symtab node availability. The patch also avoids
Hi!
When working on the PR109040 fix, I wanted to test it on some
WORD_REGISTER_OPERATIONS target and tried sparc-solaris on GCC Farm.
My bootstrap failed in comparison failure on cp/module.o, because
Solaris date doesn't support the -r option and one stage's cp/module.o
was built before midnight
On Wed, Apr 05, 2023 at 02:11:08PM +0200, Richard Biener wrote:
> Ok, but maybe there’s a gimple_build overload that meanwhile implements
> the desired semantics? It would probably need to specify the valueization
> hook to follow SSA edges beyond the sequence we’re currently building.
Jeff has
On 05/12/2022 10:40, Jørgen Kvalsvik wrote:
> This patch adds support in gcc+gcov for modified condition/decision
> coverage (MC/DC) with the -fprofile-conditions flag. MC/DC is a type of
> test/code coverage and it is particularly important in the avation and
> automotive industries for
80 matches
Mail list logo
