From: Tsukasa OI
In commit 1aaf3a64e92a ("[PATCH] RISC-V: Deduplicate #error messages in
testsuite"), the author made a mistake to miss the test after adding
quotes around extension names. To avoid future errors and for consistency
with other #error uses in the RISC-V testsuite, this commit
From: Tsukasa OI
In commit 1aaf3a64e92a ("[PATCH] RISC-V: Deduplicate #error messages in
testsuite"), the author made a mistake to miss the test after adding
quotes around extension names. To avoid future errors and for consistency
with other #error uses in the RISC-V testsuite, this commit
On Thu, Aug 17, 2023 at 4:05 PM Iain Sandoe wrote:
>
> Hi Eric,
>
> thanks for working on this.
>
> > On 17 Aug 2023, at 20:35, Eric Gallager wrote:
> >
> > This is a pretty simple patch that ought to help Darwin users understand
> > better why their build is failing when they forget to pass the
From: Lipeng Zhu
This patch try to introduce the rwlock and split the read/write to
unit_root tree and unit_cache with rwlock instead of the mutex to
increase CPU efficiency. In the get_gfc_unit function, the percentage
to step into the insert_unit function is around 30%, in most instances,
we
Hi Thomas,
>
> Hi Lipeng,
>
> > May I know any comment or concern on this patch, thanks for your time
> >
>
> Thanks for your patience in getting this reviewed.
>
> A few remarks / questions.
>
> Which strategy is used in this implementation, read-preferring or write-
> preferring? And if
Committed, thanks Robin.
--Original--
From:
"Robin Dapp"
This little patch fixs the -march error of a zhinxmin testcase I added earlier
and an old zhinxmin testcase, since these testcases are for zhinxmin extension
and not zfhmin extension.
---
gcc/testsuite/gcc.target/riscv/_Float16-zhinxmin-3.c | 2 +-
From: Pan Li
As suggested by kito, we will add new frm_opt_type template arg
to the op class, to avoid the duplicated function expand.
Signed-off-by: Pan Li
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc
(class binop_frm): Removed.
(class
Committed, thanks Robin and Palmer.
--Original--
From:
"Palmer Dabbelt"
If GCC is tested with a sysroot which doesn't contain a Python
installation (e.g., with a command such as
"make check-gcc-c FLAGS_UNDER_TEST="--sysroot=/some/path"), but there's
a python3-config in $PATH, then the testsuite will pick up the host's
Python.h which can't actually be used:
Executing
FAIL: gcc.target/riscv/zvkn-1.c -O0 (test for excess errors)
FAIL: gcc.target/riscv/zvkn-1.c -O1 (test for excess errors)
FAIL: gcc.target/riscv/zvkn-1.c -O2 (test for excess errors)
FAIL: gcc.target/riscv/zvkn-1.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none (test for excess
On Thu, 17 Aug 2023 at 20:44, Jonathan Wakely wrote:
>
> On Thu, 17 Aug 2023 at 20:37, Jonathan Wakely wrote:
> >
> > On Thu, 17 Aug 2023 at 19:59, Jonathan Wakely wrote:
> > >
> > > On Thu, 17 Aug 2023 at 18:40, François Dumont
> > > wrote:
> > > >
> > > >
> > > > On 17/08/2023 19:22,
On Fri, 18 Aug 2023 at 00:20, Hans-Peter Nilsson wrote:
>
> > Date: Thu, 17 Aug 2023 21:32:29 +0100
> > From: Jonathan Wakely via Gcc-patches
>
> > Tested x86_64-linux. Pushed to trunk.
>
> Does the below typo imply that for x86_64-linux,
> "__DBL_MANT_DIG__ == __LDBL_MANT_DIG__" is false and
Tested x86_64-linux. Pushed to trunk.
-- >8 --
When the library is built with --disable-libstdcxx-dual-abi the only
type of std::string supported is the COW string, and the two global
std::string objects in tzdb.cc have to allocate memory. I added them
thinking they would fit in the SSO string
> Date: Thu, 17 Aug 2023 21:32:29 +0100
> From: Jonathan Wakely via Gcc-patches
> Tested x86_64-linux. Pushed to trunk.
Does the below typo imply that for x86_64-linux,
"__DBL_MANT_DIG__ == __LDBL_MANT_DIG__" is false and the
code is actually untested?
> libstdc++-v3/ChangeLog:
>
> *
On 2023-08-17 17:25, Qing Zhao wrote:
It's not exactly the same issue, the earlier discussion was about choosing sizes in the
same pass while the current one is about choosing between passes, but I agree it
"rhymes". This is what I was alluding to originally (for OST_MINIMUM use
MIN_EXPR if
> On Aug 17, 2023, at 4:57 PM, Siddhesh Poyarekar wrote:
>
> On 2023-08-17 16:23, Qing Zhao wrote:
Then, I think whatever MIN or MAX, the early phase has more precise
information than the later phase, we should use its result if it’s NOT
UNKNOWN?
>>>
>>> We can't be sure
On 2023-08-17 16:23, Qing Zhao wrote:
Then, I think whatever MIN or MAX, the early phase has more precise information
than the later phase, we should use its result if it’s NOT UNKNOWN?
We can't be sure about that though, can we? For example for something like
this:
struct S
{
int a;
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This makes it possible to format _Float32, _Float64 etc. in C++20 mode.
Previously it was only possible to format them in C++23 when the
typedefs and the std::to_chars overloads were defined.
Instead of relying on std::to_chars for those types, we
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The extended floating-point types such as _Float32 are supported by GCC
prior to C++23, you just can't use the standard-conforming names from
to refer to them. This change defines the specializations of
std::numeric_limits for those types for older
Tested x86_64-linux. Pushed to trunk.
-- >8 --
For targets where double and long double have the same representation we
can reuse the same __convert_to_v code for both types. This will
slightly reduce the size of the compiled code in the library.
libstdc++-v3/ChangeLog:
*
Tested x86_64-linux. Pushed to trunk. Probably good to backport.
-- >8 --
This constructor should only ever be used with a literal 0 as the
argument, so we can make it consteval. This has the nice advantage that
it is expanded immediately in the front end, and so GDB will never step
into the
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This shaves about 100ns off the std::locale constructor for named
locales (which is only about 1% of the total time).
Using !*s instead of !strcmp(s, "") doesn't make any difference as GCC
optimizes that already even at -O1. !strcmp(s, "C") is
Tested x86_64-linux. Pushed to trunk. Backport to gcc-13 to follow.
-- >8 --
For std::chrono formatting we can simplify __units_suffix by using
std::format_to to generate the "[n/m]s" suffix with the correct
character type and write directly to the output iterator, so it doesn't
need to be
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This changes how std::format creates wide strings, by replacing uses of
std::ctype::widen with the recently-added __to_wstring_numeric
helper function. This removes the dependency on the locale, which should
only be used for locale-specific formats
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Calling string::assign(Iter, Iter) with "foreign" iterators (not the
string's own iterator or pointer types) currently constructs a temporary
string and then calls replace to copy the characters from it. That means
we copy from the iterators twice,
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/experimental/internet (address_v4::to_string): Remove
unused parameter name.
---
libstdc++-v3/include/experimental/internet | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This change for C++26 affects std::to_string for floating-point
arguments, so that they should be formatted using std::format("{}", v)
instead of using sprintf. The modified specification in the standard
also affects integral arguments, but there's
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This uses std::string::__resize_and_overwrite to avoid initializing the
string buffer with characters that are immediately overwritten. This
results in about 6% better performance for the std_to_string case in
int-benchmark.cc from
Tested x86_64-linux. Pushed to trunk.
-- >8 --
There are several places in the library where we can improve performance
using resize_and_overwrite so it's inconvenient only being able to use
it in C++23 mode, and only for cxx11 strings. This adds it for COW
strings, and also adds
> On Aug 17, 2023, at 3:59 PM, Siddhesh Poyarekar wrote:
>
> On 2023-08-17 15:27, Qing Zhao wrote:
>>> Yes, that's it. Maybe it's more correct if instead of MAX_EXPR if for
>>> OST_MINIMUM we stick with the early_objsz answer if it's non-zero. I'm not
>>> sure if that's the case for
On 2023-08-17 15:27, Qing Zhao wrote:
Yes, that's it. Maybe it's more correct if instead of MAX_EXPR if for
OST_MINIMUM we stick with the early_objsz answer if it's non-zero. I'm not
sure if that's the case for maximum size though, my gut says it isn't.
So, the major purpose for adding the
Hi Eric,
thanks for working on this.
> On 17 Aug 2023, at 20:35, Eric Gallager wrote:
>
> This is a pretty simple patch that ought to help Darwin users understand
> better why their build is failing when they forget to pass the
> --with-sysroot= flag to configure.
>
> gcc/ChangeLog:
>
>
On Thu, 17 Aug 2023 at 20:37, Jonathan Wakely wrote:
>
> On Thu, 17 Aug 2023 at 19:59, Jonathan Wakely wrote:
> >
> > On Thu, 17 Aug 2023 at 18:40, François Dumont wrote:
> > >
> > >
> > > On 17/08/2023 19:22, Jonathan Wakely wrote:
> > > > On Sun, 13 Aug 2023 at 14:27, François Dumont via
On Thu, 17 Aug 2023 at 19:59, Jonathan Wakely wrote:
>
> On Thu, 17 Aug 2023 at 18:40, François Dumont wrote:
> >
> >
> > On 17/08/2023 19:22, Jonathan Wakely wrote:
> > > On Sun, 13 Aug 2023 at 14:27, François Dumont via Libstdc++
> > > wrote:
> > >> Here is the fixed patch tested in all 3
This is a pretty simple patch that ought to help Darwin users understand
better why their build is failing when they forget to pass the
--with-sysroot= flag to configure.
gcc/ChangeLog:
PR target/90835
* Makefile.in: improve error message when /usr/include is
missing
> On Aug 17, 2023, at 1:49 PM, Siddhesh Poyarekar wrote:
>
> On 2023-08-17 09:58, Qing Zhao wrote:
>>> So this is a (sort of) known issue, which necessitated the early_objsz pass
>>> to get an estimate before a subobject reference was optimized to a MEM_REF.
>> Do you mean that after a
When I added `cond_one_cmpl` (and the corresponding IFN) I had noticed cond_neg
standard named pattern was not documented and this adds the documentation for
all 4 named patterns now.
OK? Tested by building the manual.
gcc/ChangeLog:
* doc/md.texi (Standard patterns): Document cond_neg,
On Thu, 17 Aug 2023 at 18:40, François Dumont wrote:
>
>
> On 17/08/2023 19:22, Jonathan Wakely wrote:
> > On Sun, 13 Aug 2023 at 14:27, François Dumont via Libstdc++
> > wrote:
> >> Here is the fixed patch tested in all 3 modes:
> >>
> >> - _GLIBCXX_USE_DUAL_ABI
> >>
> >> -
Richard Biener writes:
>> Am 17.08.2023 um 13:25 schrieb Richard Sandiford via Gcc-patches
>> :
>>
>> Joseph Myers writes:
On Wed, 16 Aug 2023, Richard Sandiford via Gcc-patches wrote:
Would it be OK to add support for:
[[__extension__ ...]]
to suppress
This implements TLS Descriptors (TLSDESC) as specified in [1].
In TLSDESC instruction sequence, the first instruction relocates against
the target TLS variable, while subsequent instructions relocates against
the address of the first. Such usage of labels are not well-supported
within GCC. Due to
Quick question: do you plan to make the merge or should I ask Antoni?
Le jeu. 17 août 2023 à 17:59, Guillaume Gomez
a écrit :
> Thanks for the review!
>
> Le jeu. 17 août 2023 à 17:50, David Malcolm a écrit
> :
> >
> > On Thu, 2023-08-17 at 17:41 +0200, Guillaume Gomez wrote:
> > > And now I
On Thu, 17 Aug 2023 10:03:04 PDT (-0700), rdapp@gmail.com wrote:
Indeed all ANYLSF patterns have TARGET_HARD_FLOAT (==f extension) which
is incompatible with ZHINX or ZHINXMIN anyway. That should really be fixed
separately or at least clarified, maybe I'm missing something.
We've also got
On 2023-08-17 09:58, Qing Zhao wrote:
So this is a (sort of) known issue, which necessitated the early_objsz pass to
get an estimate before a subobject reference was optimized to a MEM_REF.
Do you mean that after a subobject reference was optimized to a MEM_REF, there
is no way to compute
On Thu, 17 Aug 2023 10:10:38 PDT (-0700), Patrick O'Neill wrote:
On 8/16/23 21:36, Jeff Law wrote:
On 8/16/23 19:17, Patrick O'Neill wrote:
This adds new regression tests to ensure half-register rotations are
correctly optimized into rori instructions.
gcc/testsuite/ChangeLog:
*
On 17/08/2023 19:22, Jonathan Wakely wrote:
On Sun, 13 Aug 2023 at 14:27, François Dumont via Libstdc++
wrote:
Here is the fixed patch tested in all 3 modes:
- _GLIBCXX_USE_DUAL_ABI
- !_GLIBCXX_USE_DUAL_ABI && !_GLIBCXX_USE_CXX11_ABI
- !_GLIBCXX_USE_DUAL_ABI && _GLIBCXX_USE_CXX11_ABI
I
operator_addr was simply calling fold_range() to implement op1_range,
but it turns out op1_range needs to be more restrictive.
take for example from the PR :
_13 = >maj
when folding, getting a value of 0 for op1 means dso->maj resolved to a
value of [0,0].
On Sun, 13 Aug 2023 at 14:27, François Dumont via Libstdc++
wrote:
>
> Here is the fixed patch tested in all 3 modes:
>
> - _GLIBCXX_USE_DUAL_ABI
>
> - !_GLIBCXX_USE_DUAL_ABI && !_GLIBCXX_USE_CXX11_ABI
>
> - !_GLIBCXX_USE_DUAL_ABI && _GLIBCXX_USE_CXX11_ABI
>
> I don't know what you have in mind
Another fix to define __cow_string(const std::string&) in
cxx11-stdexcept.cc even if ! _GLIBCXX_USE_DUAL_ABI.
On 13/08/2023 21:51, François Dumont wrote:
Here is another version with enhanced sizeof/alignof static_assert in
string-inst.cc for the std::__cow_string definition from .
The
On Tue, 15 Aug 2023 at 14:28, Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Mon, 14 Aug 2023, Prathamesh Kulkarni wrote:
> >> On Mon, 7 Aug 2023 at 13:19, Richard Biener
> >> wrote:
> >> > It doesn't seem to make a difference for x86. That said, the "fix" is
> >> > probably
On 8/16/23 21:36, Jeff Law wrote:
On 8/16/23 19:17, Patrick O'Neill wrote:
This adds new regression tests to ensure half-register rotations are
correctly optimized into rori instructions.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/zbb-rol-ror-08.c: New test.
*
> Am 17.08.2023 um 13:25 schrieb Richard Sandiford via Gcc-patches
> :
>
> Joseph Myers writes:
>>> On Wed, 16 Aug 2023, Richard Sandiford via Gcc-patches wrote:
>>>
>>> Would it be OK to add support for:
>>>
>>> [[__extension__ ...]]
>>>
>>> to suppress the pedwarn about using [[]]
Indeed all ANYLSF patterns have TARGET_HARD_FLOAT (==f extension) which
is incompatible with ZHINX or ZHINXMIN anyway. That should really be fixed
separately or at least clarified, maybe I'm missing something.
Still we can go forward with the patch itself as it improves things
independently, so
On Thu, Aug 17, 2023 at 01:44:42PM +, Qing Zhao wrote:
> Thanks for the testing case.
> Yes, I noticed this issue too, and already fixed it in my private branch.
>
> With the latest patch, the compilation has no issue:
> [opc@qinzhao-ol8u3-x86 108896]$ sh t
>
On 8/17/23 07:19, senthilkumar.selva...@microchip.com wrote:
On Wed, 2023-08-16 at 12:13 -0400, Vladimir Makarov wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know the
content is safe
The attached patch fixes recently found wrong insn removal in LRA port
for AVR.
The following patch fixes a problem with allocating the same stack slots
to conflicting pseudos. The problem exists only for AVR LRA port.
The patch was successfully bootstrapped and tested on x86-64 and aarch64.
commit c024867d1aa9d465e0236fc9d45d8e1d4bb6bd30
Author: Vladimir N. Makarov
Thanks for the review!
Le jeu. 17 août 2023 à 17:50, David Malcolm a écrit :
>
> On Thu, 2023-08-17 at 17:41 +0200, Guillaume Gomez wrote:
> > And now I just discovered that a lot of commits from Antoni's fork
> > haven't been sent upstream which is why the ABI count is so high in
> > his
On Thu, 2023-08-17 at 17:41 +0200, Guillaume Gomez wrote:
> And now I just discovered that a lot of commits from Antoni's fork
> haven't been sent upstream which is why the ABI count is so high in
> his repository. Fixed that as well.
Thanks for the updated patch; I was about to comment on that.
And now I just discovered that a lot of commits from Antoni's fork
haven't been sent upstream which is why the ABI count is so high in
his repository. Fixed that as well.
Le jeu. 17 août 2023 à 17:26, Guillaume Gomez
a écrit :
>
> Antoni spot a typo I made:
>
> I added
> On Thu, 17 Aug 2023, Jose E. Marchesi via Gcc-patches wrote:
>
>> +@opindex Wcompare-distinct-pointer-types
>> +@item -Wcompare-distinct-pointer-types
>
> This @item should say @r{(C and Objective-C only)}, since the option isn't
> implemented for C++. OK with that change.
Pushed with that
Antoni spot a typo I made:
I added `LIBGCCJIT_HAVE_gcc_jit_type_get_size` instead of
`LIBGCCJIT_HAVE_gcc_jit_type_get_restrict`. Fixed in this patch, sorry
for the noise.
Le jeu. 17 août 2023 à 11:30, Guillaume Gomez
a écrit :
>
> Hi Dave,
>
> > What kind of testing has the patch had? (e.g. did
On Thu, 17 Aug 2023, Jose E. Marchesi via Gcc-patches wrote:
> +@opindex Wcompare-distinct-pointer-types
> +@item -Wcompare-distinct-pointer-types
This @item should say @r{(C and Objective-C only)}, since the option isn't
implemented for C++. OK with that change.
--
Joseph S. Myers
On Thu, 17 Aug 2023, Xi Ruoyao via Gcc-patches wrote:
> So I guess we just need
>
> builtin_define ("__builtin_fabsq=__builtin_fabsf128");
> builtin_define ("__builtin_nanq=__builtin_nanf128");
>
> etc. to map the "q" builtins to "f128" builtins if we really need the
> "q" builtins.
>
>
On Wed, 16 Aug 2023, Eric Gallager via Gcc-patches wrote:
> PING
>
> On Tue, Aug 8, 2023 at 8:17 PM Eric Gallager wrote:
> >
> > On Tue, May 30, 2023 at 5:42 PM Eric Gallager wrote:
> > >
> > > PR109836 is a request to have -Wpointer-sign enabled by default. There
> > > were points of
LGTM!
在 2023/8/16 上午9:48, Guo Jie 写道:
gcc/ChangeLog:
* config/loongarch/t-loongarch: Add loongarch-driver.h into
TM_H. Add loongarch-def.h and loongarch-tune.h into
OPTIONS_H_EXTRA.
Co-authored-by: Lulu Cheng
---
gcc/config/loongarch/t-loongarch | 4
1 file
OK, thanks.
Regards
Robin
[Changes from V3:
- Previous thread:
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600625.html
- The tests have been augmented to check all six relational
operators. In particular it covers both code paths impacted
by the patch: the equality/inequality and the relational ops.]
GCC
> On Aug 17, 2023, at 7:00 AM, Siddhesh Poyarekar wrote:
>
> On 2023-08-16 11:59, Qing Zhao wrote:
>> Jakub and Sid,
>> During my study, I found an interesting behavior for the following small
>> testing case:
>> #include
>> #include
>> struct fixed {
>> size_t foo;
>> char b;
>> char
On 8/13/23 20:53, Tsukasa OI via Gcc-patches wrote:
From: Tsukasa OI
"#error Feature macro not defined" is required to test the existence of an
extension through the preprocessor. However, multiple occurrence of the
exact same error message will confuse the developer once an error is
Hi, Kees,
Thanks for the testing case.
Yes, I noticed this issue too, and already fixed it in my private branch.
With the latest patch, the compilation has no issue:
[opc@qinzhao-ol8u3-x86 108896]$ sh t
/home/opc/Install/latest-d/bin/gcc -O2 -c -o /dev/null bug.c
[opc@qinzhao-ol8u3-x86
On Wed, 16 Aug 2023, Philipp Tomsich wrote:
> > > I fully expect that latency to drop within the next 12-18 months. In that
> > > world, there's not going to be much benefit to using hand-coded libraries
> > > vs
> > > just letting the compiler do it.
>
> I would also hope that the
Found when looking at libnuma/libmemkind test issues discussing
in https://gcc.gnu.org/PR111024
[The fails of the PR are not fully understood but point towards a
buggy libmemkind or combination or libmemkind + other libraries;
they only show up recently as before no libgomp testcase checked
The following guards the bit test merging code in if-combine against
the appearance of SSA names used in abnormal PHIs.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/111039
* tree-ssa-ifcombine.cc (ifcombine_ifandif): Check for
Hi,
There is a new failed RISC-V
testcase(testsuite/gcc.target/riscv/rvv/autovec/vls/const-4.c)
on the current trunk branch when use medany as default cmodel.
The reason is the load of half floating-point imm is convert from RTL 1 to RTL
2 as the cmodel be changed from medlow to medany. This
The kernel selftests and other BPF programs make extensive use of the
`naked' function attribute with bodies written using basic inline
assembly. This patch adds support for the attribute to
bpf-unkonwn-none, makes it to inhibit warnings due to lack of explicit
`return' statement, and updates
Hi,
This little patch fix the fail testcase
(gcc.target/riscv/rvv/autovec/gather-scatter/strided_load_run-1.c)
after apply this patch
(https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627121.html).
The specific reason is that the vsetvl pass has bug and this patch
forbidden the fuse of this
Tested x86_64-linux. Pushed to trunk. Backport to gcc-13 will follow.
-- >8 --
std::format was treating {:f} and {:F} identically on the basis that for
the fixed 1.234567 format there are no alphabetical characters that need
to be in uppercase. But that's wrong for infinities and NaNs, which
This target in include/Makefile.am was supposed to ensure that nobody
building gcc would need autogen to regenerate the bits/version.h header,
but it didn't make it in to include/Makefile.in.
Tested x86_64-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/Makefile.in:
Hi Robin,
Hmm, ok so that has nothing to do with the rest of the patch but just
happend to be the same test case.
So we didn't schedule a vsetvl here because vmv1r doesn't require
one but the simulation doesn't initialize vtype before the first vsetvl?
If this is the only instance, I guess
Hi Robin,
You likely want TARGET_ZHINXMIN instead of ZHINX though? I mean the
hardware support is obviously always there but the patterns should
be available for the min extension already. Please double check as
I haven't worked with that extension before.
Our test coverage for the *inx
Hi Lehua,
> XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-assembler \\tvand
> XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-assembler \\tvand
> XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-assembler \\tvand
> XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c
Hi Lehua,
thanks for fixing this. Looks like the same reason we have the
separation of zvfh and zvfhmin for vector loads/stores.
> +;; Iterator for hardware-supported load/store floating-point modes.
> +(define_mode_iterator ANYLSF [(SF "TARGET_HARD_FLOAT || TARGET_ZFINX")
> +
LGTM.
Thanks for fixing my previous mistakes.
juzhe.zh...@rivai.ai
From: Lehua Ding
Date: 2023-08-17 19:43
To: gcc-patches
CC: juzhe.zhong; kito.cheng; rdapp.gcc; palmer; jeffreyalaw
Subject: [PATCH] RISC-V: Fix XPASS slp testcases
This patch fixs XPASS slp testcases on trunk by
making the
This patch fixs XPASS slp testcases on trunk by
making the conditions for xfail stricter.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/partial/slp-1.c: Fix.
* gcc.target/riscv/rvv/autovec/partial/slp-16.c: Ditto.
* gcc.target/riscv/rvv/autovec/partial/slp-17.c:
On Thu, Aug 17, 2023 at 12:34 AM David Malcolm wrote:
> On Wed, 2023-08-16 at 14:19 +0200, priour...@gmail.com wrote:
> > From: benjamin priour
> >
> > Hi,
> > (s/we/the analyzer/)
>
> Hi Benjamin, thanks for the updated patch.
>
> >
> > I've been continuing my patch of supporting operator new
Hi Kito
Root cause has been identified.
Here's the frame layout fo the TC, please use courier font :)
+---+
| |
| GPR save area 112 B |
| |
Joseph Myers writes:
> On Wed, 16 Aug 2023, Richard Sandiford via Gcc-patches wrote:
>
>> Would it be OK to add support for:
>>
>> [[__extension__ ...]]
>>
>> to suppress the pedwarn about using [[]] prior to C2X? Then we can
>
> That seems like a plausible feature to add.
Thanks. Of
On Wed, 2023-08-16 at 12:13 -0400, Vladimir Makarov wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> The attached patch fixes recently found wrong insn removal in LRA port
> for AVR.
>
> The patch was successfully tested and bootstrapped
I see these failing testcases on trunk:
=== gcc: Unexpected
fails for rv64gcv_zfh lp64d medany spike ===
FAIL: gcc.dg/pr42685.c (test for excess errors)
FAIL: gcc.dg/pr45105.c (test for excess errors)
XPASS: gcc.dg/unroll-7.c scan-rtl-dump-not loop2_unroll "Invalid sum"
FAIL:
On 2023-08-16 11:59, Qing Zhao wrote:
Jakub and Sid,
During my study, I found an interesting behavior for the following small
testing case:
#include
#include
struct fixed {
size_t foo;
char b;
char array[10];
} q = {};
#define noinline __attribute__((__noinline__))
static void
Hi Robin,
unrelated but I'm seeing a lot of failing gather/scatter tests on
master right now.
Are you talking about these FAILs like bellow? If so,If so it should be
caused by a
recent commit from juzhe who is looking at it.If not,I didn't have
these fails
in my local run.
XPASS:
On Thu, Aug 17, 2023 at 9:21 AM Jan-Benedict Glaw wrote:
>
> Hi!
>
> fr30 is the only target defining GO_IF_LEGITIMATE_ADDRESS right now, in
> which case the `code_helper ch` argument to memory_address_addr_space_p()
> is unused and emits a new warning.
OK.
> gcc/ChangeLog:
> * recog.cc
Alex Coplan writes:
> Hi,
>
> This patch fixes up the code examples in the RTL-SSA documentation (the
> sections on making insn changes) to reflect the current API.
>
> The main issues are as follows:
> - rtl_ssa::recog takes an obstack_watermark & as the first parameter.
>Presumably this is
Hi,
This patch fixes up the code examples in the RTL-SSA documentation (the
sections on making insn changes) to reflect the current API.
The main issues are as follows:
- rtl_ssa::recog takes an obstack_watermark & as the first parameter.
Presumably this is intended to be the change attempt,
Hi Lehua,
unrelated but I'm seeing a lot of failing gather/scatter tests on
master right now.
> /* DIRTY -> DIRTY or VALID -> DIRTY. */
> + if (block_info.reaching_out.demand_p (DEMAND_NONZERO_AVL)
> + && vlmax_avl_p (prop.get_avl ()))
> +
I'd like to ping this for review from C and C++ maintainers:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626178.html
I probably should have dropped the RFC tag this time round as I think
the patch is nearly ready, I suppose we just need agreement on the
issues below: is there any GCC
Hi Dave,
> What kind of testing has the patch had? (e.g. did you run "make check-
> jit" ? Has this been in use on real Rust code?)
I tested it as Rust backend directly on this code:
```
pub fn foo(a: i32, b: i32, c: ) {
*a += *c;
*b += *c;
}
```
I ran it with `rustc` (and the GCC
> On Tue, Aug 15, 2023 at 9:03 PM Jose E. Marchesi via Gcc-patches
> wrote:
>>
>>
>> Hello David.
>> Thanks for the patch.
>>
>> OK.
>
> Picking a random patch/mail for this question - how do we maintain BPF
> support for the most recent GCC release which is GCC 13? I see the
> current state
On Tue, Aug 15, 2023 at 9:03 PM Jose E. Marchesi via Gcc-patches
wrote:
>
>
> Hello David.
> Thanks for the patch.
>
> OK.
Picking a random patch/mail for this question - how do we maintain BPF
support for the most recent GCC release which is GCC 13? I see the
current state in GCC 13 isn't
On Tue, Aug 15, 2023 at 8:36 PM Benjamin Priour via Gcc-patches
wrote:
>
> From: benjamin priour
>
> Yet another blunder.
>
> Succesfully regstrapped against ce8cdf5bcf96a2db6d7b9f656fc9ba58d7942a83
> on x86_64-linux-gnu.
>
> OK to push on trunk ?
OK.
> Sorry,
> Benjamin.
>
> Fixup below.
>
1 - 100 of 131 matches
Mail list logo
