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
>
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
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
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);
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
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:
>>>
>>>
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
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
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
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
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
钟居哲 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
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
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
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
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
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
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
> 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,
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
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
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
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?
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
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
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
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
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)
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
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
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
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...
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
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} //
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
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
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
> +++
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:
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
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
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
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
> ...
>
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
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
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
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 {
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
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
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
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
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.
> *
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:
> 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
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
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,
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.
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
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
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,
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,
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
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
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
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
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
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
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
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.
---
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
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
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
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:
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
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
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
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
* 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
* 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]
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,
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
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
1 - 100 of 137 matches
Mail list logo
