I create a pr in https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/455,
maybe we can discuss it there.
Zhijin,
Thanks.
> From: "Kito Cheng"
> Date: Tue, Nov 26, 2024, 23:41
> Subject: Re: [RFC][PATCH] RISC-V: Support
> TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN
> To: "Zhijin Zeng"
On Thu 28. Nov 2024 at 15:36, Richard Biener
wrote:
> On Mon, Nov 25, 2024 at 3:28 AM Philipp Tomsich
> wrote:
> >
> > Pushed to master with the following fixups:
> > - new timevar added
> > - nits addressed
> > - whitespace fixes
>
> The pass seems to be disabled by default everywhere - I
On Mon, Nov 25, 2024 at 3:28 AM Philipp Tomsich
wrote:
>
> Pushed to master with the following fixups:
> - new timevar added
> - nits addressed
> - whitespace fixes
The pass seems to be disabled by default everywhere - I thought we
decided to avoid adding
passes like this because they tend
Oh, I saw the second patch is just adding testcase, I think all
comments are minor, so no need v2, I will address those minor change
and commit after verified on my hand :)
On Thu, Nov 28, 2024 at 2:52 PM Kito Cheng wrote:
>
> I incline to just keep sifive-vector, it although actually an IME
> (I
I incline to just keep sifive-vector, it although actually an IME
(Integrated Matrix Extension), but we don't have too much
instructions, also we will have more SiFive vector extension which not
IME, so I think just put in sifive-vector is fine.
And this patch is generally in good shape, I assume
在 2024/11/28 上午9:26, Jinyang He 写道:
For {xv,v}{srl,sll,sra}, the constraint `vector_same_uimm6` cause overflow
in when emit {w,h,b}. Since the number of bits shifted is the remainder of
the register value, it is actually unnecessary to constrain the range.
Simply mask the shift number with the
On Wed, Nov 27, 2024 at 8:50 PM Richard Biener wrote:
>
> On Wed, 27 Nov 2024, Jakub Jelinek wrote:
>
> > Hi!
> >
> > The r15-4833-ge9ab41b79933 patch had among tons of config/i386
> > specific changes also important change to the generic code, allowing
> > also 2 as valid value of the second argu
libiberty/getopt.c file is defining _NO_PROTO which causes conflicting
declarations for the functions in AIX header files like stdio.h & stdlib.h.
These declarations are being considered as errors in C23 which wasn't
the case with C17.
Here is the error we get.
/gcc_build/./prev-gcc/xgcc -B/g
Ping^2
Hongyu Wang 于2024年11月21日周四 11:04写道：
>
> Gently ping, it would be appreciate if anyone can help review this.
> We hope this patch will not miss GCC15 for complete support on APX.
>
> Kong, Lingling 于2024年11月14日周四 09:50写道：
>
> >
> > Hi,
> >
> > Many thanks to Richard for the suggestion that
From: yulong
This commit adds testcases for Xsfvqmaccqoq/dod.
Co-Authored by: Kito Cheng
Co-Authored by: Monk Chiang
Co-Authored by: Jiawei Chen
Co-Authored by: Shihua Liao
Co-Authored by: Yixuan Chen
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/rvv.exp:
* gcc.target/ri
From: yulong
This patch implements the Sifvie vendor extension Xsfvqmaccqoq and
Xsfvqmaccdod[1] support to gcc. Providing intrinsic functions vqmacc
(signed-signed mac), vqmaccu (unsigned-unsignedmac), vqmaccsu
(signed-unsigned mac), vqmaccus (unsigned-signed mac) for 4x8x4 and
2x8x2 martix multi
As reported in bug 117757, there is a C gimplification ICE for shifts
involving a variable that was incompatibly redeclared (and thus had
its type changed to error_mark_node). Fix this with an appropriate
error_operand_p check.
Note that this is not the same issue as any of the other bugs reporte
From: yulong
This commit adds intrinsics support for Xsfvqmaccqoq/dod.
Co-Authored by: Kito Cheng
Co-Authored by: Monk Chiang
Co-Authored by: Jiawei Chen
Co-Authored by: Shihua Liao
Co-Authored by: Yixuan Chen
gcc/ChangeLog:
* config.gcc: Add new SiFive *.o files.
* config
Not a bugfix, but this should only affect C++26.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8--
This patch implements P2865R5 by promoting the warning to error in C++26
only. -Wno-array-compare shouldn't disable the error, so adjust the call
sites as well.
In C++20 we sho
On Wed, Nov 27, 2024 at 04:19:33PM -0500, Jason Merrill wrote:
> On 11/6/24 3:33 PM, Marek Polacek wrote:
> > On Mon, Nov 04, 2024 at 11:10:05PM -0500, Jason Merrill wrote:
> > > On 10/30/24 4:59 PM, Marek Polacek wrote:
> > > > On Wed, Oct 30, 2024 at 09:01:36AM -0400, Patrick Palka wrote:
> > > >
On Wed, Nov 27, 2024 at 9:43 PM Richard Biener
wrote:
>
> On Wed, Nov 27, 2024 at 4:26 AM liuhongt wrote:
> >
> > When loop requires any kind of versioning which could increase register
> > pressure too much, and it's in a deeply nest big loop, don't do
> > vectorization.
> >
> > I tested the pat
For {xv,v}{srl,sll,sra}, the constraint `vector_same_uimm6` cause overflow
in when emit {w,h,b}. Since the number of bits shifted is the remainder of
the register value, it is actually unnecessary to constrain the range.
Simply mask the shift number with the unit-bit-width, without any
constraint o
Now that is always included, use std::unique_ptr in a few more
places to avoid naked "new".
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-5740-g066f309db6a545.
gcc/analyzer/ChangeLog:
* engine.cc (strongly_connected_
Some builtin macros are only defined when certain command-line options
are provided. Update the error messages for them so that we suggest
the pertinent option ('-fopenacc' for '_OPENACC', and '-fopenmp' for
'_OPENMP')
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-5737-g9f06b910a840d8.
gcc/analyzer/ChangeLog:
PR c/104896
* sm-malloc.cc: Replace "%<%s%>" with "%qs" in message wording.
gcc/c-family/ChangeLog:
PR c/1048
On Tue, 19 Nov 2024, Prathamesh Kulkarni wrote:
> +#ifdef USE_LD_AS_NEEDED
> +#define LINK_LIBATOMIC_SPEC "%{!fno-link-libatomic:" LD_AS_NEEDED_OPTION \
> + " -latomic " LD_NO_AS_NEEDED_OPTION "} "
> +#else
> +#define LINK_LIBATOMIC_SPEC ""
> +#endif
I'd expect conditional
I see, thanks Robin, will have a try for this change.
Pan
-Original Message-
From: Robin Dapp
Sent: Wednesday, November 27, 2024 9:44 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; jeffreya...@gmail.com; Robin
Dapp
Subject: Re: [PATCH v1 1/3]
On Wed, 2024-11-27 at 13:18 -0500, Lewis Hyatt wrote:
> On Wed, Nov 27, 2024 at 09:41:13AM -0500, David Malcolm wrote:
> > On Wed, 2024-11-27 at 14:56 +0100, Richard Biener wrote:
> > > On Sun, Nov 3, 2024 at 11:28 PM Lewis Hyatt
> > > wrote:
> > > >
> > > > Several of the selftests in diagnostic
On Thu, Nov 21, 2024, 2:02 PM H.J. Lu wrote:
> Promote integer arguments smaller than int if TARGET_PROMOTE_PROTOTYPES
> returns true.
>
> PR middle-end/14907
> * calls.c (initialize_argument_information): Promote small integer
> arguments if TARGET_PROMOTE_PROTOTYPES retu
As reported in bug 91193, if an old-style function definition
redeclares a typedef name as a function, then uses that function name
at the start of the first old-style parameter definition, then the
parser interprets that token as a typedef name (because lookahead
occurred before processing of the
On Linux/x86_64,
4a8685911697c237ff8c0589827eb8649f8440f1 is the first bad commit
commit 4a8685911697c237ff8c0589827eb8649f8440f1
Author: Pan Li
Date: Fri Nov 22 11:48:26 2024 +0800
I386: Add more testcases for unsigned SAT_ADD vector pattern
caused
FAIL: gcc.target/i386/pr112600-5-u16.c
This helps the compiler to split the cold path into a separate clone, so
that the hot path is a smaller function that uses less icache, and the
cold path is only fetched into the icache if actually executed.
libstdc++-v3/ChangeLog:
PR libstdc++/117650
* include/bits/c++config (__g
libstdc++-v3/ChangeLog:
* include/bits/c++config (__glibcxx_assert): Remove useless
__builtin_expect from constexpr-only assertion. Improve
comments.
---
Tested x86_64-linux. Pushed to trunk.
libstdc++-v3/include/bits/c++config | 15 +--
1 file changed, 9 ins
Am 27.11.24 um 21:56 schrieb Jerry D:
On 11/27/24 12:31 PM, Harald Anlauf wrote:
Dear all,
the attached patch fixes a wrong-code issue with bounds-checking
enabled when doing I/O of an array section and an index is either
an expression or a function result. The problem does not occur
without b
On 11/6/24 3:33 PM, Marek Polacek wrote:
On Mon, Nov 04, 2024 at 11:10:05PM -0500, Jason Merrill wrote:
On 10/30/24 4:59 PM, Marek Polacek wrote:
On Wed, Oct 30, 2024 at 09:01:36AM -0400, Patrick Palka wrote:
On Tue, 29 Oct 2024, Marek Polacek wrote:
+static tree
+cp_parser_pack_index (cp_par
On 11/27/24 12:31 PM, Harald Anlauf wrote:
Dear all,
the attached patch fixes a wrong-code issue with bounds-checking
enabled when doing I/O of an array section and an index is either
an expression or a function result. The problem does not occur
without bounds-checking.
When looking at the or
Dear all,
the attached patch fixes a wrong-code issue with bounds-checking
enabled when doing I/O of an array section and an index is either
an expression or a function result. The problem does not occur
without bounds-checking.
When looking at the original testcase, the function occuring in
the
This patch adds a new case for unsigned scalar saturating subtraction
using a branch with a greater-than-or-equal condition. For example,
X >= (X - Y) ? (X - Y) : 0
is transformed into SAT_SUB (X, Y) when X and Y are unsigned scalars,
which therefore correctly matches more cases of IFN SAT_SUB. N
Case 7 of unsigned scalar saturating addition defines
SAT_ADD = X <= (X + Y) ? (X + Y) : -1. This is the same as
SAT_ADD = Y <= (X + Y) ? (X + Y) : -1 due to usadd_left_part_1
being commutative.
The pattern for case 7 currently does not accept the alternative
where Y is used in the condition. Ther
Support for middle-end representation of saturating arithmetic (via
IFN_SAT_ADD or IFN_SAT_SUB) cannot be determined externally, making it
currently impossible to selectively skip relevant tests on targets which
do not support this.
This patch adds new dg-require-effective-target keywords for each
Hi all,
This patch series adds support for 2 new cases of unsigned scalar saturating
arithmetic
(one addition, one subtraction). This results in more valid patterns being
recognised,
which results in a call to .SAT_ADD or .SAT_SUB where relevant.
v3 of this series now introduces support for dg-
x86 targets mask 32-bit shifts with a 5-bit mask (and 64-bit with 6-bit mask),
so they can use x >> y instead of x >> 32+y.
The optimization converts:
leal32(%rsi), %ecx
sall%cl, %eax
to:
sall%cl, %eax
PR target/36503
gcc/ChangeLog:
* config/i386/i386.md (*ashl
On Tue, 5 Nov 2024, Jason Merrill wrote:
> On 10/15/24 12:45 AM, Patrick Palka wrote:
> > This patch further cleans up the concepts code following the removal of
> > Concepts TS support:
> >
> >* concept-ids are now the only kind of "concept check", so we can
> > simplify some code accor
> > Hi,
> >
> > when inlining (during the analysis phase) a call graph edge, we update
> > all pass-through jump functions corresponding to edges going out of
> > the newly inlined function to be relative to the function into which
> > we are inlining or to expose the information originally capture
Hi All,
The testcase
#include
#include
#define N 8
#define L 8
void f(const uint8_t * restrict seq1,
const uint8_t *idx, uint8_t *seq_out) {
for (int i = 0; i < L; ++i) {
uint8_t h = idx[i];
memcpy((void *)&seq_out[i * N], (const void *)&seq1[h * N / 2], N / 2);
}
}
compil
On Wed, Nov 27, 2024 at 09:41:13AM -0500, David Malcolm wrote:
> On Wed, 2024-11-27 at 14:56 +0100, Richard Biener wrote:
> > On Sun, Nov 3, 2024 at 11:28 PM Lewis Hyatt wrote:
> > >
> > > Several of the selftests in diagnostic-show-locus.cc and input.cc
> > > are
> > > sensitive to linemap inter
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14/13?
-- >8 --
Here we end up ICEing at instantiation time for the call to
f ultimately because we wrongly consider the call to be
non-dependent, and so we specialize f ahead of time and then get
confused when fully s
On Wed, 27 Nov 2024, Jonathan Wakely wrote:
> On Wed, 27 Nov 2024 at 15:43, Patrick Palka wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> OK
Thanks, I noticed Jason already pushed his module std fixes patch so I
went ahead and removed the now unnecessary export as
On 11/26/24 6:44 AM, Robin Dapp wrote:
Hi,
this patch makes genrecog split its output into separate files (10 by
default) in the same vein genemit does. The changes are mostly
mechanical again, changing printfs and puts to fprintf.
As insn-recog.cc relies on being able to call other recog fu
On 11/27/24 5:59 AM, Oleg Endo wrote:
Hi,
Can the issue be resolved in a target independent manner as suggested below?
Or is it better to deal with this in the target code?
A blockage barrier like this patch does is probably significant
overkill, particularly since it's emitted at the gimple
On Fri, 8 Nov 2024, Nathaniel Shead wrote:
> Does this approach seem reasonable? I'm pretty sure that the way I've
> handled the templating here is unideal but I'm not sure what a neat way
> to do what I'm trying to do here would be; any comments are welcome.
Clever approach, I like it!
>
> --
On 11/27/24 1:43 AM, Nathaniel Shead wrote:
On Wed, Nov 27, 2024 at 12:03:23AM -0500, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu.
Does this approach make sense to you? Any other ideas?
-- 8< --
We weren't representing 'using namespace' at all in modules, which broke
some of the literal
On Wed, Nov 27, 2024 at 10:12:25AM +0100, Jakub Jelinek wrote:
> Hi!
>
> Compilation of the following testcase hangs forever after emitting first
> error. The problem is that in one place we just return error_mark_node
> directly rather than going through c_expr_sizeof_expr or c_expr_sizeof_type.
On Wed, 27 Nov 2024 at 15:43, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK
>
> -- >8 --
>
> This declares the range adaptor pipe operators a friend of the
> _RangeAdaptorClosure base class so that the std module doesn't need to
> export them for ADL to
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
This declares the range adaptor pipe operators a friend of the
_RangeAdaptorClosure base class so that the std module doesn't need to
export them for ADL to find them.
Note that we deliberately don't define these pipe operators
Hi,
On Fri, Nov 15 2024, Richard Biener wrote:
> On Fri, Nov 15, 2024 at 1:45 PM Jan Hubicka wrote:
>>
>> >
>> > The patch only ever skips just one conversion, never a chain of them and
>> > deliberately so, for the reasons shown in the example.
>> >
>> > However, I have just realized that combin
Hello,
I believe all questions regarding the patch below have been answered and
so I would like to ping it.
Thanks,
Martin
On Tue, Nov 05 2024, Martin Jambor wrote:
> Hi,
>
> when inlining (during the analysis phase) a call graph edge, we update
> all pass-through jump functions corresponding
On Tue, 26 Nov 2024, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, OK for trunk?
>
> -- 8< --
>
> Some tests were failing due to the exported using declaration of iter_move
> conflicting with friend declarations; the exported using needs to be in the
> inline namespace, like the customizati
On Tue, 26 Nov 2024 at 15:43, Jan Hubicka wrote:
>
> Hi,
> here is updated patch.
>
> I am not ceratin if:
> const size_t __diffmax
> = __gnu_cxx::__numeric_traits::__max / sizeof(_CharT);
> really needs "/ sizeof (_CharT)". I think we only need to be able to
> compute the diffe
On 11/13/24 7:16 AM, Mariam Arutunian wrote:
To address this, I added code in |target-supports.exp| and modified the
relevant tests.
I've attached the patch. Could you please check whether it is correct?
Yea, it basically looks right. Doing a test now ;-)
I think I've got the word_mode
On 11/27/24 5:48 AM, Robin Dapp wrote:
This patch would like to combine the vec_duplicate + vadd.vv to the
vadd.vx. From example as below:
I think we concluded a while ago that we don't want this turned on universally.
For the example/tests you provide it will be a de-optimization on any ua
On Wed, 2024-11-27 at 14:56 +0100, Richard Biener wrote:
> On Sun, Nov 3, 2024 at 11:28 PM Lewis Hyatt wrote:
> >
> > Several of the selftests in diagnostic-show-locus.cc and input.cc
> > are
> > sensitive to linemap internals. Adjust them here so they will
> > support 64-bit
> > location_t if co
Hi,
Ping for this, if possible Id be grateful to know if the direction of
this patch
is okay before working on it further?
I have played around with it more and have some improvements I can make
(pending clarification PR's to the ACLE) but would like feedback on the work
so far before pushing
Ping.
On Wed, Nov 06, 2024 at 03:33:00PM -0500, Marek Polacek wrote:
> On Mon, Nov 04, 2024 at 11:10:05PM -0500, Jason Merrill wrote:
> > On 10/30/24 4:59 PM, Marek Polacek wrote:
> > > On Wed, Oct 30, 2024 at 09:01:36AM -0400, Patrick Palka wrote:
> > > > On Tue, 29 Oct 2024, Marek Polacek wrote:
On Wed, Nov 27, 2024 at 8:56 AM Richard Biener
wrote:
>
> On Sun, Nov 3, 2024 at 11:28 PM Lewis Hyatt wrote:
> >
> > Several of the selftests in diagnostic-show-locus.cc and input.cc are
> > sensitive to linemap internals. Adjust them here so they will support 64-bit
> > location_t if configured.
> OK, but please drop "a" suffix from new files (when I added original
> pr112600 testcases, "a" suffix was for char type and "b" was for short
> type, but this is not the case with your testcases).
Thanks Uros, will commit with these changes if no surprise from test.
Pan
-Original Message--
On Wed, Nov 6, 2024 at 3:36 PM Michal Jires wrote:
>
> Die symbols are used for external references.
> Typically during LTO, early debug emits 'die_symbol+offset' for each
> possibly referenced DIE in future. Partitions in LTRANS phase then
> use these references.
>
> Originally die symbols are ha
As reported in bug 117781, my fix for bug 112841 broke the case of
typeof_unqual applied to an array of _Atomic elements, which should
not have _Atomic removed since only the element type is atomic, not
the array type. Fix with logic to ensure that atomic element types
are preserved as such, while
On Wed, Nov 6, 2024 at 3:36 PM Michal Jires wrote:
>
> During Incremental LTO, contents of LTO partitions diverge because of
> external DIE references (DW_AT_abstract_origin).
>
> External references are in form 'die_symbol+offset'.
> Originally there is only single die_symbol for each compilation
On Mon, Nov 25, 2024 at 12:10 PM Jakub Jelinek wrote:
>
> On Mon, Nov 25, 2024 at 11:52:31AM +0100, Uros Bizjak wrote:
> > > Any reason for an exact comparison rather than
> > > && (INTVAL (operands[3]) & ( * BITS_PER_UNIT - 1)) == 0
> > > ?
> > > I mean, we can optimize this way 1U << (32 - x)
On Wed, Nov 6, 2024 at 3:35 PM Michal Jires wrote:
>
> This if branch checks for comdat_type_p (GTY union tag) and then uses
> incorrect union variant die_id.die_symbol. There is no way to create
> this combination of valid values even if we ignore the GTY.
>
> Running testsuite with abort() in br
On Sun, Nov 3, 2024 at 11:28 PM Lewis Hyatt wrote:
>
> Several of the selftests in diagnostic-show-locus.cc and input.cc are
> sensitive to linemap internals. Adjust them here so they will support 64-bit
> location_t if configured.
>
> Likewise, handle 64-bit location_t in the support for
> -fdump
On Mon, Nov 25, 2024 at 2:23 AM wrote:
>
> From: Pan Li
>
> This patch would like to refactor the unsigned SAT_ADD pattern when
> leverage the IFN ADD_OVERFLOW, aka:
> * Extract type check outside.
> * Re-arrange the related match pattern forms together.
> * Remove unnecessary helper pattern matc
On Wed, Nov 27, 2024 at 1:20 AM Andrew Pinski wrote:
>
> For a double conversion, we will simplify it into a conversion
> with an and if the outer type and inside precision matches and
> the intra precision is smaller and unsigned. We should be able
> to extend this to where the outer precision is
> I see, didn't aware of that. I am not sure if we need to consider vsetvl here?
> As there are extra 2 insn here.
I wouldn't consider it as it's outside of the loop. What matters is latency
inside the loop.
> I see, need to consider the cost here. Any example I can reference? Sorry I
> haven't
On Wed, Nov 27, 2024 at 4:26 AM liuhongt wrote:
>
> When loop requires any kind of versioning which could increase register
> pressure too much, and it's in a deeply nest big loop, don't do
> vectorization.
>
> I tested the patch with both Ofast and O2 for SPEC2017, besides
> 548.exchange_r,
> ot
On 11/27/24 4:12 AM, Nathaniel Shead wrote:
On Thu, Nov 21, 2024 at 07:51:55PM +0100, Jason Merrill wrote:
On 11/9/24 9:22 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? Given
that this doesn't actually fix the modules PR c++/116568 anymore I've
pul
While working on fancy pointer support for the linked lists I noticed
they didn't have any debug assertions. This adds the obvious non-empty
assertions to front() and back().
libstdc++-v3/ChangeLog:
* include/bits/forward_list.h (forward_list::front): Add
non-empty assertions.
Thanks Robin for comments.
> I think we concluded a while ago that we don't want this turned on
> universally.
> For the example/tests you provide it will be a de-optimization on any uarch
> that has non-zero GPR -> VR latency
I see, didn't aware of that. I am not sure if we need to consider vse
Hi,
Can the issue be resolved in a target independent manner as suggested below?
Or is it better to deal with this in the target code?
Best regards,
Oleg Endo
On Fri, 2024-09-27 at 00:26 -0400, Pietro Monteiro wrote:
> The prefetch instruction that is emitted by __builtin_prefetch is
> re-ordere
On Mon, 18 Nov 2024 at 19:10, Marc Glisse wrote:
>
> On Sat, 16 Nov 2024, Jonathan Wakely wrote:
>
> >>void
> >>_M_erase(iterator __position) _GLIBCXX_NOEXCEPT
> >>{
> >> + if (__builtin_expect(empty(), 0))
> >> + {
> >> + __glibcxx_requires_nonempty
On Wed, 27 Nov 2024, Jakub Jelinek wrote:
> Hi!
>
> The r15-4833-ge9ab41b79933 patch had among tons of config/i386
> specific changes also important change to the generic code, allowing
> also 2 as valid value of the second argument of __builtin_prefetch:
> - /* Argument 1 must be either zero or
Use diagnostic pragmas to allow using `if constexpr` in C++11 mode, so
that we don't need to use tag dispatching.
The _M_move_assign overloads that were previously used for tag
dispatching are no longer used, but are retained here (at least for the
default config) so that an explicit instantiation
> This patch would like to combine the vec_duplicate + vadd.vv to the
> vadd.vx. From example as below:
I think we concluded a while ago that we don't want this turned on universally.
For the example/tests you provide it will be a de-optimization on any uarch
that has non-zero GPR -> VR latency.
On Wed, 27 Nov 2024, Jakub Jelinek wrote:
> Hi!
>
> As the following testcases show, in case of multi-word
> __sync_lock_test_and_set where we don't actually support atomics for that
> size (__int128 for x86_64 lp64 with -mno-cx16, long long for ia32 with
> -march=i{3,4}86), as the last fallback
On Wed, Nov 06 2024, Michal Jires wrote:
> On Wed, 2024-11-06 at 17:33:50 +, Jonathan Wakely wrote:
>>
>> If there's going to be a constructor then it should initialize the members.
>>
>> Otherwise, your original patch was better, because you could write
>> this to get an all-zeros object:
>>
On Mon, 18 Nov 2024 at 18:32, François Dumont wrote:
>
>
> On 18/11/2024 19:24, François Dumont wrote:
> >
> > On 16/11/2024 02:18, Jonathan Wakely wrote:
> >> On Sat, 16 Nov 2024 at 01:09, Jonathan Wakely
> >> wrote:
> >>> While working on fancy pointer support for the linked lists I noticed
> >
On 11/27/24 04:05, Uros Bizjak wrote:
Hello!
I'd like to backport two LRA patches to gcc-14 branch:
1. [PR114942][LRA]: Don't reuse input reload reg of inout early clobber operand
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=9585317f0715699197b1313bbf939c6ea3c1ace6
2. [PR117105][LRA]: Use
Use diagnostic pragmas to allow using `if constexpr` in C++11 mode, so
that we don't need to use tag dispatching.
The unused member functions are preserved for the purposes of explicit
instantiations. The _M_assign function template can be removed, because
member function templates aren't instanti
On Wed, 27 Nov 2024, Jakub Jelinek wrote:
> Hi!
>
> As the pr117692.c testcase shows, the generalized pattern can introduce
> UB when there wasn't any.
> The old pattern was I believe correct, it is as if in the new
> pattern C3 was always 1 and I don't see how that could have introduced
> UB.
>
From: Pan Li
Add asm dump check and run test for vec_duplicate + vadd.vv combine
to vadd.vx. Introduce new folder to hold all related testcases.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/rvv.ex
From: Pan Li
After we support the vec_duplicate + vadd.vv combine to vadd.vx, the
existing testcases need some adjust for asm dump check times.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/
From: Pan Li
This patch would like to combine the vec_duplicate + vadd.vv to the
vadd.vx. From example as below:
#define DEF_VX_BINARY(T, OP)\
void\
test_vx_binary (T * restrict out, T
When the max argument to std::codecvt::length
is SIZE_MAX/4+1 or greater the multiplication with sizeof(wchar_t) will
wrap to a small value, and the alloca call will have a buffer that's
smaller than requested. The call to mbsnrtowcs then has a buffer that is
smaller than the value passed as the bu
> On 27 Nov 2024, at 09:34, Richard Sandiford wrote:
>
> Soumya AR writes:
>> NBSL, BSL1N, and BSL2N are bit-select intructions on SVE2 with certain
>> operands
>> inverted. These can be extended to work with Neon modes.
>>
>> Since these instructions are unpredicated, duplicate patterns wer
Simplify and cleanup ifunc selection logic. Since LRCPC3 does
not imply LSE2, has_rcpc3() should also check LSE2 is enabled.
Passes regress and bootstrap, OK for commit?
libatomic:
* config/linux/aarch64/host-config.h (has_lse2): Cleanup.
(has_lse128): Likewise.
(has_rcp
Hi!
The r15-4833-ge9ab41b79933 patch had among tons of config/i386
specific changes also important change to the generic code, allowing
also 2 as valid value of the second argument of __builtin_prefetch:
- /* Argument 1 must be either zero or one. */
For {xv,v}{srl,sll,sra}, the constraint `vector_same_uimm6` cause overflow
in when emit {w,h,b}. Since the number of bits shifted is the remainder of
the register value, it is actually unnecessary to constrain the range.
Simply mask the shift number with the unit-bit-width, without any
constraint o
Hi Tobias!
On 2024-11-18T14:23:24+0100, Tobias Burnus wrote:
> This fixes a C23 error, causing a build fail: 'false'
> should have been 'NULL'.
ACK.
> The NULL value is not really handled as the code calling
> maybe_init_omp_async assumes that agent->omp_async_queue can be
> dereferenced. Henc
Soumya AR writes:
> NBSL, BSL1N, and BSL2N are bit-select intructions on SVE2 with certain
> operands
> inverted. These can be extended to work with Neon modes.
>
> Since these instructions are unpredicated, duplicate patterns were added with
> the predicate removed to generate these instructions
On Wed, 27 Nov 2024, Uros Bizjak wrote:
> Hello!
>
> I'd like to backport two LRA patches to gcc-14 branch:
>
> 1. [PR114942][LRA]: Don't reuse input reload reg of inout early clobber
> operand
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=9585317f0715699197b1313bbf939c6ea3c1ace6
>
> 2. [PR
Hi!
As the following testcases show, in case of multi-word
__sync_lock_test_and_set where we don't actually support atomics for that
size (__int128 for x86_64 lp64 with -mno-cx16, long long for ia32 with
-march=i{3,4}86), as the last fallback if we don't know anything else
we just emit calls to __
Hi!
As the pr117692.c testcase shows, the generalized pattern can introduce
UB when there wasn't any.
The old pattern was I believe correct, it is as if in the new
pattern C3 was always 1 and I don't see how that could have introduced
UB.
But if type is signed and C3 (aka factor) isn't 1 and for +
Pushed as r15-5716.
Paul
On Wed, 27 Nov 2024 at 09:15, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi Andre,
>
> Yes indeed, I did regtest the patch :-)
>
> Thanks for the thumbs up.
>
> Paul
>
>
> On Wed, 27 Nov 2024 at 09:07, Andre Vehreschild wrote:
>
>> Hi Paul,
>>
>> the
On Thu, Nov 21, 2024 at 07:51:55PM +0100, Jason Merrill wrote:
> On 11/9/24 9:22 AM, Nathaniel Shead wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? Given
> > that this doesn't actually fix the modules PR c++/116568 anymore I've
> > pulled my workaround for that out as
1 - 100 of 108 matches
Mail list logo
