On Thu, Mar 2, 2023 at 2:28 PM Richard Biener wrote:
>
> The following puts a hard limit on the inherently quadratic STV chain
> discovery. Without a limit for the compiler.i testcase in PR26854
> we see at -O2
>
> machine dep reorg : 574.45 ( 53%)
>
> with release checking
Please don't use the same title for all the patches. This will puzzle
people running "git log" once they are committed.
And when you send 01-07, use "reply" instead of "new" so they will show
up in the correct location in a mail client. Or use git send-email
which is much eaiser to use.
On
This patch adds tests for autovectorization of integer add and subtract.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec: New directory
for autovectorization tests.
* gcc.target/riscv/rvv/autovec/loop-add-rv32.c: New
test to verify code generation of vector add on rv32.
This patch adds patterns that provide basic autovectorization support
for integer adds and subtracts.
gcc/ChangeLog:
* config/riscv/riscv.md (riscv_classify_vlmul_field):
New external declaration.
(riscv_vector_preferred_simd_mode): Include
vector-iterators.md.
*
This patch adds support for registering target hooks for basic
autovectorization support as well as basic tuning information for the
vector extension.
gcc/ChangeLog:
* config/riscv/riscv-cores.def (RISCV_TUNE):
Add VECTOR_TUNE_INFO parameter and
*
This patch adds support for functions used in implementing various
portions of autovectorization support.
gcc/ChangeLog:
* config/riscv/riscv-v.cc (riscv_classify_vlmul_field):
New function.
(riscv_vector_preferred_simd_mode): Ditto.
(get_mask_policy_no_pred): Ditto.
This patches adds two new files to support the vector cost model and
modifies the Makefile fragment to build the cost model c++ file. Due to
the large size this patch is provided as an attachment.
gcc/ChangeLog:
* gcc/config.gcc (riscv-vector-cost.o): New object file to build.
*
This patch adds foundational support by making two functions that handle
predication policies visibly globally.
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins.cc (get_tail_policy_for_pred):
Remove static declaration to to make externally visible.
(get_mask_policy_for_pred):
This patch adds foundational support in the form of:
1. New predicates
2. New function prototypes
3. Exporting emit_vlmax_vsetvl to global scope
4. Add a new command line option -mriscv_vector_lmul
gcc/ChangeLog:
* config/riscv/riscv-protos.h (riscv_classify_vlmul_field):
New
This series of patches adds foundational support for RISC-V
autovectorization. These patches are based on the current upstream rvv
vector intrinsic support and is not a new implementation. Most of the
implementation consists of adding the new vector cost model, the
autovectorization patterns
On Fri, 2023-03-03 at 10:12 +0800, Yujie Yang wrote:
> However, "loongarch64" is defined to include the "fpu64" ISA module[1]
> (i.e. enable "-mfpu=64" when -mfpu is not explicitly used). So I believe
> the above behavior you observed is expected.
Ah this make things much simpler and aligns with
Got it. Thank you and very appreciate for your help and patient. Updated the
PATCH to below link.
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613257.html
Pan
-Original Message-
From: Richard Sandiford
Sent: Friday, March 3, 2023 1:55 AM
To: Li, Pan2
Cc:
From: Pan Li
Fix the bug of the rvv bool mode precision with the adjustment.
The bits size of vbool*_t will be adjusted to
[1, 2, 4, 8, 16, 32, 64] according to the rvv spec 1.0 isa. The
adjusted mode precison of vbool*_t will help underlying pass to
make
On Fri, Mar 03, 2023 at 12:01:22AM +0800, Xi Ruoyao via Gcc-patches wrote:
> But then it causes "-mabi=lp64s -march=loongarch64" to generate code like:
>
> movgr2fr.d $fa0, $a0
> frecip.d $fa0, $fa0
> movfr2gr.d $a0, $fa0
>
> The problem here is "loongarch64" is never strictly defined.
Hi,
When comparing two vectors, the type of vector was used as the result of
the condition result. This meant that for floating point comparisons,
each value would either be `0.0' or `-1.0' reinterpreted as an integer,
not the expected integral bitmask values `0' and `-1'.
Instead, use the
Hi,
This patch fixes an ICE in the D front-end when importing an immutable
struct. Const and immutable types are built as variants of the type
they are derived from, and TYPE_STUB_DECL is not set for these variants.
Bootstrapped and regression tested on x86_64-linux-gnu/-m32, committed
to
Hi,
Vector equality and comparisons are now accepted by the language
implementation, but identity wasn't. This patch implements it as an
extra integer comparison of the bit-casted bitmask.
Bootstrapped and regression tested on x86_64-linux-gnu/-m32, and
committed to mainline.
Regards,
Iain.
Hi,
This patch adds the test for checking PR108167. The D front-end
implementation got fixed in upstream, add test to the gdc testsuite to
check we don't regress on it.
Regression tested on x86_64-linux-gnu/-m32, and committed to mainline.
Regards,
Iain.
---
PR d/108167
Ping.
Qing
> On Feb 24, 2023, at 1:35 PM, Qing Zhao wrote:
>
> on a structure with a C99 flexible array member being nested in
> another structure.
>
> "GCC extension accepts a structure containing an ISO C99 "flexible array
> member", or a union containing such a structure (possibly
Ping.
Qing
> On Feb 24, 2023, at 1:35 PM, Qing Zhao wrote:
>
> GCC extension accepts the case when a struct with a C99 flexible array member
> is embedded into another struct or union (possibly recursively).
> __builtin_object_size should treat such struct as flexible size.
>
>
Ping
Qing
> On Feb 24, 2023, at 1:35 PM, Qing Zhao wrote:
>
> Hi, Joseph and Richard,
>
> Could you please review this patch and let me know whether it’s ready
> for committing into GCC13?
>
> The fix to Bug PR101832 is an important patch for kernel security
> purpose. it's better to be put
On Thu, Mar 02, 2023 at 01:43:30PM +, Jonathan Yong via Gcc-patches wrote:
> On 3/2/23 10:46, Richard Sandiford wrote:
> > > diff --git a/gcc/testsuite/gcc.dg/memchr-3.c
> > > b/gcc/testsuite/gcc.dg/memchr-3.c
> > > index c38d9cf3349..af1b26ef3ae 100644
> > > ---
The PR complains that we do not handle UTF-8 in the suffix for a user-defined
literal, such as:
bool operator ""_π (unsigned long long);
In fact we don't handle any extended identifier characters there, whether
UTF-8, UCNs, or the $ sign. We do handle it fine if the optional space after
the ""
On Fri, Mar 03, 2023 at 12:05:09AM +0100, Gerald Pfeifer wrote:
> On Thu, 2 Mar 2023, Jakub Jelinek wrote:
> > +
> > +#include
>
> Oops, in HTML we need to spell "<" as "" and ">" as " - otherwise
> the above would be seen as a tag by the name of stdlib.h. ;-)
>
> I pushed the follow-up patch
On Thu, 2 Mar 2023, Jakub Jelinek wrote:
> +
> +#include
Oops, in HTML we need to spell "<" as "" and ">" as " - otherwise
the above would be seen as a tag by the name of stdlib.h. ;-)
I pushed the follow-up patch below.
Gerald
commit 935fcdebfb2fb4dcd89edb51ebed5f1be0fb41e5
Author: Gerald
On Linux/x86_64,
62a8d31ecc07041af4a81353c2d57d9845c4b771 is the first bad commit
commit 62a8d31ecc07041af4a81353c2d57d9845c4b771
Author: Jonathan Yong <10wa...@gmail.com>
Date: Mon Feb 27 10:02:32 2023 +
gcc.dg/memchr-3.c: Account for LLP64 warnings
caused
FAIL: gcc.dg/memchr-3.c
On Thu, 2023-03-02 at 23:35 +0100, Guillaume Gomez wrote:
> I don't have push rights so if you could push it, it'd be super
> appreciated!
Done, as r13-6425-g6b432c0f777ab9; I took the liberty of slightly
tweaking the subject line to add a "jit, testsuite: " prefix.
Thanks again for the patch
This patch is second in importance after the first patch in the series. It is
needed to allow complex IBM 128-bit multiply/divide when long double is IEEE
128-bit.
| Date: Fri, 3 Feb 2023 00:53:05 -0500
| From: Michael Meissner
| Subject: [PATCH 2/2] Rework 128-bit complex multiply and divide.
This is the most important patch. It is needed to allow the boostrap to work
again when long double is IEEE 128-bit.
| Date: Fri, 3 Feb 2023 00:49:12 -0500
| From: Michael Meissner
| Subject: [PATCH 1/2] PR target/107299: Fix build issue when long double is
IEEE 128-bit
| Message-ID:
--
I don't have push rights so if you could push it, it'd be super appreciated!
Le jeu. 2 mars 2023 à 23:33, David Malcolm a écrit :
> On Thu, 2023-03-02 at 23:29 +0100, Guillaume Gomez wrote:
> > Just realized I used whitespace and not a tab. Sorry about that.
> > Here's the
> > fixed version...
On Thu, 2023-03-02 at 23:29 +0100, Guillaume Gomez wrote:
> Just realized I used whitespace and not a tab. Sorry about that.
> Here's the
> fixed version...
Looks great. Do you have push rights, or do you want me to push this?
Thanks
Dave
>
> Le jeu. 2 mars 2023 à 23:19, Guillaume Gomez
> a
Just realized I used whitespace and not a tab. Sorry about that. Here's the
fixed version...
Le jeu. 2 mars 2023 à 23:19, Guillaume Gomez a
écrit :
> No problem, thanks for the explanations.
>
> I joined the patch with the fixed commit message.
>
> Le jeu. 2 mars 2023 à 22:58, David Malcolm a
The following patch is for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706
The patch was successfully bootstrapped and tested on i686, x86-64,
aarch64, ppc64le.
commit 23661e39df76e07fb4ce1ea015379c7601d947ef
Author: Vladimir N. Makarov
Date: Thu Mar 2 16:29:05 2023 -0500
IRA: Use
No problem, thanks for the explanations.
I joined the patch with the fixed commit message.
Le jeu. 2 mars 2023 à 22:58, David Malcolm a écrit :
> On Thu, 2022-12-15 at 08:34 +0100, Guillaume Gomez via Jit wrote:
> > Forgot it indeed, thanks for notifying me!
> >
> > I modified the commit
Dear all,
the attached patch fixes a long-standing issue with CLASS attributes
when a declaration is scattered over multiple statements.
The major part ("draft") of the patch is by Tobias, which I took up
before it started to bit-rot too much, see PR. It is mainly about
a proper updating and
On Thu, 2022-12-15 at 08:34 +0100, Guillaume Gomez via Jit wrote:
> Forgot it indeed, thanks for notifying me!
>
> I modified the commit message to add it and added it into this email.
Sorry about the delay in reviewing this; for some reason I didn't see
the mail.
The patch looks good for
On Wed, Mar 01, 2023 at 04:53:23PM -0500, Jason Merrill wrote:
> > @@ -13791,12 +13830,39 @@ std_pair_ref_ref_p (tree t)
> >const int& y = (f(1), 42); // NULL_TREE
> >const int& z = f(f(1)); // f(f(1))
> > - EXPR is the initializer. */
> > + EXPR is the initializer. If ARG_P
Pushed to wwwdocs.
---
htdocs/gcc-13/porting_to.html | 60 +++
1 file changed, 60 insertions(+)
diff --git a/htdocs/gcc-13/porting_to.html b/htdocs/gcc-13/porting_to.html
index 5cbeefb6..f0ccef69 100644
--- a/htdocs/gcc-13/porting_to.html
+++
Hi!
On Wed, Dec 14, 2022 at 03:29:02PM -0500, Michael Meissner wrote:
> These 3 patches fix the problems with building GCC on PowerPC systems when
> long
> double is configured to use the IEEE 128-bit format.
If you are strictly trying to fix a bootstrap problem, you should say
so: it should be
Ping David.
Le lun. 16 janv. 2023 à 15:08, Guillaume Gomez
a écrit :
> Ping David.
>
> Le jeu. 5 janv. 2023 à 23:37, Guillaume Gomez
> a écrit :
>
>> Ping David.
>>
>> Le sam. 24 déc. 2022 à 21:01, Guillaume Gomez
>> a écrit :
>>
>>> Ping David
>>>
>>> Le jeu. 15 déc. 2022 à 11:34, Guillaume
This is a proposal to fix PR71850 by applying the existing logic for
passing include paths to cc1 to as.
Thanks,
Costas
From 393aff0d006ee9372cc8b9321c612c2dfb4b0a31 Mon Sep 17 00:00:00 2001
From: Costas Argyris
Date: Thu, 2 Mar 2023 18:27:22 +
Subject: [PATCH] driver: Treat include path
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-6420-g20bd258d0fa098.
gcc/analyzer/ChangeLog:
PR analyzer/108968
* region-model.cc (region_model::get_rvalue_1): Handle VAR_DECLs
with a DECL_HARD_REGISTER by returning UNKNOWN.
Hi,
this patch changes SLP test expectations. As we only vectorize when no
more than one rgroup is present, no vectorization is performed.
I was also considering using a separate target selector (something like
vect_partial_vectors_bias_m1) but as the number of testcases is limited
that would
Hi,
When compiling on a system where binutils do not yet support the 'z16'
name assembling fails with -march=native which we currently interpret
as -march=z16 (on a z16 machine). This patch uses -march=arch14
instead.
Is it OK?
Regards
Robin
--
gcc/ChangeLog:
*
Hi,
we seem to flip flop between the "high" and "not low" variants of load on
condition. Accept both in the affected test cases.
Going to commit this as obvious.
Regards
Robin
--
gcc/testsuite/ChangeLog:
* gcc.target/s390/ifcvt-two-insns-bool.c: Allow "high" and
"not low or
On Feb 27, 2023, at 5:54 PM, Hans-Peter Nilsson via Gcc-patches
wrote:
>
> Ping...
Ok.
>
>> From: Hans-Peter Nilsson
>> Date: Thu, 16 Feb 2023 21:05:29 +0100
>
>> Asking for the lines outside the "#if __CRIS__" part.
>> Ok to commit?
>>
>> -- >8 --
>> tm.texi says for BIGGEST_ALIGNMENT
"Li, Pan2" writes:
> Oops, looks I missed that part for assertion. Thank you for coaching.
> Added and tested the below changes at the end of emit_mode_adjustments
> already but looks we may have other problems about the size, the precision
> and the C types.
>
> Looks like I need to hold this
On 02/03/2023 15:07, Kwok Cheung Yeung wrote:
Hello
I've made the suggested changes. Should I hold off on committing this
until GCC 13 has been branched off?
No need, amdgcn is not a primary target and this stuff won't affect
anyone else. Please go ahead and commit.
Andrew
On 01/03/2023 16:56, Paul-Antoine Arras wrote:
This patch introduces instruction patterns for conditional min and max
operations (cond_{f|s|u}{max|min}) in the GCN machine description. It
also allows the exec register to be saved in SGPRs to avoid spilling to
memory.
Tested on GCN3 Fiji
On 2/9/23 03:41, Jakub Jelinek wrote:
Hi!
Before IMPORTED_DECL has been introduced in PR37410, we used to emit correct
DW_AT_decl_line on DW_TAG_imported_module on the testcase below, after that
change we haven't emitted it at all for a while and after some time
started emitting incorrect
On 2/9/23 11:14, Jakub Jelinek wrote:
Hi!
The stmtexpr19.C testcase used to be rejected as it has a static
variable in statement expression in constexpr context, but as that
static variable is initialized by constant expression, when P2647R1
was implemented we agreed to make it valid.
Now, as
On 2/21/23 14:10, Patrick Palka wrote:
We should also fold the overall initializer passed to cp_fully_fold_init
with mce_false, which enables folding of the copy-initialization of
'a1' in the below testcase (the initializer here is an AGGR_INIT_EXPR).
Unfortunately this doesn't help with
On 2/21/23 15:18, Patrick Palka wrote:
On Mon, 20 Feb 2023, Patrick Palka wrote:
According to [basic.start.static]/2 and [expr.const]/2, a variable
with static storage duration initialized with a constant initializer
has constant initialization, and such an initializer is manifestly
On 3/2/23 06:20, Jakub Jelinek wrote:
Hi!
On Wed, Mar 01, 2023 at 05:50:47PM -0500, Jason Merrill wrote:
And then there is a question whether we want to emit rtti for
_Float{16,32,64,128}, _Float{32,64,128}x and decltype(0.0bf16) regardless
of whether the target supports them at all or not.
In the toolchain convention, we describe -mfpu= as:
"Selects the allowed set of basic floating-point instructions and
registers. This option should not change the FP calling convention
unless it's necessary."
Though not explicitly stated, the rationale of this rule is to allow
combinations like
On 3/1/23 17:33, Marek Polacek wrote:
On Wed, Mar 01, 2023 at 04:44:12PM -0500, Jason Merrill wrote:
On 3/1/23 16:40, Marek Polacek wrote:
On Wed, Mar 01, 2023 at 04:30:16PM -0500, Jason Merrill wrote:
On 3/1/23 15:33, Marek Polacek wrote:
-Wmismatched-tags warns about the (harmless)
> Am 02.03.2023 um 15:28 schrieb Richard Sandiford via Gcc-patches
> :
>
> The loop body in the testcase contains an operation on invariants.
> SLP detects this and can hoist/schedule the operation outside of
> the loop. However, after the fix for PR96373, we would try to
> apply a loop
This is a follow-up to commit a4c6bd0821099f6b8c0f64a96ffd9d01a025c413
introducing a runtime check for alignment for 16 byte atomic
compare-exchange, load, and store.
Bootstrapped and regtested on s390.
Ok for mainline and gcc-{12,11,10}?
libatomic/ChangeLog:
* config/s390/cas_n.c: New
Hello
I've made the suggested changes. Should I hold off on committing this
until GCC 13 has been branched off?
Kwok
On 01/03/2023 10:01 am, Andrew Stubbs wrote:
On 28/02/2023 23:01, Kwok Cheung Yeung wrote:
Hello
This patch implements the TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION
Oops, looks I missed that part for assertion. Thank you for coaching.
Added and tested the below changes at the end of emit_mode_adjustments already
but looks we may have other problems about the size, the precision and the C
types.
Looks like I need to hold this PATCH for a while until we have
The loop body in the testcase contains an operation on invariants.
SLP detects this and can hoist/schedule the operation outside of
the loop. However, after the fix for PR96373, we would try to
apply a loop mask to this operation, even though the mask is
defined in the loop.
The patch does what
Committed attached patch.
On 02/03/2023 10:13, Richard Sandiford wrote:
"Andre Vieira (lists)" writes:
Hey both,
Sorry about that, don't know how I missed those. Just running a test on
that now and will commit when it's done. I assume the comment and 0 ->
byte change can be seen as obvious,
Thanks for the review.
What is the next step please?
Thanks,
Costas
On Thu, 2 Mar 2023 at 10:08, Richard Biener
wrote:
> On Thu, Mar 2, 2023 at 10:21 AM Costas Argyris
> wrote:
> >
> > I forgot to mention that:
> >
> > 1) The CreateProcess documentation
> >
> >
>
Jonathan Yong <10wa...@gmail.com> writes:
> On 3/2/23 10:44, Richard Sandiford wrote:
>>> diff --git a/gcc/testsuite/gcc.dg/overflow-warn-9.c
>>> b/gcc/testsuite/gcc.dg/overflow-warn-9.c
>>> index 57c0f17bc91..ae588bd8491 100644
>>> --- a/gcc/testsuite/gcc.dg/overflow-warn-9.c
>>> +++
On 3/2/23 10:46, Richard Sandiford wrote:
diff --git a/gcc/testsuite/gcc.dg/memchr-3.c b/gcc/testsuite/gcc.dg/memchr-3.c
index c38d9cf3349..af1b26ef3ae 100644
--- a/gcc/testsuite/gcc.dg/memchr-3.c
+++ b/gcc/testsuite/gcc.dg/memchr-3.c
@@ -6,7 +6,7 @@
typedef __INT8_TYPE__ int8_t;
typedef
On 3/2/23 10:44, Richard Sandiford wrote:
diff --git a/gcc/testsuite/gcc.dg/overflow-warn-9.c
b/gcc/testsuite/gcc.dg/overflow-warn-9.c
index 57c0f17bc91..ae588bd8491 100644
--- a/gcc/testsuite/gcc.dg/overflow-warn-9.c
+++ b/gcc/testsuite/gcc.dg/overflow-warn-9.c
@@ -59,7 +59,8 @@ const struct
On Thu, Mar 02, 2023 at 12:46:42PM +0100, Jakub Jelinek wrote:
> Hi!
>
> Tobias mentioned on IRC that assume attribute wasn't mentioned in
> changes.html. The P1774R8 entry was missing for C++, so I went through
> projects/cxx-status.html#cxx23 and filled in all the missing papers
> which have
The following puts a hard limit on the inherently quadratic STV chain
discovery. Without a limit for the compiler.i testcase in PR26854
we see at -O2
machine dep reorg : 574.45 ( 53%)
with release checking while with the proposed limit it's
machine dep reorg
On 3/2/23 02:43, Richard Biener wrote:
On Wed, 1 Mar 2023, Jason Merrill wrote:
On 3/1/23 08:09, Jakub Jelinek wrote:
On Wed, Mar 01, 2023 at 01:07:02PM +, Richard Biener wrote:
When combining -g1 with -flto we run into the DIE location annotation
machinery for globals calling
On 3/2/23 11:32, Jakub Jelinek wrote:
> Hi!
>
> On Fri, Feb 10, 2023 at 10:06:03AM +0100, Gerald Pfeifer wrote:
>> Yes, thank you! Two minor suggestions/questions below:
>>
>>> --- a/htdocs/gcc-13/changes.html
>>> +++ b/htdocs/gcc-13/changes.html
>>> + -fexcess-precision=fast. The option
Hi!
Tobias mentioned on IRC that assume attribute wasn't mentioned in
changes.html. The P1774R8 entry was missing for C++, so I went through
projects/cxx-status.html#cxx23 and filled in all the missing papers
which have been implemented newly in GCC 13, plus a small note for C family
about
Hi!
On Wed, Mar 01, 2023 at 05:50:47PM -0500, Jason Merrill wrote:
> > And then there is a question whether we want to emit rtti for
> > _Float{16,32,64,128}, _Float{32,64,128}x and decltype(0.0bf16) regardless
> > of whether the target supports them at all or not.
> > Emitting them always would
Jonathan Yong <10wa...@gmail.com> writes:
> On 2/27/23 16:55, Richard Sandiford wrote:
>> Jonathan Yong via Gcc-patches writes:
>>> Attached patch OK?
>>>
>>> gcc.dg/memchr-3.c: fix for LLP64
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> PR middle-end/97956
>>>
On Thu, Mar 2, 2023 at 11:22 AM Xionghu Luo wrote:
>
>
>
> On 2023/3/2 16:41, Richard Biener wrote:
> > On Thu, Mar 2, 2023 at 3:31 AM Xionghu Luo via Gcc-patches
> > wrote:
> >>
> >> When spliting edge with self loop, the split edge should be placed just
> >> next to
> >> the edge_in->src,
Jonathan Yong via Gcc-patches writes:
> On 2/28/23 03:06, Hans-Peter Nilsson wrote:
>>
>> On Mon, 27 Feb 2023, Jonathan Yong via Gcc-patches wrote:
>>
>>> This test is for LP64 only, exclude LLP64 too.
>>> Patch OK?
>>
>> I may be confused, but you're not making use of the "llp64"
>> effective
On Thu, 2 Mar 2023 at 05:40, François Dumont via Libstdc++
wrote:
>
> Just forget about this patch, bad idea.
>
> The key_type might have additional data not used for the comparison.
> This data would not be preserved if we were inserting the already stored
> equivalent key instead of the user
"Xin Liu" writes:
> From: Robert Suchanek
>
> gcc/ChangeLog:
>
>* config/mips/mips.cc (mips_set_text_contents_type): Modified parameter
>* config/mips/mips-protos.h (mips_set_text_contents_type): Likewise
>
> Signed-off-by: Xin Liu
Thanks, pushed to trunk. I guess this is a
"Junxian Zhu" writes:
> From: Junxian Zhu
>
> Add buildtime option to decide whether will compiler build with `-mmsa`
> option default.
>
> gcc/ChangeLog:
> * config.gcc: add -with-{no-}msa build option.
> * config/mips/mips.h: Likewise.
> * doc/install.texi: Likewise.
Hi!
On Fri, Feb 10, 2023 at 10:06:03AM +0100, Gerald Pfeifer wrote:
> Yes, thank you! Two minor suggestions/questions below:
>
> > --- a/htdocs/gcc-13/changes.html
> > +++ b/htdocs/gcc-13/changes.html
> > + -fexcess-precision=fast. The option affects mainly
>
> Here I'd say "mainly
On Thu, Mar 2, 2023 at 11:21 AM Richard Sandiford via Gcc-patches
wrote:
>
> convert_memory_address_addr_space_1 has two modes: one in which it
> tries to create a self-contained RTL expression (which might fail)
> and one in which it can emit new instructions where necessary.
>
> When handling a
Xi Ruoyao writes:
> Hi,
>
> This patch series fixes a lot of test failures with --enable-default-pie
> or --enable-default-ssp for AArch64 target. Only test files are changed
> to disable PIE or SSP to satisify the expectation of the developer who
> programmed the test.
>
> Bootstrapped and
On Thu, Mar 2, 2023 at 11:19 AM Richard Sandiford via Gcc-patches
wrote:
>
> vectorizable_condition checks whether a COND_EXPR condition is used
> elsewhere with a loop mask. If so, it applies the loop mask to the
> COND_EXPR too, to reduce the number of live masks and to increase the
> chance
On 2023/3/2 16:41, Richard Biener wrote:
On Thu, Mar 2, 2023 at 3:31 AM Xionghu Luo via Gcc-patches
wrote:
When spliting edge with self loop, the split edge should be placed just next to
the edge_in->src, otherwise it may generate different position latch bbs for
two consecutive self
convert_memory_address_addr_space_1 has two modes: one in which it
tries to create a self-contained RTL expression (which might fail)
and one in which it can emit new instructions where necessary.
When handling a CONST, the function recurses into the CONST's
operand and then constifies the
>> I realise it's a corner case. But I don't think making GET_MODE_SIZE
>>bigger than the real size is conservatively correct.
I don't understand which corner case will riscks wrong code.
Would you mind giving me some examples?
VNx8BI ABI size is the same as machine size.
The only inconsistency
vectorizable_condition checks whether a COND_EXPR condition is used
elsewhere with a loop mask. If so, it applies the loop mask to the
COND_EXPR too, to reduce the number of live masks and to increase the
chance of combining the AND with the comparison.
There is also code to do this for inverted
"Andre Vieira (lists)" writes:
> Hey both,
>
> Sorry about that, don't know how I missed those. Just running a test on
> that now and will commit when it's done. I assume the comment and 0 ->
> byte change can be seen as obvious, especially since it was supposed to
> be in my original patch...
On Thu, Mar 2, 2023 at 10:21 AM Costas Argyris wrote:
>
> I forgot to mention that:
>
> 1) The CreateProcess documentation
>
> https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa
>
> doesn't mention anything about taking ownership of this or
Hey both,
Sorry about that, don't know how I missed those. Just running a test on
that now and will commit when it's done. I assume the comment and 0 ->
byte change can be seen as obvious, especially since it was supposed to
be in my original patch...
On 27/02/2023 15:46, Richard Sandiford
On Thu, 2 Mar 2023, Xionghu Luo wrote:
>
>
> On 2023/3/2 16:16, Richard Biener wrote:
> > On Thu, Mar 2, 2023 at 3:31 AM Xionghu Luo via Gcc-patches
> > wrote:
> >>
> >> For case like belowi test.c:
> >>
> >> 1:int foo(char c)
> >> 2:{
> >> 3: return ((c >= 'A' && c <= 'Z')
> >> 4: ||
Hi,
Gentle ping:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609396.html
Thanks for comments and suggestions!
I'm thinking that we may use these patches to fix some of the issues
on parm and returns.
Sorry for the late ping for this patch to ask if this is acceptable.
BR,
Jeff
On 2023/3/2 16:16, Richard Biener wrote:
On Thu, Mar 2, 2023 at 3:31 AM Xionghu Luo via Gcc-patches
wrote:
For case like belowi test.c:
1:int foo(char c)
2:{
3: return ((c >= 'A' && c <= 'Z')
4: || (c >= 'a' && c <= 'z')
5: || (c >= '0' && c <='0'));}
the generated line
pan2...@intel.com writes:
> From: Pan Li
>
> Fix the bug of the rvv bool mode precision with the adjustment.
> The bits size of vbool*_t will be adjusted to
> [1, 2, 4, 8, 16, 32, 64] according to the rvv spec 1.0 isa. The
> adjusted mode precison of vbool*_t will help
Thanks for the explanation about the sizes.
"juzhe.zh...@rivai.ai" writes:
> Fortunately, we won't have aggregates, arrays of vbool*_t in the future.
> I think it's not an issue.
But isn't it possible to allocate a char/byte array and construct
vbool*_ts at addresses calculated by intrinsics?
Hi,
Ping this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609394.html
Thanks for any comments and suggestions!
BR,
Jeff (Jiufu)
Jiufu Guo writes:
> Hi,
>
> When assigning a parameter to a variable, or assigning a variable to
> return value with struct type, "block move"
I forgot to mention that:
1) The CreateProcess documentation
https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa
doesn't mention anything about taking ownership of this or any other buffer
passed to it.
2) The cmdline buffer gets created by
On Thu, Mar 2, 2023 at 3:31 AM Xionghu Luo via Gcc-patches
wrote:
>
> When spliting edge with self loop, the split edge should be placed just next
> to
> the edge_in->src, otherwise it may generate different position latch bbs for
> two consecutive self loops. For details, please refer to:
>
Fortunately, we won't have aggregates, arrays of vbool*_t in the future.
I think it's not an issue.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-03-02 16:25
To: juzhe.zhong
CC: richard.sandiford; pan2.li; gcc-patches; Pan Li; kito.cheng
Subject: Re: Re: [PATCH] RISC-V: Bugfix for rvv
From: Christoph Müllner
The XTheadMemPair ISA extension allows to pair two loads or stores:
* th.ldd (2x LD)
* th.lwd (2x LW)
* th.lwud (2x LWU)
* th.sdd (2x SD)
* th.swd (2x SW)
The displacement of these instructions is quite limited:
* Displacement := imm2 << shamt
* imm2 is a 2-bit unsigned
From: Christoph Müllner
The XTheadMac ISA extension provides multiply-accumulate/subtract
instructions:
* mula/mulaw/mulah
* muls/mulsw/mulsh
To benefit from middle-end passes, we expand the following named
patterns in riscv.md (as they are not T-Head-specific):
* maddhisi4
* msubhisi4
1 - 100 of 114 matches
Mail list logo
