From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/vmsge_vv-1.c: New test.
* gcc.target/riscv/rvv/base/vmsge_vv-2.c: New test.
* gcc.target/riscv/rvv/base/vmsge_vv-3.c: New test.
* gcc.target/riscv/rvv/base/vmsge_vv_m-1.c: New test.
*
On Sat, 11 Feb 2023, juzhe.zh...@rivai.ai wrote:
> Thanks for contributing this.
> Hi, Richard. Can you help us with this issue?
> In RVV, we have vbool8_t (VNx8BImode), vbool16_t (VNx4BImode), vbool32_t
> (VNx2BImode), vbool64_t (VNx1BImode)
> Since we are using 1bit-mask which is 1-BOOL occupy
>> But then GET_MODE_PRECISION (GET_MODE_INNER (..)) should always be 1?
Yes, I think so.
Let's explain RVV more clearly.
Let's suppose we have vector-length = 64bits in RVV CPU.
VNx1BI is exactly 1 consecutive bits.
VNx2BI is exactly 2 consecutive bits.
VNx4BI is exactly 4 consecutive bits.
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/vmseq_vv-1.c: New test.
* gcc.target/riscv/rvv/base/vmseq_vv-2.c: New test.
* gcc.target/riscv/rvv/base/vmseq_vv-3.c: New test.
* gcc.target/riscv/rvv/base/vmseq_vv_m-1.c: New test.
*
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/binop_vv_constraint-2.c: New test.
* gcc.target/riscv/rvv/base/binop_vv_constraint-3.c: New test.
* gcc.target/riscv/rvv/base/binop_vv_constraint-4.c: New test.
*
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* g++.target/riscv/rvv/base/vmsne_vv-1.C: New test.
* g++.target/riscv/rvv/base/vmsne_vv-2.C: New test.
* g++.target/riscv/rvv/base/vmsne_vv-3.C: New test.
* g++.target/riscv/rvv/base/vmsne_vv_m-1.C: New test.
*
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* g++.target/riscv/rvv/base/vmslt_vv-1.C: New test.
* g++.target/riscv/rvv/base/vmslt_vv-2.C: New test.
* g++.target/riscv/rvv/base/vmslt_vv-3.C: New test.
* g++.target/riscv/rvv/base/vmslt_vv_m-1.C: New test.
*
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* g++.target/riscv/rvv/base/vmsle_vv-1.C: New test.
* g++.target/riscv/rvv/base/vmsle_vv-2.C: New test.
* g++.target/riscv/rvv/base/vmsle_vv-3.C: New test.
* g++.target/riscv/rvv/base/vmsle_vv_m-1.C: New test.
*
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* g++.target/riscv/rvv/base/vmsgt_vv-1.C: New test.
* g++.target/riscv/rvv/base/vmsgt_vv-2.C: New test.
* g++.target/riscv/rvv/base/vmsgt_vv-3.C: New test.
* g++.target/riscv/rvv/base/vmsgt_vv_m-1.C: New test.
*
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* g++.target/riscv/rvv/base/vmsge_vv-1.C: New test.
* g++.target/riscv/rvv/base/vmsge_vv-2.C: New test.
* g++.target/riscv/rvv/base/vmsge_vv-3.C: New test.
* g++.target/riscv/rvv/base/vmsge_vv_m-1.C: New test.
*
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* g++.target/riscv/rvv/base/vmseq_vv-1.C: New test.
* g++.target/riscv/rvv/base/vmseq_vv-2.C: New test.
* g++.target/riscv/rvv/base/vmseq_vv-3.C: New test.
* g++.target/riscv/rvv/base/vmseq_vv_m-1.C: New test.
*
On Mon, 13 Feb 2023, juzhe.zh...@rivai.ai wrote:
> >> But then GET_MODE_PRECISION (GET_MODE_INNER (..)) should always be 1?
> Yes, I think so.
>
> Let's explain RVV more clearly.
> Let's suppose we have vector-length = 64bits in RVV CPU.
> VNx1BI is exactly 1 consecutive bits.
> VNx2BI is
I am not sure changing the precision inner mode of BImode is correct for RVV.
Since by definition , each single 1-bit mask in RVV mask layout are consecutive.
Maybe we can wait for Kito answer this question ?
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-02-13 16:46
To:
gcc/ChangeLog:
* doc/invoke.texi: Document ira-simple-lra-insn-threshold.
---
gcc/doc/invoke.texi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 51447a78584..26de582e41e 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@
ARC has enter_s/leave_s instructions which can save/restore the entire
function context. It is not needed the millicode thunks anylonger when
compiling for size, thus, make their usage optional.
gcc/
* common/config/arc/arc-common.cc (arc_option_optimization_table):
Remove
Richard Biener writes:
> On Mon, 13 Feb 2023, juzhe.zh...@rivai.ai wrote:
>
>> >> But then GET_MODE_PRECISION (GET_MODE_INNER (..)) should always be 1?
>> Yes, I think so.
>>
>> Let's explain RVV more clearly.
>> Let's suppose we have vector-length = 64bits in RVV CPU.
>> VNx1BI is exactly 1
>> What's the byte size of VNx1BI, expressed as a function of N?
>> If it's CEIL (N, 8) then we don't have a way of representing that yet.
N is a poly value.
RVV like SVE support scalable vector.
the N is poly (1,1).
VNx1B mode nunits = poly(1,1) units.
VNx1B mode bitsize =poly (1,1) bitsize.
On Mon, 13 Feb 2023, Richard Sandiford wrote:
> Richard Biener writes:
> > On Mon, 13 Feb 2023, juzhe.zh...@rivai.ai wrote:
> >
> >> >> But then GET_MODE_PRECISION (GET_MODE_INNER (..)) should always be 1?
> >> Yes, I think so.
> >>
> >> Let's explain RVV more clearly.
> >> Let's suppose we
> -Original Message-
> From: Andrew MacLeod
> Sent: Friday, February 10, 2023 8:59 PM
> To: Richard Biener ; Richard Sandiford
>
> Cc: Tamar Christina ; Tamar Christina via Gcc-
> patches ; nd ;
> j...@ventanamicro.com
> Subject: Re: [PATCH 1/2]middle-end: Fix wrong overmatching of
On Feb 09 2023, Andrew Pinski via Gcc-patches wrote:
> Maybe you could use check-function-bodies for these files?
> check-function-bodies does remove cfi and other .line directives too
> when doing the scanning.
It doesn't work for negative assertions, though.
--
Andreas Schwab, SUSE Labs,
"juzhe.zh...@rivai.ai" writes:
>>> What's the byte size of VNx1BI, expressed as a function of N?
>>> If it's CEIL (N, 8) then we don't have a way of representing that yet.
> N is a poly value.
> RVV like SVE support scalable vector.
> the N is poly (1,1).
>
> VNx1B mode nunits = poly(1,1) units.
Yeah, I am aggree with you. Memory system access should always at least 1-byte.
So, consider such following code:
vsetvl e8,mf8
vlm.v v8, a0 (v8 is a 1-bit mask (Not sure what the behavior dealing with this
case))
vsm.v v8,a1
vsetvl e8,m1
vlm.v v8, a0 (v8 is a 8-bit mask)
vsm.v v8,a2
(Note:
This patch implement RISC-V Scalar Cryptography extension.
It includes machine descrption , intrinsic and testcase .
Liao Shihua (5):
Add prototypes for RISC-V Crypto built-in functions
Implement ZBKB, ZBKC and ZBKX extensions
Implement ZKND and ZKNE extensions
Implement ZKNH
I'd like to ping a few pending patches:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607534.html
- PR107846 - P1 - c-family: Account for integral promotions of left shifts
for -Wshift-overflow warning
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610285.html
- PR108464 -
Multiarch tuple will be coded in file or directory names in
multiarch-aware distros, so one ABI should have only one multiarch
tuple. For example, "--target=loongarch64-linux-gnu --with-abi=lp64s"
and "--target=loongarch64-linux-gnusf" should both set multiarch tuple
to "loongarch64-linux-gnusf".
>> Yeah, I am aggree with you. Memory system access should always at least
>> 1-byte.
>> So, consider such following code:
>> vsetvl e8,mf8
>> vlm.v v8, a0 (v8 is a 1-bit mask (Not sure what the behavior dealing with
>> this case))
>> vsm.v v8,a1
>> vsetvl e8,m1
>> vlm.v v8, a0 (v8 is a
On 2/2/23 09:43, Robin Dapp wrote:
> Hi,
>
> this patch adds LEN_LOAD/LEN_STORE support for z14 and newer.
> It defines a bias value of -1 and implements the LEN_LOAD and LEN_STORE
> optabs.
>
> It also includes various vll/vstl testcases adapted from Kewen Lin's patch
> for Power.
>
>
Ping for the patch below
aarch64/fcsel_1.c contains:
double
f_2 (double a, double b, double c, double d)
{
if (a > b)
return c;
else
return d;
}
which started failing in the GCC 12 timeframe. When it passed,
the RTL had the form:
[A]
(set (reg ret) (reg c))
(set (pc)
On 2/11/23 17:10, Stefan Schulze Frielinghaus wrote:
> Use constrain_operands in order to check whether there exists a valid
> alternative instead of extract_constrain_insn which ICEs in case no
> alternative is found.
>
> Bootstrapped and regtested on IBM zSystems. Ok for mainline?
>
>
Ping^3 [https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606741.html]
Various parts of the omp code checked whether the size of a decl
was an INTEGER_CST in order to determine whether the decl was
variable-sized or not. If it was variable-sized, it was expected
to have a
This patch implement RISC-V Scalar Cryptography extension.
It includes machine descrption , intrinsic and testcase .
Liao Shihua (5):
Add prototypes for RISC-V Crypto built-in functions
Implement ZBKB, ZBKC and ZBKX extensions
Implement ZKND and ZKNE extensions
Implement ZKNH
Implement ZKNH extensions.
ZKNH is NIST Suite: Hash Function Instructions.
gcc/ChangeLog:
* config/riscv/crypto.md (riscv_sha256sig0_):Add ZKNH's
instructions.
(riscv_sha256sig1_): Likewise.
(riscv_sha256sum0_): Likewise.
(riscv_sha256sum1_):
Add prototypes for RISC-V Crypto built-in functions .
gcc/ChangeLog:
* config/riscv/riscv-builtins.cc (RISCV_FTYPE_NAME2): New enumeration
identifier.
(RISCV_FTYPE_NAME3): Likewise.
(RISCV_ATYPE_QI): New Argument types.
(RISCV_ATYPE_HI): Likewise.
Implement ZKSH and ZKSED extensions.
ZKSH is ShangMi Suite: SM3 Hash Function Instructions.
ZKSED is ShangMi Suite: SM4 Block Cipher Instructions.
gcc/ChangeLog:
* config/riscv/crypto.md (riscv_sm3p0_): Add ZKSH's and ZKSED's
instructions.
(riscv_sm3p1_):
Implement ZKND and ZKNE extensions.
ZKND is NIST Suite: AES Decryption.
ZKNE is NIST Suite: AES Encryption.
gcc/ChangeLog:
* config/riscv/constraints.md (D03): New constraints of bs.
(DsA):New constraints of rnum.
* config/riscv/crypto.md
Implement ZBKB, ZBKC and ZBKX extensions.
ZBKB is Bitmanip instructions for Cryptography.
ZBKC is Carry-less multiply instructions.
ZBKX is Crossbar permutation instructions.
Only add Machine description and intrinsics of these instructions which are
not defined in the first
Richard Sandiford via Gcc-patches writes:
> Ping for the patch below
Ugh, somehow missed Jeff's OK over the weekend. Sorry for the noise!
Richard
I presume I've been CC'd on this conversation because weird vector
architecture problems have happened to me before. :)
However, I'm not sure I can help much because AMD GCN does not use
BImode vectors at all. This is partly because loading boolean values
into a GCN vector would have 31
DCE now chokes on indirect setjmp calls becoming direct because
that exposes them too late to be subject to abnormal edge creation.
The following patch honors gimple_call_ctrl_altering for those and
_not_ treat formerly indirect calls to setjmp as calls to setjmp.
Unfortunately there's no way to
On Mon, Feb 13, 2023 at 12:00:56PM +0100, Richard Biener wrote:
> DCE now chokes on indirect setjmp calls becoming direct because
> that exposes them too late to be subject to abnormal edge creation.
> The following patch honors gimple_call_ctrl_altering for those and
> _not_ treat formerly
On 2/13/23 06:28, Jeff Law wrote:
On 2/11/23 01:33, Jonathan Yong via Gcc-patches wrote:
Attached patch OK?
0001-builtin-declaration-mismatch-7-fix-LLP64-targets.patch
From 3ba6812366e837a87c15360e83d1f72ffdd29684 Mon Sep 17 00:00:00 2001
From: Jonathan Yong<10wa...@gmail.com>
Date: Sat,
On 2/13/23 07:04, Jeff Law wrote:
On 1/28/23 11:16, Jonathan Yong via Gcc-patches wrote:
Patch OK?
gcc/testsuite/ChangeLog:
* gcc.dg/pr65658.c: fix LLP64 test.
0001-pr65658.c-fix-excess-warnings-on-LLP64-targets.patch
From bd2634e2795723f290dcf4bbb06e70fb6ca6af51 Mon Sep 17 00:00:00
On 2/11/23 22:14, Gerald Pfeifer wrote:
On Sat, 11 Feb 2023, NightStrike wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
I would have expected the PR to have been automatically updated based on
the commit email. Any idea why that didn't happen? Not to change the state
to closed, but
On Mon, Feb 13, 2023 at 10:45:05AM +, Richard Sandiford wrote:
> Ping^3 [https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606741.html]
>
>
>
> Various parts of the omp code checked whether the size of a decl
> was an INTEGER_CST in order to determine whether the decl was
>
On Mon, 13 Feb 2023, Jakub Jelinek wrote:
> On Mon, Feb 13, 2023 at 12:00:56PM +0100, Richard Biener wrote:
> > DCE now chokes on indirect setjmp calls becoming direct because
> > that exposes them too late to be subject to abnormal edge creation.
> > The following patch honors
Hi Richard,
on 2023/1/27 19:08, Richard Sandiford via Gcc-patches wrote:
> PR96373 points out that a predicated SVE loop currently converts
> trapping unconditional ops into unpredicated vector ops. Doing
> the operation on inactive lanes can then raise an exception.
>
> As discussed in the PR
On Mon, Feb 13, 2023 at 12:41:48PM +, Richard Biener wrote:
> > Could we e.g. prevent turning such indirect calls into direct calls?
>
> We do exactly have gimple_call_fntype and gimple_call_ctrl_altering_p
> to not require special-casing indirect to direct call promotion here.
Ah, so if we
On Mon, 13 Feb 2023, Jakub Jelinek wrote:
> On Mon, Feb 13, 2023 at 12:41:48PM +, Richard Biener wrote:
> > > Could we e.g. prevent turning such indirect calls into direct calls?
> >
> > We do exactly have gimple_call_fntype and gimple_call_ctrl_altering_p
> > to not require special-casing
On 2/11/23 16:59, Stefan Schulze Frielinghaus wrote:
> So far we propagate scheduler state across basic blocks within EBBs and
> reset the state otherwise. In certain circumstances the entry block of
> an EBB might be empty, i.e., no_real_insns_p is true. In those cases
> scheduler state is not
"Kewen.Lin" writes:
> Hi Richard,
>
> on 2023/1/27 19:08, Richard Sandiford via Gcc-patches wrote:
>> PR96373 points out that a predicated SVE loop currently converts
>> trapping unconditional ops into unpredicated vector ops. Doing
>> the operation on inactive lanes can then raise an exception.
Hi!
On 2022-03-08T11:30:55+, Hafiz Abid Qadeer wrote:
> From: Andrew Stubbs
>
> Add a new option. It will be used in follow-up patches.
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> +@option{-foffload-memory=pinned} forces all host memory to be pinned (this
> +mode may
On 2/10/23 04:02, Richard Biener via Gcc-patches wrote:
This fixes an oversight to when removing the hard limits on using
generic vectors for the vectorizer to enable both SLP and BB
vectorization to use those. The vectorizer relies on vector lowering
to expand plus, minus and negate to bit
On 2/10/23 03:12, Richard Biener via Gcc-patches wrote:
The following fixes a latent issue when we mark control edges but
end up with marking a block with no stmts necessary. In this case
we fail to mark dependent control edges of that block.
Bootstrapped and tested on
On Mon, 13 Feb 2023, Jeff Law wrote:
>
>
> On 2/10/23 04:02, Richard Biener via Gcc-patches wrote:
> > This fixes an oversight to when removing the hard limits on using
> > generic vectors for the vectorizer to enable both SLP and BB
> > vectorization to use those. The vectorizer relies on
I noticed that for gcc.c-torture/compile/20001226-1.c even -O1 has
around 50% of the compile-time accounted to FRE. That's because
we have blocks with a high incoming edge count and
can_track_predicate_on_edge visits all of them even though it could
stop after the second. The function is also
On 13/02/2023 14:38, Thomas Schwinge wrote:
Hi!
On 2022-03-08T11:30:55+, Hafiz Abid Qadeer wrote:
From: Andrew Stubbs
Add a new option. It will be used in follow-up patches.
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
+@option{-foffload-memory=pinned} forces all host
Thanks all for your help and comments.
Let me share more information about this patch. Especially for the
tree-ssa-sccvn.cc part.
Assume we have the blow test code for this issue.
void
test_1(int8_t * restrict in, int8_t * restrict out) {
vbool8_t v2 = *(vbool8_t*)in;
vbool16_t v5 =
On Mon, 13 Feb 2023, 盼 李 wrote:
> Thanks all for your help and comments.
>
> Let me share more information about this patch. Especially for the
> tree-ssa-sccvn.cc part.
>
> Assume we have the blow test code for this issue.
>
> void
> test_1(int8_t * restrict in, int8_t * restrict out) {
>
On 1/25/23 13:06, Ben Boeckel wrote:
Unicode does not support such values because they are unrepresentable in
UTF-16.
libcpp/
* charset.cc: Reject encodings of codepoints above 0x10.
UTF-16 does not support such codepoints and therefore all
Unicode rejects such
On 2/13/23 07:51, Richard Biener wrote:
On Mon, 13 Feb 2023, Jeff Law wrote:
On 2/10/23 04:02, Richard Biener via Gcc-patches wrote:
This fixes an oversight to when removing the hard limits on using
generic vectors for the vectorizer to enable both SLP and BB
vectorization to use those.
joust_maybe_elide_copy checks that the last conversion in the ICS for
the first argument is ck_ref_bind, which is reasonable, because we've
checked that we're dealing with a copy/move constructor. But it can
also happen that we couldn't figure out which conversion function is
better to convert
[N.B. this is a corrected version of
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607443.html ]
This patch factors out the TYPENAME_TYPE case of tsubst into a separate
function tsubst_typename_type. It also factors out the two tsubst flags
controlling TYPENAME_TYPE substitution,
[N.B. this is a corrected version of
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607443.html ]
Currently when resolving a TYPENAME_TYPE for 'typename T::m' via
make_typename_type, we consider only type bindings of 'm' and ignore
non-type ones. But [temp.res.general]/3 says, in a
Andrew Pinski via Gcc-patches writes:
> On Fri, Feb 10, 2023 at 2:47 PM Philipp Tomsich
> wrote:
>>
>> Some architectures, as it the case on RISC-V with the proposed
>> ZiCondOps and the vendor-defined XVentanaCondOps, define a
>> conditional-zero instruction that is equivalent to:
>> - the
Pushed as:
commit 086a1df4374962787db37c1f0d1bd9beb828f9e3
Thanks,
Harald
On 2/12/23 22:28, Harald Anlauf via Gcc-patches wrote:
Hi Rimvydas,
Gesendet: Sonntag, 12. Februar 2023 um 07:59 Uhr
Von: "Rimvydas Jasinskas"
An: "Harald Anlauf"
Cc: "fortran"
Betreff: Re: Support for NOINLINE
On 1/25/23 13:06, Ben Boeckel wrote:
They affect the build, so report them via `-MF` mechanisms.
gcc/cp/
* module.cc (do_import): Report imported CMI files as
dependencies.
Both this and the mapper dependency patch seem to cause most of the
modules testcases to crash; please
On 2/13/23 10:32, Richard Sandiford via Gcc-patches wrote:
Andrew Pinski via Gcc-patches writes:
On Fri, Feb 10, 2023 at 2:47 PM Philipp Tomsich
wrote:
Some architectures, as it the case on RISC-V with the proposed
ZiCondOps and the vendor-defined XVentanaCondOps, define a
On Mon, Feb 13, 2023 at 10:43 AM Jeff Law wrote:
>
>
>
> On 2/13/23 10:32, Richard Sandiford via Gcc-patches wrote:
> > Andrew Pinski via Gcc-patches writes:
> >> On Fri, Feb 10, 2023 at 2:47 PM Philipp Tomsich
> >> wrote:
> >>>
> >>> Some architectures, as it the case on RISC-V with the
The .su files generated with -fstack-usage are arguably debug info. In
order to make builds more reproducible, apply the same remapping logic
to the recorded file names as for when producing the debug info
embedded in the object files.
To this end, teach print_decl_identifier() a new
Combine pass simplifies zero-extend of a zero-extract to:
Trying 16 -> 6:
16: r86:QI#0=zero_extract(r87:HI,0x8,0x8)
REG_DEAD r87:HI
6: r84:SI=zero_extend(r86:QI)
REG_DEAD r86:QI
Failed to match this instruction:
(set (reg:SI 84 [ s.e2 ])
(zero_extract:SI (reg:HI 87)
The problem is that GOMP_MAP_ALWAYS_POINTER, there is a lookup for "i - 1"
but with 'target enter data', GOMP_MAP_ALWAYS_POINTER and its data were passed
as separate entities.
I am not sure whether there is a legitimate reason to have two
GOMP_MAP_ALWAYS_POINTER in a row; the check in
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108774
The patch was successfully bootstrapped and tested on i686, x86_64, and
aarch64.
commit a33e3dcbd15e73603796e30b5eeec11a0c8bacec
Author: Vladimir N. Makarov
Date: Mon Feb 13 16:05:04 2023 -0500
RA: Clear
Jeff Law writes:
> On 2/7/23 03:29, Richard Sandiford via Gcc-patches wrote:
>> In this PR we had a write to one vector of a 4-vector tuple.
>> The vector had mode V1DI, and the target doesn't provide V1DI
>> moves, so this was converted into:
>>
>> (clobber (subreg:V1DI (reg/v:V4x1DI 92 [
Dear all,
the attached simple and obvious patch fixes a NULL pointer dereference
on an invalid use of a CLASS variable.
Committed to mainline after regtesting on x86_64-pc-linux-gnu as
https://gcc.gnu.org/g:2ce7e2a83e18a27fe9c659f8667fc24f0df4ea9a
Thanks,
Harald
From
Ping on this patch. I took the liberty to rebase it. The changes are
minimal, so I didn't want to resend the entire patchset. I included a
range diff and a pull request for your convenience.
The render is also updated, and ``make all && make html'' passes (which
is something I forgot to check
Ping:
https://inbox.sourceware.org/gcc-patches/20230123012100.4021860-1-ar...@aarsen.me/
No further changes happened to the file between the post and today.
Have a lovely night :-)
--
Arsen Arsenović
signature.asc
Description: PGP signature
Pushed.
Gerald
libstdc++-v3/ChangeLog:
* doc/xml/manual/policy_data_structures_biblio.xml: Adjust
"The Component Object Model" reference.
* doc/html/manual/policy_data_structures.html: Regenerate.
---
libstdc++-v3/doc/html/manual/policy_data_structures.html | 4
Tested x86_64-pc-linux-gnu. Pushed to trunk.
The first patch has also been backported and pushed to releases/gcc-12 and
releases/gcc-11
The second patch fails to cleanly cherry-pick. Will resolve and push
shortly.
On Fri, Feb 10, 2023 at 4:41 PM Jonathan Wakely wrote:
> On Fri, 10 Feb 2023 at
on 2023/2/13 21:57, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richard,
>>
>> on 2023/1/27 19:08, Richard Sandiford via Gcc-patches wrote:
>>> PR96373 points out that a predicated SVE loop currently converts
>>> trapping unconditional ops into unpredicated vector ops. Doing
>>> the
Ok to commit? It survived both a cris-elf regtest and a
x86_64-linux-gnu native regtest. :)
8<
The debug-function in sel-sched-dump.cc that would be
suitable for a hookup to a command in gdb is guarded by
#ifdef INSN_SCHEDULING, thus can't be used for all targets.
Better move the
add yangyujie.
在 2023/2/13 下午6:38, Xi Ruoyao 写道:
Multiarch tuple will be coded in file or directory names in
multiarch-aware distros, so one ABI should have only one multiarch
tuple. For example, "--target=loongarch64-linux-gnu --with-abi=lp64s"
and "--target=loongarch64-linux-gnusf" should
81 matches
Mail list logo
