Hi,
Gently ping for this.
This version has removed the target hook and added a new optab for cfcmov.
Thanks,
Lingling
From: Kong, Lingling
Sent: Tuesday, June 18, 2024 3:41 PM
To: gcc-patches@gcc.gnu.org
Cc: Alexander Monakov ; Uros Bizjak ;
lingling.ko...@gmail.com; Hongtao Liu ; Jeff Law
Got it, thanks Tamer, will have a try.
Pan
-Original Message-
From: Tamar Christina
Sent: Tuesday, June 25, 2024 2:11 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; richard.guent...@gmail.com;
jeffreya...@gmail.com; pins...@gmail.com
Subject:
Ping. [Message-ID: <1e003d78-3b2e-4263-830a-7c00a3e9d...@linux.ibm.com>]
Peter
On 6/18/24 5:59 PM, Peter Bergner wrote:
> Updated patch. This passed bootstrap and regtesting on powerpc64le-linux
> with no regressions. Ok for trunk?
>
> Changes from v1:
> 1. Moved the disabling of shrink
> -Original Message-
> From: Li, Pan2
> Sent: Tuesday, June 25, 2024 7:06 AM
> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; richard.guent...@gmail.com;
> jeffreya...@gmail.com; pins...@gmail.com
> Subject: RE: [PATCH v2] Vect: Support trun
> Ah, no you're right, those would end up wrong for saturation. Arg.. Sorry
> should have
> though it through more.
Never mind, but you enlighten me for even more optimize with some restrictions.
I revisited the pattern, for example as below.
uint16_t a, b;
uint8_t result = (uint8_t)(a >= b ?
On 6/24/24 8:49 PM, Mark Harmstone wrote:
On 24/6/24 04:39, Jeff Law wrote:
So presumably you're freeing these objects elsewhere? I see the free
(custom_types), but I don' see where you free an subobjects. Did I
miss something?
I'll go ahead and commit, but please double check for memo
On 6/17/24 6:17 PM, Mark Harmstone wrote:
Translates DW_TAG_structure_type DIEs into LF_STRUCTURE symbols, and
DW_TAG_class_type DIEs into LF_CLASS symbols.
gcc/
* dwarf2codeview.cc
(struct codeview_type): Add is_fwd_ref member.
(struct codeview_sub
This fixes most, but not all of the testsuite fallout from the
late-combine patch. Specifically in the vector space we're often able
to eliminate a broadcast of an scalar element across a vector. That
eliminates the vsetvl related to the broadcast, but more importantly
from the testsuite stan
Ping.
On Mon, Jun 10, 2024 at 07:19:19AM +0200, Stefan Schulze Frielinghaus wrote:
> Ping.
>
> On Fri, May 24, 2024 at 11:13:12AM +0200, Stefan Schulze Frielinghaus wrote:
> > This implements hard register constraints for inline asm. A hard register
> > constraint is of the form {regname} where
The problem here is even though we pass std namespace to lookup_template_class
as the context, it will look at the current scope for the name too.
The fix is to lookup the qualified name first and then use that
for lookup_template_class.
This is how std::initializer_list is handled in listify.
Not
This was missing when Wnrvo was added in
r14-1594-g2ae5384d457b9c67586de012816dfc71a6943164 .
Pushed to the trunk and GCC 14 branch as obvious after a bootstrap/test on
x86_64-linux-gnu.
gcc/c-family/ChangeLog:
PR C++/115624
* c.opt (Wnrvo): Add Warning property.
Signed-off-by:
On Mon, Jun 24, 2024 at 7:35 PM Andrew Pinski wrote:
>
> On Mon, Jun 24, 2024 at 7:20 PM Andrew MacLeod wrote:
> >
> >
> > On 6/22/24 09:15, Richard Biener wrote:
> > > On Fri, Jun 21, 2024 at 3:02 PM Andrew MacLeod
> > > wrote:
> > >> This patch adds
> > >>
> > >> --param=vrp-block-limit
> -Original Message-
> From: Li, Pan2
> Sent: Tuesday, June 25, 2024 3:25 AM
> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; richard.guent...@gmail.com;
> jeffreya...@gmail.com; pins...@gmail.com
> Subject: RE: [PATCH v2] Vect: Support trun
Hi,
This is the current version.
I haven't made any major changes to the original code, I think it will have
less impact on your code. And I think the current API is sufficient to support
the mode selection you mentioned, if you have any concerns you can mention
them. I can tweak it further.
Thanks for taking a look!
Things have changed after I posted this patch and LLVM doesn't support
this option now, so I think we don't need this patch any more.
Please see this PR and its references:
https://github.com/riscv-non-isa/riscv-c-api-doc/pull/62.
On 2024/6/25 2:17, Palmer Dabbelt wrot
Kewen:
On 6/18/24 20:03, Kewen.Lin wrote:
> Hi Carl,
>
> on 2024/6/14 03:40, Carl Love wrote:
>> GCC maintainers:
>>
>> Per the comments on patch 0004 from version 3, the removal of
>> The built-in __builtin_vsx_xvcvdpuxds_uns and __builtin_vsx_xvcvspuxws was
>> moved to this patch. The rest o
On 24/6/24 04:39, Jeff Law wrote:
So presumably you're freeing these objects elsewhere? I see the free
(custom_types), but I don' see where you free an subobjects. Did I miss
something?
I'll go ahead and commit, but please double check for memory leaks.
Thanks Jeff. I just realized I wro
On Mon, Jun 24, 2024 at 7:20 PM Andrew MacLeod wrote:
>
>
> On 6/22/24 09:15, Richard Biener wrote:
> > On Fri, Jun 21, 2024 at 3:02 PM Andrew MacLeod wrote:
> >> This patch adds
> >>
> >> --param=vrp-block-limit=N
> >>
> >> When the basic block counter for a function exceeded 'N' , VRP is
Thanks Tamar for comments. It indeed benefits the vectorized code, for example
in RISC-V, we may eliminate some vsetvel insn in loop for widen here.
> iftmp.0_5 = .SAT_SUB ((short unsigned int) a_11, (short unsigned int)
> b_12(D));
> is cheaper than
> iftmp.0_5 = (short unsigned int).SAT_SUB (a
On 6/22/24 09:15, Richard Biener wrote:
On Fri, Jun 21, 2024 at 3:02 PM Andrew MacLeod wrote:
This patch adds
--param=vrp-block-limit=N
When the basic block counter for a function exceeded 'N' , VRP is
invoked with the new fast_vrp algorithm instead. This algorithm uses a
lot less me
Transitive relations can add processing time to the relation oracle as
they need to look up previous relations. This that may not be desired,
especially for something like fast VRP. This patch adds a flag at
oracle creation time which makes processing them optional.
Bootstraps on x86_64-pc
On 6/17/24 14:17, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
In r13-272 we hardened the *_PACK_EXPANSION and *_ARGUMENT_PACK macros.
That trips up here because make_pack_expansion returns error_mark_node
and we access that with PACK_EXPANSIO
On 6/18/24 10:31, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14/13?
Makes sense to me, though probably the [meta.unary.prop] table should be
adjusted in the same way. Jonathan, what do you think?
-- >8 --
Here we started to ICE with r13-25: in check_tr
On 6/18/24 10:58, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
Since r13-3299, build_dynamic_cast_1 calls pushdecl which calls
duplicate_decls and that in this testcase emits the "conflicting
declaration" error and returns error_mark_node, so
> -Original Message-
> From: Tamar Christina
> Sent: Monday, June 24, 2024 10:12 PM
> To: Richard Biener ; Hu, Lin1
> Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao ;
> ubiz...@gmail.com
> Subject: RE: [PATCH 1/3 v3] vect: generate suitable convert insn for int ->
> int,
> float -> float and
On 6/24/24 21:00, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14?
-- >8 --
The capture proxy handling in finish_decltype_type added in r14-5330
was stripping the reference type of a capture proxy's captured variable,
which is desirable for
On 6/24/24 21:00, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk? This fixes PR115358 whose testcase used a constexpr static
array variable, but it seems the general issue is not specific to
constexpr as illustrated by the below testcase. Not
On 6/18/24 20:03, Kewen.Lin wrote:
> Hi Carl,
>
> on 2024/6/14 03:40, Carl Love wrote:
>>
>> GCC maintainers:
>>
>> As noted the removal of __builtin_vsx_xvcvdpuxds_uns and
>> __builtin_vsx_xvcvspuxws was moved to patch 2 in the seris. The patch has
>> been updated per the comments from vers
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk? This fixes PR115358 whose testcase used a constexpr static
array variable, but it seems the general issue is not specific to
constexpr as illustrated by the below testcase. Note that Clang
currently rejects the testca
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14?
-- >8 --
The capture proxy handling in finish_decltype_type added in r14-5330
was stripping the reference type of a capture proxy's captured variable,
which is desirable for a by-value capture, but not for a by-ref
So this is the cmpmem patch from Sergei, updated for the trunk.
Updates included adjusting the existing cmpmemsi expander to
conditionally try expansion via vector. And a minor testsuite
adjustment to turn off vector expansion in one test that is primarily
focused on vset optimization and ens
On Sat, 2024-06-22 at 11:26 +0300, Dimitar Dimitrov wrote:
> On Fri, Jun 21, 2024 at 08:55:36AM -0400, David Malcolm wrote:
> > This patch extends the dg directive verify-sarif-file so that if
> > the "jsonschema" tool is available, it will be used to validate the
> > generated .sarif file.
> >
>
On Fri, 2024-06-14 at 10:16 +0800, Kewen.Lin wrote:
> Hi David,
>
> on 2024/6/13 21:44, David Malcolm wrote:
> > On Sun, 2024-06-02 at 22:01 -0500, Kewen Lin wrote:
> > > Joseph pointed out "floating types should have their mode,
> > > not a poorly defined precision value" in the discussion[1],
>
In r14-5118-gc5db4d8ba5f3de I added a mechanism to automatically add
documentation URLs to quoted strings in diagnostics.
In r14-6920-g9e49746da303b8 I added a mechanism to generate URLs for
mentions of command-line options in quoted strings in diagnostics.
This patch does a similar thing for attr
On Mon, 24 Jun 2024 at 21:33, Alexandre Oliva wrote:
>
>
> libatomic hasn't been ported to vxworks. Most of the stdatomic.h and
> underlying requirements are provided by builtins and libgcc,
> and the vxworks libc already provides remaining __atomic symbols, so
> porting libatomic doesn't seem t
On Sun, Jun 23, 2024 at 08:42:36PM +0200, Martin Uecker wrote:
>
> This adds an explicit error message for [static] and [static*]
> (the same as clang has) instead of the generic "error: expected
> expression before ']' token", which is not entirely accurate.
> For function definitions the subseq
libatomic hasn't been ported to vxworks. Most of the stdatomic.h and
underlying requirements are provided by builtins and libgcc,
and the vxworks libc already provides remaining __atomic symbols, so
porting libatomic doesn't seem to make sense.
However, some of the target arch-only tests in
ad
On 12/19/23 2:53 AM, Sergei Lewis wrote:
gcc/ChangeLog
* config/riscv/riscv-protos.h (riscv_vector::expand_vec_setmem): New
function
declaration.
* config/riscv/riscv-string.cc (riscv_vector::expand_vec_setmem): New
function: this generates an inline vectorised memory se
Committed.
Patrick
On 6/24/24 12:06, Patrick O'Neill wrote:
This introduces testsuite support infra for removing extensions.
Since z* extensions don't have ordering requirements the logic for
adding/removing those extensions has also been consolidated.
This fixes RVWMO compile testcases failin
Hi,
> -Original Message-
> From: pan2...@intel.com
> Sent: Monday, June 24, 2024 2:55 PM
> To: gcc-patches@gcc.gnu.org
> Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; richard.guent...@gmail.com;
> jeffreya...@gmail.com; pins...@gmail.com; Pan Li
> Subject: [PATCH v2] Vect: Support trun
I didn't see this before. Sigh.
On Tue, Jan 02, 2024 at 09:47:11AM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Tue, Oct 24, 2023 at 07:49:10PM +0100, Richard Sandiford wrote:
> >> This patch adds a combine pass that runs late in the pipeline.
> >
> > But it is not. It i
On Jun 24, 2024, "Richard Earnshaw (lists)" wrote:
> A signed shift right on a 16-bit vector element by 15 would still
> yield -1
Yeah. Indeed, ISTM that we *could* have retained the clamping
transformation for *signed* shifts, since the clamping would only make a
difference in case of (undefin
This introduces testsuite support infra for removing extensions.
Since z* extensions don't have ordering requirements the logic for
adding/removing those extensions has also been consolidated.
This fixes RVWMO compile testcases failing on Ztso targets by removing
the extension from the -march stri
Hi,
Gently ping it.
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653096.html
Thanks
Gui Haochen
在 2024/6/20 14:56, HAO CHEN GUI 写道:
> Hi,
> Gently ping it.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653096.html
>
> Thanks
> Gui Haochen
>
> 在 2024/5/30 10:46, HAO CHEN GUI 写道:
On 6/24/24 09:11, David Faust wrote:
Ping.
Richard: I changed the option name as you asked but forgot to CC you on
the updated patch. Is the new option OK?
Indu: You had some minor comments on the prior version which I have
addressed, not sure whether you meant the rest of the patch was OK or
On Fri, 22 Dec 2023 01:23:13 PST (-0800), wangpengcheng...@bytedance.com wrote:
These two options are negative alias of -m[no-]strict-align.
This matches LLVM implmentation.
gcc/ChangeLog:
* config/riscv/riscv.opt: Add option alias.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/predef-align-10
This introduces testsuite support infra for removing extensions.
Since z* extensions don't have ordering requirements the logic for
adding/removing those extensions has also been consolidated.
This fixes RVWMO compile testcases failing on Ztso targets by removing
the extension from the -march stri
Hi,
Gently ping it.
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653094.html
Thanks
Gui Haochen
在 2024/6/20 14:57, HAO CHEN GUI 写道:
> Hi,
> Gently ping it.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653094.html
>
> Thanks
> Gui Haochen
>
> 在 2024/5/30 10:46, HAO CHEN GUI 写道:
On 24/06/2024 12:35, Alexandre Oliva wrote:
> On Jun 21, 2024, Christophe Lyon wrote:
>
>>> How about mentioning Christophe's simplification in the commit log?
>
>> For the avoidance of doubt: it's OK for me (but you don't need to
>> mention my name in fact ;-)
>
> Needing or not, I added it ;-
Ping.
archive: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654253.html
On 6/11/24 12:01, David Faust wrote:
> Previously it was not supported to generate both CTF and BTF debug info
> in the same compiler run, as both formats made incompatible changes to
> the same internal data structure
Ping.
Richard: I changed the option name as you asked but forgot to CC you on
the updated patch. Is the new option OK?
Indu: You had some minor comments on the prior version which I have
addressed, not sure whether you meant the rest of the patch was OK or
not, or if you had a chance to review i
Hi,
Commit r12-4496 changes some define_expands and define_insns
for vector merge high/low char, which are altivec_vmrg[hl]b.
These defines are mainly for built-in function vec_merge{h,l}
and some internal gen function needs. These functions should
consider endianness, taking vec_mergeh as exampl
> -Original Message-
> From: Richard Biener
> Sent: Thursday, June 20, 2024 8:55 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; bin.ch...@linux.alibaba.com
> Subject: RE: [PATCH][ivopts]: perform affine fold on unsigned addressing modes
> known not to overflow. [PR114932]
>
On Jun 21, 2024, Christophe Lyon wrote:
>> How about mentioning Christophe's simplification in the commit log?
> For the avoidance of doubt: it's OK for me (but you don't need to
> mention my name in fact ;-)
Needing or not, I added it ;-)
>> > be accepted. (int16_t)32768 >> (int16_t)16 must
> -Original Message-
> From: Richard Biener
> Sent: Monday, June 24, 2024 1:34 PM
> To: Hu, Lin1
> Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao ;
> ubiz...@gmail.com
> Subject: RE: [PATCH 1/3 v3] vect: generate suitable convert insn for int ->
> int, float
> -> float and int <-> float.
>
>
From: Pan Li
The zip benchmark of coremark-pro have one SAT_SUB like pattern but
truncated as below:
void test (uint16_t *x, unsigned b, unsigned n)
{
unsigned a = 0;
register uint16_t *p = x;
do {
a = *--p;
*p = (uint16_t)(a >= b ? a - b : 0); // Truncate after .SAT_SUB
} while
> -Original Message-
> From: Richard Biener
> Sent: Thursday, June 20, 2024 8:49 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; bin.ch...@linux.alibaba.com
> Subject: RE: [PATCH][ivopts]: use affine_tree when comparing IVs during
> candidate
> selection [PR114932]
>
> O
On Sun, Jun 23, 2024 at 5:10 PM Feng Xue OS wrote:
>
> >> - if (slp_node)
> >> + if (slp_node && SLP_TREE_LANES (slp_node) > 1)
> >
> > Hmm, that looks wrong. It looks like SLP_TREE_NUMBER_OF_VEC_STMTS is off
> > instead, which is bad.
> >
> >> nvectors = SLP_TREE_NUMBER_OF_VEC_
On Thu, 20 Jun 2024, Hu, Lin1 wrote:
> > >else if (ret_elt_bits > arg_elt_bits)
> > > modifier = WIDEN;
> > >
> > > + if (supportable_convert_operation (code, ret_type, arg_type, &code1))
> > > +{
> > > + g = gimple_build_assign (lhs, code1, arg);
> > > + gsi_replace (gsi,
On Sat, Jun 22, 2024 at 12:26 AM David Malcolm wrote:
>
> PR analyzer/115564 reports a missing warning from the analyzer
> on this infinite loop at -O2 and above:
>
> void test (unsigned b)
> {
>for (unsigned i = b; i >= 0; --i) {}
> }
>
> The issue is that there are no useful location_t va
On Fri, Jun 21, 2024 at 10:51 PM Roger Sayle wrote:
>
>
> Hi Richard,
> Thanks for the review and apologies for taking so long to get back to this.
> This revision implements your suggestions from early May, as found at
> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650405.html
>
> This patc
On Mon, Jun 24, 2024 at 1:34 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Mon, Jun 24, 2024 at 10:03 AM Richard Sandiford
> > wrote:
> >>
> >> Richard Biener writes:
> >> > On Sat, Jun 22, 2024 at 6:50 PM Richard Sandiford
> >> >> The traditional (and IMO correct) way to handle
The following prevents SLP CSE to create new cycles which happened
because of a 1:1 permute node being present where its child was then
CSEd to the permute node. Fixed by making a node only available to
CSE to after recursing.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
Richard Biener writes:
> On Mon, Jun 24, 2024 at 10:03 AM Richard Sandiford
> wrote:
>>
>> Richard Biener writes:
>> > On Sat, Jun 22, 2024 at 6:50 PM Richard Sandiford
>> >> The traditional (and IMO correct) way to handle this is to make the
>> >> pattern reserve the temporary registers that it
On Mon, Jun 24, 2024 at 1:18 PM Malladi, Rama wrote:
>
> From: Rama Malladi
Hmm, if we offer the ability to set -O3 inline limits why wouldn't we
offer a way to set -O2 inline limits for example with -O3? So ... wouldn't
a -finline-limit={default,O2,O3} option be a more generic and
extensible w
On Mon, Jun 24, 2024 at 10:03 AM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Sat, Jun 22, 2024 at 6:50 PM Richard Sandiford
> >> The traditional (and IMO correct) way to handle this is to make the
> >> pattern reserve the temporary registers that it needs, using
> >> match_scratch
On Mon, Jun 24, 2024 at 3:39 AM HAO CHEN GUI wrote:
>
> Hi,
> Gently ping it.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653001.html
OK
> Thanks
> Gui Haochen
>
> 在 2024/6/17 13:30, HAO CHEN GUI 写道:
> > Hi,
> > Gently ping it.
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-May/
On Mon, Jun 24, 2024 at 3:38 AM HAO CHEN GUI wrote:
>
> Hi,
> Gently ping it.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652991.html
OK
> Thanks
> Gui Haochen
>
> 在 2024/6/17 13:29, HAO CHEN GUI 写道:
> > Hi,
> > Gently ping it.
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-May/
From: Rama Malladi
Signed-off-by: Rama Malladi
---
gcc/common.opt | 5 +
gcc/doc/invoke.texi | 18 +-
gcc/opts.cc | 17 -
3 files changed, 30 insertions(+), 10 deletions(-)
diff --git a/gcc/common.opt b/gcc/common.opt
index f2bc47fdc5e..ce95175c1e4
On Linux/x86_64,
ea8061f46a301797e7ba33b52e3b4713fb8e6b48 is the first bad commit
commit ea8061f46a301797e7ba33b52e3b4713fb8e6b48
Author: Haochen Gui
Date: Mon Jun 24 13:12:51 2024 +0800
fwprop: invoke change_is_worthwhile to judge if a replacement is worthwhile
caused
FAIL: gcc.target/i
This patch tries to address the issue in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115413 .
It does so by adding another pass devirtualize-typeid which does the same thing
as the value range propagation pass, except
* in the true branch of a conditional of the form `typeid (a) == typeid (b)`
On 6/23/24 16:40, Pali Rohár wrote:
Add missing msvcr40* and msvcrtd* cases to CPP_SPEC and
document missing _UCRT macro and msvcr71* case.
Fixes commit 453cb585f0f8673a5d69d1b420ffd4b3f53aca00.
Thanks, pushed to master branch.
Hi Dave,
May I ask if you still have some concerns on this patch with some
replies to your previous questions?
BR,
Kewen
on 2024/6/14 10:16, Kewen.Lin wrote:
> Hi David,
>
> on 2024/6/13 21:44, David Malcolm wrote:
>> On Sun, 2024-06-02 at 22:01 -0500, Kewen Lin wrote:
>>> Joseph pointed out "f
Hi,
Commit r12-4496 changes some define_expands and define_insns
for vector merge high/low short, which are altivec_vmrg[hl]h.
These defines are mainly for built-in function vec_merge{h,l}
and some internal gen function needs. These functions should
consider endianness, taking vec_mergeh as examp
Hi,
Gently ping it.
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653001.html
Thanks
Gui Haochen
在 2024/6/17 13:30, HAO CHEN GUI 写道:
> Hi,
> Gently ping it.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653001.html
>
> Thanks
> Gui Haochen
>
> 在 2024/6/3 10:37, HAO CHEN GUI 写道:
Richard Biener writes:
> On Sat, Jun 22, 2024 at 6:50 PM Richard Sandiford
>> The traditional (and IMO correct) way to handle this is to make the
>> pattern reserve the temporary registers that it needs, using match_scratches.
>> rs6000 has many examples of this. E.g.:
>>
>> (define_insn_and_spli
On Jun 24 2024, Mikael Morin wrote:
> tree-pretty-print.cc's op_symbol_code handles them as:
>
> case TRUTH_AND_EXPR:
> case TRUTH_ANDIF_EXPR:
> return "&&";
>
> so no, I don't think they are differentiated.
Only because C does not have a TRUTH_AND_EXPR operator.
--
Andreas Schwab
Hi,
on 2024/6/22 00:15, Carl Love wrote:
> GCC maintainers:
>
> Per the discussion of the dg header changes for test files
> altivec-1-runnable.c and altivec-2-runnable.c it was decided it would be best
> to change the names of the two tests to better align them with the tests that
> they are
Le 23/06/2024 à 22:58, Harald Anlauf a écrit :
Dear all,
the attached patch fixes issues exhibited by the testcase in comment#19 of
PR55978.
First, when passing an allocatable optional dummy array to an optional dummy,
we need to prevent accessing the data component of the array when the argum
79 matches
Mail list logo
