On Fri, 17 Nov 2023 at 04:44, Hans-Peter Nilsson wrote:
>
> > From: Jonathan Wakely
> > Date: Thu, 16 Nov 2023 08:12:39 +
>
> > PR libstdc++/111667
> > * include/Makefile.am: Add new header.
> > * include/Makefile.in: Regenerate.
> > * include/bits/out_ptr.h: New file.
This patch series presents gcc implementation of the XTheadVector
extension [1].
[1] https://github.com/T-head-Semi/thead-extension-spec/
Contributors:
Jun Sha (Joshua)
Jin Ma
RISC-V: minimal support for xtheadvector
RISC-V: Handle differences between xtheadvector and vector
RI
Hi,
I would like to have a ping for this patch.
There are some aspects(TODOs) that can be improved for this patch.
I had some statistics to see if these aspects occur often, by
checking the gcc source code(including test suite) and spec2017.
- Reverse storage order. This only occurs in very few
On Thu, Nov 16, 2023 at 11:30 PM Robin Dapp wrote:
>
> > For the fortran testcase we don't even run into this but hit an
> > internal def and assert on
> >
> > gcc_assert (STMT_VINFO_VEC_STMTS (def_stmt_info).length () ==
> > ncopies);
> >
> > I think this shows missing handling of .COND_*
On 2023-11-16 10:00 p.m., Jeff Law wrote:
I'm not seeing any obvious problems in the gcc testsuite. It needs testing on
packages that do extensive
floating point calculations.
OK, I'll focus on those.
THe more likely scenario is xmpy which is used for integer multiply, but the operands have t
Hi Juzhe,
> csrra4,vlenb
> csrra5,vlenb
Totally unrelated to this patch but this looks odd. I don't
remember if we had a patch for this already at some point.
In general the idea for the patch is to use the largest vector
element mode for the indices and compress several of
On Fri, Nov 17, 2023 at 1:12 AM liuhongt wrote:
>
> x86 backend support reduc_{and,ior,xor>_scal_m for vector integer
> modes.
>
> Ok for trunk?
OK
> gcc/testsuite/ChangeLog:
>
> * lib/target-supports.exp (vect_logical_reduc): Add i?86-*-*
> and x86_64-*-*.
> ---
> gcc/testsuite
Oh, ok I got why it happened and it is definitely caused by my patch
(but not that one, it is caused by another patch[1]), let me describe
the reason why I try to emit errors. RISC-V has a crazy number of
possible extension combinations, so it's easy to make some mistakes by
using some unsupported
On Fri, Nov 17, 2023 at 12:13 AM Arsen Arsenović wrote:
>
>
> Bruno Haible writes:
>
> > Hi David,
> >
> >> the default, distributed libintl library will not allow GCC to be built
> >> with NLS enabled.
> >
> > The problem is this configure test from gettext.m4
> >
> > checking for GNU gettext
Because the la464 memory model design allows the same address load out of order,
so in the following test example, the Load of 23 lines may be executed first
over
the load of 21 lines, resulting in an error.
So when memmodel is MEMMODEL_RELAXED, the load instruction will be followed by
"dbar 0x700
Lulu Cheng (3):
LoongArch: Add LA664 support.
LoongArch: Implement atomic operations using LoongArch1.1
instructions.
LoongArch: atomic_load and atomic_store are implemented using dbar
grading.
gcc/config.gcc| 10 +-
.../loongarch/genopts/loongarch
Define ISA_BASE_LA64V110, which represents the base instruction set defined in
LoongArch1.1.
Support the configure setting --with-arch =la664, and support
-march=la664,-mtune=la664.
gcc/ChangeLog:
* config.gcc: Support LA664.
* config/loongarch/genopts/loongarch-strings: Likewis
1. short and char type calls for atomic_add_fetch and __atomic_fetch_add are
implemented using amadd{_db}.{b/h}.
2. Use amcas{_db}.{b/h/w/d} to implement __atomic_compare_exchange_n and
__atomic_compare_exchange.
3. The short and char types of the functions __atomic_exchange and
__atomic_excha
> Also, should the test code below (between %%%) be included in the
> testsuite?
It would be good but tests shouldn't output anything, they should be self
testing,
and you will need to deal with making the test portable to all targets.
Given that the compiler itself uses this feature, I don't th
Pushed to r14-5547.
在 2023/11/17 上午10:38, Li Wei 写道:
The LoongArch has defined ctz and clz on the backend, but if we want GCC
do CTZ transformation optimization in forwprop2 pass, GCC need to know
the value of c[lt]z at zero, which may be beneficial for some test cases
(like spec2017 deepsjeng_r
LGTM.
Thanks.
在 2023/11/14 上午4:07, Xi Ruoyao 写道:
With LSX or LASX, copysign (x[i], -1) (or any negative constant) can be
vectorized using [x]vbitseti.{w/d} instructions to directly set the
signbits.
Inspired by Tamar Christina's "AArch64: Handle copysign (x, -1) expansion
efficiently" (r14-528
> But note you can explicitly specify a vector type as well, there's an
> overload for it, so we can fix the "invariant" case with the following
> (OK if you can test this on relevant targets)
>
> diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
> index 3f59139cb01..936a3de9534 100644
>
David Edelsohn writes:
> On Thu, Nov 16, 2023 at 5:52 PM Arsen Arsenović wrote:
>
> [snip]
>> Sure, but my patch does insert --disable-shared:
>>
>> --8<---cut here---start->8---
>> host_modules= { module= gettext; bootstrap=true; no_install=true;
>>
On Fri, Nov 17, 2023 at 9:45 AM Robin Dapp wrote:
>
> > But note you can explicitly specify a vector type as well, there's an
> > overload for it, so we can fix the "invariant" case with the following
> > (OK if you can test this on relevant targets)
> >
> > diff --git a/gcc/tree-vect-loop.cc b/gc
> diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
> index 6a2009ffb05..08bbb657a06 100644
> --- a/gcc/config/riscv/riscv-v.cc
> +++ b/gcc/config/riscv/riscv-v.cc
> @@ -374,10 +374,24 @@ void
> emit_vlmax_insn_lra (unsigned icode, unsigned insn_flags, rtx *ops, rtx vl)
> {
>
On Fri, Nov 17, 2023 at 9:46 AM Arsen Arsenović wrote:
>
>
> David Edelsohn writes:
>
> > On Thu, Nov 16, 2023 at 5:52 PM Arsen Arsenović wrote:
> >
> > [snip]
> >> Sure, but my patch does insert --disable-shared:
> >>
> >> --8<---cut here---start->8---
> >> h
Richard Biener writes:
> On Fri, Nov 17, 2023 at 12:13 AM Arsen Arsenović wrote:
>>
>>
>> Bruno Haible writes:
>>
>> > Hi David,
>> >
>> >> the default, distributed libintl library will not allow GCC to be built
>> >> with NLS enabled.
>> >
>> > The problem is this configure test from gettext.
This patch is to introduce basic XTheadVector support
(march string parsing and a test for __riscv_xtheadvector)
according to https://github.com/T-head-Semi/thead-extension-spec/
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_subset_list::parse): : Add new vendor exte
Hi Kito and Robin,
So, going back to our testcases that reported errors with this, I don't
think we should explicitly specify -march and -mabi when compiling a
runnable program, but use the defaults (--with-arch). Most of our
current runnable testcases adhere to this convention, except for the
This patch is to handle the differences in instruction generation
between vector and xtheadvector, mainly adding th. prefix
to all xtheadvector instructions.
gcc/ChangeLog:
* config.gcc: Add header for XTheadVector intrinsics.
* config/riscv/riscv-c.cc (riscv_pragma_intrinsic):
Richard Biener writes:
> On Fri, Nov 17, 2023 at 9:46 AM Arsen Arsenović wrote:
>>
>>
>> David Edelsohn writes:
>>
>> > On Thu, Nov 16, 2023 at 5:52 PM Arsen Arsenović wrote:
>> >
>> > [snip]
>> >> Sure, but my patch does insert --disable-shared:
>> >>
>> >> --8<---cut here---
> So, going back to our testcases that reported errors with this, I
> don't think we should explicitly specify -march and -mabi when
> compiling a runnable program, but use the defaults (--with-arch).
> Most of our current runnable testcases adhere to this convention,
> except for the ones we are
For big changes in instruction generation, we can only duplicate
some typical tests in testsuite/gcc.target/riscv/rvv/base.
This patch is adding some tests for binary operations.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/xtheadvector/binop_vv_constraint-1.c: New test.
* gcc
For big changes in instruction generation, we can only duplicate
some typical tests in testsuite/gcc.target/riscv/rvv/base.
This patch is adding some tests for binary operations.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/xtheadvector/binop_vx_constraint-11.c: New test.
* gc
For big changes in instruction generation, we can only duplicate
some typical tests in testsuite/gcc.target/riscv/rvv/base.
This patch is adding some tests for binary operations.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/xtheadvector/binop_vx_constraint-31.c: New test.
* gc
For big changes in instruction generation, we can only duplicate
some typical tests in testsuite/gcc.target/riscv/rvv/base.
This patch is adding some tests for ternary and unary operations.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/xtheadvector/ternop_vv_constraint-1.c: New test.
For big changes in instruction generation, we can only duplicate
some typical tests in testsuite/gcc.target/riscv/rvv/base.
This patch is adding some tests for auto-vectorization.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/xtheadvector/autovec/vadd-run-nofm.c: New test.
* gc
This patch only involves the generation of xtheadvector
special load/store instructions.
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc
(class th_loadstore_width): Define new builtin bases.
(BASE): Define new builtin bases.
* config/riscv/riscv-vector
Because the XTheadVector extension does not support fractional
operations, so we need to delete the related intrinsics.
The types involved are as follows:
v(u)int8mf8_t,
v(u)int8mf4_t,
v(u)int8mf2_t,
v(u)int16mf4_t,
v(u)int16mf2_t,
v(u)int32mf2_t,
vfloat16mf4_t,
vfloat16mf2_t,
vfloat32mf2_t
gcc/C
on 2023/11/15 17:43, Alexander Monakov wrote:
>
> On Wed, 15 Nov 2023, Kewen.Lin wrote:
>
And I suppose it would be OK to do that. Empty BBs are usually removed by
CFG cleanup so the situation should only happen in rare corner cases where
the fix would be to actually run CFG clean
On 17 Nov 2023, at 08:37, Arnaud Charlet wrote:
>
>> Also, should the test code below (between %%%) be included in the
>> testsuite?
>
> It would be good but tests shouldn't output anything, they should be self
> testing,
> and you will need to deal with making the test portable to all targets.
> > Please simplify the above to (untested):
> >
> > #elif defined (__APPLE__)
> >/* By default, macOS volumes are case-insensitive, iOS
> > volumes are case-sensitive. */
> > #if TARGET_OS_MAC/* macOS, in older SDK. */
> > file_names_case_sensitive_cache = 0;
> > #
gcc/ChangeLog:
* config/loongarch/loongarch-d.cc: Undefine LoongArch32.
Define LoongArch_SF, LoongArch_F32, LoongArch_F64
gcc/d/ChangeLog:
* dmd/cond.d: Same.
* implement-d.texi: Same.
---
gcc/config/loongarch/loongarch-d.cc | 27 ++-
gcc/
This patchset is based on Zixing Liu's initial support patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631260.html
Yang Yujie (3):
LoongArch: Adjust D version strings.
libphobos: Update build scripts for LoongArch64.
libphobos: Adjust LoongArch definitons.
gcc/config/loonga
libphobos/ChangeLog:
* m4/druntime/cpu.m4: Support loongarch* targets.
* libdruntime/Makefile.am: Same.
* libdruntime/Makefile.in: Regenerate.
* configure: Regenerate.
---
libphobos/configure | 21 ++-
libphobos/libdruntime/Makefile.am | 3 +
lib
Upstream commits:
https://github.com/dlang/phobos/commit/870eb5d5d6972b12dd4b69d48ef049abee811b6b
https://github.com/dlang/dmd/commit/9cb5517290fac5d28f52c11c254115c0f1086b69
libphobos/ChangeLog:
* libdruntime/core/stdc/fenv.d: Fix LongArch FP rounding mode constants.
* libdruntim
On Fri, Nov 17, 2023 at 10:04 AM Kewen.Lin wrote:
>
> on 2023/11/15 17:43, Alexander Monakov wrote:
> >
> > On Wed, 15 Nov 2023, Kewen.Lin wrote:
> >
> And I suppose it would be OK to do that. Empty BBs are usually removed
> by
> CFG cleanup so the situation should only happen in
On Fri, 17 Nov 2023 at 01:34, Cassio Neri wrote:
>
> The following functions invoke signed integer overflow (UB) for some extreme
> values of days and months [1]:
>
> weekday operator+(const weekday& x, const days& y); // #1
> month operator+(const month& x, const months& y); // #2
>
> For #1
> > > > > Yes, but that only works for the inductions marked so. We'd
> > > > > need to mark the others as well, but only for the early exits.
> > > > >
> > > > > > although I don't understand why we use the scalar count, I
> > > > > > suppose the reasoning is that we don't really want to keep it
Hello,
> I haven't manged to test the Ada frontend, but this patch (and the following
I don't have an aarch64 setup to test, but I may be able to help with the
issue preventing you from testing. Can you elaborate what is the problem?
Marc
On Fri, 2023-11-17 at 16:33 +0800, Lulu Cheng wrote:
>
> Lulu Cheng (3):
> LoongArch: Add LA664 support.
> LoongArch: Implement atomic operations using LoongArch1.1
> instructions.
> LoongArch: atomic_load and atomic_store are implemented using dbar
> grading.
>
> gcc/config.gcc
Heads-up: this broke bootstrap on darwin:
> +typedef void (^dispatch_mach_handler_t)(dispatch_mach_reason reason,
> +dispatch_mach_msg_t message,
> +mach_error_t error);
Blocks are an Apple/clang extension, not (yet)
On Fri, Nov 17, 2023 at 11:45:16AM +0100, Marc Poulhi�s wrote:
>
> Hello,
>
> > I haven't manged to test the Ada frontend, but this patch (and the following
>
> I don't have an aarch64 setup to test, but I may be able to help with the
> issue preventing you from testing. Can you elaborate what
I have reported the issue to llvm at
https://github.com/llvm/llvm-project/issues/72639
There is a trivial one-line patch to fix it, which I hope they will accept. Not
sure what our policy is here, in the meantime.
FX
90% theadvector extension reusing current RVV 1.0 instructions patterns:
Just change ASM, For example:
@@ -2923,7 +2923,7 @@ (define_insn "*pred_mulh_scalar"
(match_operand:VFULLI_D 3 "register_operand" "vr,vr, vr, vr")]
VMULH)
(match_operand:VFULLI_D 2 "vector_merge_opera
On Fri, Nov 17, 2023 at 12:31:40PM +0100, FX Coudert wrote:
> I have reported the issue to llvm at
> https://github.com/llvm/llvm-project/issues/72639
> There is a trivial one-line patch to fix it, which I hope they will accept.
> Not sure what our policy is here, in the meantime.
If they accept
Hi,
> If I remove the line from libtool.m4 (innocent smile) I see that
> fixincludes/configure is better, and it does not appear to change the
> regenerated files in other directories (I didn’t do a build yet, just tried
> to regenerate with some manual autoconf invocations).
I have done a ful
> If they accept it say within a day, wait for it + cherry-pick to GCC,
> otherwise apply to GCC as a local patch in anticipation they accept it.
> If it is all that fixes Darwin support, great.
With that patch, I can finish bootstrap, and regtesting is undergoing but I’m
seeing no issue so far.
Le 17/11/2023 à 12:38, Tobias Burnus a écrit :
Unless there are follow up comments, I will commit it later today.
I skimmed quickly through the patch, and noticed one typo to fix:
> diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
> index 10387e39501..5f87b330a22 100644
> --- a/
On Fri, 17 Nov 2023, Tamar Christina wrote:
> > > > > > Yes, but that only works for the inductions marked so. We'd
> > > > > > need to mark the others as well, but only for the early exits.
> > > > > >
> > > > > > > although I don't understand why we use the scalar count, I
> > > > > > > suppos
Hi FX!
On 2023-11-17T12:56:13+0100, FX Coudert wrote:
>> If I remove the line from libtool.m4 (innocent smile) I see that
>> fixincludes/configure is better, and it does not appear to change the
>> regenerated files in other directories (I didn’t do a build yet, just tried
>> to regenerate wit
>> I didn't get why we need vlmax vsetvl here?
>> We use code_for_pred_mov if subpart_mode is fractional LMUL mode
>> and will use the whole reg load store if not fractional LMUL.
>> So we don't need explicitly vsetvl for the above 2 cases in my understanding?
>> I know I must miss something, d
The address-spaces locate data in their attaches sections like
.progmem.data; but that should only be done if the user did not
specify a section attribute.
Johann
--
PR target/53372: Don't ignore section attribute with address-space.
gcc/
PR target/53372
* config/avr/avr.cc (av
David Edelsohn and Richard Biener wrote:
> > > * GCC can pass --enable-threads=isoc, to avoid the libpthread dependency
> > > on AIX ≥ 7.2.
> >
> > Hmm, would that option work everywhere, though? Or would we have to
> > wire up configury to detect which flag to use? If so, what would it
> >
On Fri, 2023-11-17 at 16:33 +0800, Lulu Cheng wrote:
> Define ISA_BASE_LA64V110, which represents the base instruction set defined
> in LoongArch1.1.
> Support the configure setting --with-arch =la664, and support
> -march=la664,-mtune=la664.
>
> gcc/ChangeLog:
>
> * config.gcc: Support L
Hi!
On 2023-11-15T11:29:20+0100, FX Coudert wrote:
>>> it's unclear if those messages can just be removed (they are pretty
>>> cryptic as is) or at least changed to use verbose instead of puts.
>>> Please fix.
>
> I don’t see value in this output, so I think it’s best to remove the puts
> calls
>>> Please simplify the above to (untested):
>>>
>>> #elif defined (__APPLE__)
>>> /* By default, macOS volumes are case-insensitive, iOS
>>> volumes are case-sensitive. */
>>> #if TARGET_OS_MAC/* macOS, in older SDK. */
>>>file_names_case_sensitive_cache = 0;
>>> #e
On Fri, 17 Nov 2023, Kewen.Lin wrote:
> > I don't think you can run cleanup_cfg after sched_init. I would suggest
> > to put it early in schedule_insns.
>
> Thanks for the suggestion, I placed it at the beginning of haifa_sched_init
> instead, since schedule_insns invokes haifa_sched_init, altho
在 2023/11/17 下午8:31, Xi Ruoyao 写道:
On Fri, 2023-11-17 at 16:33 +0800, Lulu Cheng wrote:
Define ISA_BASE_LA64V110, which represents the base instruction set defined in
LoongArch1.1.
Support the configure setting --with-arch =la664, and support
-march=la664,-mtune=la664.
gcc/ChangeLog:
On Thu, 2 Nov 2023, Filip Kastl wrote:
> > Hi,
> >
> > this is a patch that I submitted two months ago as an RFC. I added some
> > polish
> > since.
> >
> > It is a new lightweight pass that removes redundant PHI functions and as a
> > bonus does basic copy propagation. With Jan Hubi?ka we meas
> Yes, your version is also OK.
The attached was bootstrapped and regtested on aarch64, x86 and
regtested on riscv. Going to commit it later unless somebody objects.
Regards
Robin
Subject: [PATCH] vect: Pass truth type to vect_get_vec_defs.
For conditional operations the mask is loop invarian
> Apple’s naming is definitely confusing in this area!
>
> In current SDKs, TARGET_OS_MAC means code is being generated for a Mac OS X
> variant,
> which covers OSX, IOS, Watch … ; to determine which kind of device, you have
> to check the
> specific define for that device - OSX corresponds to
Hi!
As mentioned in the PR, the intent of the r14-5076 changes was that
it doesn't count one of the uses on the use_stmt, but what actually
got implemented is that it does this processing on any op_use_stmt,
even if it is not the use_stmt statement, which means that it
can increase count even on d
Bruno Haible writes:
> David Edelsohn and Richard Biener wrote:
>> > > * GCC can pass --enable-threads=isoc, to avoid the libpthread
>> > > dependency
>> > > on AIX ≥ 7.2.
>> >
>> > Hmm, would that option work everywhere, though? Or would we have to
>> > wire up configury to detect which
> OK so then the following is sufficient for our needs:
>
> #elif defined (__APPLE__)
>/* By default, macOS volumes are case-insensitive, iOS
> volumes are case-sensitive. */
> #if TARGET_OS_IOS
> file_names_case_sensitive_cache = 1;
> #else
> file_names_case_
Ok. I just read the theadvector extension.
https://github.com/T-head-Semi/thead-extension-spec/blob/master/xtheadvector.adoc
Theadvector is not custom extension. Just a uarch to disable some of the RVV1.0
extension
Theadvector can be considered as subextension of 'V' extension with disabling
>
>> Apple’s naming is definitely confusing in this area!
>>
>> In current SDKs, TARGET_OS_MAC means code is being generated for a Mac OS X
>> variant,
>> which covers OSX, IOS, Watch … ; to determine which kind of device, you have
>> to check the
>> specific define for that device - OSX corr
On Fri, 17 Nov 2023, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, the intent of the r14-5076 changes was that
> it doesn't count one of the uses on the use_stmt, but what actually
> got implemented is that it does this processing on any op_use_stmt,
> even if it is not the use_stmt stat
Hi!
ctz(ext(X)) is the same as ctz(X) in the UB on zero case (or could be also
in the 2 argument case on large BITINT_TYPE by preserving the argument, not
implemented in this patch),
popcount(zext(X)) is the same as popcount(X),
parity(zext(X)) is the same as parity(X),
parity(sext(X)) is the same
Fix segment fault on tuple move:
bbl loader
z ra 000102ac sp 003ffaf0 gp 0001c0b8
tp t0 000104a0 t1 000f t2
s0 s1 a0 003ffb30 a1 003ffb58
a2 000
The offending commit r14-5444-g5ea2965b499f9e was reverted. The
following adds a testcase.
Pushed.
PR tree-optimization/112585
* gcc.dg/torture/pr112585.c: New testcase.
---
gcc/testsuite/gcc.dg/torture/pr112585.c | 18 ++
1 file changed, 18 insertions(+)
create
On Fri, 17 Nov 2023, Jakub Jelinek wrote:
> Hi!
>
> ctz(ext(X)) is the same as ctz(X) in the UB on zero case (or could be also
> in the 2 argument case on large BITINT_TYPE by preserving the argument, not
> implemented in this patch),
> popcount(zext(X)) is the same as popcount(X),
> parity(zext(
Hi!
Per the earlier discussions on this PR, the following patch folds
popcount (x) == 1 (and != 1) into (x ^ (x - 1)) > x - 1 (or <=)
if the corresponding popcount optab isn't implemented (I think any
double-word popcount or call will be necessarily slower than the
above cheap 3 op check and even
On Thu, Nov 16, 2023 at 11:49:03PM +, Joseph Myers wrote:
> > > While filing a clang request to return 18 on _BitInts for
> > > __builtin_classify_type instead of -1 they return currently, I've
> > > noticed that we return -1 for vector types. I'm not convinced it is a
> > > good
> > > idea t
On 11/16/23 21:06, Lehua Ding wrote:
Hi Vladimir,
Thank you so much for your review. Based on your comments, I feel like
there are a lot of issues, especially the long compile time issue. So
I'm going to reorganize and refactor the patches so that as many of
them as possible can be reviewed
On 11/17/23 01:27, John David Anglin wrote:
On 2023-11-16 10:00 p.m., Jeff Law wrote:
I'm not seeing any obvious problems in the gcc testsuite. It needs testing on
packages that do extensive
floating point calculations.
OK, I'll focus on those.
THe more likely scenario is xmpy which is us
May I please ping this one? Thanks...
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/634931.html
On Wed, Nov 1, 2023 at 5:55 PM Lewis Hyatt wrote:
>
> Hello-
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112319
>
> This is a one-line patch to fix the GCC 14 regression noted in the
> P
I didn’t take a closer look yet on the ira/lra dump yet, but my feeling is
that may cause by the earlyclober modifier isn’t work as expect?
Let me take closer look tomorrow.
juzhe.zh...@rivai.ai 於 2023年11月17日 週五,20:16寫道:
> >> I didn't get why we need vlmax vsetvl here?
>
> >> We use code_for_pre
You recently pinged this patch, but I haven't seen an update since this
review?
On 10/26/23 21:21, Jason Merrill wrote:
On 9/18/23 13:21, Jakub Jelinek wrote:
Here is an updated version of the patch.
Compared to the last version, based on the discussion in the PR, the
patch
1) warns (but
>> I have done a full rebuild, and having looked more at the structure of
>> libtool.m4 I am now convinced that having that line outside of the scope of
>> _LT_DARWIN_LINKER_FEATURES is simply wrong (probably a copy-pasto or
>> leftover from earlier code).
>> Having rebuilt everything, it only m
On Fri, Nov 17, 2023 at 09:18:39AM -0500, Jason Merrill wrote:
> You recently pinged this patch, but I haven't seen an update since this
> review?
Oops, sorry, I've missed this and DR 2406 review posts in my inbox
during vacation, will get to that momentarily.
Thanks.
Jakub
Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/chrono_io.h: Fix Doxygen markup.
---
libstdc++-v3/include/bits/chrono_io.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/include/bits/chrono_io.h
b/libstdc++-v3/include/bits/chrono_io.h
On Fri, Nov 17, 2023 at 3:46 AM Arsen Arsenović wrote:
>
> David Edelsohn writes:
>
> > On Thu, Nov 16, 2023 at 5:52 PM Arsen Arsenović wrote:
> >
> > [snip]
> >> Sure, but my patch does insert --disable-shared:
> >>
> >> --8<---cut here---start->8---
> >> ho
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Improve Doxygen comments for std::out_ptr etc. and add a test for the
feature test macro. Also remove a redundant preprocessor condition.
Ideally the docs for std::out_ptr and std::inout_ptr would show examples
of how to use them and what they do,
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This is more consistent with the specification in the standard.
libstdc++-v3/ChangeLog:
* include/std/utility (in_range): Rename _Up parameter to _Res.
---
libstdc++-v3/include/std/utility | 14 +++---
1 file changed, 7 insertions(
Hi,
This is a v5 patch to address Marek's feedback here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635157.html
I also implemented Jason's suggestion to use constexpr for the tables
from this review:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634484.html
I'll attach the
> OK. Make sense。
I'm wondering whether the VLA modes in the iterator are correct.
Looks dubious to me but unsure, will need to create some tests
before continuing.
> LGTM as long as you remove all
> GET_MODE_BITSIZE (GET_MODE_INNER (mode)) <= GET_MODE_BITSIZE (Pmode)
What's the problem with th
>> I'm wondering whether the VLA modes in the iterator are correct.
>> Looks dubious to me but unsure, will need to create some tests
>> before continuing.
It must be correct. We already have test (intrinsic codes) for it.
>> What's the problem with those? We probably won't reach there
>> becaus
On 03/11/2023 12:19, Marek Polacek wrote:
> On Wed, Sep 27, 2023 at 03:27:30PM +0100, Alex Coplan wrote:
> > Hi,
> >
> > This is a v4 patch to address Jason's feedback here:
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630911.html
> >
> > w.r.t. v3 it just removes a comment now th
> It must be correct. We already have test (intrinsic codes) for it.
Yeah, just noticed that myself. Anyway will do some more tests,
maybe my initial VLS analysis was somehow flawed.
> Condition should be put into iterators (Add a new iterator for
> indexed load store).
Ah, that's what you mea
On 11/17/23 07:18, Kito Cheng wrote:
I didn’t take a closer look yet on the ira/lra dump yet, but my feeling
is that may cause by the earlyclober modifier isn’t work as expect?
Let me take closer look tomorrow.
Remember that constraints aren't checked until register allocation. So
the comb
David Edelsohn writes:
> On Fri, Nov 17, 2023 at 3:46 AM Arsen Arsenović wrote:
>
>>
>> David Edelsohn writes:
>>
>> > On Thu, Nov 16, 2023 at 5:52 PM Arsen Arsenović wrote:
>> >
>> > [snip]
>> >> Sure, but my patch does insert --disable-shared:
>> >>
>> >> --8<---cut here
>> Yeah, just noticed that myself. Anyway will do some more tests,
>> maybe my initial VLS analysis was somehow flawed.
You can check binop_vx_constraint-167.c ~ binop_vx_constraint-174.c
This patch is pre-approved if you change as my suggestion.
I am gonna sleep so I am not able to review again
Hi!
I found that with GCC's '-fthreadsafe-statics' implementation (..., which
is enabled by default) instrumented as follows:
--- libstdc++-v3/libsupc++/guard.cc
+++ libstdc++-v3/libsupc++/guard.cc
@@ -271,6 +273,7 @@ namespace __cxxabiv1
extern "C"
int __cxa_guard_acqui
Tested x86_64-linux. Pushed to trunk.
GCC generates better code for add_sat if we use:
unsigned z = x + y;
z |= -(z < x);
return z;
If the compiler can't be improved we should consider using that instead
of __builtin_add_overflow.
-- >8 --
This was approved for C++26 last week at the WG21 me
1 - 100 of 184 matches
Mail list logo