On Fri, 11 Aug 2023, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> Hi, Richard and Richi.
>
> This patch add support live vectorization by VEC_EXTRACT for LEN loop control.
>
> Consider this following case:
>
> #include
>
> #define EXTRACT_LAST(TYPE)\
> TYPE __a
From: Pan Li
This patch would like to support the rounding mode API for the
VFMADD as the below samples.
* __riscv_vfmadd_vv_f32m1_rm
* __riscv_vfmadd_vv_f32m1_rm_m
* __riscv_vfmadd_vf_f32m1_rm
* __riscv_vfmadd_vf_f32m1_rm_m
Signed-off-by: Pan Li
gcc/ChangeLog:
* config/riscv/riscv-v
Hi, Richi.
>> So how can we resolve the issue when a non-VL operation like
>> .VEC_EXTRACT is used for _len support?
Do you mean non-VL extract last operation (I am sorry that not sure whether I
understand your question correctly)?
If yes, the answer is for RVV, we are reusing the same flow as
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-11 13:54
To: gcc-patches
CC: juzhe.zhong; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support RVV VFNMSAC rounding mode intrinsic API
From: Pan Li
This patch would like to support the rounding mode API for
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-11 15:17
To: gcc-patches
CC: juzhe.zhong; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support RVV VFMADD rounding mode intrinsic API
From: Pan Li
This patch would like to support the rounding mode API for
On Thu, Aug 10, 2023 at 5:43 PM Jakub Jelinek wrote:
>
> Hi!
>
> On Thu, Aug 10, 2023 at 12:28:24PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > On Tue, Aug 08, 2023 at 03:18:51PM +0200, Richard Biener via Gcc-patches
> > wrote:
> > > On Fri, Aug 4, 2023 at 11:49 PM Drew Ross via Gcc-patches
>
Committed, thanks Juzhe.
Pan
From: juzhe.zh...@rivai.ai
Sent: Friday, August 11, 2023 3:30 PM
To: Li, Pan2 ; gcc-patches
Cc: jeffreyalaw ; Li, Pan2 ; Wang,
Yanzhang ; kito.cheng
Subject: Re: [PATCH v1] RISC-V: Support RVV VFMADD rounding mode intrinsic API
LGTM
_
Committed, thanks Juzhe.
Pan
From: juzhe.zh...@rivai.ai
Sent: Friday, August 11, 2023 3:30 PM
To: Li, Pan2 ; gcc-patches
Cc: jeffreyalaw ; Li, Pan2 ; Wang,
Yanzhang ; kito.cheng
Subject: Re: [PATCH v1] RISC-V: Support RVV VFNMSAC rounding mode intrinsic API
LGTM
On Fri, 11 Aug 2023, 06:44 François Dumont via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> I hadn't tested the most basic default configuration and it is failing,
I did wonder about that when you said which configurations you had tested :)
> I need some more time yet.
>
OK, no problem.
I
On Thu, 10 Aug 2023 at 20:52, Andrew Pinski wrote:
> On Thu, Aug 10, 2023 at 6:39 AM Christophe Lyon via Gcc-patches
> wrote:
> >
> > Hi Andrew,
> >
> >
> > On Wed, 9 Aug 2023 at 21:20, Andrew Pinski via Gcc-patches <
> > gcc-patches@gcc.gnu.org> wrote:
> >
> > > This adds a simple match pattern
On Thu, Aug 10, 2023 at 10:31:12PM +, Joseph Myers wrote:
> > The following patch (on top of the stdckdint.h patch and _BitInt patch
> > series) adds a test for _BitInt diagnostics of ckd_{add,sub,mul} macros.
>
> I remain unconvinced that diagnosing use with types where it's clear what
> the
Hello,
I ran into a bug recently, running dg-cmp-results.sh with variant
unix/-m32. This fixes it.
OK for master?
-- >8 --
Escape slash characters in $header variable (coming from the variant
argument). This avoids runs with say "unix/-m32" as variant resulting
in sed errors "unknown command:
From: Pan Li
This patch would like to support the rounding mode API for the
VFNMADD as the below samples.
* __riscv_vfnmadd_vv_f32m1_rm
* __riscv_vfnmadd_vv_f32m1_rm_m
* __riscv_vfnmadd_vf_f32m1_rm
* __riscv_vfnmadd_vf_f32m1_rm_m
Signed-off-by: Pan Li
gcc/ChangeLog:
* config/riscv/ri
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-11 16:11
To: gcc-patches
CC: juzhe.zhong; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support RVV VFNMADD rounding mode intrinsic API
From: Pan Li
This patch would like to support the rounding mode API fo
Committed, thanks Juzhe.
Pan
From: juzhe.zh...@rivai.ai
Sent: Friday, August 11, 2023 4:12 PM
To: Li, Pan2 ; gcc-patches
Cc: jeffreyalaw ; Li, Pan2 ; Wang,
Yanzhang ; kito.cheng
Subject: Re: [PATCH v1] RISC-V: Support RVV VFNMADD rounding mode intrinsic API
LGTM
This patch fix bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110985
PR target/110985
gcc/ChangeLog:
* config/riscv/riscv-v.cc (expand_vec_series): Refactor the expander.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vls-vlmax/pr110985.c: New test.
---
gc
On Fri, Aug 11, 2023 at 01:13:32AM +0200, Jakub Jelinek wrote:
> Looking at the first uses of the builtin back in 90s in va*.h, it certainly
> relied on array/function decay there (the macros would abort e.g. on
> array_type_class, function_type_class and various other return values).
> Looking at
Hi,
This patch revert the convert from vmv.s.x to vmv.v.i and add new pattern
optimize the special case when the scalar operand is zero.
Currently, the broadcast pattern where the scalar operand is a imm
will be converted to vmv.v.i from vmv.s.x and the mask operand will be
converted from 00..01
From: Tsukasa OI
Commit c283c4774d1c ("RISC-V: Throw compilation error for unknown
extensions") changed how do we handle unknown extensions and
commit 6f709f79c915a ("[committed] [RISC-V] Fix expected diagnostic messages
in testsuite") "fixed" test failures caused by that change (on pr102957.c,
b
So with my next VRP patch, VRP causes:
```
# c$_M_value_18 = PHI <-1(3), 0(2), 1(4)>
_11 = (unsigned int) c$_M_value_18;
_16 = _11 <= 1;
```
To be changed to:
```
# c$_M_value_18 = PHI <-1(3), 0(2), 1(4)>
_11 = (unsigned int) c$_M_value_18;
_16 = _11 != 4294967295;
```
So let's add sup
So it turns out there was a simplier way of starting to
improve VRP to start to fix PR 110131, PR 108360, and PR 108397.
That was rewrite test_for_singularity to use range_op_handler
and Value_Range.
This patch implements that and
OK? Bootstrapped and tested on x86_64-linux-gnu with no regression
On Fri, Aug 11, 2023 at 11:17 AM Andrew Pinski via Gcc-patches
wrote:
>
> So with my next VRP patch, VRP causes:
> ```
> # c$_M_value_18 = PHI <-1(3), 0(2), 1(4)>
> _11 = (unsigned int) c$_M_value_18;
> _16 = _11 <= 1;
> ```
> To be changed to:
> ```
> # c$_M_value_18 = PHI <-1(3), 0(2), 1
On Fri, Aug 11, 2023 at 11:17 AM Andrew Pinski via Gcc-patches
wrote:
>
> So it turns out there was a simplier way of starting to
> improve VRP to start to fix PR 110131, PR 108360, and PR 108397.
> That was rewrite test_for_singularity to use range_op_handler
> and Value_Range.
>
> This patch imp
This patch enables COSNT_VECTOR for VLS modes.
void foo1 (int * __restrict a)
{
for (int i = 0; i < 16; i++)
a[i] = 8;
}
void foo2 (int * __restrict a)
{
for (int i = 0; i < 16; i++)
a[i] = i;
}
Compile option: -O3 --param=riscv-autovec-preference=scalable
Before this patch:
LGTM
Juzhe-Zhong 於 2023年8月11日 週五 17:56 寫道：
> This patch enables COSNT_VECTOR for VLS modes.
>
> void foo1 (int * __restrict a)
> {
> for (int i = 0; i < 16; i++)
> a[i] = 8;
> }
>
> void foo2 (int * __restrict a)
> {
> for (int i = 0; i < 16; i++)
> a[i] = i;
> }
>
> Compile
From: Pan Li
This patch would like to support the rounding mode API for the
VFMSUB as the below samples.
* __riscv_vfmsub_vv_f32m1_rm
* __riscv_vfmsub_vv_f32m1_rm_m
* __riscv_vfmsub_vf_f32m1_rm
* __riscv_vfmsub_vf_f32m1_rm_m
Signed-off-by: Pan Li
gcc/ChangeLog:
* config/riscv/riscv-v
On Fri, 11 Aug 2023, juzhe.zh...@rivai.ai wrote:
> Hi, Richi.
>
> >> So how can we resolve the issue when a non-VL operation like
> >> .VEC_EXTRACT is used for _len support?
>
> Do you mean non-VL extract last operation (I am sorry that not sure whether I
> understand your question correctly)?
On Fri, 11 Aug 2023, Juzhe-Zhong wrote:
> This patch is add vec_mask_len_{load_lanes,store_stores} autovectorization
> patterns.
>
> Here we want to support this following autovectorization:
>
> #include
> void
> foo (int8_t *__restrict a,
> int8_t *__restrict b,
> int8_t *__restrict cond,
>
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-11 18:11
To: gcc-patches
CC: juzhe.zhong; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support RVV VFMSUB rounding mode intrinsic API
From: Pan Li
This patch would like to support the rounding mode API for
Committed, thanks Richard.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Richard Biener via Gcc-patches
Sent: Friday, August 11, 2023 6:23 PM
To: Juzhe-Zhong
Cc: gcc-patches@gcc.gnu.org; richard.sandif...@arm.com
Subject: Re: [PATCH] VECT: Add vec_mask_len_{load_lanes,store_lan
Hi, Richi.
> 1. Target is using loop MASK as the partial vector loop control.
>> I don't think it checks for this?
I am not sure whether I understand EXTRACT_LAST correctly.
But if target doesn't use loop MASK for partial vector loop control, how does
target use EXTRACT_LAST?
Since EXTRACT_LAST
Committed, thanks Juzhe.
Pan
From: juzhe.zh...@rivai.ai
Sent: Friday, August 11, 2023 6:24 PM
To: Li, Pan2 ; gcc-patches
Cc: jeffreyalaw ; Li, Pan2 ; Wang,
Yanzhang ; kito.cheng
Subject: Re: [PATCH v1] RISC-V: Support RVV VFMSUB rounding mode intrinsic API
LGTM
_
When we vectorize fold-left reductions with partial vectors but
no target operation available we use a vector conditional to force
excess elements to zero. But that doesn't correctly preserve
the sign of zero. The following patch disables partial vector
support in that case.
Bootstrap and regtes
The following makes us more correctly print the used vector size
when doing BB vectorization and also print all involved SLP graph
roots, not just the random one we ended up picking as leader.
In particular the last bit improves diffing opt-info between
different GCC revs but it also requires some
On Fri, 11 Aug 2023, juzhe.zh...@rivai.ai wrote:
> Hi, Richi.
>
> > 1. Target is using loop MASK as the partial vector loop control.
> >> I don't think it checks for this?
>
> I am not sure whether I understand EXTRACT_LAST correctly.
> But if target doesn't use loop MASK for partial vector loop
On Fri, 11 Aug 2023, Richard Biener wrote:
> When we vectorize fold-left reductions with partial vectors but
> no target operation available we use a vector conditional to force
> excess elements to zero. But that doesn't correctly preserve
> the sign of zero. The following patch disables part
Hi, Richi.
>> check here the target supports VEC_EXTRACT
>> else set LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P to false with a
>> diagnostic.
I am wondering target has VEC_EXTRACT but no EXTRACT_LAST, and such target is
using MASK as the loop control.
It seems that it will cause ICE for such target ?
Richard Biener writes:
> When we vectorize fold-left reductions with partial vectors but
> no target operation available we use a vector conditional to force
> excess elements to zero. But that doesn't correctly preserve
> the sign of zero. The following patch disables partial vector
> support i
From: benjamin priour
This patch introduces -fanalyzer-show-events-in-system-headers,
disabled by default.
This option reduce the noise of the analyzer emitted diagnostics
when dealing with system headers.
The new option only affects the display of the diagnostics,
but doesn't hinder the actual
This patch fixes bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110989
This ICE is caused because of this situation:
mask__49.21_99 = vect__17.19_96 == { 0.0, ... };
...
vect__6.24_107 = .MASK_LEN_LOAD (vectp.22_105, 32B, mask__49.21_99,
POLY_INT_CST [2, 2], 0);
The MASK_LEN_LOAD is using re
I forgot to mention that this has been successfully regstrapped off trunk
54be338589ea93ad4ff53d22adde476a0582537b on x86_64-linux-gnu.
Is it OK for trunk ?
Thanks,
Benjamin.
On Fri, 11 Aug 2023, Alexander Monakov wrote:
>
> On Fri, 11 Aug 2023, Richard Biener wrote:
>
> > When we vectorize fold-left reductions with partial vectors but
> > no target operation available we use a vector conditional to force
> > excess elements to zero. But that doesn't correctly prese
On Fri, 11 Aug 2023, Juzhe-Zhong wrote:
> This patch fixes bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110989
>
> This ICE is caused because of this situation:
>
> mask__49.21_99 = vect__17.19_96 == { 0.0, ... };
> ...
> vect__6.24_107 = .MASK_LEN_LOAD (vectp.22_105, 32B, mask__49.21_99,
On Fri, 11 Aug 2023, juzhe.zh...@rivai.ai wrote:
> Hi, Richi.
>
> >> check here the target supports VEC_EXTRACT
> >> else set LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P to false with a
> >> diagnostic.
>
> I am wondering target has VEC_EXTRACT but no EXTRACT_LAST, and such
> target is using MASK as t
When we vectorize fold-left reductions with partial vectors but
no target operation available we use a vector conditional to force
excess elements to zero. But that doesn't correctly preserve
the sign of zero. The following patch disables partial vector
support when we have to do that and also ne
Hi Martin,
On Fri, 4 Aug 2023 at 18:26, Martin Jambor wrote:
> Hello,
>
> On Wed, Aug 02 2023, Richard Biener wrote:
> > On Mon, Jul 31, 2023 at 7:05 PM Martin Jambor wrote:
> >>
> >> Hi,
> >>
> >> when IPA-SRA detects whether a parameter passed by reference is
> >> written to, it does not spe
Hi Jason,
Regarding the initialization example - no, the set of classes that we
consider cold is more loosely defined.
On Thu, Aug 10, 2023 at 11:01 PM Jason Merrill wrote:
> Yes, but that's because the implicit op== isn't declared lazily like
> some other special member functions (CLASSTYPE_LAZ
On 8/10/23 20:12, Jin Ma wrote:
My fault, I'm very sorry for not replying to the patch follow-up, I just
forgot this :)
No worries. We're tracking it in patchwork and it also overlaps with
some work we had internally at Ventana. So it was trivial to pick it up
once it was clear it'd fall
Richard Biener writes:
> On Fri, 11 Aug 2023, juzhe.zh...@rivai.ai wrote:
>
>> Hi, Richi.
>>
>> > 1. Target is using loop MASK as the partial vector loop control.
>> >> I don't think it checks for this?
>>
>> I am not sure whether I understand EXTRACT_LAST correctly.
>> But if target doesn't use
On Fri, 11 Aug 2023, Jakub Jelinek wrote:
> All that is diagnosed is when result is bool or enum (any kind). Even for
I'd suggest tests that other nonsense cases are diagnosed, such as
floating-point or pointer arguments or results (hopefully such cases are
already diagnosed and just need test
On 8/10/23 21:45, Palmer Dabbelt wrote:
OK, that seems like the way to go. I still think it's likely we'll need
to split up these types more, but that's something we can only deal with
when there's HW that behaves oddly.
Yea, but I think we can fault this in as problematic hardware arrive
On Fri, 11 Aug 2023, Richard Biener wrote:
> > I think it converts SNan to QNan (when the partial vector has just one
> > element which is SNan), so is a test for -fsignaling-nans missing?
>
> Hm, I guess that's a corner case that could happen when there's no
> runtime profitability check on mo
Hello,
On Fri, Aug 11 2023, Christophe Lyon wrote:
> Hi Martin,
>
>
> On Fri, 4 Aug 2023 at 18:26, Martin Jambor wrote:
>
>> Hello,
>>
>> On Wed, Aug 02 2023, Richard Biener wrote:
>> > On Mon, Jul 31, 2023 at 7:05 PM Martin Jambor wrote:
>> >>
>> >> Hi,
>> >>
>> >> when IPA-SRA detects whether
On Thu, 10 Aug 2023, Jason Merrill wrote:
> On 8/10/23 16:40, Patrick Palka wrote:
> > On Thu, 10 Aug 2023, Jason Merrill wrote:
> >
> > > On 8/10/23 12:09, Patrick Palka wrote:
> > > > Booststrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > > > for
> > > > trunk and perhaps 13?
This ICE is caused because of this situation:
mask__49.21_99 = vect__17.19_96 == { 0.0, ... };
...
vect__6.24_107 = .MASK_LEN_LOAD (vectp.22_105, 32B, mask__49.21_99,
POLY_INT_CST [2, 2], 0);
The MASK_LEN_LOAD is using real MASK which is produced by the EQ comparison
wheras the LEN
is the dummy
On Fri, 11 Aug 2023, Juzhe-Zhong wrote:
> This ICE is caused because of this situation:
>
> mask__49.21_99 = vect__17.19_96 == { 0.0, ... };
> ...
> vect__6.24_107 = .MASK_LEN_LOAD (vectp.22_105, 32B, mask__49.21_99,
> POLY_INT_CST [2, 2], 0);
>
> The MASK_LEN_LOAD is using real MASK which is p
On 8/11/23 03:51, Richard Biener via Gcc-patches wrote:
On Fri, Aug 11, 2023 at 11:17 AM Andrew Pinski via Gcc-patches
wrote:
So it turns out there was a simplier way of starting to
improve VRP to start to fix PR 110131, PR 108360, and PR 108397.
That was rewrite test_for_singularity to use
On 8/11/23 09:54, Patrick Palka wrote:
On Thu, 10 Aug 2023, Jason Merrill wrote:
On 8/10/23 16:40, Patrick Palka wrote:
On Thu, 10 Aug 2023, Jason Merrill wrote:
On 8/10/23 12:09, Patrick Palka wrote:
Booststrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for
trunk and perhap
As promised yesterday, this reverts the part of the change I didn't mean
to commit. Tested x86_64-linux. Pushed to trunk.
-- >8 --
In commit r14-3134-g9cb2a7c8d54b1f I only meant to change some uses of
__clamp_iter_cat to use __iter_category_t, I didn't mean to commit the
additional change introd
Tested x86_64-linux, Pushed to trunk. I'll backport this to gcc-13 too.
-- >8 --
This avoids an IndexError exception when printing invalid chrono::month
or chrono::weekday values.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (StdChronoCalendarPrinter):
Check for out
On 8/11/23 03:11, Tsukasa OI via Gcc-patches wrote:
From: Tsukasa OI
Commit c283c4774d1c ("RISC-V: Throw compilation error for unknown
extensions") changed how do we handle unknown extensions and
commit 6f709f79c915a ("[committed] [RISC-V] Fix expected diagnostic messages
in testsuite") "fix
Hi,
Thanks for working on the BPF backend!
I noticed a tiny typo while test compiling libbpf-tools[1]. (Have yet look
into the cause of failure in detail though)
On Thu, Aug 03, 2023 at 10:54:31AM +0100, Cupertino Miranda wrote:
> [snip]
> +
> +pack_type_fail:
> + bpf_error_at (EXPR_LOC_OR_
On Fri, 11 Aug 2023 at 15:50, Martin Jambor wrote:
> Hello,
>
> On Fri, Aug 11 2023, Christophe Lyon wrote:
> > Hi Martin,
> >
> >
> > On Fri, 4 Aug 2023 at 18:26, Martin Jambor wrote:
> >
> >> Hello,
> >>
> >> On Wed, Aug 02 2023, Richard Biener wrote:
> >> > On Mon, Jul 31, 2023 at 7:05 PM Mar
From: Ju-Zhe Zhong
Hi, Richard and Richi.
This patch add support live vectorization by VEC_EXTRACT for LEN loop control.
Consider this following case:
#include
#define EXTRACT_LAST(TYPE) \
TYPE __attribute__ ((noinline, noclone)) \
test_##TYPE (TYPE *x, int n, T
On 2023/08/11 23:15, Jeff Law wrote:
>
>
> On 8/11/23 03:11, Tsukasa OI via Gcc-patches wrote:
>> From: Tsukasa OI
>>
>> Commit c283c4774d1c ("RISC-V: Throw compilation error for unknown
>> extensions") changed how do we handle unknown extensions and
>> commit 6f709f79c915a ("[committed] [RISC-V
On 2023-08-10 14:50, Siddhesh Poyarekar wrote:
As a result, the only case for a potential security issue in all
these cases is when it ends up generating vulnerable output for
valid input source code.
I think this leaves open the interpretation "every wrong code bug
is potenti
On 8/11/23 02:45, Juzhe-Zhong wrote:
This patch fix bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110985
PR target/110985
gcc/ChangeLog:
* config/riscv/riscv-v.cc (expand_vec_series): Refactor the expander.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autove
On 8/11/23 03:01, Lehua Ding wrote:
Hi,
This patch revert the convert from vmv.s.x to vmv.v.i and add new pattern
optimize the special case when the scalar operand is zero.
Currently, the broadcast pattern where the scalar operand is a imm
will be converted to vmv.v.i from vmv.s.x and the ma
On 8/11/23 05:51, Richard Biener wrote:
On Fri, Aug 11, 2023 at 11:17 AM Andrew Pinski via Gcc-patches
wrote:
So it turns out there was a simplier way of starting to
improve VRP to start to fix PR 110131, PR 108360, and PR 108397.
That was rewrite test_for_singularity to use range_op_handler
> On Aug 11, 2023, at 10:36 AM, Siddhesh Poyarekar wrote:
>
> On 2023-08-10 14:50, Siddhesh Poyarekar wrote:
As a result, the only case for a potential security issue in all
these cases is when it ends up generating vulnerable output for
valid input source code
On 8/10/23 13:27, John David Anglin wrote:
Ping.
On 2023-07-19 2:59 p.m., John David Anglin wrote:
Tested on trunk with hppa64-hp-hpux11.11.
Okay?
Dave
---
Use strtol instead of std::stoi [PR110646]
Implementation of std::stoi was overlooked on hppa-hpux, so use
strtol instead.
2023-07-
On Wed, Aug 9, 2023 at 1:33 PM Siddhesh Poyarekar
wrote:
> On 2023-08-08 10:30, Siddhesh Poyarekar wrote:
> >> Do you have a suggestion for the language to address libgcc,
> >> libstdc++, etc. and libiberty, libbacktrace, etc.?
> >
> > I'll work on this a bit and share a draft.
>
> Hi David,
>
>
On 2023-08-11 11:09, Paul Koning wrote:
On Aug 11, 2023, at 10:36 AM, Siddhesh Poyarekar wrote:
On 2023-08-10 14:50, Siddhesh Poyarekar wrote:
As a result, the only case for a potential security issue in all
these cases is when it ends up generating vulnerable output for
On 8/10/23 05:33, Thomas Neumann via Gcc-patches wrote:
Original bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110956
Rainer Orth successfully tested the patch on Solaris with a full bootstrap.
Some uncommon unwinding table encodings need to access the base pointer
for address co
On 2023-08-11 11:12, David Edelsohn wrote:
The text above states "bugs in these libraries may be evaluated for
security impact", but there is no comment about the criteria for a
security impact, unlike the GLIBC SECURITY.md document. The text seems
to imply the "What is a security bug?" defini
Sorry, I had some problems with email. Therefore there are email
duplication and they were sent to g...@gcc.gnu.org instead of
gcc-patches@gcc.gnu.org
On 8/9/23 16:54, Vladimir Makarov wrote:
On 8/9/23 07:15, senthilkumar.selva...@microchip.com wrote:
Hi,
After turning on FP -> SP el
On Fri, 2023-08-11 at 13:51 +0200, priour...@gmail.com wrote:
> From: benjamin priour
Hi Benjamin, thanks for the patch.
Overall, the patch is close to being ready, but see the various
comments inline below...
>
> This patch introduces -fanalyzer-show-events-in-system-headers,
> disabled by de
> I can't speak for other uarches, but as a guiding principle for Ventana
> we're assuming vsetvl instructions are common and as a result need to be
> very cheap in hardware. It's likely a good tradeoff for us.
> I could see other uarches making different design choices though. So
at
> a high
On 8/11/23 09:43, Lehua Ding wrote:
> I can't speak for other uarches, but as a guiding principle for Ventana
> we're assuming vsetvl instructions are common and as a result need to be
> very cheap in hardware. It's likely a good tradeoff for us.
> I could see other uarches making diffe
> Hi Jin Ma,
>
> On 5/16/23 00:06, jinma via Gcc-patches wrote:
> > On 5/15/23 07:16, Jin Ma wrote:
> >>
> >> Do we also need to check Z[FDH]INX too?
> >>
> >> Otherwise it looks pretty good. We just need to wait for everything to
> >> freeze and finalization on the assembler interface.
> >>
> >>
On 8/8/23 21:54, Lehua Ding wrote:
Hi Jeff,
> The pattern's operand 0 explicitly allows MEMs as do the constraints.
> So forcing the operand into a register just seems like it's papering
> over the real problem.
The added of force_reg code is address the problem preduced after
address th
On 8/11/23 04:48, Jakub Jelinek wrote:
On Fri, Aug 11, 2023 at 01:13:32AM +0200, Jakub Jelinek wrote:
Looking at the first uses of the builtin back in 90s in va*.h, it certainly
relied on array/function decay there (the macros would abort e.g. on
array_type_class, function_type_class and various
> But combine doesn't run at -O0. So something is inconsistent. I
> certainly believe we need to avoid the mem->mem case, but that's
> independent of combine and affects all optimization levels.
This is an new bug when running all tests after fixing the combine bug.
I understand that maybe I sh
>> But combine doesn't run at -O0. So something is
inconsistent. I >> certainly believe we need to avoid the
mem->mem case, but that's >> independent of combine and affects all
optimization levels. > This is an new bug when running all tests after
fixing the combine bug. > I understand that
Hi,
Thanks for the finding.
I will fix it in next upcoming patches.
Thanks,
Cupertino
Shung-Hsi Yu writes:
> Hi,
>
> Thanks for working on the BPF backend!
>
> I noticed a tiny typo while test compiling libbpf-tools[1]. (Have yet look
> into the cause of failure in detail though)
>
> On Thu,
Second attempt to fix this PR. Tested x86_64-linux, pushed to trunk.
-- >8 --
Calling log10(0.0) returns -inf which has undefined behaviour when
converted to an integer. We only need to use log10 for large values
anyway. If the value is zero then the larger buffer is only needed due
to a large pr
ChangeLog:
* MAINTAINERS: Add myself.
Signed-off-by: Eric Feng
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1e54844c905..7a3ad68bc42 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -411,6 +411,7 @@ Chris Fairles
On Fri, Aug 11, 2023 at 01:25:38PM +, Joseph Myers wrote:
> On Fri, 11 Aug 2023, Jakub Jelinek wrote:
>
> > All that is diagnosed is when result is bool or enum (any kind). Even for
>
> I'd suggest tests that other nonsense cases are diagnosed, such as
> floating-point or pointer arguments
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
This makes the generic pretty printer print braces around a TREE_VEC
like we do for CONSTRUCTOR. This should improve readability of nested
TREE_VECs in particular.
gcc/ChangeLog:
* tree-pretty-print.cc (dump_generic_n
Thanks for the feedback! I've incorporated the changes (aside from
expanding test coverage, which I plan on releasing in a follow-up),
rebased, and performed a bootstrap and regtest on
aarch64-unknown-linux-gnu. Since you mentioned that it is good for trunk
with nits fixed and no problems after reb
On 8/11/23 13:35, Patrick Palka wrote:
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK.
-- >8 --
This makes the generic pretty printer print braces around a TREE_VEC
like we do for CONSTRUCTOR. This should improve readability of nested
TREE_VECs in particular.
gcc/ChangeLog:
BPF currently limits the number of registers used to pass arguments to
functions to five registers. There is a check for this at function
expansion time. However, if a function is guaranteed to be always
inlined (and its body never generated) by virtue of the always_inline
attribute, it can "rece
We were reserving one of the hard registers in BPF in order to
implement dynamic stack allocation: alloca and VLAs. However, there is
kernel code that has inline assembly that requires all the non-fixed
registers to be available for register allocation.
This patch:
1. Liberates r9 that is now ava
Tested x86_64-linux, pushed to trunk.
This is a pure addition that only affects C++20 mode, so I'm considering
backporting it to gcc-13 at some point (once any dust has settled from
landing it on trunk).
-- >8 --
This adds the missing C++20 features to .
I've implemented my proposed resolutions
On rv32 targets, this patch fixes ztso testcases errors like this:
cc1: error: ABI requires '-march=rv32'
2023-08-11 Patrick O'Neill
gcc/testsuite/ChangeLog:
* gcc.target/riscv/amo-table-ztso-amo-add-1.c: Add -mabi=lp64d
to dg-options.
* gcc.target/riscv/amo-table-ztso-a
I've noticed there were still some strange indentations in the last
patch ... however, I think I've finally figured out a sane formatting
solution for me (fingers crossed). I will address them in the
follow-up patch at the same time as adding more test coverage.
---
In case, anyone else using VSC
On 8/11/23 13:15, Patrick O'Neill wrote:
On rv32 targets, this patch fixes ztso testcases errors like this:
cc1: error: ABI requires '-march=rv32'
2023-08-11 Patrick O'Neill
gcc/testsuite/ChangeLog:
* gcc.target/riscv/amo-table-ztso-amo-add-1.c: Add -mabi=lp64d
to dg-option
On 8/11/23 13:44, Jeff Law wrote:
On 8/11/23 13:15, Patrick O'Neill wrote:
On rv32 targets, this patch fixes ztso testcases errors like this:
cc1: error: ABI requires '-march=rv32'
2023-08-11 Patrick O'Neill
gcc/testsuite/ChangeLog:
* gcc.target/riscv/amo-table-ztso-amo-add-1.c: Add
On 8/8/23 21:05, pan2...@intel.com wrote:
From: Pan Li
In same cases, like gcc/testsuite/gcc.dg/pr78148.c in RISC-V, there will
be only 1 operand when SET_SRC in create_pre_exit. For example as below.
(insn 13 9 14 2 (clobber (reg/i:TI 10 a0))
"gcc/testsuite/gcc.dg/pr78148.c":24:1 -1
(e
On Fri, 11 Aug 2023, Jakub Jelinek via Gcc-patches wrote:
> On Fri, Aug 11, 2023 at 01:25:38PM +, Joseph Myers wrote:
> > On Fri, 11 Aug 2023, Jakub Jelinek wrote:
> >
> > > All that is diagnosed is when result is bool or enum (any kind). Even for
> >
> > I'd suggest tests that other nonsen
1 - 100 of 125 matches
Mail list logo
