I would prefer NOT to expose those --param on user manual since
generally those options are used for internal only, we should add -m
option and enable `--param=riscv-autovec-preference=scalable` by
default once we think it's stable enough.
On Wed, Aug 30, 2023 at 1:04 PM Palmer Dabbelt wrote:
>
On Wed, 2023-08-30 at 09:58 +0800, Yang Yujie wrote:
> LoongArch processors may not support memory accesses without natural
> alignments. Building libraries with -mstrict-align may help with
> toolchain binary compatiblity and performance on these implementations
> (e.g. Loongson 2K1000LA).
>
>
Vineet just got bit by the autovec params, and a bunch of us forgot
about the second one.
gcc/ChangeLog:
* doc/invoke.texi (RISC-V Options): Add some -march special
cases.
---
gcc/doc/invoke.texi | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff
On 8/28/23 21:31, Tsukasa OI wrote:
From: Tsukasa OI
arch-24.c and arch-25.c are exactly the same and redundant. The author
suspects that the original author intended to test two base ISAs (RV32I and
RV64I) so this commit changes arch-24.c to test that RV32I+Zcf does not
cause any errors.
Like MASK_LOAD_LANES/MASK_STORE_LANES, add MASK_LEN_ variant.
Bootstrap and Regression on X86 passed.
Ok for trunk?
gcc/ChangeLog:
* tree-ssa-alias.cc (ref_maybe_used_by_call_p_1): Add MASK_LEN_ variant.
(call_may_clobber_ref_p_1): Ditto.
* tree-ssa-loop-ivopts.cc
Committed, thanks Kito.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Kito Cheng via Gcc-patches
Sent: Wednesday, August 30, 2023 10:57 AM
To: Juzhe-Zhong
Cc: gcc-patches@gcc.gnu.org; kito.ch...@sifive.com
Subject: Re: [PATCH] RISC-V: Make sure we get VL REG operand for VLMAX
Lgtm
Juzhe-Zhong 於 2023年8月30日 週三，10:22寫道：
> Fix ICE in "vect" testsuite:
>
> FAIL: gcc.dg/vect/pr64495.c (internal compiler error: in df_uses_record,
> at df-scan.cc:2958)
> FAIL: gcc.dg/vect/pr64495.c (test for excess errors
>
> After this patch, all current found VSETVL PASS related bugs in
On Tue, Aug 29, 2023 at 11:23 AM Nick Clifton via Gcc-patches
wrote:
>
> 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
Fix ICE in "vect" testsuite:
FAIL: gcc.dg/vect/pr64495.c (internal compiler error: in df_uses_record, at
df-scan.cc:2958)
FAIL: gcc.dg/vect/pr64495.c (test for excess errors
After this patch, all current found VSETVL PASS related bugs in "vect" are
fixed.
gcc/ChangeLog:
*
This is an update of
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627275.html
Changes since the last patchset:
1. Add new configure option --with-strict-align-lib to control
whether -mstrict-align should be used when building libraries.
This facilitates building toolchains
gcc/ChangeLog:
* config.gcc: add loongarch*-elf target.
* config/loongarch/elf.h: New file.
Link against newlib by default.
libgcc/ChangeLog:
* config.host: add loongarch*-elf target.
---
gcc/config.gcc | 15 ++-
gcc/config/loongarch/elf.h |
The configure script and the GCC driver are updated so that
it is easier to customize and control GCC builds for targeting
different LoongArch implementations.
* Make --with-abi obsolete, since it might cause different default ABI
under the same target triplet, which is undesirable. The
These are exported according to the LoongArch Toolchain Conventions[1]
as a replacement of the obsolete "_LOONGARCH_{ARCH,TUNE}" macros,
which are expanded to strings representing the actual architecture
and microarchitecture of the target.
[1] currently relased at
LoongArch processors may not support memory accesses without natural
alignments. Building libraries with -mstrict-align may help with
toolchain binary compatiblity and performance on these implementations
(e.g. Loongson 2K1000LA).
No significant performance degredation is observed on current
Because functions which follow vector calling convention variant has
callee-saved vector reigsters but functions which follow standard calling
convention don't have. We need to distinguish which function callee is so that
we can tell GCC exactly which vector registers callee will clobber. So I
Functions which follow vector calling convention variant need be annotated by
.variant_cc directive according the RISC-V Assembly Programmer's Manual[1] and
RISC-V ELF Specification[2].
[1]
https://github.com/riscv-non-isa/riscv-asm-manual/blob/master/riscv-asm.md#pseudo-ops
[2]
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
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
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
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.
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.
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,
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
> 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:
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
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
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, 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
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
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.
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
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
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
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
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
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
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();
> "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
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;
| ^~~~
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
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
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
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
>
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++
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
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,
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
> 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
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
> 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
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
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
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:
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
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
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
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.
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
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
> > ---
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
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
>
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
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
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 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;
+
> +/* 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
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:
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
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
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
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
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
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
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)
> +
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
Committed, thanks Robin.
On 2023/8/29 21:10, Robin Dapp wrote:
Hi Lehua,
thanks, LGTM now.
Regards
Robin
--
Best,
Lehua
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
Hi Lehua,
thanks, LGTM now.
Regards
Robin
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
>
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
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
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.
>
>
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
>>
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
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]
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
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
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
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)
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
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!
>> >>
>> >>
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:
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
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:
> >>
> >> >
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
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,
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 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
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
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
1 - 100 of 122 matches
Mail list logo
