Hi Richard,
Thanks a lot for your review!
Richard Biener writes:
> On Wed, 23 Aug 2023, guojiufu wrote:
>
>> Hi,
>>
>> I would like to have a gentle ping...
>>
>> BR,
>> Jeff (Jiufu Guo)
>>
>> On 2023-08-07 10:45, guojiufu via Gcc-patches wrote:
>> > Hi,
>> >
>> > Gentle ping...
>> >
>>
Committed, thanks Richard.
On 2023/8/29 14:53, Richard Biener via Gcc-patches wrote:
On Tue, 29 Aug 2023, Juzhe-Zhong wrote:
We are planning to enable "vect" testsuite with scalable vector
auto-vectorization.
This case XPASS:
XPASS: gcc.dg/vect/no-scevccp-outer-12.c scan-tree-dump-times vect
Hi,
This patch enables the use of mixed-types for simd clones for AArch64,
adds aarch64 as a target_vect_simd_clones and corrects the way the
simdlen is chosen for non-specified simdlen clauses according to the
'Vector Function Application Binary Interface Specification for AArch64'.
Additio
On Mon, Aug 28, 2023 at 10:15 PM Andrew Pinski via Gcc-patches
wrote:
>
> This moves the match pattern `(x | y) & (~x ^ y)` over to use
> bitwise_inverted_equal_p.
> This now also allows to optmize comparisons and also catches the missed `(~x
> | y) & (x ^ y)`
> transformation into `~x & y`.
>
>
On Tue, Aug 29, 2023 at 1:23 AM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 8/28/23 02:17, Di Zhao OS via Gcc-patches wrote:
> > This patch tries to fix the 2% regression in 510.parest_r on
> > ampere1 in the tracker. (Previous discussion is here:
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-
Hi,
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, August 29, 2023 3:41 PM
> To: Jeff Law ; Martin Jambor
> Cc: Di Zhao OS ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] [tree-optimization/110279] swap operands in reassoc to
> reduce cross backedge FMA
>
> On Tue, Aug 29
This is a follow-up for the zfa extension, added according to the
recommendations
for zvfh and patch of Tsukasa OI . At the same
time,
zfa-fli-5.c of which is also based on the patch.
Ref:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627284.html
https://gcc.gnu.org/pipermail/gcc-patches
ping
Ref:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627341.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621296.html
Hi!
The uaddc/usubc usual matching is of the .{ADD,SUB}_OVERFLOW pair in the
middle, which adds/subtracts carry-in (from lower limbs) and computes
carry-out (to higher limbs). Before optimizations (unless user writes
it intentionally that way already), all the steps look the same, but
optimizatio
On Tue, Aug 29, 2023 at 9:49 AM Di Zhao OS
wrote:
>
> Hi,
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Tuesday, August 29, 2023 3:41 PM
> > To: Jeff Law ; Martin Jambor
> > Cc: Di Zhao OS ; gcc-patches@gcc.gnu.org
> > Subject: Re: [PATCH] [tree-optimization/110279] swap op
On Tue, 29 Aug 2023, Jakub Jelinek wrote:
> Hi!
>
> The uaddc/usubc usual matching is of the .{ADD,SUB}_OVERFLOW pair in the
> middle, which adds/subtracts carry-in (from lower limbs) and computes
> carry-out (to higher limbs). Before optimizations (unless user writes
> it intentionally that way
Hi Richard,
Thanks a lot for your quick reply!
Richard Biener writes:
> On Tue, 29 Aug 2023, Jiufu Guo wrote:
>
>>
>> Hi All!
>>
>> "rguenth at gcc dot gnu.org" writes:
>>
>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66
>> ...
>> >
>> >
>> > At RTL expansion time we store to D.28
Fei Gao (3):
[RISC-V] support cm.push cm.pop cm.popret in zcmp
[RISC-V] support cm.popretz in zcmp
[RISC-V] support cm.mva01s cm.mvsa01 in zcmp
gcc/config/riscv/iterators.md | 15 +
gcc/config/riscv/peephole.md | 28 +
gcc/config/riscv/predicates.md
Zcmp can share the same logic as save-restore in stack allocation:
pre-allocation
by cm.push, step 1 and step 2.
Pre-allocation not only saves callee saved GPRs, but also saves callee saved
FPRs and
local variables if any.
Please be noted cm.push pushes ra, s0-s11 in reverse order than what
sa
From: Die Li
Signed-off-by: Die Li
Co-Authored-By: Fei Gao
gcc/ChangeLog:
* config/riscv/peephole.md: New pattern.
* config/riscv/predicates.md (a0a1_reg_operand): New predicate.
(zcmp_mv_sreg_operand): New predicate.
* config/riscv/riscv.md: New predicate.
Generate cm.popretz instead of cm.popret if return value is 0.
gcc/ChangeLog:
* config/riscv/riscv.cc
(riscv_zcmp_can_use_popretz): true if popretz can be used
(riscv_gen_multi_pop_insn): interface to generate cm.pop[ret][z]
(riscv_expand_epilogue): expand cm.pop[r
LGTM, did you have commit access for GCC repo? you should obtain it if
you don't have it yet, I think you are already an important member of
the RISC-V GNU toolchain community :)
https://gcc.gnu.org/gitwrite.html#authenticated , and you can add me
to the cc list as your sponsor.
On Tue, Aug 29,
On 2023/08/29 17:42, Kito Cheng wrote:
> LGTM, did you have commit access for GCC repo? you should obtain it if
> you don't have it yet, I think you are already an important member of
> the RISC-V GNU toolchain community :)
Not yet (only Binutils/GDB). Jeff is mainly merging my changes to the
tru
Hi Carl,
on 2023/8/29 04:00, Carl Love wrote:
>
> GCC maintainers:
>
> Version 4, additional define_insn name fix. Change Log fix for the
> UNSPEC_DQUAN. Retested patch on Power 10 LE.
>
> Version 3, fixed the built-in instance names. Missed removing the "n"
> the name. Added the tighter co
Hi Haochen,
on 2023/8/29 10:50, HAO CHEN GUI wrote:
> Hi,
> This patch adds "TARGET_64BIT" check when calling vector load/store
> with length expand in expand_block_move. It matches the expand condition
> of "lxvl" and "stxvl" defined in vsx.md.
>
> This patch fixes the ICE occurred with the
Hi,
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, August 29, 2023 4:09 PM
> To: Di Zhao OS
> Cc: Jeff Law ; Martin Jambor ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH] [tree-optimization/110279] swap operands in reassoc to
> reduce cross backedge FMA
>
> On Tue, Aug
On Wed, 23 Aug 2023, Jiufu Guo wrote:
>
> Hi,
>
> I just updated the patch. We could review this one.
>
> Compare with previous patch:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627287.html
> This version:
> * Supports bitfield access from one register.
> * Allow return scalar reg
On Tue, 29 Aug 2023, Jiufu Guo wrote:
>
> Hi Richard,
>
> Thanks a lot for your quick reply!
>
> Richard Biener writes:
>
> > On Tue, 29 Aug 2023, Jiufu Guo wrote:
> >
> >>
> >> Hi All!
> >>
> >> "rguenth at gcc dot gnu.org" writes:
> >>
> >> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id
On Tue, 29 Aug 2023, Tsukasa OI wrote:
> On 2023/08/29 8:09, Hans-Peter Nilsson wrote:
> > On Mon, 28 Aug 2023, Jeff Law via Gcc-patches wrote:
> >>
> >>
> >> On 8/9/23 00:11, Tsukasa OI via Gcc-patches wrote:
> >>> From: Tsukasa OI
> >>>
> >>> This built-in does not imply the 'Xgnuzihintpausesta
This patch fixed this bunch of failures in "vect" testsuite:
FAIL: gcc.dg/vect/pr63341-1.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/pr63341-1.c execution test
FAIL: gcc.dg/vect/pr63341-2.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/pr63341-2.c execution test
FAIL: gcc.
Hi Richard,
Thanks a lot for your great comments!
Richard Biener writes:
> On Tue, 29 Aug 2023, Jiufu Guo wrote:
>
>>
>> Hi Richard,
>>
>> Thanks a lot for your quick reply!
>>
>> Richard Biener writes:
>>
>> > On Tue, 29 Aug 2023, Jiufu Guo wrote:
>> >
>> >>
>> >> Hi All!
>> >>
>> >>
On Mon, 28 Aug 2023, Jakub Jelinek wrote:
> Hi!
>
> While the _BitInt series isn't committed yet, I had a quick look at
> lifting the current lowest limitation on maximum _BitInt precision,
> that wide_int can only support wide_int until WIDE_INT_MAX_PRECISION - 1.
>
> Note, other limits if that
Prevous patch (which removed VLA modes movmisalign pattern) to fix run-time bug.
Such patch disable vectorization for misalign data movement.
After I check LLVM codes, LLVM supports misalign for VLS modes.
Before this patch:
sll a5,a4,0x1
add a5,a5,a1
lhu a3,64(a5)
lbu a5,66(a5)
Hi Jeff,
Can you take a look at the patch? It fixes a bootstrap failure on
LoongArch. And in this month 3 related bugzilla tickets have been
created (110939, 24, 71).
On Thu, 2023-08-10 at 15:04 +0200, Stefan Schulze Frielinghaus via Gcc-
patches wrote:
> In the former fix in commit 41e
Just some off-the-cuff thoughts. Might think differently when
I've had more time...
Richard Biener writes:
> On Mon, 28 Aug 2023, Jakub Jelinek wrote:
>
>> Hi!
>>
>> While the _BitInt series isn't committed yet, I had a quick look at
>> lifting the current lowest limitation on maximum _BitInt p
From: Pan Li
There will be one ICE when build vect-multitypes-5.c similar as below:
riscv64-unknown-elf-gcc -O3 \
-march=rv64imafdcv -mabi=lp64d -mcmodel=medlow \
-fdiagnostics-plain-output -flto -ffat-lto-objects \
--param riscv-autovec-preference=scalable -Wno-psabi \
-ftree-vectorize
On Tue, Aug 29, 2023 at 10:59 AM Di Zhao OS
wrote:
>
> Hi,
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Tuesday, August 29, 2023 4:09 PM
> > To: Di Zhao OS
> > Cc: Jeff Law ; Martin Jambor ; gcc-
> > patc...@gcc.gnu.org
> > Subject: Re: [PATCH] [tree-optimization/110279] s
From: Tsukasa OI
ChangeLog:
* MAINTAINERS: Add myself.
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4e706df65226..35f00beebff2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -592,6 +592,7 @@ Carlos O'Donell
Jeff Law writes:
> On 8/24/23 08:06, Robin Dapp via Gcc-patches wrote:
>> Ping. I refined the code and some comments a bit and added a test
>> case.
>>
>> My question in general would still be: Is this something we want
>> given that we potentially move some of combine's work a bit towards
>> t
On Mon, Aug 28, 2023 at 12:58 AM Andrew Pinski via Gcc-patches
wrote:
>
> This adds a simple case to remove an outer condition if the two inner
> condtionals are the same and lead the same location.
> This can show up due to jump threading or inlining or someone wrote code
> like this.
>
> ifcombi
libstdc++: Fix -Wunused-parameter warnings when _GLIBCXX_USE_WCHAR_T is
not defined.
libstdc++-v3/ChangeLog:
* src/c++11/cow-locale_init.cc: Add [[maybe_unused]] attribute.
* src/c++17/fs_path.cc (path::_S_convert_loc): Likewise.
* src/filesystem/path.cc (path::_S_convert
On 8/29/23 01:41, Richard Biener wrote:
_1 = a * b;
_2 = .FMA (c, d, _1);
acc_1 = acc_0 + _2;
How can we execute the multiply and the FMA in parallel? They
depend on each other. Or is it the uarch can handle dependence
on the add operand but only when it is with a multiplic
ping
> Hi,
>
> This was a painful one to fix, because I hate regexps, especially when they
> are quoted. On darwin, we have this failure:
>
>FAIL: gcc.dg/debug/dwarf2/inline4.c scan-assembler
> DW_TAG_inlined_subroutine[^(]*([^)]*)[^(]*(DIE
> (0x[0-9a-f]*)
Hi Lehua,
thanks, LGTM now.
Regards
Robin
Hi Prathamesh,
Thanks for the report, I am running on a x86_64_linux_gnu and never had to
cross-compile before.
I've tried to set it up and reproduce your errors, please tell me if I'm
off the mark.
I configured gcc as:
../gcc/configure --prefix $CONTROL_PFX --disable-bootstrap
--host=x86_64-lin
Committed, thanks Robin.
On 2023/8/29 21:10, Robin Dapp wrote:
Hi Lehua,
thanks, LGTM now.
Regards
Robin
--
Best,
Lehua
This is an attempt to improve the constexpr machinery's handling of
union lifetime by catching more cases that cause UB. Is this approach
OK?
I'd also like some feedback on a couple of pain points with this
implementation; in particular, is there a good way to detect if a type
has a non-deleted t
Hi Tatsuyuki:
Thanks your TLS desc implementation, it's looks already in good shape
now! just few minor comment :)
> @@ -121,6 +121,14 @@
> (T1_REGNUM 6)
> (S0_REGNUM 8)
> (S1_REGNUM 9)
> + (A0_REGNUM 10)
> + (A1
On 8/28/23 21:39, Tsukasa OI wrote:
From: Tsukasa OI
After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown
extensions") changed how do we handle unknown extensions, we have no
guarantee that we can share the same architectural string with Binutils
(specifically, the assembl
On 8/28/23 21:39, Tsukasa OI wrote:
From: Tsukasa OI
After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown
extensions") changed how do we handle unknown extensions, we have no
guarantee that we can share the same architectural string with Binutils
(specifically, the assembl
On 8/28/23 21:39, Tsukasa OI wrote:
From: Tsukasa OI
After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown
extensions") changed how do we handle unknown extensions, we have no
guarantee that we can share the same architectural string with Binutils
(specifically, the assembl
On 8/28/23 21:28, Tsukasa OI wrote:
From: Tsukasa OI
Commit c283c4774d1c ("RISC-V: Throw compilation error for unknown
extensions") changed how do we handle unknown extensions and
commit 6f709f79c915a ("[committed] [RISC-V] Fix expected diagnostic messages
in testsuite") "fixed" test failure
LGTM, thanks :)
On Tue, Aug 29, 2023 at 6:50 PM Pan Li via Gcc-patches
wrote:
>
> From: Pan Li
>
> There will be one ICE when build vect-multitypes-5.c similar as below:
>
> riscv64-unknown-elf-gcc -O3 \
> -march=rv64imafdcv -mabi=lp64d -mcmodel=medlow \
> -fdiagnostics-plain-output -flto -f
On 8/28/23 20:09, Tsukasa OI wrote:
On 2023/08/29 6:20, Jeff Law wrote:
On 8/9/23 21:10, Tsukasa OI via Gcc-patches wrote:
From: Tsukasa OI
The "__builtin_riscv_zicbop_cbo_prefetchi" built-in function was terribly
broken so that practically unusable. It emitted "prefetch.i" but with no
On 8/29/23 03:39, Juzhe-Zhong wrote:
This patch fixed this bunch of failures in "vect" testsuite:
FAIL: gcc.dg/vect/pr63341-1.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/pr63341-1.c execution test
FAIL: gcc.dg/vect/pr63341-2.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/
> +/* To support misalign data movement, we should use
> + minimum element alignment load/store. */
> +unsigned int size = GET_MODE_SIZE (GET_MODE_INNER (mode));
> +poly_int64 nunits = GET_MODE_NUNITS (mode) * size;
> +machine_mode mode = riscv_vector::get_vector_mode (QImode
On 8/29/23 07:54, Kito Cheng via Gcc-patches wrote:
+/* To support misalign data movement, we should use
+ minimum element alignment load/store. */
+unsigned int size = GET_MODE_SIZE (GET_MODE_INNER (mode));
+poly_int64 nunits = GET_MODE_NUNITS (mode) * size;
+machine_mo
Committed, thanks Kito.
Pan
-Original Message-
From: Kito Cheng
Sent: Tuesday, August 29, 2023 9:46 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; Wang, Yanzhang ;
juzhe.zh...@rivai.ai
Subject: Re: [PATCH v1] RISC-V: Fix one ICE for vect test vect-multitypes-5
LGTM, thanks :)
On Tue,
On Tue, Aug 29, 2023 at 09:49:59AM +, Richard Biener wrote:
> The simplest way would probably to keep widest_int at
> WIDE_INT_MAX_PRECISION like we have now and assert that this is
> enough at ::to_widest time (we probably do already). And then
> declare uses with more precision need to use
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r14-3549-gf687fc1ff6d4a4.
gcc/analyzer/ChangeLog:
PR analyzer/105899
* kf.cc (kf_strdup::impl_call_pre): Set size of
dynamically-allocated buffer. Simulate copying the string from
the
On Tue, Aug 29, 2023 at 11:42:48AM +0100, Richard Sandiford wrote:
> > I'll note tree-ssa-loop-niter.cc also uses GMP in some cases, widest_int
> > is really trying to be poor-mans GMP by limiting the maximum precision.
>
> I'd characterise widest_int as "a wide_int that is big enough to hold
> al
We finished the investigation and found out the issue: when passing
arguments by value to functions, rustc still provides "NoAlias" as
attribute to the argument whereas it should never be passed in this
case. Luckily for us, in case the argument is a function pointer
coming from a struct field, it
Kewen:
On Tue, 2023-08-29 at 16:54 +0800, Kewen.Lin wrote:
> > The following functions require @option{-mhard-float},
> > diff --git a/gcc/testsuite/gcc.target/powerpc/pr93448.c
> > b/gcc/testsuite/gcc.target/powerpc/pr93448.c
> > new file mode 100644
> > index 000..f9c388585d7
> > --- /
Hi Guys,
Currently the top level configure.ac file sets the minimum required
version of texinfo to be 4.7. I would like to propose changing this
to 6.8.
The reason for the change is that the bfd documentation now needs at
least version 6.8 in order to build[1][2]. Given that 4.7 is
On 8/28/2023 2:45 PM, Jeff Law via Gcc-patches wrote:
On 8/28/23 13:03, Edwin Lu wrote:
Related Discussion:
https://inbox.sourceware.org/gcc-patches/12fb5088-3f28-0a69-de1e-f387371a5...@gmail.com/
This patch updates vector instructions to ensure that no insn is left
without a type attribute.
On Tue, 2023-08-29 at 17:15 +0200, Guillaume Gomez wrote:
> We finished the investigation and found out the issue: when passing
> arguments by value to functions, rustc still provides "NoAlias" as
> attribute to the argument whereas it should never be passed in this
> case. Luckily for us, in case
Thanks a lot!
Le mar. 29 août 2023 à 17:35, David Malcolm a écrit :
>
> On Tue, 2023-08-29 at 17:15 +0200, Guillaume Gomez wrote:
> > We finished the investigation and found out the issue: when passing
> > arguments by value to functions, rustc still provides "NoAlias" as
> > attribute to the arg
excl_hash_traits can be defined more simply by reusing existing traits.
Tested on aarch64-linux-gnu. OK to install?
Richard
gcc/
* attribs.cc (excl_hash_traits): Delete.
(test_attribute_exclusions): Use pair_hash and nofree_string_hash
instead.
---
gcc/attribs.cc | 45
In the patch call we talked about sign extsnsion elimination, so I dug
up this patch set that I did a while ago. It is still lacking some
documentation and testing in a more recent base version;
I only adjusted the common.opt part context for the patch to apply.
Author: Joern Rennecke
Date: Thu
On Tue, Aug 29, 2023 at 04:21:44PM +0100, Nick Clifton via Gcc-patches wrote:
> Currently the top level configure.ac file sets the minimum required
> version of texinfo to be 4.7. I would like to propose changing this
> to 6.8.
>
> The reason for the change is that the bfd documentation
On 8/28/2023 3:40 PM, Jeff Law wrote:
On 8/15/23 12:29, Edwin Lu wrote:
This patch is a modification of
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610115.html
following the discussion on
https://github.com/riscv-non-isa/riscv-c-api-doc/issues/32
Distinguish between explicit -mst
> I think that is too new.
> We still allow building gcc e.g. with GCC 4.8 from ~ 10 years ago and
> I think various boxes where people regularly build gcc will have similarly
> old other tools.
> So, bumping requirement from ~ 20 years old tools to ~ 10 years old tools
> might be ok, but requiring
On Tue, 29 Aug 2023 08:48:56 PDT (-0700), e...@rivosinc.com wrote:
On 8/28/2023 3:40 PM, Jeff Law wrote:
On 8/15/23 12:29, Edwin Lu wrote:
This patch is a modification of
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610115.html
following the discussion on
https://github.com/riscv-n
> Date: Tue, 29 Aug 2023 17:45:20 +0200
> Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org,
> binut...@sourceware.org
> From: Jakub Jelinek via Gdb-patches
>
> On Tue, Aug 29, 2023 at 04:21:44PM +0100, Nick Clifton via Gcc-patches wrote:
> > Currently the top level configure.ac file set
On Tue, Aug 29, 2023 at 8:50 AM YunQiang Su via Binutils
wrote:
>
> > I think that is too new.
> > We still allow building gcc e.g. with GCC 4.8 from ~ 10 years ago and
> > I think various boxes where people regularly build gcc will have similarly
> > old other tools.
> > So, bumping requirement f
On Tue, 2023-08-29 at 19:01 +0300, Eli Zaretskii via Gcc-patches wrote:
> > Date: Tue, 29 Aug 2023 17:45:20 +0200
> > Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org,
> > binut...@sourceware.org
> > From: Jakub Jelinek via Gdb-patches
> >
> > On Tue, Aug 29, 2023 at 04:21:44PM +0100, Nic
On 8/29/2023 8:53 AM, Palmer Dabbelt wrote:
On Tue, 29 Aug 2023 08:48:56 PDT (-0700), e...@rivosinc.com wrote:
On 8/28/2023 3:40 PM, Jeff Law wrote:
On 8/15/23 12:29, Edwin Lu wrote:
This patch is a modification of
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610115.html
followi
This adds support for
#pragma omp allocate(var-list) [allocator(..) align(..)]
While the spec permits stack and static variables, this patch only
adds support for stack variables - keeping the 'sorry' for static
variables.
It is also only C as I wanted to get this out before updating C++
parsin
On Tue, Aug 29, 2023 at 06:12:58PM +0200, Tobias Burnus wrote:
> This adds support for
> #pragma omp allocate(var-list) [allocator(..) align(..)]
>
> While the spec permits stack and static variables, this patch only
> adds support for stack variables - keeping the 'sorry' for static
> variables
On 29.08.23 18:28, Jakub Jelinek wrote:
One thing is that for C++ one needs to be careful about vars optimized
by NRV by the FE.
Thanks for the warning.
And, just from the gimplify_bind_expr function name,
(I forgot that one change in there which makes it look larger is that
I moved the stack
On 8/29/23 01:51, Jin Ma wrote:
This is a follow-up for the zfa extension, added according to the
recommendations
for zvfh and patch of Tsukasa OI. At the same
time,
zfa-fli-5.c of which is also based on the patch.
Ref:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627284.html
https
On Tue, Aug 29, 2023 at 06:56:40PM +0200, Tobias Burnus wrote:
> On 29.08.23 18:28, Jakub Jelinek wrote:
> > One thing is that for C++ one needs to be careful about vars optimized
> > by NRV by the FE.
> Thanks for the warning.
> > And, just from the gimplify_bind_expr function name,
>
> (I forgot
Additionally, by using the old model and the pointer per your suggestion,
we are able to find the representative tree and emit a more accurate diagnostic!
rc3.c:23:10: warning: expected ‘item’ to have reference count: ‘1’ but
ob_refcnt field is: ‘2’
23 | return list;
| ^~~~
> "Nick" == Nick Clifton via Gdb-patches
> writes:
Nick> The reason for the change is that the bfd documentation now needs at
Nick> least version 6.8 in order to build[1][2].
Sorry about this. It was fallout from my patch.
However, GDB has used this same one-argument @node syntax
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
[dcl.constinit]/1: The constinit specifier shall be applied only to a
declaration
of a variable with static or thread storage duration.
and while we detect
constinit int fn();
we weren't detecting
using F = int();
co
On 8/23/23 15:49, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This patch implements P2564, described at , whereby
certain functions are promoted to consteval. For example:
Great, thanks!
consteval int id(int i) { return i; }
template
Improving the security of software has been a major trend in the recent
years. Fortunately, GCC offers a wide variety of flags that enable extra
hardening. These flags aren't enabled by default, though. And since
there are a lot of hardening flags, with more to come, it's been difficult
to keep
Hi
Any feedback regarding this patch ?
François
On 24/07/2023 13:02, François Dumont wrote:
libstdc++: [_Hashtable] Make more use of insertion hint
When inserting an element into an empty bucket we currently insert
the new node
after the before-begin node so in first position. The d
On Tue, 29 Aug 2023, FX Coudert via Gcc-patches wrote:
> > The driver changes are still OK.
>
> Just to be clear: apart from you and Iain, whose approval do I need (and
> for what parts)?
I think a build machinery review is needed.
--
Joseph S. Myers
jos...@codesourcery.com
Marek Polacek via Gcc-patches writes:
> Improving the security of software has been a major trend in the recent
> years. Fortunately, GCC offers a wide variety of flags that enable extra
> hardening. These flags aren't enabled by default, though. And since
> there are a lot of hardening flag
On 8/28/23 19:24, Marek Polacek wrote:
On Fri, Aug 25, 2023 at 08:34:37PM -0400, Jason Merrill wrote:
On 8/25/23 19:37, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
1) When saying that a conversion is erroneous because it would use
an explicit con
On 8/28/23 19:09, Marek Polacek wrote:
On Mon, Aug 28, 2023 at 06:27:26PM -0400, Jason Merrill wrote:
On 8/25/23 12:44, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This CWG clarifies that designated initializer support direct-initialization.
Just
On Tue, 2023-08-29 at 00:31 -0400, Eric Feng wrote:
> Hi Dave,
Hi Eric.
Thanks for the updated patch.
A few nits below; this is OK for trunk with them fixed...
[...snip...]
>
> gcc/analyzer/ChangeLog:
> PR analyzer/107646
> * engine.cc (impl_region_model_context::warn): New optional p
On Tue, 2023-08-29 at 13:28 -0400, Eric Feng wrote:
> Additionally, by using the old model and the pointer per your
> suggestion,
> we are able to find the representative tree and emit a more accurate
> diagnostic!
>
> rc3.c:23:10: warning: expected ‘item’ to have reference count: ‘1’
> but ob_ref
On Tue, Aug 29, 2023 at 04:42:33PM -0400, Jason Merrill wrote:
> On 8/28/23 19:24, Marek Polacek wrote:
> > On Fri, Aug 25, 2023 at 08:34:37PM -0400, Jason Merrill wrote:
> > > On 8/25/23 19:37, Marek Polacek wrote:
> > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > > >
> > >
On Tue, Aug 29, 2023 at 09:11:35PM +0100, Sam James via Gcc-patches wrote:
>
> Marek Polacek via Gcc-patches writes:
>
> > Improving the security of software has been a major trend in the recent
> > years. Fortunately, GCC offers a wide variety of flags that enable extra
> > hardening. These f
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r14-3556-g034d99e81484fb.
gcc/ChangeLog:
PR analyzer/99860
* Makefile.in (ANALYZER_OBJS): Add analyzer/ranges.o.
gcc/analyzer/ChangeLog:
PR analyzer/99860
* analyzer-selftests.cc (sel
> OK for the trunk.
Thanks. Will commit it soon.
> Does force_reg safe for movmisalign?
Both operands[0] and operands[1] are vector QImode already, so it's safe to
force reg.
And we have fully tested MEM->MEM and CONST->MEM in gcc.dg/vect.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-08-29
On Tue, 2023-08-29 at 11:01 +0530, Prathamesh Kulkarni wrote:
> On Fri, 25 Aug 2023 at 18:15, David Malcolm via Gcc-patches
> wrote:
> >
> > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> > Pushed to trunk as r14-3481-g99a3fcb8ff0bf2.
> Hi David,
> It seems the new tests FAIL on
So in analyzing Ventana's internal tree against the trunk it became
apparent that the current zicond code is missing a case that helps
coremark's bitwise CRC implementation.
Here's a minimized testcase:
long xor1(long crc, long poly)
{
if (crc & 1)
crc ^= poly;
return crc;
}
ie, it'
From: Yanzhang Wang
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/sve/acle/asm/subr_s8.c: Modify subr with -1
to not.
Signed-off-by: Yanzhang Wang
---
Tested on my local arm environment and passed. Thanks Andrew Pinski's comment
the code is the same with that.
gcc/testsuite/gcc.
Committed, thanks Jeff and Kito.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of ???
Sent: Wednesday, August 30, 2023 6:27 AM
To: Jeff Law ; kito.cheng
Cc: gcc-patches ; kito.cheng
Subject: Re: Re: [PATCH] RISC-V: Enable movmisalign for VLS modes
> OK for the trunk.
Thanks. Wil
Ping. This patch also fixed issue occurred in RISC-V backend:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71
Thanks.
juzhe.zh...@rivai.ai
V3 change: Rebasing.
Hi RISC-V folks,
This patch implement the proposal of RISC-V vector calling convention[1] and
this feature can be enabled by `--param=riscv-vector-abi` option. Currently,
all vector type arguments and return values are pass by reference. With this
patch, these arguments and r
I post the vector register calling convention rules from in the proposal[1]
directly here:
v0 is used to pass the first vector mask argument to a function, and to return
vector mask result from a function. v8-v23 are used to pass vector data
arguments, vector tuple arguments and the rest vector ma
1 - 100 of 120 matches
Mail list logo
