On Thu, Sep 7, 2023 at 10:25 PM Lehua Ding wrote:
>
> Hi,
>
> This patch adds support that tries to fold `MIN (poly, poly)` to
> a constant. Consider the following C Code:
Does it make sense to handle max also?
Thanks,
Andrew
>
> ```
> void foo2 (int* restrict a, int* restrict b, int n)
> {
>
Hi,
This patch adds support that tries to fold `MIN (poly, poly)` to
a constant. Consider the following C Code:
```
void foo2 (int* restrict a, int* restrict b, int n)
{
for (int i = 0; i < 3; i += 1)
a[i] += b[i];
}
```
Before this patch:
```
void foo2 (int * restrict a, int *
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,} on SPR.
Ready push to trunk and backport to GCC13/GCC12.
gcc/ChangeLog:
PR target/111306
* config/i386/sse.md (int_comm): New int_attr.
(fma__):
Remove % for Complex conjugate operations since they're not
Maybe use $(AM_V_at) instead? That would allow it to be controlled by
the --enable-silent-rules flag to configure, as well as make V=1 vs.
make V=0 too.
On Thu, Sep 7, 2023 at 9:32 AM Jonathan Wakely via Gcc-patches
wrote:
>
> Any objections to this change?
>
> -- >8 --
>
> This removes the 39
On 2023-09-08 04:33 Palmer Dabbelt wrote:
>
>On Thu, 07 Sep 2023 13:16:36 PDT (-0700), dimi...@dinux.eu wrote:
>> Hi,
>>
>> This patch appears to have caused PR 111259.
Hi Patrick
We're reproducing the issue also.
One thing that puzzles me is why a zcmp predicate casused
a regression in
gcc/ChangeLog:
* common/config/loongarch/loongarch-common.cc:
(default_options loongarch_option_optimization_table):
Default to -fsched-pressure.
---
gcc/common/config/loongarch/loongarch-common.cc | 1 +
1 file changed, 1 insertion(+)
diff --git
Accoring to Kito's advice, using "MASK(name) Var(other_flag_name)"
to generate MASK and TARGET MACRO automatically.
This patch improve the MACRO generation of MASK_* and TARGET_*.
Due to the more and more riscv extensions are added, the default target_flag
is full.
Before this patch,if you want to
From: Tsukasa OI
This is in parity with the LLVM commit 599421ae36c3 ("[RISCV] Re-define
sha256, Zksed, and Zksh intrinsics to use i32 types.").
SHA-256, SM3 and SM4 instructions operate on 32-bit integers and upper
32-bits have no effects on RV64 (the output is sign-extended from the
original
Hi,
This is built on another RFC PATCH "RISC-V: Change RISC-V bit manipulation
/ scalar crypto builtin types" and changes SHA-256, SM3 and SM4 intrinsics
operate on uint32_t, not on XLEN-bit wide integers.
This is in parity with the LLVM commit 599421ae36c3 ("[RISCV] Re-define
sha256, Zksed, and
PR analyzer/110529 notes that -fanalyzer was giving up on execution
paths that follow a computed goto, due to ignoring CFG edges with the
flag EDGE_ABNORMAL set.
This patch implements enough handling for them to allow analysis of
such execution paths to continue.
Successfully bootstrapped &
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r14-3793-g18f1f79ec5b1f1.
gcc/analyzer/ChangeLog:
* region-model.h: fix -Wunused-parameter warnings
---
gcc/analyzer/region-model.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
In the conversion of iranges to wide_int (commit cb779afeff204f), I
mistakenly made contains_zero_p() return TRUE for undefined ranges.
This means the rest of the patch was adjusted for this stupidity.
For example, we ended up doing the following, to make up for the fact
that contains_zero_p was
On 9/7/23 16:12, Patrick Palka wrote:
On Thu, 7 Sep 2023, Jason Merrill wrote:
On 9/6/23 18:07, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? This cache apparently has a 98% hit rate for TYPE_HAS_CONVERSION
types on some test files.
On Thu, 07 Sep 2023 13:16:36 PDT (-0700), dimi...@dinux.eu wrote:
Hi,
This patch appears to have caused PR 111259.
Thanks. Looks like wer'e not running our tests with RTL checking,
Patrick is going to try and see if we've got compute time left for some
builds -- even just having builds
Hi,
This patch appears to have caused PR 111259.
Regards,
Dimitar
On Tue, Aug 29, 2023 at 08:37:46AM +, Fei Gao wrote:
> From: Die Li
>
> Signed-off-by: Die Li
> Co-Authored-By: Fei Gao
>
> gcc/ChangeLog:
>
> * config/riscv/peephole.md: New pattern.
> *
On Thu, 7 Sep 2023, Jason Merrill wrote:
> On 9/6/23 18:07, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk? This cache apparently has a 98% hit rate for TYPE_HAS_CONVERSION
> > types on some test files.
>
> Does it make a measurable
On 7.9.2023 19:40, Jonathan Wakely wrote:
> On 29/08/23 15:04 +0300, Pekka Seppänen wrote:
>> 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.
>> *
When range_of_stmt invokes prefill_name to evaluate unvisited
dependneciesit should not mark visited names as always_current.
when raner_cache::get_globaL_range() is invoked with the optional
"current_p" flag, it triggers additional functionality. This call is
meant to be from within ranger
On 9/6/23 18:07, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? This cache apparently has a 98% hit rate for TYPE_HAS_CONVERSION
types on some test files.
Does it make a measurable difference in compile time?
+/* A cache of the result of
On 9/6/23 18:09, Patrick Palka wrote:
On Mon, 28 Aug 2023, Jason Merrill wrote:
On 8/24/23 09:31, Patrick Palka wrote:
On Wed, 23 Aug 2023, Jason Merrill wrote:
On 8/21/23 21:51, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look like
a reasonable
On 9/7/23 11:23, Marek Polacek wrote:
On Tue, Sep 05, 2023 at 04:36:34PM -0400, Jason Merrill wrote:
On 9/5/23 15:59, Marek Polacek wrote:
On Tue, Sep 05, 2023 at 10:52:04AM -0400, Jason Merrill wrote:
On 9/1/23 13:23, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok
On 9/7/2023 6:19 AM, Jeff Law wrote:
On 9/6/23 11:50, Edwin Lu wrote:
This patch turns on the assert which ensures every instruction has type
that is not TYPE_UNKNOWN.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_sched_variable_issue): Remove assert
And this is fine. But hold off
On Mon, 2023-09-04 at 22:13 -0400, Eric Feng wrote:
> Hi Dave,
Hi Eric, thanks for the patch.
>
> Recently I've been working on symbolic value support for the reference
> count checker. I've attached a patch for it below; let me know it looks
> OK for trunk. Thanks!
>
> Best,
> Eric
>
> ---
On 9/6/2023 4:33 PM, Kito Cheng wrote:
csr is kind of confusing, I would suggest something like `pushpop` and
`mvpair`.
Sounds good! I'll make the update.
Edwin
On 9/6/2023 4:23 PM, Kito Cheng wrote:
LGTM
Edwin Lu 於 2023年9月7日 週四 01:51 寫道：
This patch adds types to vector instructions that were added after
or were
missed by the original patch
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628594.html
gcc/ChangeLog:
On Thu, Sep 07, 2023 at 10:18:37AM -0600, Sandra Loosemore wrote:
> This ICE was caused by an invalid assumption that all BIND_EXPRs have
> a non-null BIND_EXPR_BLOCK. In C++ these do exist and are used for
> temporaries introduced in expressions that are not full-expressions.
> Since they have
Hi
Any news regarding this problem ?
François
On 23/08/2023 19:35, François Dumont wrote:
Hi
The few tests that are failing in versioned namespace mode are due to
those friend declarations.
This is a fix proposal even if I considered 2 other options:
1. Make __format::_Arg_store a struct
On 01/09/2023 10:59, Jonathan Wakely wrote:
On Tue, 29 Aug 2023 at 20:52, François Dumont via Libstdc++
wrote:
Hi
Any feedback regarding this patch ?
This is a fairly large patch
I've decided to split it, at least in 2.
So just ignore this one, I'll submit new ones once abi issue is
On Mon, 21 Aug 2023 at 21:40, Jonathan Wakely wrote:
>
>
>
> On Mon, 21 Aug 2023, 21:33 Bruno Victal, wrote:
>>
>> This small patch-series fixes the 'doc-install-info' rule
>> and updates the URI used for docbook-xsl.
>
>
> Thanks! I'll get these committed tomorrow.
It took a little longer than
On 9/7/23 02:56, Tobias Burnus wrote:
Main reason was to fix an ICV value; as collateral change, I also added
documentation for some of the memory-management functions.
Comments, suggestions? If not, I will commit it soon.
I only have one nit:
+@node omp_destroy_allocator
+@subsection
Hello,
This patch is a simple addition of a debug counter to FMA formation in
tree-ssa-math-opts.cc. Given that issues with FMAs do occasionally
pop up, it seems genuinely useful.
I simply added an if right after the initial checks in
convert_mult_to_fma even though when FMA formation deferring
Tested x86_64-linux. Pushed to trunk.
-- >8 --
A target selector allows multiple target triplets, it's not necessary to
use the || operator in a logical expression.
libstdc++-v3/ChangeLog:
* testsuite/27_io/filesystem/path/concat/94063.cc: Simplify
dg-do target selector.
---
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Also fix the name of a source file used by an effective target check.
libstdc++-v3/ChangeLog:
* testsuite/config/default.exp: Remove trailing whitespace.
* testsuite/lib/dg-options.exp: Likewise.
* testsuite/lib/prune.exp:
On 29/08/23 15:04 +0300, Pekka Seppänen wrote:
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.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_block_move_straight):
Check precondition (delta must be a power of 2) and use
popcount_hwi instead of a homebrew loop.
---
I've not run a full bootstrap with this, but it should be obvious.
Ok for trunk?
On Fri, 18 Aug 2023 at 20:14, Paul M. Bendixen wrote:
>
> Hi
> Jonathan, I just went over the proposal again as well as [compliance], which
> Arsen mentioned ( https://wg21.link/compliance ) don't seem to mention either
> or .
Those headers were freestanding in C++17. They're not present in
This ICE was caused by an invalid assumption that all BIND_EXPRs have
a non-null BIND_EXPR_BLOCK. In C++ these do exist and are used for
temporaries introduced in expressions that are not full-expressions.
Since they have no block to fix up, the traversal can just ignore
these tree nodes.
gcc/ChangeLog:
* config/loongarch/loongarch.h (LARCH_MAX_MOVE_PER_INSN):
Define to the maximum amount of bytes able to be loaded or
stored with one machine instruction.
* config/loongarch/loongarch.cc (loongarch_mode_for_move_size):
New static function.
Tested x86_64-linux. Built on avr. Pushed to trunk.
-- >8 --
The filesystem code was using these functions without checking for their
existence, assuming that any UNIX-like libc with would always
provide them. That's not true for some newlib targets like arm-eabi.
libstdc++-v3/ChangeLog:
libstdc++-v3/ChangeLog:
* acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Disable by default
for avr.
* configure: Regenerate.
---
libstdc++-v3/acinclude.m4 | 5 -
libstdc++-v3/configure| 5 -
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git
On Tue, Sep 05, 2023 at 04:36:34PM -0400, Jason Merrill wrote:
> On 9/5/23 15:59, Marek Polacek wrote:
> > On Tue, Sep 05, 2023 at 10:52:04AM -0400, Jason Merrill wrote:
> > > On 9/1/23 13:23, Marek Polacek wrote:
> > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > > >
> > >
Forget about this patch.
I found a better and reasonable way to fix it.
juzhe.zh...@rivai.ai
From: Juzhe-Zhong
Date: 2023-09-07 22:05
To: gcc-patches
CC: kito.cheng; kito.cheng; jeffreyalaw; rdapp.gcc; Juzhe-Zhong
Subject: [PATCH] RISC-V: Replace rtx REG for zero REGS operations
This patch
Thanks for looking at it in detail.
> Yeah, I think this is potentially a blocker for propagating A into B
> when A is used elsewhere. Combine is able to combine A and B while
> keeping A in parallel with the result. I think either fwprop would
> need to try that too, or it would need to be
gcc/
* config/xtensa/predicates.md (xtensa_cstoresi_operator): Add
unsigned comparisons.
* config/xtensa/xtensa.cc (xtensa_expand_scc): Add code
generation of salt/saltu instructions.
* config/xtensa/xtensa.h (TARGET_SALT): New macro.
*
The v7 memory ordering model allows reordering of conditional atomic
instructions.
To avoid this, make all atomic patterns unconditional. Expand atomic loads and
stores for all architectures so the memory access can be wrapped into an UNSPEC.
Passes regress/bootstrap, OK for commit?
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111225
The patch was successfully bootstrapped and tested on x86-64, aarch64,
and ppc64le.
commit f7bca44d97ad01b39f9d6e7809df7bf517eeb2fb
Author: Vladimir N. Makarov
Date: Thu Sep 7 09:59:10 2023 -0400
[LRA]:
This patch fixes these following FAILs:
FAIL: gcc.target/riscv/zero-scratch-regs-3.c -O0 (internal compiler error:
in gen_reg_rtx, at emit-rtl.cc:1176)
FAIL: gcc.target/riscv/zero-scratch-regs-3.c -O0 (test for excess errors)
FAIL: gcc.target/riscv/zero-scratch-regs-3.c -O1 (internal
On 9/1/23 02:40, Andrew Pinski wrote:
On Fri, Aug 11, 2023 at 8:08 AM Andrew MacLeod via Gcc-patches
wrote:
If this is only going to work with integers, you might want to check
that somewhere or switch to irange and int_range_max..
You can make it work with any kind (if you know op1 is a
Robin Dapp writes:
> Hi Richard,
>
> I did some testing with the attached v2 that does not restrict to UNARY
> anymore. As feared ;) there is some more fallout that I'm detailing below.
>
> On Power there is one guality fail (pr43051-1.c) that I would take
> the liberty of ignoring for now.
>
>
Alright, was not expecting to mess up this patchset so bad so here we go:
This patchset reintroduces proper targetrustm hooks without the old
problematic mess of macros we had, which had been removed for the first
merge of gccrs upstream.
Tested on x86-64 GNU Linux, and has also been present in
From: Iain Buclaw
gcc/ChangeLog:
* config.gcc (*-*-solaris2*): Set rust_target_objs and
target_has_targetrustm.
* config/t-sol2 (sol2-rust.o): New rule.
* config/sol2-rust.cc: New file.
---
gcc/config.gcc | 2 ++
gcc/config/sol2-rust.cc | 40
From: Iain Buclaw
gcc/ChangeLog:
* config.gcc (*linux*): Set rust target_objs, and
target_has_targetrustm,
* config/t-linux (linux-rust.o): New rule.
* config/linux-rust.cc: New file.
---
gcc/config.gcc | 2 ++
gcc/config/linux-rust.cc | 57
From: Iain Buclaw
gcc/ChangeLog:
* config.gcc (*-*-openbsd*): Set rust_target_objs and
target_has_targetrustm.
* config/t-openbsd (openbsd-rust.o): New rule.
* config/openbsd-rust.cc: New file.
---
gcc/config.gcc | 2 ++
gcc/config/openbsd-rust.cc |
From: Iain Buclaw
gcc/ChangeLog:
* config.gcc (*-*-dragonfly*): Set rust_target_objs and
target_has_targetrustm.
* config/t-dragonfly (dragonfly-rust.o): New rule.
* config/dragonfly-rust.cc: New file.
---
gcc/config.gcc | 2 ++
From: Iain Buclaw
gcc/ChangeLog:
* config.gcc (*-*-netbsd*): Set rust_target_objs and
target_has_targetrustm.
* config/t-netbsd (netbsd-rust.o): New rule.
* config/netbsd-rust.cc: New file.
---
gcc/config.gcc| 2 ++
gcc/config/netbsd-rust.cc | 40
From: Iain Buclaw
gcc/ChangeLog:
* config.gcc (*-*-fuchsia): Set tmake_rule, rust_target_objs,
and target_has_targetrustm.
* config/fuchsia-rust.cc: New file.
* config/t-fuchsia: New file.
---
gcc/config.gcc | 3 +++
gcc/config/fuchsia-rust.cc | 40
From: Iain Buclaw
gcc/ChangeLog:
* config.gcc (*-*-freebsd*): Set rust_target_objs and
target_has_targetrustm.
* config/t-freebsd (freebsd-rust.o): New rule.
* config/freebsd-rust.cc: New file.
---
gcc/config.gcc | 2 ++
gcc/config/freebsd-rust.cc |
From: Iain Buclaw
gcc/ChangeLog:
* config.gcc (i[34567]86-*-mingw* | x86_64-*-mingw*): Set
rust_target_objs and target_has_targetrustm.
* config/t-winnt (winnt-rust.o): New rule.
* config/winnt-rust.cc: New file.
---
gcc/config.gcc | 2 ++
From: Iain Buclaw
gcc/ChangeLog:
* config.gcc (*-*-darwin*): Set rust_target_objs and
target_has_targetrustm.
* config/t-darwin (darwin-rust.o): New rule.
* config/darwin-rust.cc: New file.
---
gcc/config.gcc| 2 ++
gcc/config/darwin-rust.cc | 44
From: Iain Buclaw
gcc/ChangeLog:
* config.gcc (*-*-vxworks*): Set rust_target_objs and
target_has_targetrustm.
* config/t-vxworks (vxworks-rust.o): New rule.
* config/vxworks-rust.cc: New file.
---
gcc/config.gcc | 3 +++
gcc/config/t-vxworks
From: Iain Buclaw
There are still quite a lot of the previously reverted i386-rust.cc
missing, so it's only a partial reimplementation.
gcc/ChangeLog:
* config/i386/t-i386 (i386-rust.o): New rule.
* config/i386/i386-rust.cc: New file.
* config/i386/i386-rust.h: New
From: Iain Buclaw
gcc/ChangeLog:
* doc/tm.texi: Regenerate.
* doc/tm.texi.in: Document TARGET_RUST_OS_INFO.
gcc/rust/ChangeLog:
* rust-session-manager.cc (Session::init): Call
targetrustm.rust_os_info.
* rust-target.def (rust_os_info): New hook.
---
From: Iain Buclaw
gcc/ChangeLog:
* doc/tm.texi: Regenerate.
* doc/tm.texi.in: Add @node for Rust language and ABI, and document
TARGET_RUST_CPU_INFO.
gcc/rust/ChangeLog:
* rust-lang.cc (rust_add_target_info): Remove sorry.
* rust-session-manager.cc:
From: Iain Buclaw
gcc/ChangeLog:
* Makefile.in (tm_rust_file_list, tm_rust_include_list, TM_RUST_H,
RUST_TARGET_DEF, RUST_TARGET_H, RUST_TARGET_OBJS): New variables.
(tm_rust.h, cs-tm_rust.h, default-rust.o,
rust/rust-target-hooks-def.h,
Any objections to this change?
-- >8 --
This removes the 39 lines of shell commands that get echoed when
starting the testsuite. The fact that near the end of that output it
prints `echo "WARNING: could not find \`runtest'" 1>&2; :;` makes it
look like that warning is actually being shown the
On 9/6/23 11:50, Edwin Lu wrote:
This patch turns on the assert which ensures every instruction has type
that is not TYPE_UNKNOWN.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_sched_variable_issue): Remove assert
And this is fine. But hold off committing until all the dependencies
On 9/6/23 18:42, Tsukasa OI via Gcc-patches wrote:
Looks okay to me but will need to resolve merge conflicts after commit
af88776caa20 ("RISC-V: Add support for 'XVentanaCondOps' reusing
'Zicond' support").
Sure. We allow trival updates to resolve merge conflicts without
needing another
On Thu, Sep 07, 2023 at 02:23:00PM +0300, Dan Carpenter wrote:
> On Thu, Sep 07, 2023 at 06:04:09AM -0500, Segher Boessenkool wrote:
> > On Thu, Sep 07, 2023 at 12:48:25PM +0300, Dan Carpenter via Gcc-patches
> > wrote:
> > > I started to hunt
> > > down all the Makefile which add a -Werror but
On Thu, Sep 07, 2023 at 07:22:45AM -0400, Steven Rostedt wrote:
> On Thu, 7 Sep 2023 06:04:09 -0500
> Segher Boessenkool wrote:
> > On Thu, Sep 07, 2023 at 12:48:25PM +0300, Dan Carpenter via Gcc-patches
> > wrote:
> > No. You should patch your program, instead. One easy way is to add a
> >
On 9/7/23 02:23, Uros Bizjak wrote:
On Wed, Sep 6, 2023 at 9:43 PM Vladimir Makarov wrote:
On 9/1/23 05:07, Hongyu Wang wrote:
I think the approach proposed by Intel developers is better. In some way
we already use such approach when we pass memory mode to get the base
reg class.
Committed, thanks Robin.
On 2023/9/7 20:00, Robin Dapp via Gcc-patches wrote:
I have an almost identical patch locally that passed testing as well
but didn't get around to posting it yet. Therefore LGTM.
Regards
Robin
--
Best,
Lehua
I have an almost identical patch locally that passed testing as well
but didn't get around to posting it yet. Therefore LGTM.
Regards
Robin
This patterns fix these following ICE FAILs when running the whole GCC testsuite
with enabling scalable vector by default.
All of these FAILs are fixed:
FAIL: c-c++-common/opaque-vector.c -std=c++14 (internal compiler error: in
emit_move_multi_word, at expr.cc:4079)
FAIL:
On Thu, Sep 07, 2023 at 05:47:36PM +0800, Xi Ruoyao wrote:
> On Thu, 2023-09-07 at 17:31 +0800, Yang Yujie wrote:
> > > This is bad. It makes BOOT_CFLAGS=-mlasx or CFLAGS_FOR_TARGET=-mlasx
> > > silently ignored so we cannot test a LSX/LASX or vectorizer change with
> > > them.
> > >
> > > Why
On Thu, Sep 07, 2023 at 06:04:09AM -0500, Segher Boessenkool wrote:
> On Thu, Sep 07, 2023 at 12:48:25PM +0300, Dan Carpenter via Gcc-patches wrote:
> > I started to hunt
> > down all the Makefile which add a -Werror but there are a lot and
> > eventually I got bored and gave up.
>
> I have a
On Thu, 7 Sep 2023 06:04:09 -0500
Segher Boessenkool wrote:
> On Thu, Sep 07, 2023 at 12:48:25PM +0300, Dan Carpenter via Gcc-patches wrote:
> > I started to hunt
> > down all the Makefile which add a -Werror but there are a lot and
> > eventually I got bored and gave up.
>
> I have a patch
On Thu, Sep 07, 2023 at 12:48:25PM +0300, Dan Carpenter via Gcc-patches wrote:
> I started to hunt
> down all the Makefile which add a -Werror but there are a lot and
> eventually I got bored and gave up.
I have a patch stack for that, since 2014 or so. I build Linux with
unreleased GCC versions
OK,
Thank you for your contribution,
Claudiu
On Wed, Sep 6, 2023 at 3:50 PM Shahab Vahedi wrote:
>
> This patch covers signed and unsigned subtractions. The generated code
> would be something along these lines:
>
> signed:
> sub.f r0, r1, r2
> b.v @label
>
> unsigned:
> sub.f
Ok.
Thank you for your contribution,
Claudiu
On Wed, Sep 6, 2023 at 3:50 PM Shahab Vahedi wrote:
>
> This patch covers signed and unsigned additions. The generated code
> would be something along these lines:
>
> signed:
> add.f r0, r1, r2
> b.v @label
>
> unsigned:
> add.f r0,
Hi,
Gentle ping...
BR,
Jeff (Jiufu Guo)
Jiufu Guo writes:
> Hi,
>
> If a constant is possible to be rotated to/from a positive or negative
> value which "li" can generated, then "li;rotldi" can be used to build
> the constant.
>
> Compare with the previous version:
>
On Thu, 2023-09-07 at 17:47 +0800, Xi Ruoyao wrote:
/* snip */
> I've made some local experiment too, I think we can add a "-mbuild-
> multilib" option which does nothing but in the hacked spec we can wrap
> the line in %{mbuild-multilib:...}:
>
> %{mbuild-multilib:% %{mabi=lp64d:-march=la464
On Wed, Sep 06, 2023 at 09:53:27PM -0400, Steven Rostedt wrote:
> On Thu, 7 Sep 2023 08:54:38 +1000
> Dave Chinner wrote:
>
> > And let's not forget: removing a filesystem from the kernel is not
> > removing end user support for extracting data from old filesystems.
> > We have VMs for that - we
On Thu, 2023-09-07 at 17:31 +0800, Yang Yujie wrote:
> > This is bad. It makes BOOT_CFLAGS=-mlasx or CFLAGS_FOR_TARGET=-mlasx
> > silently ignored so we cannot test a LSX/LASX or vectorizer change with
> > them.
> >
> > Why do we need to purge all user-specified -m options here?
>
> Yes, that
On Thu, Sep 07, 2023 at 10:20:19AM +0200, Christophe Lyon via Gcc-patches wrote:
> On Tue, 5 Sept 2023 at 16:38, Tobias Burnus wrote:
>
> > That's based on the fail
> > https://gcc.gnu.org/pipermail/gccadmin/2023q3/020349.html
> > and on the discussion on IRC.
> >
>
> Sorry I didn't notice the
Pushed to trunk this morning with Changelogs and SoB lines.
Thanks for the review David!
All the best,
Arthur
On 9/6/23 15:53, Arthur Cohen wrote:
This short patchset from David Malcolm enables errors to contain extra
metadata - this is particularly useful for the Rust frontend, which will
On Thu, Sep 07, 2023 at 11:30:53AM +0200, Tobias Burnus wrote:
> contrib/gcc-changelog: Check whether revert-commit exists
>
> contrib/ChangeLog:
>
> * gcc-changelog/git_commit.py (GitCommit.__init__):
> Handle commit_to_info_hook = None; otherwise, if None,
> regard it as
> This is bad. It makes BOOT_CFLAGS=-mlasx or CFLAGS_FOR_TARGET=-mlasx
> silently ignored so we cannot test a LSX/LASX or vectorizer change with
> them.
>
> Why do we need to purge all user-specified -m options here?
Yes, that is an issue that I haven't considered.
The purge rules (self_specs)
First: Hi all,
attached is an updated patch (v3) where I changed the wording
of the warning to distinguish technical reasons for not using
the commit data (→ git_email.py) from not-found lookups (git_check_commit.py)
to avoid confusion. (See also below.)
Any remarks/suggestions - related to
When I tried to use config-list.mk, the build for every triple except
the build machine's failed for m2. This is because, unlike other
languages, m2 builds target objects during all-gcc. The build will
therefore fail unless you have access to an appropriate binutils
(or an equivalent). That's
On Thu, Sep 07, 2023 at 10:36:02AM +0200, Thomas Schwinge wrote:
> Minor comment/question: are we doing away with the property that
> 'assert'-like "calls" must not have side effects? Per 'gcc/system.h',
> this is "OK" for 'gcc_assert' for '#if ENABLE_ASSERT_CHECKING' or
> '#elif (GCC_VERSION >=
Main reason was to fix an ICV value; as collateral change, I also added
documentation for some of the memory-management functions.
Comments, suggestions? If not, I will commit it soon.
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
On Wed, 2023-09-06 at 09:04 +0800, Yang Yujie wrote:
> On Tue, Sep 05, 2023 at 09:31:56PM +0800, Xi Ruoyao wrote:
> > On Thu, 2023-08-31 at 20:48 +0800, Yang Yujie wrote:
> > > * Support options for LoongArch SIMD extensions:
> > > new configure options --with-simd={none,lsx,lasx};
> > > new
Hi Jakub!
On 2023-08-09T20:17:50+0200, Jakub Jelinek via Gcc-patches
wrote:
> The following patch introduces the middle-end part of the _BitInt
> support, a new BITINT_TYPE, handling it where needed, except the lowering
> pass and sanitizer support.
Minor comment/question: are we doing away
Hi!
On Tue, 5 Sept 2023 at 16:38, Tobias Burnus wrote:
> That's based on the fail
> https://gcc.gnu.org/pipermail/gccadmin/2023q3/020349.html
> and on the discussion on IRC.
>
Sorry I didn't notice the problem, nor the discussion on IRC, but I can see
that my commits created the problem, sorry
On Thu, 2023-09-07 at 10:15 +0800, chenglulu wrote:
>
> 在 2023/9/6 下午6:58, Xi Ruoyao 写道:
> > Forgot to mention: I've bootstrapped and regtested this patch on
> > loongarch64-linux-gnu (with PR110939 patch applied to unbreak the
> > bootstrapping). Ok for trunk?
>
> LGTM!
>
> Thanks!
Pushed
> Thanks for giving it a go. Can you post the latest version of the
> regpressure patch too? The previous on-list version I could find
> seems to be too old.
Oh, sure, attached. Apologies, I added the regpressure_same_class
convenience helper but forgot to re-send it.
Regards
Robin
>From
On Thu, 2023-09-07 at 15:00 +0800, Xiaolong Chen wrote:
/* snip */
> diff --git
> a/gcc/testsuite/gcc.target/loongarch/vector/simd_correctness_check.h
> b/gcc/testsuite/gcc.target/loongarch/vector/simd_correctness_check.h
> new file mode 100644
> index 000..7be199ee3a0
> --- /dev/null
This patch is not ready but they all will be fixed very soon.
gcc/ChangeLog:
* config/riscv/riscv.opt: Set default as scalable vectorization.
---
gcc/config/riscv/riscv.opt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/riscv/riscv.opt
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The tests for the std::ranges access CPOs (ranges::begin etc) use
pathological types with ridiculous overload sets for begin/end/data
members, to exercise all the corner cases in the specification.
Since P2278R4 "cbegin should always return a
Tested x86_64-linux. Pushed to trunk.
-- >8 --
These tests do not run by default, because the c++20 effective target
selector isn't matched.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/unordered_map/operations/1.cc: Add
dg-options for C++20 mode.
*
1 - 100 of 110 matches
Mail list logo
