Attached is what I have for carry_backpropagate .
The utility of special handling for SS_ASHIFT / US_ASHIFT seems
somewhat marginal.
I suspect it'd be more useful to add handling of LSHIFTRT and ASHIFTRT
. Some ports do
a lot of static shifting.
commit ed47c3d0d38f85c9b4e22bdbd079e0665465ef9c
Au
On Wed, Nov 29, 2023 at 8:24 PM Patrick O'Neill wrote:
>
> Hi Christoph,
>
> The precommit-ci is seeing a large number of ICE segmentation faults as a
> result of this patch:
> https://github.com/ewlu/gcc-precommit-ci/issues/796#issuecomment-1831853523
>
> The failures aren't in riscv.exp testsui
On Wed, 29 Nov 2023 at 19:57, Joern Rennecke
wrote:
>
> Attached is what I have for carry_backpropagate .
>
> The utility of special handling for SS_ASHIFT / US_ASHIFT seems
> somewhat marginal.
>
> I suspect it'd be more useful to add handling of LSHIFTRT and ASHIFTRT
> . Some ports do
> a lot o
On 11/29/23 12:43, Marek Polacek wrote:
On Wed, Nov 29, 2023 at 12:23:46PM -0500, Patrick Palka wrote:
On Wed, 29 Nov 2023, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
Now that I'm posting this patch, I think you'll probably want me to use
ba_any uncondit
The intrinsics that use macros are the ones that require an integer constant
expression for one of the arguments. Clang needs to be able to see the constant
expression as an argument to the underlying builtin. Thus the macro.
Based on my previous x86 experience, gcc may only require a macro for
On 11/29/23 13:56, Marek Polacek wrote:
On Mon, Nov 20, 2023 at 04:29:33PM -0500, Jason Merrill wrote:
On 11/17/23 16:46, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This patch is an attempt to implement (part of?) P2280, Using unknown
pointers an
On 11/29/23 14:42, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linu-xgnu, does this look OK for
trunk?
OK.
-- >8 --
We need to consistently look through implicit INDIRECT_REF when
setting/checking for -Wparentheses warning suppression. In passing
use STRIP_REFERENCE_REF con
Hi Tsukasa,
I'm seeing a new regression across all tested riscv targets:
https://github.com/patrick-rivos/gcc-postcommit-ci/issues/224
Regression:
|FAIL: gcc.target/riscv/predef-13.c -O0 (test for excess errors) FAIL:
gcc.target/riscv/predef-13.c -O1 (test for excess errors) FAIL:
gcc.target/
Dear all,
the attached simple patch fixes the handling of the TARGET
attribute of an associate variable in an ASSOCIATE construct.
See e.g. F2018:11.1.3.3 for a standard reference.
(Note that the patch does not touch the pointer or allocatable
attributes, as that would lead to several testsuite
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, November 29, 2023 2:29 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> Subject: RE: [PATCH 8/21]middle-end: update vectorizable_live_reduction
> with support for multiple exits and differen
These build-ins are used internally for the
TARGET_ATOMIC_ASSIGN_EXPAND_FENV expansion (and therefore can not be
removed):
/* Implement TARGET_ATOMIC_ASSIGN_EXPAND_FENV. */
void
riscv_atomic_assign_expand_fenv (tree *hold, tree *clear, tree *update)
{
if (!(TARGET_HARD_FLOAT || TARGET_ZFINX))
On Wed, Nov 29, 2023 at 01:58:31PM -0500, Jason Merrill wrote:
> On 11/29/23 10:45, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > Now that I'm posting this patch, I think you'll probably want me to use
> > ba_any unconditionally. That works too; g++
On Wed, Nov 29, 2023 at 03:28:44PM -0500, Jason Merrill wrote:
> On 11/29/23 12:43, Marek Polacek wrote:
> > On Wed, Nov 29, 2023 at 12:23:46PM -0500, Patrick Palka wrote:
> > > On Wed, 29 Nov 2023, Marek Polacek wrote:
> > >
> > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
On Mon, Nov 20, 2023 at 11:57 AM Björn Schäpers wrote:
>
> this is what I'm using with GCC 12 and 13 on my windows machines, rebased onto
> the current HEAD.
Thanks. Committed as follows.
Ian
* fileline.c: Include if available.
(windows_get_executable_path): New static
Hi Patrick,
Found a cause (although GCC is functionally correct, I forgot to fix
corresponding test case [which assumes that 'E' is not ratified]).
> #if !defined(__riscv_e) || (__riscv_e != (1 * 1000 * 1000 + 9 * 1000))
> #error "__riscv_e"
> #endif
1*1000*1000 + 9*1000 ('E' version 1.9) should
Fix for Robin's suggestion.
gcc/ChangeLog:
* config/riscv/constraints.md (TARGET_VECTOR ? V_REGS : NO_REGS): Fix
constraint.
* config/riscv/riscv.md (no,W21,W42,W84,W41,W81,W82): Rename
vconstraint into group_overlap.
(no,yes): Ditto.
(none,W21,W42,W84,W43,W86,W8
gcc/ChangeLog:
doc/extend.texi: Update builtin example for __builtin_FILE
__builtin_LINE __builtin_FUNCTION.
>From 66290eb477dd1a99310ad9972c45391c2a87c1c7 Mon Sep 17 00:00:00 2001
From: Jonathan Grant
Date: Wed, 29 Nov 2023 11:02:06 +
Subject: [PATCH] gcc/doc: Update builtin example for
Not my specialist subject, but here goes anyway:
Wilco Dijkstra writes:
> ping
>
> From: Wilco Dijkstra
> Sent: 02 June 2023 18:28
> To: GCC Patches
> Cc: Richard Sandiford ; Kyrylo Tkachov
>
> Subject: [PATCH] libatomic: Enable lock-free 128-bit atomics on AArch64
> [PR110061]
>
>
> Enable l
Applied to master, thanks!
Philipp.
On Tue, 28 Nov 2023 at 12:57, Richard Sandiford
wrote:
>
> Philipp Tomsich writes:
> > On Tue, 28 Nov 2023 at 12:21, Richard Sandiford
> > wrote:
> >>
> >> Philipp Tomsich writes:
> >> > This patch adds initial support for Ampere-1B core.
> >> >
> >> > The A
On Thu, Nov 09, 2023 at 04:16:10PM -0500, Lewis Hyatt wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111918
>
> This patch fixes the behavior of `#pragma GCC diagnostic pop' for permissive
> error diagnostics such as -Wnarrowing (in C++11). Those currently do not
> return to the correct sta
Pre-approve the fix :)
On Thu, Nov 30, 2023 at 6:07 AM Tsukasa OI wrote:
>
> Hi Patrick,
>
> Found a cause (although GCC is functionally correct, I forgot to fix
> corresponding test case [which assumes that 'E' is not ratified]).
>
> > #if !defined(__riscv_e) || (__riscv_e != (1 * 1000 * 1000 +
This patch leverages the approach of vwcvt/vext.vf2 which has been approved.
Their approaches are totally the same.
Tested no regression and committed.
PR target/112431
gcc/ChangeLog:
* config/riscv/vector.md: Add widenning overlap.
gcc/testsuite/ChangeLog:
* gcc.targe
On Wed, 29 Nov 2023 at 20:05, Joern Rennecke
wrote:
> > I suspect it'd be more useful to add handling of LSHIFTRT and ASHIFTRT
> > . Some ports do
> > a lot of static shifting.
>
> > +case SS_ASHIFT:
> > +case US_ASHIFT:
> > + if (!mask || XEXP (x, 1) == const0_rtx)
> > + retu
From: Tsukasa OI
Commit 006e90e1 ("RISC-V: Initial RV64E and LP64E support") caused a
regression (test failure) but this is caused by failing to track GCC
changes in that test case (not a true GCC bug).
This commit fixes the test case to track the latest GCC with 'E'
extension version 2.0 (ratif
From: chenxiaolong
gcc/ChangeLog:
* doc/extend.texi: Add information about the intrinsic function of the
vector
instruction.
Change-Id: I0117d6f5d68731f1596b6c3016fd82f3d5e2a98d
---
gcc/doc/extend.texi | 1662 +++
1 file changed, 1662 in
Hi, Richard and Tamar.
I am sorry for bothering you.
Hope you don't mind I give some comments:
Can we support partial vector for length ?
IMHO, we can do that as follows:
bool length_loop_p = LOOP_VINFO_FULLY_WITH_LENGTH_P (loop_vinfo);
if (LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo))
I originally computed mmask in carry_backpropagate from XEXP (x, 0),
but abandoned that when I realized we also get called for RTX_OBJ
things. I forgot to adjust the SIGN_EXTEND code, though. Fixed
in the attached revised patch. Also made sure to not make inputs
of LSHIFTRT / ASHIFTRT live if t
On Nov 29, 2023, Richard Biener wrote:
>> Because &arg_#(D)[n_#] is good gimple, but &(*byref_arg_#(D))[n_#] isn't.
> 'arg_#(D)' looks like a SSA name, and no, taking the address doesn't work,
> so I assume it was &MEM[arg_(D)][n_#] which is indeed OK.
Yeah.
> But you shouldn't need to change
On Nov 29, 2023, Hans-Peter Nilsson wrote:
>> XPASS: gcc.dg/tree-ssa/scev-3.c scan-tree-dump-times ivopts "&a" 1
>> XPASS: gcc.dg/tree-ssa/scev-4.c scan-tree-dump-times ivopts "&a" 1
>> XPASS: gcc.dg/tree-ssa/scev-5.c scan-tree-dump-times ivopts "&a" 1
> It XPASSes on the ilp32 targets I've trie
On 11/27/23 00:35, waffl3x wrote:
I think this is cleaned up enough to be presentable. Bootstrapped but
not tested but I don't think I changed anything substantial. I am
running tests right now and will report if anything fails. I have not
fixed the problem in tsubst_lambda_expr that we talked ab
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 remove it.
gcc/cp/ChangeLog:
* cp-tree.h (LAMBDA_
On Nov 29, 2023, Richard Biener wrote:
> On Wed, Nov 29, 2023 at 9:53 AM Alexandre Oliva wrote:
>> Because &arg_#(D)[n_#] is good gimple, but &(*byref_arg_#(D))[n_#] isn't.
> 'arg_#(D)' looks like a SSA name, and no, taking the address doesn't work,
> so I assume it was &MEM[arg_(D)][n_#] whic
This patch add the Zvkb subset of crypto vector extension. The
corresponding test cases have aslo been modified.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc: Add zvkb ISA info.
* config/riscv/riscv.opt: Add Mask(ZVKB)
gcc/testsuite/ChangeLog:
* gcc.target/riscv/
On Wednesday, November 29th, 2023 at 10:00 PM, Jason Merrill
wrote:
>
>
> On 11/27/23 00:35, waffl3x wrote:
>
> > I think this is cleaned up enough to be presentable. Bootstrapped but
> > not tested but I don't think I changed anything substantial. I am
> > running tests right now and
On 27 November 2023 15:48:33 CET, Thomas Schwinge
wrote:
>Hi!
>
>On 2023-10-28T21:19:59+0200, Samuel Thibault wrote:
>> We need the multilib paths in gcc to find e.g. glibc crt files on
>> Debian.
>
>ACK.
>
>> This is essentially based on t-linux64 version.
>
>Yes, but isn't the overall setup di
size_t
foo (char const *buf, size_t len)
{
size_t sum = 0;
size_t vl = __riscv_vsetvlmax_e8m8 ();
size_t step = vl * 4;
const char *it = buf, *end = buf + len;
for (; it + step <= end;)
{
vint8m1_t v0 = __riscv_vle8_v_i8m1 ((void *) it, vl);
it += vl;
vint8m1_t v1
LGTM, thanks :)
On Thu, Nov 30, 2023 at 2:49 PM Juzhe-Zhong wrote:
>
>
> size_t
> foo (char const *buf, size_t len)
> {
> size_t sum = 0;
> size_t vl = __riscv_vsetvlmax_e8m8 ();
> size_t step = vl * 4;
> const char *it = buf, *end = buf + len;
> for (; it + step <= end;)
> {
>
LGTM
On Thu, Nov 30, 2023 at 2:16 PM Feng Wang wrote:
>
> This patch add the Zvkb subset of crypto vector extension. The
> corresponding test cases have aslo been modified.
>
> gcc/ChangeLog:
>
> * common/config/riscv/riscv-common.cc: Add zvkb ISA info.
> * config/riscv/riscv.opt:
From: Pan Li
When require mode after get_vec_mode in riscv_legitimize_move,
there will be precondition that the mode is exists. Or we will
have E_VOIDMode and of course have ICE when required.
Typically we should first check the mode exists or not before
require, or more friendly like leverage e
On Nov 29, 2023, Jason Merrill wrote:
> On 11/29/23 04:39, Alexandre Oliva wrote:
>> Hello, Jason,
>> On Nov 22, 2023, Jason Merrill wrote:
>>
>>> On 11/22/23 13:12, Jason Merrill wrote:
I'm coming to the conclusion that your C++ patch is fine but we
should remove the TYPE_PACKED warn
Why does get_vector_mode doesn't exist a vector mode ?
It must exist a vector mode, otherwise, it will cause ICE in other situations.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-11-30 15:21
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Bugfi
> Why does get_vector_mode doesn't exist a vector mode ?
Because we set the zve32f here, but try to get_vect_mode with E_V1DFmode.
According to the ISA, FP64 is not support when zve32F.
Pan
From: juzhe.zh...@rivai.ai
Sent: Thursday, November 30, 2023 3:24 PM
To: Li, Pan2 ; gcc-patches
Cc: Li,
Take this file riscv-gnu-toolchain/newlib/newlib/libc/stdlib/mprec.c for
example, the arguments and/or related local variables list as below
riscv_legitimize_move
mode = E_DFmode
dest = (reg:DF 144 [ ])
src = (subreg:DF (reg:V2SI 170) 0)
nunits = 1
smode = {m_mode = E_DFmode}
Pan
From:
The libgcc-exported runtime component of control flow redundancy
hardening was missing symbol versioning information. Add it.
Regstrapped on x86_64-linux-gnu. Ok to install?
for libgcc/ChangeLog
* libgcc-std.ver.in (__hardcfr_check): Add to GCC_14.0.0.
---
libgcc/libgcc-std.ver.in
101 - 144 of 144 matches
Mail list logo
