Iain Sandoe writes:
> HI Sam,
Hi Iain,
>
> I think this qualifies as obvious (it’s on my list, but I did not get to it
> yet,
> so go ahead).
Thanks. I can't push it myself - could you do that for me?
thanks again,
sam
>
> Iain
>
>> On 2 Dec 2023, at 05:30, Sam James wrote:
>>
>> From:
HI Sam,
I think this qualifies as obvious (it’s on my list, but I did not get to it yet,
so go ahead).
Iain
> On 2 Dec 2023, at 05:30, Sam James wrote:
>
> From: Iain Sandoe
>
> r12-3005-g220c410162ebece4f missed a cast for the set_32 call.
> Fixed thus.
>
> Signed-off-by: Iain Sandoe
> Si
When I moved two_value to match.pd, I removed the check for the {0,+-1}
as I had placed it after the {0,+-1} case for cond in match.pd.
In the case of {0,+-1} and non boolean, before we would optmize those
case to just `(convert)a` but after we would get `(convert)(a != 0)`
which was not handled an
This patch set fixes PR 111972 and the fallout from it.
The first patch is a fix to zero_one_valued_p's convert pattern
which I hit while running the testsuite with the last patch.
The second patch is a fix for -fanalyzer which I had implemented with
a different version of the 3rd patch while I w
From: Andrew Pinski
The check for the type seems unnecessary and gets in the way sometimes.
Also with a patch I am working on for match.pd, it causes a failure to happen.
Before my patch the IR was:
_1 = BIT_FIELD_REF ;
_2 = _1 & 1;
_3 = _2 != 0;
_4 = (int) _3;
__analyzer_eval (_4);
Wh
While working on PR 111972, I was getting a regression
due to zero_one_valued_p matching a signed 1 bit integer
when it came to convert. This patch fixes that by checking
the outer type too.
Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
* match.pd (zero_
Jeff Law writes:
> On 12/1/23 18:13, Sam James wrote:
>> 钟居哲 writes:
>>
>>> Hi, This patch cause error on building newlib/glibc/musl on RISC-V port:
>>>
>>> /work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_acces
From: Iain Sandoe
r12-3005-g220c410162ebece4f missed a cast for the set_32 call.
Fixed thus.
Signed-off-by: Iain Sandoe
Signed-off-by: Sam James
libiberty/ChangeLog:
PR other/112823
* simple-object-mach-o.c (simple_object_mach_o_write_segment):
Cast the first argument
On 12/1/23 18:13, Sam James wrote:
钟居哲 writes:
Hi, This patch cause error on building newlib/glibc/musl on RISC-V port:
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_access.c:8:40:
error: passing argument
That failure is is due to newlib files:
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/../../*newlib*/newlib/libm/complex/ccoshl.c:
In function 'ccoshl':
To build gcc w/ glibc with riscv-gnu-toolchain, run make linux.
A temporary fix for newli
Committed, thanks Juzhe.
Pan
From: 钟居哲
Sent: Saturday, December 2, 2023 9:10 AM
To: Li, Pan2 ; gcc-patches
Cc: Li, Pan2 ; Wang, Yanzhang ;
kito.cheng
Subject: Re: [PATCH v4] RISC-V: Bugfix for legitimize move when get vec mode in
zve32f
LGTM
juzhe.zh...@riv
No. GLIBC 2.37 also failed:
make[4]: Leaving directory
'/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/build-newlib/riscv64-unknown-elf/newlib'
CC libm/complex/libm_a-casinhl.o
make[3]: *** [Makefile:5283: all] Error 2
make[3]: Leaving di
On Friday, December 1st, 2023 at 9:52 AM, Jason Merrill
wrote:
>
>
> On 12/1/23 01:02, waffl3x wrote:
>
> > I ran into another issue while devising tests for redeclarations of
> > xobj member functions as static member functions and vice versa. I am
> > pretty sure by the literal wordi
钟居哲 writes:
> Hi, This patch cause error on building newlib/glibc/musl on RISC-V port:
>
> /work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_access.c:8:40:
> error: passing argument 3 of 'syscall_errno' makes integ
Hi Juzhe,
I can confirm the failure on Newlib.
I'm not seeing any issues on glibc 2.37.
I haven't tried to build musl.
Since this patch promotes warnings to errors breakages were probably
expected.
The fix may require changes to newlib to remove the errors.
I've hacked together a series of pat
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-12-02 08:59
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v4] RISC-V: Bugfix for legitimize move when get vec mode in
zve32f
From: Pan Li
If we want to extract 64bit value but ELEN < 64, we use RVV
vec
From: Pan Li
If we want to extract 64bit value but ELEN < 64, we use RVV
vector mode with EEW = 32 to extract the highpart and lowpart.
However, this approach doesn't honor DFmode when movdf pattern
when ZVE32f and of course results in ICE when zve32f.
This patch would like to reuse the approach
On 12/1/23 18:37, Marek Polacek wrote:
On Thu, Nov 30, 2023 at 06:34:01PM -0500, Jason Merrill wrote:
On 11/23/23 11:46, Marek Polacek wrote:
v5 greatly simplifies the code.
Indeed, it's much cleaner now.
I still need a new ff_ flag to signal that we can return immediately
after seeing an i
Hi, This patch cause error on building newlib/glibc/musl on RISC-V port:
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_access.c:8:40:
error: passing argument 3 of 'syscall_errno' makes integer from pointer
witho
On Thu, Nov 30, 2023 at 06:34:01PM -0500, Jason Merrill wrote:
> On 11/23/23 11:46, Marek Polacek wrote:
> > v5 greatly simplifies the code.
>
> Indeed, it's much cleaner now.
>
> > I still need a new ff_ flag to signal that we can return immediately
> > after seeing an i-e expr.
>
> That's stil
> Date: Fri, 1 Dec 2023 08:07:14 +0100 (CET)
> From: Richard Biener
> On Fri, 1 Dec 2023, Hans-Peter Nilsson wrote:
>
> > > From: Hans-Peter Nilsson
> > > Date: Thu, 30 Nov 2023 18:09:10 +0100
> >
> > Richard B.:
> > > > > In the end we might need to move/duplicate the test to some
> > > >
lgtm
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-12-01 23:23
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Add vectorized strcmp.
Hi,
this patch adds a vectorized strcmp implementation and tests. Similar
to strlen, expansi
LGTM.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-12-01 23:21
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Add vectorized strlen.
Hi,
this patch implements a vectorized strlen by re-using and slightly
adjusting the rawmemc
LGTM
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-12-01 23:21
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Rename and unify stringop strategy handling [NFC].
Hi,
now split into multiple patches.
In preparation for the vec
LGTM。
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-12-01 23:20
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Fix rawmemchr implementation.
Hi,
this fixes a bug in the rawmemchr implementation by incrementing the
source addre
On Fri, 1 Dec 2023, Jason Merrill wrote:
> On 12/1/23 12:32, Patrick Palka wrote:
> > On Tue, 14 Nov 2023, Jason Merrill wrote:
> >
> > > On 11/14/23 11:10, Patrick Palka wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > > > trunk?
> > > >
> > > > -- >8
Dear all,
this patch extends the previous version by adding further code testing
the presence of an optional deferred-length character argument also
in the function initialization code. This allows to re-enable a
commented-out test in v2.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Tha
Hi Mikael,
On 12/1/23 21:24, Mikael Morin wrote:
Hello,
Le 30/11/2023 à 22:06, Harald Anlauf a écrit :
the attached rather obvious patch fixes the first testcase of pr112772:
we unconditionally generated copy-out code for optional class arguments,
while the copy-in properly checked the presenc
On Fri, Dec 01, 2023 at 03:53:14PM -0500, Marek Polacek wrote:
> On Fri, Dec 01, 2023 at 11:44:28AM -0800, Andrew Pinski wrote:
> > On Fri, Dec 1, 2023, 11:36 Marek Polacek wrote:
> >
> > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > >
> > > -- >8 --
> > > It came up that a g
On Fri, Dec 01, 2023 at 11:44:28AM -0800, Andrew Pinski wrote:
> On Fri, Dec 1, 2023, 11:36 Marek Polacek wrote:
>
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > It came up that a good hardening strategy is to disable trampolines
> > which may require execut
On 12/1/23 15:40, Alexandre Oliva wrote:
On Nov 9, 2023, Jonathan Wakely wrote:
On Thu, 9 Nov 2023 at 01:56, Alexandre Oliva wrote:
g++.dg/tls/thread_local-order2.C fails when the toolchain is built for
a platform that lacks __cxa_thread_atexit_impl, even if the program is
built and run u
On Nov 9, 2023, Jonathan Wakely wrote:
> On Thu, 9 Nov 2023 at 01:56, Alexandre Oliva wrote:
>> g++.dg/tls/thread_local-order2.C fails when the toolchain is built for
>> a platform that lacks __cxa_thread_atexit_impl, even if the program is
>> built and run using that toolchain on a (later) pl
On 12/1/23 12:32, Patrick Palka wrote:
On Tue, 14 Nov 2023, Jason Merrill wrote:
On 11/14/23 11:10, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
For decltype((x)) within a lambda where x is not captured, we dubiously
require th
Hello,
Le 30/11/2023 à 22:06, Harald Anlauf a écrit :
the attached rather obvious patch fixes the first testcase of pr112772:
we unconditionally generated copy-out code for optional class arguments,
while the copy-in properly checked the presence of arguments.
Regtested on x86_64-pc-linux-gnu.
On Fri, Dec 1, 2023, 11:36 Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> -- >8 --
> It came up that a good hardening strategy is to disable trampolines
> which may require executable stack. Therefore the following patch
> adds -Werror=trampolines to -fha
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
It came up that a good hardening strategy is to disable trampolines
which may require executable stack. Therefore the following patch
adds -Werror=trampolines to -fhardened.
gcc/ChangeLog:
* common.opt (Wtrampolines):
Comments in PR 112788 correctly brought up that the new
check_operands_p() routine is directly checking precision rather than
calling range_compatible_p().
Most earlier iterations of the original patch had ranges as arguments,
and it wasn't primarily a CHECKING_P only call then... Regardless
On Thu, 30 Nov 2023, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> -- 8< --
>
> In review of the deducing 'this' patch it came up that LAMBDA_EXPR_MUTABLE_P
> doesn't make sense for a lambda with an explicit object parameter. And it
> was never necessary, so let's re
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112445
The patch was successfully bootstrapped and tested on x86-64, aarch64,
ppc64le.
commit 1390bf52c17a71834a1766c0222e4f8a74efb162
Author: Vladimir N. Makarov
Date: Fri Dec 1 11:46:37 2023 -0500
[PR112445][LRA]:
ping.
On Sat, 25 Nov 2023 at 13:52, Cassio Neri wrote:
> The following invoke signed integer overflow (UB) [1]:
>
> month + months{MAX} // where MAX is the maximum value of months::rep
> month + months{MIN} // where MIN is the maximum value of months::rep
> month - months{MIN} // whe
On Thu, 2023-11-30 at 17:13 -0500, Antoni Boucher wrote:
> Here's the updated patch.
> The failure was due to the test being in the test array while it
> should
> not have been there since it changes the context.
Thanks for the updated patch.
Did you do a full bootstrap and regression test with t
On Thu, 2023-11-16 at 17:20 -0500, Antoni Boucher wrote:
> I forgot to attach the patch.
>
> On Thu, 2023-11-16 at 17:19 -0500, Antoni Boucher wrote:
> > Hi.
> > This patch adds the support for the type bfloat16 (bug 112574).
> >
> > This was asked to be splitted from a another patch sent here:
>
On 12/1/23 10:33, Jakub Jelinek wrote:
On Fri, Dec 01, 2023 at 10:04:38AM -0700, Sandra Loosemore wrote:
Thanks, this looks good to me. I think I also noticed this weird formatting
in passing recently when I was looking for something else and did not have
time to track it down myself.
There i
On Dec 1, 2023, Alexandre Oliva wrote:
> diff --git a/gcc/testsuite/c-c++-common/torture/harden-cfr-noret.c
> b/gcc/testsuite/c-c++-common/torture/harden-cfr-noret.c
> index fdd803109a4ae..8c7cc01c0ce68 100644
> --- a/gcc/testsuite/c-c++-common/torture/harden-cfr-noret.c
> +++ b/gcc/testsuite/c
On Nov 6, 2023, at 2:59 AM, Marc Poulhiès wrote:
>
> These 3 tests fails parsing the 'vect' dump when not using -mavx. Make
> the dependency explicit.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/vect/vect-ifcvt-18.c: Add dep on avx_runtime.
> * gcc.dg/vect/vect-simd-clone-16f.c: Likew
On Fri, Dec 01, 2023 at 10:04:38AM -0700, Sandra Loosemore wrote:
> Thanks, this looks good to me. I think I also noticed this weird formatting
> in passing recently when I was looking for something else and did not have
> time to track it down myself.
There is another question. In many cases we
On Tue, 14 Nov 2023, Jason Merrill wrote:
> On 11/14/23 11:10, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk?
> >
> > -- >8 --
> >
> > For decltype((x)) within a lambda where x is not captured, we dubiously
> > require that the lambda
This has been unreachable for months (at least).
If any of you is aware of some other link to add to
https://gcc.gnu.org/benchmarks/ please let me know.
Gerald
---
htdocs/benchmarks/index.html | 7 ---
1 file changed, 7 deletions(-)
diff --git a/htdocs/benchmarks/index.html b/htdocs/benchma
This feels a bit lick whack-a-mole to me, though I am hopefull to now have
caught and covered all cases where your CoC pages link to addresses that
permanently redirect.
Famous last words. :-)
(The redirect work, avoiding them primarily helps us to find "odd" cases.
The extra turnaround should
On Nov 6, 2023, at 3:01 AM, Marc Poulhiès wrote:
>
> Contrary to glibc, including stdio.h from newlib defines mode_t which
> conflicts with the test's type definition.
>
> .../gcc/testsuite/gcc.dg/analyzer/fd-4.c:19:3: error: redefinition of typedef
> 'mode_t' with different type
> ...
> .../in
On Nov 6, 2023, at 2:57 AM, Marc Poulhiès wrote:
>
> Using newlib produces a different codegen because the support for c99
> differs (see libc_has_function hook).
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/i386/pr106910-1.c: Disable for newlib.
> ---
> Tested on x86_64-linux and x86_64
On 12/1/23 03:26, Jakub Jelinek wrote:
Hi!
In
https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fstdc_005fbit_005ffloor>>
I've noticed that while e.g. __builtin_stdc_bit_floor builtin is properly
rendered in bold and bigger size, for the __builtin_stdc_bit_width
Hi Richard,
> + rtx load[max_ops], store[max_ops];
>
> Please either add a comment explaining why 40 is guaranteed to be
> enough, or (my preference) use:
>
> auto_vec, ...> ops;
I've changed to using auto_vec since that should help reduce conflicts
with Alex' LDP changes. I double-checked maxi
On 12/1/23 01:02, waffl3x wrote:
I ran into another issue while devising tests for redeclarations of
xobj member functions as static member functions and vice versa. I am
pretty sure by the literal wording of the standard, this is well formed.
template
concept Constrain = true;
struct S {
vo
On 12/1/2023 2:10 PM, Richard Earnshaw (lists) wrote:
On 01/12/2023 13:45, Christophe Lyon wrote:
On Fri, 1 Dec 2023 at 13:44, Richard Earnshaw (lists)
wrote:
On 01/12/2023 11:28, Saurabh Jha wrote:
Hey,
I introduced this test "gcc/testsuite/gcc.target/arm/mve/pr112337.c" in this
commit 236
On 29/11/2023 17:01, Richard Sandiford wrote:
"Andre Vieira (lists)" writes:
Rebased, no major changes, still needs review.
On 30/08/2023 10:19, Andre Vieira (lists) via Gcc-patches wrote:
This patch finalizes adding support for the generation of SVE simd
clones when no simdlen is provided
On 11/30/23 14:17, Indu Bhagat wrote:
> PR debug/112768 - btf: fix asm comment output for BTF_KIND_FUNC* kinds
>
> The patch adds a small function to abstract out the detail and return
> the name of the type. The patch also fixes the issue of BTF_KIND_FUNC
> appearing in the comments with a 'nu
Hi Indu,
On 11/30/23 14:18, Indu Bhagat wrote:
> PR debug/112656 - btf: function prototypes generated with name
>
> With this patch, all BTF_KIND_FUNC_PROTO will appear anonymous in the
> generated BTF section.
>
> As noted in the discussion in the bugzilla, the number of
> BTF_KIND_FUNC_PROTO t
Marc Poulhiès writes:
> Using newlib produces a different codegen because the support for c99
> differs (see libc_has_function hook).
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/i386/pr106910-1.c: Disable for newlib.
> ---
> Tested on x86_64-linux and x86_64-elf.
>
> OK for master?
>
>
Marc Poulhiès writes:
> These 3 tests fails parsing the 'vect' dump when not using -mavx. Make
> the dependency explicit.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/vect/vect-ifcvt-18.c: Add dep on avx_runtime.
> * gcc.dg/vect/vect-simd-clone-16f.c: Likewise.
> * gcc.dg/vect/ve
Marc Poulhiès writes:
> Contrary to glibc, including stdio.h from newlib defines mode_t which
> conflicts with the test's type definition.
>
> .../gcc/testsuite/gcc.dg/analyzer/fd-4.c:19:3: error: redefinition of typedef
> 'mode_t' with different type
> ...
> .../include/sys/types.h:189:25: no
> Date: Fri, 1 Dec 2023 08:09:08 -0700
> From: Jeff Law
> On 11/30/23 18:08, Hans-Peter Nilsson wrote:
> >> Date: Sun, 19 Nov 2023 17:47:56 -0700
> >> From: Jeff Law
> >
> >> Locally we have had this enabled at -O1 and above to encourage testing,
> >> but I'm thinking that for the trunk enablin
Hi!
On 2023-11-20T10:56:16+0100, Florian Weimer wrote:
> --- a/gcc/c/c-decl.cc
> +++ b/gcc/c/c-decl.cc
> @@ -3515,14 +3515,14 @@ implicit_decl_warning (location_t loc, tree id, tree
> olddecl)
> {
> gcc_rich_location richloc (loc);
> richloc.add_fixit_replace (suggestion);
Rainer Orth writes:
> The recent warning changes broke Ada bootstrap on macOS:
>
> adaint.c: In function '__gnat_copy_attribs':
> adaint.c:3336:10: error: implicit declaration of function 'utimes'; did you
> mean 'utime'? [-Wimplicit-function-declaration]
> 3336 | if (utimes (to, tbuf) =
On Wed, 14 Jun 2023 21:14:02 +0200
Bernhard Reutner-Fischer wrote:
> plonk.
ping^3
patch at
https://inbox.sourceware.org/gcc-patches/20230526103151.3a7f6...@nbbrfq.loc/
I would regenerate it for rtx and/or tree, though, whatever you deem
desirable?
thanks
>
> On 26 May 2023 10:31:51 CEST, B
Please cross-reference against issue 37210 if/when merging, if it
hasn't already been:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37210
On Fri, Dec 1, 2023 at 2:15 AM Richard Biener
wrote:
>
> On Thu, Nov 30, 2023 at 2:42 PM Xi Ruoyao wrote:
> >
> > Recently there are some people building GCC
> On 1 Dec 2023, at 15:14, Rainer Orth wrote:
>
> The recent warning changes broke Ada bootstrap on macOS:
>
> adaint.c: In function '__gnat_copy_attribs':
> adaint.c:3336:10: error: implicit declaration of function 'utimes'; did you
> mean 'utime'? [-Wimplicit-function-declaration]
> 3336 |
Split it into four separate patches now.
Regards
Robin
Hi,
this patch adds a vectorized strcmp implementation and tests. Similar
to strlen, expansion is still guarded by -minline-strcmp. I just
realized I forgot to make it a series but this one is actually
dependent on the NFC patch and the rawmemchr fix before.
Regards
Robin
gcc/ChangeLog:
Hi,
this patch implements a vectorized strlen by re-using and slightly
adjusting the rawmemchr implementation. Rawmemchr returns the address
of the needle while strlen returns the difference between needle address
and start address.
As before, strlen expansion is guarded by -minline-strlen.
Whi
Hi,
now split into multiple patches.
In preparation for the vectorized strlen and strcmp support this NFC
patch unifies the stringop strategy handling a bit. The "auto"
strategy now is a combination of scalar and vector and an expander
should try the strategies in their preferred order.
For the
Hi,
this fixes a bug in the rawmemchr implementation by incrementing the
source address by vl * element_size instead of just vl.
This is normally harmless as we will just scan the same region more than
once but, in combination with an older qemu version, would lead to
an execution failure in SPEC
The recent warning changes broke Ada bootstrap on macOS:
adaint.c: In function '__gnat_copy_attribs':
adaint.c:3336:10: error: implicit declaration of function 'utimes'; did you
mean 'utime'? [-Wimplicit-function-declaration]
3336 | if (utimes (to, tbuf) == -1) {
| ^~
On Dec 1, 2023, Alexandre Oliva wrote:
> Also tested on arm-eabi, but it's *not* enough (or needed) to fix the
> PR, there's another bug lurking there, with a separate patch coming
> up.
Here it is.
The computation of apply_args_size and apply_result_size is saved in a
static variable, s
On 11/30/23 18:08, Hans-Peter Nilsson wrote:
Date: Sun, 19 Nov 2023 17:47:56 -0700
From: Jeff Law
Locally we have had this enabled at -O1 and above to encourage testing,
but I'm thinking that for the trunk enabling at -O2 and above is the
right thing to do.
Yes.
Thoughts, comments, rec
On 12/1/23 03:26, Jakub Jelinek wrote:
Hi!
In
https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fstdc_005fbit_005ffloor
I've noticed that while e.g. __builtin_stdc_bit_floor builtin is properly
rendered in bold and bigger size, for the __builtin_stdc_bit_width
On 11/30/23 10:27, Hans-Peter Nilsson wrote:
My plan was to split up the test case in one which is for
-Wstringop-overflow and one which is for -Wnonnull and then
one could turn off the -Wstringop-overflow for the tests
which are actually for -Wnonnull. But adding the dg-blah
would certain
David: ping.
On Thu, 2023-11-16 at 17:20 -0500, Antoni Boucher wrote:
> I forgot to attach the patch.
>
> On Thu, 2023-11-16 at 17:19 -0500, Antoni Boucher wrote:
> > Hi.
> > This patch adds the support for the type bfloat16 (bug 112574).
> >
> > This was asked to be splitted from a another patc
Hi FX,
> On 1 Dec 2023, at 13:55, FX Coudert wrote:
>
> That commit makes gcc.target/i386/libcall-1.c on darwin:
>
> FAIL: gcc.target/i386/libcall-1.c scan-assembler globl\t__divti3
>
> because the pattern is not found, the only mention of divti3 in the generated
> assembly is:
>
> LCFI0:
>
On Fri, Dec 1, 2023 at 1:58 PM Alexandre Oliva wrote:
>
>
> Rework __builtin_return tests to explicitly call __builtin_apply and
> use its return value rather than anything else. Also require
> untyped_assembly. Avoid the noise out of exceptions escaping the
> builtin-applied function, but add a
On Fri, Dec 1, 2023 at 3:39 AM liuhongt wrote:
>
> > Hmm, I would suggest you put reg_needed into the class and accumulate
> > over all vec_construct, with your patch you pessimize a single v32qi
> > over two separate v16qi for example. Also currently the whole block is
> > gated with INTEGRAL_TY
On 01/12/2023 13:45, Christophe Lyon wrote:
> On Fri, 1 Dec 2023 at 13:44, Richard Earnshaw (lists)
> wrote:
>>
>> On 01/12/2023 11:28, Saurabh Jha wrote:
>>> Hey,
>>>
>>> I introduced this test "gcc/testsuite/gcc.target/arm/mve/pr112337.c" in
>>> this commit 2365aae84de030bbb006edac18c9314812fc6
I've found it useful in debugging the analyzer for the SARIF output to
contain extra analyzer-specific data in each diagnostic.
This patch:
* adds a way for a diagnostic_metadata to populate a property
bag within a SARIF "result" object based on a new vfunc
* reworks how diagnostics are emitted wi
I missed this one in r14-5464-gcfaaa8b11b8429.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r14-6056-g83b210d55b2846.
gcc/ChangeLog:
PR analyzer/103533
* doc/extend.texi: Remove stray reference to
-fanalyzer-checker=taint.
---
gcc/doc/
That commit makes gcc.target/i386/libcall-1.c on darwin:
FAIL: gcc.target/i386/libcall-1.c scan-assembler globl\t__divti3
because the pattern is not found, the only mention of divti3 in the generated
assembly is:
LCFI0:
movabsq $_b@GOTOFF, %rdx
movabsq $___divti3@PLTOFF, %rax
On Fri, 1 Dec 2023 at 13:44, Richard Earnshaw (lists)
wrote:
>
> On 01/12/2023 11:28, Saurabh Jha wrote:
> > Hey,
> >
> > I introduced this test "gcc/testsuite/gcc.target/arm/mve/pr112337.c" in
> > this commit 2365aae84de030bbb006edac18c9314812fc657b before. This had an
> > error which I unfortu
Rework __builtin_return tests to explicitly call __builtin_apply and
use its return value rather than anything else. Also require
untyped_assembly. Avoid the noise out of exceptions escaping the
builtin-applied function, but add a test to cover their effects as
well.
Regstrapped on x86_64-linu
On 01/12/2023 11:28, Saurabh Jha wrote:
> Hey,
>
> I introduced this test "gcc/testsuite/gcc.target/arm/mve/pr112337.c" in this
> commit 2365aae84de030bbb006edac18c9314812fc657b before. This had an error
> which I unfortunately missed. This patch fixes that test.
>
> Did regression testing on a
Background:
RVV ISA vx instructions for example vadd.vx,
When EEW = 64 and RV32. We can't directly use vadd.vx.
Instead, we need to use:
sw
sw
vlse
vadd.vv
However, we have some special situation that we still can directly use
vadd.vx directly for EEW=64 && RV32.
that is, when scalar is a known
One more comment:
+ unsigned int num = (smode == DImode || smode == DFmode)
+ && !TARGET_VECTOR_ELEN_64 ? 2 : 1;
change it into:
unsigned int num = known_eq (GET_MODE_SIZE (smode), 8) &&
!TARGET_VECTOR_ELEN_64 ? 2 : 1;
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-12-01 18:11
To: gcc-
On Fri, 1 Dec 2023, Richard Sandiford wrote:
> Richard Biener writes:
> > When querying a single set of vector defs with the overloaded
> > vect_get_vec_defs API then when you try to use the overload with
> > the vector type specified the call will be ambiguous with the
> > variant without the ve
On 30/11/2023 23:56, Joseph Myers wrote:
> On Thu, 30 Nov 2023, Jonny Grant wrote:
>
>> ChangeLog:
>>
>> htdocs/git.html: change example to use git:// and correct
>> spelling repostiory -> repository .
>
> git:// (unencrypted / unauthenticated) is pretty widely consid
LGTM.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-12-01 17:27
To: Roger Sayle; gcc-patches
CC: rdapp.gcc; juzhe.zh...@rivai.ai
Subject: Re: [RISC-V PATCH] Improve style to work around PR 60994 in host
compiler.
Yes, OK, thanks for that. CC'ing Juzhe as this is his pass.
Regards
Robin
Richard Biener writes:
> When querying a single set of vector defs with the overloaded
> vect_get_vec_defs API then when you try to use the overload with
> the vector type specified the call will be ambiguous with the
> variant without the vector type. The following fixes this by
> re-ordering th
Manos Anagnostakis writes:
> This is an RTL pass that detects store forwarding from stores to larger loads
> (load pairs).
>
> This optimization is SPEC2017-driven and was found to be beneficial for some
> benchmarks,
> through testing on ampere1/ampere1a machines.
>
> For example, it can transf
* Jakub Jelinek:
> Hi!
>
> On IRC Richi mentioned some FAILs in gcc.target/x86_64 and in pr83126.c.
>
> The following patch fixes the former ones (they need recent binutils to
> be enabled), for pr83126.c because I didn't have graphite configured I've
> just verified that the test compiles (didn't
* Thomas Schwinge:
> I'm not proposing a patch as I don't know whether you'd like to just
> silence the diagnostic, fix (?) the test case, and/or add another
> 'dg-error'-checking test case? (I've not yet looked at the history of
> the test case.)
Jakub just posted a patch:
[PATCH] testsuite:
Hi Florian!
On 2023-11-13T14:10:34+0100, Florian Weimer wrote:
> --- a/gcc/c/c-typeck.cc
> +++ b/gcc/c/c-typeck.cc
> @@ -7616,27 +7639,28 @@ convert_for_assignment (location_t location,
> location_t expr_loc, tree type,
> case ic_assign:
> - pedwarn (location, OPT_Wint_conversi
Hey,
I introduced this test "gcc/testsuite/gcc.target/arm/mve/pr112337.c" in this
commit 2365aae84de030bbb006edac18c9314812fc657b before. This had an error which I
unfortunately missed. This patch fixes that test.
Did regression testing on arm-none-eabi and found no regressions. Output of
run
On Fri, 1 Dec 2023, Jakub Jelinek wrote:
> Hi!
>
> On IRC Richi mentioned some FAILs in gcc.target/x86_64 and in pr83126.c.
>
> The following patch fixes the former ones (they need recent binutils to
> be enabled), for pr83126.c because I didn't have graphite configured I've
> just verified that
1 - 100 of 137 matches
Mail list logo
