On Wed, Nov 29, 2023 at 07:51:15AM +0100, Jose E. Marchesi wrote:
> > FAIL: gcc.c-torture/compile/libcall-2.c -O1 (test for excess errors)
> > FAIL: gcc.c-torture/compile/libcall-2.c -O2 -flto
> > -fno-use-linker-plugin -flto-partition=none (test for excess errors)
> > FAIL: gcc.c-torture/compil
On Tue, Nov 28, 2023 at 8:54 AM liuhongt wrote:
>
> For vec_contruct, the components must be live at the same time if
> they're not loaded from memory, when the number of those components
> exceeds available registers, spill happens. Try to account that with a
> rough estimation.
> ??? Ideally, we
在 2023/11/29 下午3:12, Xi Ruoyao 写道:
On Mon, 2023-11-20 at 08:47 +0800, Xi Ruoyao wrote:
The [1/5] patch is the PR112578 fix at
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637097.html.
It has been changed to remove the nearbyint pattern (because nearbyint
should not raise FE_INEXACT
On Tue, 28 Nov 2023, Jeff Law wrote:
>
>
> On 11/28/23 00:50, Richard Biener wrote:
>
> >
> > There's no way to distinguish a partial vs. non-partial MEM on RTL and
> > while without the bogus MEM_ATTR the alias oracle pieces that
> > miscompiled the original case are fended off we still see t
On Mon, 27 Nov 2023, Tamar Christina wrote:
> Hi All,
>
> To make code review of the updates to add multiple exit supports to
> vectorizable_live_operation easier I've extracted the refactoring part to
> its own patch.
>
> This patch is a straight extract of the function with no functional chang
On Mon, 2023-11-20 at 08:47 +0800, Xi Ruoyao wrote:
> The [1/5] patch is the PR112578 fix at
> https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637097.html.
> It has been changed to remove the nearbyint pattern (because nearbyint
> should not raise FE_INEXACT even if -ffp-int-builtin-inexact
> On Linux/x86_64,
>
> f31a019d1161ec78846473da743aedf49cca8c27 is the first bad commit
> commit f31a019d1161ec78846473da743aedf49cca8c27
> Author: Jose E. Marchesi
> Date: Fri Nov 24 06:30:28 2023 +0100
>
> Emit funcall external declarations only if actually used.
>
> caused
>
> FAIL: gcc
Committed with the test file rename, thanks Juzhe.
Pan
From: juzhe.zh...@rivai.ai
Sent: Wednesday, November 29, 2023 2:45 PM
To: Li, Pan2 ; gcc-patches
Cc: Li, Pan2 ; Wang, Yanzhang ;
kito.cheng
Subject: Re: [PATCH v1] RISC-V: Bugfix for ICE in block move when zve32f
pr112743-0.c -> pr112743
pr112743-0.c -> pr112743-1.c for consistent.
Otherwise LGTM. No need to send V2.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-11-29 14:37
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Bugfix for ICE in block move when zve32f
From: Pan Li
From: Pan Li
The exact_div requires the exactly multiple of the divider.
Unfortunately, the condition will be broken when zve32f in
some cases. For example,
potential_ew is 8
BYTES_PER_RISCV_VECTOR * lmul1 is [4, 4]
This patch would like to ensure the precondition of exact_div
when get_vec_mode
>> "Jose E. Marchesi" writes:
>>> There are many places in GCC where alternative local sequences are
>>> tried in order to determine what is the cheapest or best alternative
>>> to use in the current target. When any of these sequences involve a
>>> libcall, the current implementation of emit_l
On 11/27/23 19:32, Fei Gao wrote:
op=[PLUS, MINUS, IOR, XOR, ASHIFT, ASHIFTRT, LSHIFTRT, ROTATE, ROTATERT]
SIGN_EXTEND, ZERO_EXTEND and SUBREG has been considered
to support SImode in 64-bit machine.
Let's defer these for now. We're supposed to be wrapping up work that
was posted before sta
On 11/27/23 19:57, Fei Gao wrote:
1. In find_if_header function, I found the following piece of codes:
if (!reload_completed && noce_find_if_block(...)), and find_if_header must
be called before noce_try_cond_zero_arith().
Ah good.
2. In noce_try_strore_flag_constants, new registers are
loongarch_expand_vec_cond_mask_expr generates 'subreg's of 'subreg's, which are
not supported
in gcc, it causes an ICE:
ice.c:55:1: error: unrecognizable insn:
55 | }
| ^
(insn 63 62 64 8 (set (reg:V4DI 278)
(subreg:V4DI (subreg:V4DF (reg:V4DI 273 [ vect__53.26 ]) 0) 0)) -1
For [x]vshuf instructions, if the index value in the selector exceeds 63, it
triggers
undefined behavior on LA464, but not on LA664. To ensure compatibility of these
two
tests on both LA464 and LA664, we have modified both tests to ensure that the
index
value in the selector does not exceed 63.
According to spec, fmv.h checks if the input operands are correctly
NaN-boxed. If not, the input value is treated as an n-bit canonical NaN.
This patch fixs the issue that operands returned by soft-fp16 libgcc
(i.e., __truncdfhf2) was not correctly NaN-boxed.
*gcc/ChangeLog:*
* config/riscv/ri
在 2023/11/29 上午10:33, Xi Ruoyao 写道:
On Wed, 2023-11-29 at 10:23 +0800, Jiahao Xu wrote:
在 2023/11/29 上午10:08, Xi Ruoyao 写道:
On Tue, 2023-11-28 at 11:29 +0800, Jiahao Xu wrote:
diff --git a/gcc/config/loongarch/predicates.md
b/gcc/config/loongarch/predicates.md
index f7796da10b2..9e9ce58cb53
On Wed, Nov 29, 2023 at 9:23 AM Hu, Lin1 wrote:
>
> Hi, all
>
> This patch aims to fix the wrong CPUID of USER_MSR, its correct CPUID is
> (0x7, 0x1).EDX[15], But I set it as (0x7, 0x0).EDX[15]. And the patch modefied
> testcase for give the user a better example.
>
> It has been bootstrapped and
Currently sdot_prodv*qi is available under TARGET_AVXVNNIINT8, but it
can be emulated by
vec_unpacks_lo_v32qi
vec_unpacks_lo_v32qi
vec_unpacks_hi_v32qi
vec_unpacks_hi_v32qi
sdot_prodv16hi
sdot_prodv16hi
add3v8si
which is faster than original
vect_patt_39.11_48 = WIDEN_MULT_LO_EXPR ;
v
On Wed, 2023-11-29 at 10:23 +0800, Jiahao Xu wrote:
>
> 在 2023/11/29 上午10:08, Xi Ruoyao 写道:
> > On Tue, 2023-11-28 at 11:29 +0800, Jiahao Xu wrote:
> > > diff --git a/gcc/config/loongarch/predicates.md
> > > b/gcc/config/loongarch/predicates.md
> > > index f7796da10b2..9e9ce58cb53 100644
> > > ---
在 2023/11/29 上午10:08, Xi Ruoyao 写道:
On Tue, 2023-11-28 at 11:29 +0800, Jiahao Xu wrote:
diff --git a/gcc/config/loongarch/predicates.md
b/gcc/config/loongarch/predicates.md
index f7796da10b2..9e9ce58cb53 100644
--- a/gcc/config/loongarch/predicates.md
+++ b/gcc/config/loongarch/predicates.md
@
On Tue, 2023-11-28 at 11:29 +0800, Jiahao Xu wrote:
> diff --git a/gcc/config/loongarch/predicates.md
> b/gcc/config/loongarch/predicates.md
> index f7796da10b2..9e9ce58cb53 100644
> --- a/gcc/config/loongarch/predicates.md
> +++ b/gcc/config/loongarch/predicates.md
> @@ -235,6 +235,10 @@ (define_p
On Tue, 2023-11-28 at 15:56 +0800, Li Wei wrote:
> In the r14-5547 commit, C[LT]Z_DEFINED_VALUE_AT_ZERO were defined at
> the same time, but in fact, CLZ_DEFINED_VALUE_AT_ZERO has already been
> defined, so remove the duplicate definition.
>
> gcc/ChangeLog:
>
> * config/loongarch/loongarch
On 11/27/23 01:34, Liao Shihua wrote:
This patch add C intrinsics for scalar crypto extension.
Because of riscv-c-api
(https://github.com/riscv-non-isa/riscv-c-api-doc/pull/44/files) includes
zbkb/zbkc/zbkx's
intrinsics in bit manipulation extension, this patch only support zkn*/zks*'s
intr
Hi, all
This patch aims to fix the wrong CPUID of USER_MSR, its correct CPUID is
(0x7, 0x1).EDX[15], But I set it as (0x7, 0x0).EDX[15]. And the patch modefied
testcase for give the user a better example.
It has been bootstrapped and regtested on x86-64-pc-linux-gnu, OK for trunk?
BR,
Lin
gcc/C
On 11/23/23 11:34, Maciej W. Rozycki wrote:
On Sun, 19 Nov 2023, Jeff Law wrote:
As I suspect you know a big part of the problem here is that BRANCH_COST and
rtx_cost don't have any common scale and thus trying to compare BRANCH_COST to
RTX_COST doesn't have well defined meaning.
We do h
On Tue, Nov 28, 2023 at 9:51 PM Hongyu Wang wrote:
>
> Hi,
>
> On linux x86-64, -fomit-frame-pointer was by default enabled so the
> push2pop2 tests cfi scans are based on it. On other target with
> -fno-omit-frame-pointer the cfi scan will be wrong as the frame pointer
> is pushed at first. Add -
On 11/28/23 15:18, Jivan Hakobyan wrote:
The amdgcn ICE I reported still exists:
Can you send a build command to reproduce ICE.
I built on x86-64, RV32/64, and did not get any faults.
THe code is clearly wrong though. We need to test that we have a subreg
before we look at the subreg_b
Victor Do Nascimento writes:
> Add a build-time test to check whether system register data, as
> imported from `aarch64-sys-reg.def' has any duplicate entries.
>
> Duplicate entries are defined as any two SYSREG entries in the .def
> file which share the same encoding values (as specified by its `
Victor Do Nascimento writes:
> This patch adds the `aarch64-sys-regs.def' file, originally written
> for Binutils, to GCC. In so doing, it provides GCC with the necessary
> information for teaching the compiler about system registers known to
> the assembler and how these can be used.
>
> By align
On Linux/x86_64,
f31a019d1161ec78846473da743aedf49cca8c27 is the first bad commit
commit f31a019d1161ec78846473da743aedf49cca8c27
Author: Jose E. Marchesi
Date: Fri Nov 24 06:30:28 2023 +0100
Emit funcall external declarations only if actually used.
caused
FAIL: gcc.c-torture/compile/lib
Victor Do Nascimento writes:
> In implementing the ACLE read/write system register builtins it was
> observed that leaving argument type checking to be done at expand-time
> meant that poorly-formed function calls were being "fixed" by certain
> optimization passes, meaning bad code wasn't being p
Victor Do Nascimento writes:
> Implement the aarch64 intrinsics for reading and writing system
> registers with the following signatures:
>
> uint32_t __arm_rsr(const char *special_register);
> uint64_t __arm_rsr64(const char *special_register);
> void* __arm_rsrp(const char *spe
Victor Do Nascimento writes:
> This patch defines the structure of a new .def file used for
> representing the aarch64 system registers, what information it should
> hold and the basic framework in GCC to process this file.
>
> Entries in the aarch64-system-regs.def file should be as follows:
>
>
Victor Do Nascimento writes:
> Given the implementation of a mechanism of encoding system registers
> into GCC, this patch provides the mechanism of validating their use by
> the compiler. In particular, this involves:
>
> 1. Ensuring a supplied string corresponds to a known system
> regis
Victor Do Nascimento writes:
> Changes from v1 -
> https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635531.html
>
> * [PATCH 4/5] - For `error_at' message, put feature name in quotes.
> * [PATCH 4/5] - For `aarch64_retrieve_sysreg' function, add
> description of new parameter to comme
This has introduced an ICE building glibc for s390x-linux-gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112753
--
Joseph S. Myers
jos...@codesourcery.com
On 11/28/23 12:56, Philipp Tomsich wrote:
That's obviously a risky thing to do given it was sent right at the end
of the window, but it meets the rules.
Folks in the call seemed generally amenable to at least trying for 14,
so unless anyone's opposed on the lists it seems like the way to go.
>
> The amdgcn ICE I reported still exists:
Can you send a build command to reproduce ICE.
I built on x86-64, RV32/64, and did not get any faults.
On Tue, Nov 28, 2023 at 7:08 PM Andrew Stubbs wrote:
> On 28/11/2023 06:06, Jeff Law wrote:
> > - Verify we have a SUBREG before looking at SUBREG_
On 11/28/23 12:45, Palmer Dabbelt wrote:
IMO we're just stuck between a rock and a hard place here. Specifically,
this isn't just an assembly syntax change but also comes with a bunch of
behaviorial changes to the instructions in question -- I'm specifically
thinking of things like the re
On 11/28/23 12:52, Jakub Jelinek wrote:
On Tue, Nov 28, 2023 at 11:31:48AM -0500, Jason Merrill wrote:
+ if (len)
+ {
+ if (data)
+ msg = c_getstr (data);
+ if (msg == NULL)
+ buf = XNEWVEC (char, len);
On 11/28/23 11:51, Patrick Palka wrote:
This adds a sanity check to cp_parser_expression_statement similar to
the one in finish_expr_stmt added by r6-6795-g0fd9d4921f7ba2, which
effectively downgrades accepts-invalid/wrong-code bugs like this one
into ice-on-invalid/ice-on-valid ones.
OK.
On 11/28/23 11:51, Patrick Palka wrote:
Bootstrapped and regtested on x86-64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here we deem the array-to-pointer conversions in both calls as invalid,
but we fail to issue a diagnostic for the second call, ultimately because
cp_build_c_cast does
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
My change for PR53220 made array to pointer decay for prvalue arrays
ill-formed to catch well-defined C code that produces a dangling pointer in
C++ due to the shorter lifetime of compound literals. This wasn't really
correct, but wasn't a
On Tue, 28 Nov 2023 at 20:31, Palmer Dabbelt wrote:
>
> On Wed, 22 Nov 2023 14:27:50 PST (-0800), jeffreya...@gmail.com wrote:
> > ...
>
> [Trimming everything else, as this is a big change. I'm also making it
> a new subject/thread, so folks can see.]
>
> > More generally, I think I need to soft
Hi FX,
On 11/28/23 18:07, FX Coudert wrote:
Hi Harald,
The patch looks OK to me. Probably wait a bit for another opinion, since I’m
not that active and I may have missed something.
Thanks,
FX
thanks for having a look.
In the meantime I got an automated mail from the Linaro testers.
Accordi
On Fri, 17 Nov 2023 16:01:27 PST (-0800), jeffreya...@gmail.com wrote:
On 11/17/23 16:16, 钟居哲 wrote:
>> I assume this hunk is meant for riscv_output_operand in riscv.cc. We
may also need to add '^' to the punct_valid_p hook. But yes, this is
the preferred way to go when all we need to do i
On Wed, 22 Nov 2023 14:27:50 PST (-0800), jeffreya...@gmail.com wrote:
...
[Trimming everything else, as this is a big change. I'm also making it
a new subject/thread, so folks can see.]
More generally, I think I need to soften my prior statement about
deferring this to gcc-15. This code
On Tue, Nov 28, 2023 at 7:38 AM wrote:
>
> From: Ezra Sitorus
>
> Add the transform rule (T)(~A) -> ~(T)(A) for view_convert. The simplified
> result could be a single assembly instruction when chained with other
> instructions.
>
> gcc/ChangeLog:
> * match.pd: Add new transform rule.
>
> Am 28.11.2023 um 18:38 schrieb Jan Hubicka :
>
>
>>
>>
>>
Am 28.11.2023 um 17:59 schrieb Jan Hubicka :
>>>
>>>
> On Tue, 28 Nov 2023, Martin Jambor wrote:
>
> On Tue, Nov 28 2023, Richard Biener wrote:
>> On Mon, 27 Nov 2023, Martin Jambor wrote:
>>
>>
Richard Sandiford writes:
> Tamar Christina writes:
>> Hi All,
>>
>> This adds an implementation for conditional branch optab for AArch64.
>>
>> For e.g.
>>
>> void f1 ()
>> {
>> for (int i = 0; i < N; i++)
>> {
>> b[i] += a[i];
>> if (a[i] > 0)
>> break;
>> }
>> }
>>
>
On Tue, Nov 28, 2023 at 11:31:48AM -0500, Jason Merrill wrote:
> > + if (len)
> > + {
> > + if (data)
> > + msg = c_getstr (data);
> > + if (msg == NULL)
> > + buf = XNEWVEC (char, len);
>
> Jonathan pointed out elsewhere that t
On 11/28/23 10:30, Jakub Jelinek wrote:
On Tue, Nov 28, 2023 at 02:19:36PM +0200, Manolis Tsamis wrote:
So, like this (so far untested)?
Note, the earlier posted patch passed bootstrap/regtest on
{powerpc64le,x86_64,i686}-linux.
Testing revealed this fails miserably, artificial uses don't
On 11/27/23 13:52, Jakub Jelinek wrote:
On Mon, Oct 16, 2023 at 01:11:01PM -0600, Jeff Law wrote:
gcc/ChangeLog:
* Makefile.in: Add fold-mem-offsets.o.
* passes.def: Schedule a new pass.
* tree-pass.h (make_pass_fold_mem_offsets): Declare.
* common.opt: New op
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
>
>
> > Am 28.11.2023 um 17:59 schrieb Jan Hubicka :
> >
> >
> >>
> >>> On Tue, 28 Nov 2023, Martin Jambor wrote:
> >>>
> >>> On Tue, Nov 28 2023, Richard Biener wrote:
> On Mon, 27 Nov 2023, Martin Jambor wrote:
>
> > Hi,
> >
> > The enhancement to address PR 109849
On Tue, Nov 28, 2023 at 02:19:36PM +0200, Manolis Tsamis wrote:
> > So, like this (so far untested)?
> >
> > Note, the earlier posted patch passed bootstrap/regtest on
> > {powerpc64le,x86_64,i686}-linux.
Testing revealed this fails miserably, artificial uses don't really
have DF_REF_INSN, so I'm
> Am 28.11.2023 um 17:59 schrieb Jan Hubicka :
>
>
>>
>>> On Tue, 28 Nov 2023, Martin Jambor wrote:
>>>
>>> On Tue, Nov 28 2023, Richard Biener wrote:
On Mon, 27 Nov 2023, Martin Jambor wrote:
> Hi,
>
> The enhancement to address PR 109849 contained an importsnt thin
On 11/28/23 12:12, Jakub Jelinek wrote:
On Tue, Nov 28, 2023 at 04:45:41PM +, Alex Coplan wrote:
--- gcc/cp/cp-objcp-common.cc.jj2023-11-27 17:34:25.0 +0100
+++ gcc/cp/cp-objcp-common.cc 2023-11-28 08:55:18.868419864 +0100
@@ -145,7 +145,7 @@ static constexpr cp_feature_inf
On Tue, Nov 28, 2023 at 04:45:41PM +, Alex Coplan wrote:
> > --- gcc/cp/cp-objcp-common.cc.jj2023-11-27 17:34:25.0 +0100
> > +++ gcc/cp/cp-objcp-common.cc 2023-11-28 08:55:18.868419864 +0100
> > @@ -145,7 +145,7 @@ static constexpr cp_feature_info cp_feat
> >{ "cxx_context
On 11/28/23 12:08, Thomas Schwinge wrote:
Hi!
On 2023-11-23T09:32:24+0100, Jakub Jelinek wrote:
Here is what I've committed
--- gcc/testsuite/g++.dg/cpp26/static_assert1.C.jj2023-11-22
10:17:41.340064988 +0100
+++ gcc/testsuite/g++.dg/cpp26/static_assert1.C 2023-11-22
10:47:45.0
On 11/28/23 11:03, Thomas Schwinge wrote:
Hi!
On 2023-11-17T14:50:45+, Alex Coplan wrote:
--- a/gcc/cp/cp-objcp-common.cc
+++ b/gcc/cp/cp-objcp-common.cc
+/* Table of features for __has_{feature,extension}. */
+
+static constexpr cp_feature_info cp_feature_table[] =
+{
+ { "cxx_except
Hi!
On 2023-11-23T09:32:24+0100, Jakub Jelinek wrote:
> Here is what I've committed
> --- gcc/testsuite/g++.dg/cpp26/static_assert1.C.jj2023-11-22
> 10:17:41.340064988 +0100
> +++ gcc/testsuite/g++.dg/cpp26/static_assert1.C 2023-11-22
> 10:47:45.045848504 +0100
> @@ -0,0 +1,309 @@
>
On 11/28/23 03:22, Jakub Jelinek wrote:
On Mon, Nov 27, 2023 at 10:58:04AM +, Alex Coplan wrote:
Many thanks both for the reviews, this is now pushed (with Jason's
above changes implemented) as g:06280a906cb3dc80cf5e07cf3335b758848d488d.
The new test FAILs everywhere with GXX_TESTSUITE_STD
Hi Harald,
The patch looks OK to me. Probably wait a bit for another opinion, since I’m
not that active and I may have missed something.
Thanks,
FX
> On Tue, 28 Nov 2023, Martin Jambor wrote:
>
> > On Tue, Nov 28 2023, Richard Biener wrote:
> > > On Mon, 27 Nov 2023, Martin Jambor wrote:
> > >
> > >> Hi,
> > >>
> > >> The enhancement to address PR 109849 contained an importsnt thinko,
> > >> and that any reference that is passed to a functio
On 28/11/2023 17:03, Thomas Schwinge wrote:
> Hi!
>
> On 2023-11-17T14:50:45+, Alex Coplan wrote:
> > --- a/gcc/cp/cp-objcp-common.cc
> > +++ b/gcc/cp/cp-objcp-common.cc
>
> > +/* Table of features for __has_{feature,extension}. */
> > +
> > +static constexpr cp_feature_info cp_feature_tabl
This adds a sanity check to cp_parser_expression_statement similar to
the one in finish_expr_stmt added by r6-6795-g0fd9d4921f7ba2, which
effectively downgrades accepts-invalid/wrong-code bugs like this one
into ice-on-invalid/ice-on-valid ones.
PR c++/112658
gcc/cp/ChangeLog:
*
Bootstrapped and regtested on x86-64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here we deem the array-to-pointer conversions in both calls as invalid,
but we fail to issue a diagnostic for the second call, ultimately because
cp_build_c_cast doesn't replay errors from build_const_cast_1.
Marc Poulhiès writes:
> Simon Wright writes:
>> gcc/ada/Changelog:
>>
>> 2023-11-22 Simon Wright
>>
>> PR ada/111909
>>
>> Can we commit this one now, please?
>
> Hello Simon,
>
> Yes we can commit this one, as both Iain and Arnaud ACKed it.
>
> I'll create a proper commit with the change
On 28/11/2023 09:22, Jakub Jelinek wrote:
> On Mon, Nov 27, 2023 at 10:58:04AM +, Alex Coplan wrote:
> > Many thanks both for the reviews, this is now pushed (with Jason's
> > above changes implemented) as g:06280a906cb3dc80cf5e07cf3335b758848d488d.
>
> The new test FAILs everywhere with GXX_T
Hi Victor,
> -Original Message-
> From: Victor Do Nascimento
> Sent: Tuesday, November 28, 2023 3:56 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Sandiford
> ; Richard Earnshaw
> ; Victor Do Nascimento
>
> Subject: [PATCH v2 3/5] aarch64: Sync `aarch64-sys-regs.def' wi
Tamar Christina writes:
> Hi All,
>
> This adds an implementation for conditional branch optab for AArch64.
>
> For e.g.
>
> void f1 ()
> {
> for (int i = 0; i < N; i++)
> {
> b[i] += a[i];
> if (a[i] > 0)
> break;
> }
> }
>
> For 128-bit vectors we generate:
>
>
On Tue, 28 Nov 2023, Martin Jambor wrote:
> On Tue, Nov 28 2023, Richard Biener wrote:
> > On Mon, 27 Nov 2023, Martin Jambor wrote:
> >
> >> Hi,
> >>
> >> The enhancement to address PR 109849 contained an importsnt thinko,
> >> and that any reference that is passed to a function and does not
> >
On 11/23/23 03:32, Jakub Jelinek wrote:
On Wed, Nov 22, 2023 at 04:53:48PM -0500, Jason Merrill wrote:
I agree it's weird to get two of the same error, but maybe instead of
duplicating the error, we could look up data only if size succeeded, and
then error once if either failed?
Here is what I
On 11/24/23 03:34, Jakub Jelinek wrote:
On Mon, Sep 18, 2023 at 07:12:40PM +0200, Jakub Jelinek via Gcc-patches wrote:
On Tue, Aug 22, 2023 at 09:39:11AM +0200, Jakub Jelinek via Gcc-patches wrote:
The following patch implements the C++26 P2169R4 paper.
As written in the PR, the patch expects t
On Tue, Nov 28 2023, Richard Biener wrote:
> On Mon, 27 Nov 2023, Martin Jambor wrote:
>
>> Hi,
>>
>> The enhancement to address PR 109849 contained an importsnt thinko,
>> and that any reference that is passed to a function and does not
>> escape, must also not happen to be aliased by the return
Hi Christophe,
On 11/20/2023 10:12 AM, Christophe Lyon wrote:
Hi Saurabh,
On Tue, 14 Nov 2023 at 15:51, Kyrylo Tkachov wrote:
Hi Saurabh,
-Original Message-
From: Saurabh Jha
Sent: Thursday, November 9, 2023 10:12 AM
To: gcc-patches@gcc.gnu.org; Richard Earnshaw
; Richard Sandiford
On Tue, Nov 28, 2023 at 5:44 AM Andrew Pinski wrote:
>
> This fixes the incorrect assumption that was done in r14-3721-ge6bcf839894783,
> that being able to doing the negative after the conversion would be a valid
> thing
> but really it is not valid for boolean types.
>
> OK? Bootstrapped and te
Hi!
On 2023-11-17T14:50:45+, Alex Coplan wrote:
> --- a/gcc/cp/cp-objcp-common.cc
> +++ b/gcc/cp/cp-objcp-common.cc
> +/* Table of features for __has_{feature,extension}. */
> +
> +static constexpr cp_feature_info cp_feature_table[] =
> +{
> + { "cxx_exceptions", &flag_exceptions },
> + {
On Tue, Nov 28, 2023 at 2:24 PM Rainer Orth
wrote:
>
> The gcc.dg/scantest-lto.c test FAILs on Solaris/SPARC with the native as:
>
> FAIL: gcc.dg/scantest-lto.c scan-assembler-not ascii
> FAIL: gcc.dg/scantest-lto.c scan-assembler-times ascii 0
>
> It requires double-quoting the section name whic
REPZ CMPSB instruction does not update FLAGS register when %ecx register
equals zero. Improve cmpstrnqi_1 insn pattern to set FLAGS_REG to its
previous value instead of (const_int 0) when operand 2 equals zero.
PR target/112494
gcc/ChangeLog:
* config/i386/i386.md (cmpstrnqi_1): Set FLA
The GIMPLE frontend, when bypassing gimplification, doesn't set
DECL_SEEN_IN_BIND_EXPR_P given there are no such things in GIMPLE.
But it probably should set the flag anyway to avoid later ICEs
when regimplifying.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR middle-end/
The following fixes a stray TYPE_ALIAS_SET in a type variant built
by build_opaque_vector_type which is diagnosed by type checking
enabled with -flto.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR middle-end/112732
* tree.cc (build_opaque_vector_type): Reset TYPE
This patch updates `aarch64-sys-regs.def', bringing it into sync with
the Binutils source.
gcc/ChangeLog:
* config/aarch64/aarch64-sys-regs.def (par_el1): New.
(rcwmask_el1): Likewise.
(rcwsmask_el1): Likewise.
(ttbr0_el1): Likewise.
(ttbr0_el12): Likewise.
Given the introduction of optional 128-bit page table descriptor and
translation hardening extension support with the Arm9.4-a
architecture, this introduces the relevant flags to enable the reading
and writing of 128-bit system registers.
The `+d128' -march modifier enables the use of the followin
Implement the ACLE builtins for 128-bit system register manipulation:
* __uint128_t __arm_rsr128(const char *special_register);
* void __arm_wsr128(const char *special_register, __uint128_t value);
gcc/ChangeLog:
* config/aarch64/aarch64-builtins.cc (AARCH64_RSR128): New
`enu
Extend existing unit tests for the ACLE system register manipulation
functions to include 128-bit tests.
gcc/testsuite/ChangeLog:
* gcc/testsuite/gcc.target/aarch64/acle/rwsr.c (get_rsr128): New.
(set_wsr128): Likewise.
---
gcc/testsuite/gcc.target/aarch64/acle/rwsr.c | 32 ++
Changes from v1 -
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635531.html
* [PATCH 4/5] - For `error_at' message, put feature name in quotes.
* [PATCH 4/5] - For `aarch64_retrieve_sysreg' function, add
description of new parameter to comments.
* [PATCH 5/5] - Reduce the minimum
Given the introduction of system registers associated with the Guarded
Control Stack extension to Armv9.4-a in Binutils and their reliance on
the `+gcs' modifier, we implement the necessary changes in GCC to
allow for them to be recognized by the compiler.
gcc/ChangeLog:
* config/aarch64/
Reverted! Apologies for the mistake.
Jose E. Marchesi writes:
>> Hi Cuper.
>> OK. Thanks for the patch.
>
> This commit is breaking the BPF build, because libgcc emits libcalls to
> __builtin_abort. We need to rethink this.
>
> Please revert:
>
> commit faf5b148588bd7fbb60ec669aefa704044037c
On Tue, Nov 28, 2023 at 05:44:43PM +0800, Kewen.Lin wrote:
> on 2023/11/28 15:05, Michael Meissner wrote:
> > I tried using this patch to compare with the vector size attribute patch I
> > posted. I could not build it as a cross compiler on my x86_64 because the
> > assembler gives the following e
> Hi Cuper.
> OK. Thanks for the patch.
This commit is breaking the BPF build, because libgcc emits libcalls to
__builtin_abort. We need to rethink this.
Please revert:
commit faf5b148588bd7fbb60ec669aefa704044037cdc
Author: Cupertino Miranda
Date: Thu Nov 23 22:28:01 2023 +
Tha
From: Ezra Sitorus
Add the transform rule (T)(~A) -> ~(T)(A) for view_convert. The simplified
result could be a single assembly instruction when chained with other
instructions.
gcc/ChangeLog:
* match.pd: Add new transform rule.
*
testsuite/gcc.target/aarch64/advsimd-intrinsic
> "Jose E. Marchesi" writes:
>> There are many places in GCC where alternative local sequences are
>> tried in order to determine what is the cheapest or best alternative
>> to use in the current target. When any of these sequences involve a
>> libcall, the current implementation of emit_librar
Richard Biener writes:
> On Sun, 19 Nov 2023, Jeff Law wrote:
>
>>
>>
>> On 11/19/23 00:30, Alexandre Oliva wrote:
>> >
>> > I've recently patched scev-3.c and scev-5.c because it only passed by
>> > accident on ia32. It also fails on some (but not all) arm-eabi
>> > variants. It seems hard
On 28/11/2023 06:06, Jeff Law wrote:
- Verify we have a SUBREG before looking at SUBREG_BYTE.
The amdgcn ICE I reported still exists:
conftest.c:16:1: internal compiler error: RTL check: expected code 'subreg',
have 'reg' in ext_dce_process_uses, at ext-dce.cc:417
16 | }
| ^
0x8c7b2
On 11/28/23 00:50, Richard Biener wrote:
There's no way to distinguish a partial vs. non-partial MEM on RTL and
while without the bogus MEM_ATTR the alias oracle pieces that
miscompiled the original case are fended off we still see the load/store
as full given they have a mode with a size -
Hi Andrew,
On 27.11.23 18:35, Andrew Jenner wrote:
This is the second version of the patch - previous discussion at:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636671.html
This patch adds the testcase from PR110415 and fixes the bug.
The problem is that in a couple of places in tr
On Tue, 28 Nov 2023 at 13:36, Joern Rennecke
wrote:
> For the saturating truncation operations, we have the high-to-low
propagation,
> but no low-to-high propagation, so that would be something separate to model.
P.S.:
For unsigned saturating truncation, the propagation from higher to
lower bits
1 - 100 of 176 matches
Mail list logo
