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.
gcc/ChangeLog:
* recog.cc (memory_address_addr_space_p): Mark possibly unused
argument as unused
Hi! I try to investigate on this problem, and modify the testcase to
compile and run on aarch64 for reference, but I get some strange result
(comment shows the info that I see by stepping through by using gdb):
typedef double __attribute__((vector_size(16))) v2df;
void use1(double d) {}
__attrib
From: Pan Li
This patch would like to support the rounding mode API for the
VFWREDOSUM.VS as the below samples
* __riscv_vfwredosum_vs_f32m1_f64m1_rm
* __riscv_vfwredosum_vs_f32m1_f64m1_rm_m
Signed-off-by: Pan Li
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc
(w
ok
On Thu, Aug 17, 2023 at 3:26 PM Pan Li via Gcc-patches
wrote:
>
> From: Pan Li
>
> This patch would like to support the rounding mode API for the
> VFWREDOSUM.VS as the below samples
>
> * __riscv_vfwredosum_vs_f32m1_f64m1_rm
> * __riscv_vfwredosum_vs_f32m1_f64m1_rm_m
>
> Signed-off-by: Pan L
lgtm
On Thu, Aug 17, 2023 at 2:23 PM Pan Li via Gcc-patches
wrote:
>
> From: Pan Li
>
> This patch would like to support the rounding mode API for the
> VFREDOSUM.VS as the below samples.
>
> * __riscv_vfredosum_vs_f32m1_f32m1_rm
> * __riscv_vfredosum_vs_f32m1_f32m1_rm_m
>
> Signed-off-by: Pan L
Committed, thanks Kito.
Pan
-Original Message-
From: Kito Cheng
Sent: Thursday, August 17, 2023 3:30 PM
To: Li, Pan2
Cc: juzhe.zh...@rivai.ai
Subject: Re: [PATCH v1] RISC-V: Support RVV VFNCVT.X.F.W rounding mode
intrinsic API
Yeah, I missed that, LGTM :P
On Thu, Aug 17, 2023 at 2:2
Committed, thanks Kito.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Li, Pan2 via Gcc-patches
Sent: Thursday, August 17, 2023 10:18 AM
To: Kito Cheng
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; Wang, Yanzhang
Subject: RE: [PATCH v1] RISC-V: Support RVV VFNCVT.XU.F.W r
Committed, thanks Kito.
Pan
From: Kito Cheng
Sent: Thursday, August 17, 2023 11:32 AM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; Wang, Yanzhang
Subject: Re: [PATCH v1] RISC-V: Support RVV VFNCVT.F.{X|XU|F}.W rounding mode
intrinsic API
Lgtm
Pan Li via Gcc-patches
mail
Committed, thanks Kito.
Pan
From: Kito Cheng
Sent: Thursday, August 17, 2023 11:33 AM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; Wang, Yanzhang
Subject: Re: [PATCH v1] RISC-V: Support RVV VFREDUSUM.VS rounding mode
intrinsic API
Lgtm
Pan Li via Gcc-patches
mailto:gcc-
Committed, thanks Kito.
Pan
-Original Message-
From: Li, Pan2
Sent: Thursday, August 17, 2023 2:23 PM
To: gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; Li, Pan2 ; Wang, Yanzhang
; kito.ch...@gmail.com
Subject: [PATCH v1] RISC-V: Support RVV VFREDOSUM.VS rounding mode intrinsic API
Committed, thanks Kito.
Pan
-Original Message-
From: Kito Cheng
Sent: Thursday, August 17, 2023 3:30 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; Wang, Yanzhang
Subject: Re: [PATCH v1] RISC-V: Support RVV VFREDOSUM.VS rounding mode
intrinsic API
lgtm
On Thu,
On Thu, 17 Aug 2023 at 01:51, Jonathan Wakely wrote:
>
> On 09/08/23 01:34 +0300, Vladimir Palevich wrote:
> >Because of the recent change in _M_realloc_insert and _M_default_append, call
> >to deallocate was ordered after assignment to class members of std::vector
> >(in the guard destructor), wh
A new test I added was failing with -std=gnu++23 because that flag was
removed from the test options (but only after checking if it met the
c++20 effective target).
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The { dg-add-options no_pch } directive is supposed to add a macro
definition that i
Now that no_pch works, I can use it to fix this test that was failing
with PCH enabled and run with -std=gnu++23.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
These tests expect to be able to #undef a feature test macro and then
include to get it redefined. But if has already been
included b
On Wed, Aug 16, 2023 at 4:38 AM Kewen.Lin wrote:
>
> on 2023/8/15 17:13, Richard Sandiford wrote:
> > Richard Biener writes:
> >>> OK, fair enough. So the idea is: see where we end up and then try to
> >>> improve/factor the APIs in a less peephole way?
> >>
> >> Yeah, I think that's the only go
On Wed, Aug 16, 2023 at 12:48 AM Bradley Lucier wrote:
>
> First, if this is no longer the appropriate group for this discussion,
> please tell me where to send it.
>
> I've been working to understand all the comments here. From them, I think:
>
> 1. It's OK to have gcc report back to the user w
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 c
From: Pan Li
This patch would like to support the rounding mode API for the
VFWREDUSUM.VS as the below samples
* __riscv_vfwredusum_vs_f32m1_f64m1_rm
* __riscv_vfwredusum_vs_f32m1_f64m1_rm_m
Signed-off-by: Pan Li
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc
(v
> I'm not opposed to merging the test change, but I couldn't figure out
> where in C the implicit conversion was coming from: as far as I can
> tell the macros don't introduce any (it's "return _float16 *
> _float16"), I'd had the patch open since last night but couldn't
> figure it out.
>
> We ge
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.
> ---
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 fully
> 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
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: &mut i32, b: &mut i32, c: &i32) {
*a += *c;
*b += *c;
}
```
I ran it with `rustc` (an
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 con
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 ()))
> + continue
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,
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
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
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: g
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 no
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: gcc
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 o
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 course
Hi Kito
Root cause has been identified.
Here's the frame layout fo the TC, please use courier font :)
+---+
| |
| GPR save area 112 B |
| |
+---
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 v
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:
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 co
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")
> +
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 sca
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 *i
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 gu
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: R
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
shou
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 c
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 docu
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 chan
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
SSA_NAME_
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
for
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 hand-coded
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 108896]$
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
encount
> 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
[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 e
OK, thanks.
Regards
Robin
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 cha
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 disagreem
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.
>
> Joseph:
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
jos...@cod
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.
Pushed with that c
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 `LIBGCCJIT_HAVE_gcc_jit_typ
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.
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 reposit
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
Date
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.
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
> /home/opc/Install/latest-d/bin/g
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 L
> 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 [[]] prio
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.
* gcc.target/riscv/zbb-
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 sticki
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 asser
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 fo
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 = &dso->maj
when folding, getting a value of 0 for op1 means dso->maj resolved to a
value of [0,0]. fold_using_range::range_o
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 do
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:
* gcc.ta
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 the
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
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 ju
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
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 t
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
> >>
> >> - !_GLIBCXX_USE_DUAL_AB
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 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 subobje
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
0001-improve-er
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 mode
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 Libst
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:
>
>PR
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
> 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 maximum
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 __resize_and_ove
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 https://github.com
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 a/libstd
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 n
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, a
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 s
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 widene
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 optim
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 __cm
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:
* config/locale/
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
1 - 100 of 127 matches
Mail list logo
