This series of two patches enables the output of the LTO object file
without an assembler. As of now, .symtab is emitted with __gnu_lto_slim
symbol. To test, follow the instructions in the commit
message of patch 1. Also, as suggested by Honza, I am putting these patches
on devel/bypass-asm branch.
This patch updates 'input_location' during constant evaluation to ensure
that errors in subexpressions that lack location information still
provide accurate diagnostics.
By itself this change causes some small regressions in diagnostic
quality for circumstances where errors used 'input_location' b
Currently, when typeck discovers that a return statement will refer to a
local variable it rewrites to return a null pointer. This causes the
error messages for using the return value in a constant expression to be
unhelpful, especially for reference return values.
This patch removes this "optimis
This adds rudimentary lifetime tracking in C++ constexpr contexts,
allowing the compiler to report errors with using values after their
backing has gone out of scope. We don't yet handle other ways of
accessing values outside their lifetime (e.g. following explicit
destructor calls).
PR c+
This is an update of the patch series at
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614811.html
Changes since v2:
- Use a separate 'hash_set' to track expired variables instead of
adding a flag to 'lang_decl_base'.
- Use 'iloc_sentinel' to propagate location information down to
sube
GCC maintainers:
Ver 2, Went back thru the requirements and emails. Not sure where I
came up with the requirement for an overloaded version with double
argument. Removed the overloaded version with the double argument.
Added the macro to announce if the __builtin_set_fpscr_rn returns a
void
On Fri, 30 Jun 2023 17:25:54 PDT (-0700), Andrew Waterman wrote:
On Fri, Jun 30, 2023 at 5:13 PM Vineet Gupta wrote:
On 6/30/23 16:50, Andrew Waterman wrote:
> I don't believe this is correct; the subtraction is needed to account
> for the fact that the low part might be negative, resulting
On Fri, Jun 30, 2023 at 5:13 PM Vineet Gupta wrote:
>
>
>
> On 6/30/23 16:50, Andrew Waterman wrote:
> > I don't believe this is correct; the subtraction is needed to account
> > for the fact that the low part might be negative, resulting in a
> > borrow from the high part. See the output for you
On 6/30/23 16:50, Andrew Waterman wrote:
I don't believe this is correct; the subtraction is needed to account
for the fact that the low part might be negative, resulting in a
borrow from the high part. See the output for your test case below:
$ cat test.c
#include
int main()
{
unsigned
On 6/30/23 6:50 PM, Carl Love wrote:
> With a little help from Peter and Julian Wang. Objdump decodes some of
> the xxlor instructions as xxmr instsructions. The xxmr is a new
> mnemonic which will be out in the next ISA. But objdump already
> produces it. So if you add the counts for grep xxlo
On 6/30/23 5:20 PM, Carl Love wrote:
> So, we have the issue that looking at the assembly gives different
> instruction counts then what
>
>dg-final { scan-assembler-times {\mxxlor\M} }
>
> comes up with???
I recommend not even counting xxlor at all, since the majority of
them come from vsx
Kewen:
On Fri, 2023-06-30 at 15:20 -0700, Carl Love wrote:
> So, went to look at the assembly to verify my comment on the
> difference
> being related to the loads. I decided to actually count the
> instructions just to verify the number in the assembly files.
> Before,
> I just looked at the ass
I don't believe this is correct; the subtraction is needed to account
for the fact that the low part might be negative, resulting in a
borrow from the high part. See the output for your test case below:
$ cat test.c
#include
int main()
{
unsigned long result, tmp;
asm (
"li %1,-252645
On 6/30/23 16:33, Vineet Gupta wrote:
Ran into a minor snafu in const splitting code when playing with test
case from an old PR/23813.
long long f(void) { return 0xF0F0F0F0F0F0F0F0ull; }
This currently generates
li a5,-252645376
addia5,a5,241
li
Ran into a minor snafu in const splitting code when playing with test
case from an old PR/23813.
long long f(void) { return 0xF0F0F0F0F0F0F0F0ull; }
This currently generates
li a5,-252645376
addia5,a5,241
li a0,-252645376
sllia5,a5,32
In order to support processing #pragma in preprocess-only mode (-E or
-save-temps for gcc/g++), we need a way to obtain the #pragma tokens from
libcpp. In full compilation modes, this is accomplished by calling
pragma_lex (), which is a symbol that must be exported by the frontend, and
which is cur
On 6/30/23 04:14, Robin Dapp wrote:
The explicit conversions I see are because we need the output of the
conversion in multiple vfmul instructions. That won't be helped by
the patch you've proposed.
FWIW on my local branch and the patch applied I see that the vfwmuls
are being generated (al
Kewen:
On Fri, 2023-06-30 at 11:37 +0800, Kewen.Lin wrote:
> Hi Carl,
>
> on 2023/6/30 05:36, Carl Love wrote:
> > Kewen:
> >
> > On Wed, 2023-06-28 at 16:35 +0800, Kewen.Lin wrote:
> > > > Yea, I was going with a runnable test and didn't include the
> > > > instruction counts. Added back in.
I also set /proc/sys/kernel/perf_event_paranoid to 1 instead of the default 2.
-Original Message-
From: Gcc-patches On
Behalf Of Eugene Rozenfeld via Gcc-patches
Sent: Friday, June 30, 2023 2:44 PM
To: Sam James ; Richard Biener
Cc: gcc-patches@gcc.gnu.org
Subject: RE: [EXTERNAL] Re: [P
I don't run this with elevated privileges but I set
/proc/sys/kernel/kptr_restrict to 0. Setting that does require elevated
privileges.
If that's not acceptable, the only fix I can think of is to make that event
mapping threshold percentage a parameter to create_gcov and pass something low
eno
Jakub made a similar change a few yeas ago, but I think it got lost
in the recent PSTL rebase.
Tested x86_64-linux.
Does this look OK for trunk?
-- >8 --
This reapplies r10-1314-g32bab8b6ad0a90 which was lost in the recent
PSTL rebase from upstream.
* include/pstl/pstl_config.h (_PSTL_
Updated from prior version to address latest review comment (simplify
umod3).
Disable generation of scalar modulo instructions.
It was recently discovered that the scalar modulo instructions can suffer
noticeable performance issues for certain input values. This patch disables
their generation s
This patch adds support for "declare mapper" directives (and the "mapper"
modifier on "map" clauses) for C.
2023-06-30 Julian Brown
gcc/c/
* c-decl.cc (c_omp_mapper_id, c_omp_mapper_decl, c_omp_mapper_lookup,
c_omp_extract_mapper_directive, c_omp_map_array_section,
c_om
This patch adds support for parsing general lvalues ("locator list item
types") for OpenMP "map", "to" and "from" clauses to the C front-end,
similar to the previously-posted patch for C++.
2023-06-30 Julian Brown
gcc/c/
* c-pretty-print.cc (c_pretty_printer::postfix_expression,
This patch implements "omp declare mapper" functionality for Fortran,
following the equivalent support for C and C++. This version of the
patch has been merged to og13 and contains various fixes for e.g.:
* Mappers with deferred-length strings
* Array descriptors not being appropriately tran
This patch adds support for OpenMP 5.0 "declare mapper" functionality
for C++. I've merged it to og13 based on the last version
posted upstream, with some minor changes due to the newly-added
'present' map modifier support. There's also a fix to splay-tree
traversal in gimplify.cc:omp_instantiate
This patch fixes two more cases where an unmapped target pointer results
in a null pointer on the target instead of a copy of the host pointer.
The latter behaviour is required by OpenMP 5.2, which is a change from
earlier versions of the standard. This change has already been made in
one place by
This patch series provides generalised lvalue ("locator list item")
parsing for OpenMP "map", "to" and "from" clauses for C and C++, and
"declare mapper" support for C, C++ and Fortran. It is based on the
latter part of the patch series sent upstream previously:
https://gcc.gnu.org/pipermail/gc
This patch fixes a couple of minor merge/formatting errors.
2023-06-30 Julian Brown
gcc/fortran/
* parse.cc (decode_omp_directive): Add missing break.
gcc/
* gimplify.cc (gimplify_adjust_omp_clauses): Fix indentation.
---
gcc/fortran/parse.cc | 1 +
gcc/gimplify.cc | 4 +
On 6/22/23 10:30 PM, Ian Lance Taylor wrote:
> On Thu, Jun 22, 2023, 4: 47 PM Peter Bergner
> wrote: On 6/22/23 6: 37 PM, Peter Bergner via Gcc-patches wrote: > On 6/16/23
> >> On Fri, Jun 16, 2023 at 9:00 AM Paul E. Murphy via Gcc-patches
> >> mailto:gcc-patches@gcc.gnu.org>> wrote:
>
On Fri, Jun 30, 2023, 12:18 PM Tamar Christina
wrote:
> Hi Jason,
>
> Thanks for the review. I only now realized I should have split them
> between C and C++.
>
> Will do so on the respins.
>
> >
> > On 6/28/23 09:41, Tamar Christina wrote:
> > > Hi All,
> > >
> > > FORTRAN currently has a pragma
On Fri, Jun 30, 2023 at 08:45:38PM +0800, Kito Cheng wrote:
> Hmmm, I think maybe what we need is to leverage C++ language features
> to declare enum with underlying types like that:
>
> enum machine_mode : uint16_t
What would be the advantage of doing that?
I mean, on most hosts using unsigned r
Hi Jason,
Thanks for the review. I only now realized I should have split them between C
and C++.
Will do so on the respins.
>
> On 6/28/23 09:41, Tamar Christina wrote:
> > Hi All,
> >
> > FORTRAN currently has a pragma NOVECTOR for indicating that
> > vectorization should not be applied to a
Hi!
On 2023-06-30T20:45:38+0800, Kito Cheng wrote:
>> On 2023-05-13T16:44:41+0800, Kito Cheng via Gcc-patches
>> wrote:
>> > Tried this patch and I ran into some issues, some variables are using
>> > unsigned char to hold machine mode and will have problems when the
>> > number of modes is larg
Successfully regrtested on x86_64-pc-linux-gnu.
Verified fix on powerpc64le-unknown-linux-gnu (gcc112 in Compile Farm).
Pushed to trunk as r14-2223-gc3c0ba5436170e.
gcc/testsuite/ChangeLog:
PR jit/110466
* jit.dg/jit.exp (jit-check-debug-info): Gracefully handle too
early v
r13-4531-gd2e782cb99c311 added test coverage to libgccjit's vector
support, but used __vector, which doesn't work on Power. Additionally
the size param to gcc_jit_type_get_vector was wrong.
Fixed thusly.
Successfully regrtested on x86_64-pc-linux-gnu.
Verified fix on powerpc64le-unknown-linux-gn
On Fri, Jun 23, 2023 at 01:09:14PM -0400, Patrick Palka wrote:
> On Wed, 29 Mar 2023, Nathaniel Shead via Gcc-patches wrote:
>
> > This patch caches the current expression's location information in the
> > constexpr_global_ctx struct, which allows subexpressions that have lost
> > location informa
On Mon, Jun 26, 2023 at 03:37:32PM -0400, Patrick Palka wrote:
> On Sun, 25 Jun 2023, Nathaniel Shead wrote:
>
> > On Fri, Jun 23, 2023 at 12:43:21PM -0400, Patrick Palka wrote:
> > > On Wed, 29 Mar 2023, Nathaniel Shead via Gcc-patches wrote:
> > >
> > > > This adds rudimentary lifetime tracking
Hi David,
On Wed, May 31 2023, David Malcolm via Gcc-patches wrote:
> This patch extends -Wanalyzer-out-of-bounds so that, where possible, it
> will emit a text art diagram visualizing the spatial relationship between
[...]
>
> gcc/ChangeLog:
> PR analyzer/106626
> * Makefile.in (AN
On Fri, 30 Jun 2023 at 15:29, Patrick Palka wrote:
>
> On Fri, 30 Jun 2023, Jonathan Wakely wrote:
>
> > Tested x86_64-linux. Patrick, PTAL.
> >
> > -- >8 --
> >
> > The __has_attribute(init_priority) check in is true for Clang
> > on darwin, which means that user code including thinks the
> > l
Tested powerpc64le-linux and x86_64-linux. Pushed to trunk.
-- >8 --
This newly-introduced variable isn't used on all paths, so add the
[[maybe_unused]] attribute.
libstdc++-v3/ChangeLog:
* src/c++11/random.cc (random_device::_M_init): Add maybe_unused
attribute.
---
libstdc++-
On Fri, 30 Jun 2023, Jonathan Wakely wrote:
> Tested x86_64-linux. Patrick, PTAL.
>
> -- >8 --
>
> The __has_attribute(init_priority) check in is true for Clang
> on darwin, which means that user code including thinks the
> library will initialize the global streams. However, when libstdc++ is
Tested x86_64-linux. Patrick, PTAL.
-- >8 --
The __has_attribute(init_priority) check in is true for Clang
on darwin, which means that user code including thinks the
library will initialize the global streams. However, when libstdc++ is
built by GCC on darwin, the __has_attribute(init_priority)
Tested x86_64-linux. Pushed to trunk.
-- >8 --
In r14-289-gf9412cedd6c0e7 I made the std::random_device constructor
throw std::system_error for unrecognized tokens. But it still throws
std::runtime_error for a token such as "rdseed" that is recognized but
not supported at runtime by the CPU the p
Also change some internal variables and function argument from int to bool.
gcc/ChangeLog:
* fold-const.h (multiple_of_p): Change return type from int to bool.
* fold-const.cc (split_tree): Change negl_p, neg_litp_p,
neg_conp_p and neg_var_p variables to bool.
(const_binop): Chang
Hi,
while looking into the std::vector _M_realloc_insert codegen I noticed that
call of __throw_bad_alloc is predicted with 10% probability. This is because
the conditional guarding it has __builtin_expect (cond, 0) on it. This
incorrectly takes precedence over more reliable heuristics predicting
> On 2023-05-13T16:44:41+0800, Kito Cheng via Gcc-patches
> wrote:
> > Tried this patch and I ran into some issues, some variables are using
> > unsigned char to hold machine mode and will have problems when the
> > number of modes is larger than 255...
> >
> > And here is the fix:
>
> > --- a/gc
Hi!
On 2023-05-13T16:44:41+0800, Kito Cheng via Gcc-patches
wrote:
> Tried this patch and I ran into some issues, some variables are using
> unsigned char to hold machine mode and will have problems when the
> number of modes is larger than 255...
>
> And here is the fix:
> --- a/gcc/genmodes.c
Thanks Thomas for make it happen.
Then we have 2 patches, right? V4 Streamer and V1 LTO: Capture. Not quite sure
if these 2 has some dependencies when commit (I suppose both are well tested
and approved). But anything I can do to make some progress please feel free to
let me know.
Again, very
On Tue, Jun 13, 2023 at 4:07 AM Kewen Lin wrote:
>
> This patch series follows Richi's suggestion at the link [1],
> which suggest structuring vectorizable_load to make costing
> next to the transform, in order to make it easier to keep
> costing and the transform in sync. For now, it's a known
>
Hi,
On Thu, Jun 29 2023, Marek Polacek wrote:
> On Thu, Jun 29, 2023 at 05:58:22PM +0200, Martin Jambor wrote:
[...]
>>
>> Unfortunately I won't have time to actually look at this in the next 2-3
>> weeks, so I am inclined to just trust the verification script (which
>> essentially runs autocon
Oluwatamilore Adebayo writes:
> From: oluade01
>
> This updates vect_recog_abd_pattern to recognize the widening
> variant of absolute difference (ABDL, ABDL2).
>
> gcc/ChangeLog:
>
> * internal-fn.cc (widening_fn_p, decomposes_to_hilo_fn_p):
> Add IFN_VEC_WIDEN_ABD to the switch stat
On Tue, Jun 13, 2023 at 4:03 AM Kewen Lin wrote:
>
> This patch adjusts the cost handling on VMAT_INVARIANT in
> function vectorizable_load. We don't call function
> vect_model_load_cost for it any more.
>
> To make the costing on VMAT_INVARIANT better, this patch is
> to query hoist_defs_of_uses
Committed, thanks Jeff and Juzhe.
Pan
-Original Message-
From: Jeff Law
Sent: Friday, June 30, 2023 4:58 AM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@sifive.com; Wang, Yanzhang
Subject: Re: [PATCH v1] RISC-V: Refactor vxrm_mode attr for type attr equa
On Tue, Jun 13, 2023 at 4:03 AM Kewen Lin wrote:
>
> This patch adds one extra argument cost_vec to function
> vect_build_gather_load_calls, so that we can do costing
> next to the tranform in vect_build_gather_load_calls.
> For now, the implementation just follows the handlings in
> vect_model_lo
List items can only appear in lists. :-)
This fixes up
commit b38079855ead7f7e358d17bc06642d031de5e29b
Author: Marek Polacek
Date: Thu Jun 22 14:44:43 2023 -0400
C++26 P2752R3 - Static storage for braced initializers implemented
Gerald
---
htdocs/gcc-14/changes.html | 2 ++
1 fil
When store-merging looks for bswap opportunities we also handle
BIT_FIELD_REFs where we verify the refed object is of scalar
type but we don't check for the result type we eventually use.
That's done later but after we eventually query TYPE_PRECISION.
The following re-orders this.
Bootstrapped and
From 50cb9df7209125f9466336d23efdd4fbeda9c4d5 Mon Sep 17 00:00:00 2001
From: rsh-raj
Date: Fri, 30 Jun 2023 16:04:48 +0530
Subject: [PATCH] MAINTAINERS file: Added myself to Write After Approval and
DCO
ChangeLog:
2023-06-30 Rishi Raj
* MAINTAINERS: Added myself to Write After Approval and
From: Ju-Zhe Zhong
Hi, Richi and Richard.
This patch is adding LEN_MASK_{GATHER_LOAD,SCATTER_STORE} to allow targets
handle flow control by mask and loop control by length on gather/scatter memory
operations. Consider this following case:
#include
void
f (uint8_t *restrict a,
uint8_t *restr
From: Ju-Zhe Zhong
Hi, Richard and Richi.
It seems that the implementation of LEN_MASK_GATHER_LOAD/LEN_MASK_SCATTER_STORE
is simple
and code change is not big.
Here is an example:
#include
void
f (uint8_t *restrict a,
uint8_t *restrict b, int n,
int base, int step,
int *restrict cond
> The explicit conversions I see are because we need the output of the
> conversion in multiple vfmul instructions. That won't be helped by
> the patch you've proposed.
FWIW on my local branch and the patch applied I see that the vfwmuls
are being generated (all of the vfmuls are replaced).
> It
> (fold_nonarray_ctor_reference): Likewise. Specifically deal
> with integral bit-fields.
> (fold_ctor_reference): Check that the constructor uses the
> native storage order.
>
>
> 2023-06-30 Eric Botcazou
>
> * gcc.c-torture/
On Fri, 30 Jun 2023 at 09:42, Jonathan Wakely wrote:
>
> On Fri, 30 Jun 2023 at 04:48, Hans-Peter Nilsson wrote:
> >
> > > Date: Mon, 26 Jun 2023 11:57:49 -0700
> > > From: Thomas Rodgers via Gcc-patches
> >
> > > On Wed, May 17, 2023 at 12:32 PM Jonathan Wakely
> > > wrote:
> > > > All the act
native storage order.
2023-06-30 Eric Botcazou
* gcc.c-torture/execute/20230630-1.c: New test.
* gcc.c-torture/execute/20230630-2.c: Likewise.
--
Eric Botcazoudiff --git a/gcc/gimple-fold.cc b/gcc/gimple-fold.cc
index 3d46b76edeb..e80a72dfa22 100644
--- a/gcc/gimple
Hi Richi,
Thanks for your review!
on 2023/6/30 16:56, Richard Biener wrote:
> On Fri, Jun 30, 2023 at 7:38 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> As PR110248 shows, some middle-end passes like IVOPTs can
>> query the target hook legitimate_address_p with some
>> artificially constructed rtx to dete
Hi All,
I have gone through the PDT problem reports and made sure that they
block PR82173.
To my utter astonishment (i) There might be only one duplicate; and
(ii) Only 82649, 84119, 90218, 95541, 99079, 102901 & 105380 (out of
50 PRs) depend on the representation.
Regards
Paul
Richard Biener via Gcc-patches writes:
> On Fri, Jun 30, 2023 at 7:28 AM Eugene Rozenfeld via Gcc-patches
> wrote:
>>
>> When we collect just user events for autofdo with lbr we get some events
>> where branch
>> sources are kernel addresses and branch targets are user addresses. Without
>>
On Fri, Jun 30, 2023 at 7:46 AM Kewen.Lin wrote:
>
> Hi,
>
> As PR110248 shows, to get the expected query results for
> that case internal functions LEN_{LOAD,STORE} is unable to
> adopt some addressing modes, we need to pass down the
> related IFN code as well. This patch is to make IVOPTs
> pas
On Fri, Jun 30, 2023 at 7:38 AM Kewen.Lin wrote:
>
> Hi,
>
> As PR110248 shows, some middle-end passes like IVOPTs can
> query the target hook legitimate_address_p with some
> artificially constructed rtx to determine whether some
> addressing modes are supported by target for some gimple
> statem
On Fri, Jun 30, 2023 at 7:28 AM Eugene Rozenfeld via Gcc-patches
wrote:
>
> When we collect just user events for autofdo with lbr we get some events
> where branch
> sources are kernel addresses and branch targets are user addresses. Without
> kernel MMAP
> events create_gcov can't make sense of
On Fri, Jun 30, 2023 at 7:20 AM Kewen.Lin wrote:
>
> Hi,
>
> Similar to r0-85707-g34917a102a4e0c for PR35051, the uses
> of mpz_t should be guarded with "#ifndef GENERATOR_FILE".
> This patch is to fix it and avoid some possible build
> errors.
>
> Bootstrapped and regress-tested on x86_64-redhat-
Hi!
On 2023-06-30T01:39:39+, "Li, Pan2" wrote:
> That’s very cool, thanks Thomas for help!
:-)
> Let’s wait the AMD test running result for the final version of the patch.
That's all looking good, too.
> From: juzhe.zh...@rivai.ai
> Sent: Friday, June 30, 2023 9:27 AM
> Could you merge
On Fri, 30 Jun 2023 at 04:48, Hans-Peter Nilsson wrote:
>
> > Date: Mon, 26 Jun 2023 11:57:49 -0700
> > From: Thomas Rodgers via Gcc-patches
>
> > On Wed, May 17, 2023 at 12:32 PM Jonathan Wakely wrote:
> > > All the actual code changes look good.
>
> Unfortunately, this overwrote the fix for PR1
On 2023/6/30 10:16, Chenghui Pan wrote:
[snip]
---
gcc/config/loongarch/constraints.md| 128 +-
gcc/config/loongarch/loongarch-builtins.cc | 10 +
gcc/config/loongarch/loongarch-modes.def | 38 +
gcc/config/loongarch/loongarch-protos.h| 31 +
gcc/config/loongarch/loo
On Fri, 30 Jun 2023, Thomas Schwinge wrote:
> Hi!
>
> On 2023-06-29T22:14:59+0200, I wrote:
> > [the new] 'file_data->mode_bits' needs to be considered [somewhere]
> >
> > Easiest is in 'gcc/lto-streamer.h:class lto_input_block' to capture
> > 'lto_file_decl_data *file_data' instead of just
> > '
When we call statistics_fini_pass we unconditionally allocate
the statistics hash and traverse it. When a TU has many small
functions this can take considerable time. The following avoids
this by never allocating the hash from this function.
Bootstrapped and tested on x86_64-unknown-linux-gnu, p
On Fri, Jun 30, 2023 at 9:29 AM Roger Sayle wrote:
>
>
> This patch implements scalar-to-vector (STV) support for DImode and SImode
> rotations by constant bit counts. Scalar rotations are almost always
> optimal on x86, requiring only one or two instructions, but it is also
> possible to impleme
From: oluade01
This patch adds new RTL for ABDL (sabdl, sabdl2, uabdl, uabdl2).
gcc/ChangeLog:
* config/aarch64/aarch64-simd.md
(vec_widen_abdl_lo_, vec_widen_abdl_hi_):
Expansions for abd vec widen optabs.
(aarch64_abdl_insn): VQW based abdl RTL.
* confi
From: oluade01
This updates vect_recog_abd_pattern to recognize the widening
variant of absolute difference (ABDL, ABDL2).
gcc/ChangeLog:
* internal-fn.cc (widening_fn_p, decomposes_to_hilo_fn_p):
Add IFN_VEC_WIDEN_ABD to the switch statement.
* internal-fn.def (VEC_WIDE
> Sorry, my fault, but I meant the comment about avoiding
> (minus (max…) (min…)) for both patterns, not just the first.
Change made.
> I think the review suggestions for 1/2 will change the tests.
> For example:
>
> TEST2(signed, short, char)
This is the case and the tests have been updated to
> Sorry, my fault. I was using the original type names in this
> suggestion, rather than the TYPE1…TYPE5 ones. Should be:
>
>WIDEN_ABD exists to optimize the case where TYPE4 is at least
>twice as wide as TYPE3.
Change made.
> Lingering use of “L” suffixes here. Maybe:
>
> stmts
Hi!
On 2023-06-29T22:14:59+0200, I wrote:
> [the new] 'file_data->mode_bits' needs to be considered [somewhere]
>
> Easiest is in 'gcc/lto-streamer.h:class lto_input_block' to capture
> 'lto_file_decl_data *file_data' instead of just
> 'unsigned char *mode_table', and adjust all users.
I've split
This patch implements scalar-to-vector (STV) support for DImode and SImode
rotations by constant bit counts. Scalar rotations are almost always
optimal on x86, requiring only one or two instructions, but it is also
possible to implement these efficiently with SSE2, requiring only one
or two instr
Hi!
On 2023-04-29T09:06:54-0600, Jeff Law via Gcc-patches
wrote:
> On 4/29/23 07:37, Roger Sayle wrote:
>>
>> Segher Boessenkool wrote:
>>> I send this patch now so that people can start testing.
>>>
>>> --- a/gcc/config/nvptx/nvptx.cc
>>> +++ b/gcc/config/nvptx/nvptx.cc
>>> @@ -7601,9 +7601,6 @
Hi, Richi. I have added "BIAS" and send V4:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623293.html
Forget about V3. I made a mistake there, sorry about that.
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-06-30 14:26
To: Ju-Zhe Zhong
CC: gcc-patches; richard.sandiford
From: Ju-Zhe Zhong
Hi, Richi and Richard.
This patch is adding LEN_MASK_{GATHER_LOAD,SCATTER_STORE} to allow targets
handle flow control by mask and loop control by length on gather/scatter memory
operations. Consider this following case:
#include
void
f (uint8_t *restrict a,
uint8_t *restr
On Thu, Jun 29, 2023 at 01:43:07PM -0400, Jason Merrill wrote:
> On 6/24/23 09:24, Nathaniel Shead wrote:
> > On Fri, Jun 23, 2023 at 11:59:51AM -0400, Patrick Palka wrote:
> > > Hi,
> > >
> > > On Sat, 22 Apr 2023, Nathaniel Shead via Gcc-patches wrote:
> > >
> > > > Bootstrapped and tested on x
From: Ju-Zhe Zhong
Hi, Richi and Richard.
This patch is adding LEN_MASK_{GATHER_LOAD,SCATTER_STORE} to allow targets
handle flow control by mask and loop control by length on gather/scatter memory
operations. Consider this following case:
#include
void
f (uint8_t *restrict a,
uint8_t *rest
88 matches
Mail list logo
