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
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:
> 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,
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
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
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
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:
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;)
> {
>
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
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
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
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 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
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 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
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 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
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
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))
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
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
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
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
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 +
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
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
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
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
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
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
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
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 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++
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))
> -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
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
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/
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
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
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 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
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 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
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
Bootstrapped and regtested on x86_64-pc-linu-xgnu, does this look OK for
trunk?
-- >8 --
We need to consistently look through implicit INDIRECT_REF when
setting/checking for -Wparentheses warning suppression. In passing
use STRIP_REFERENCE_REF consistently as well.
PR c++/112765
gcc/cp
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 testsuite files so that's likely why
you didn't run into them in your test
The reason is removing MINUS from safe_for_live_propagation.
We did not do it on purpose, will roll back on V3.
> On 29 Nov 2023, at 19:46, Xi Ruoyao wrote:
>
> On Wed, 2023-11-29 at 20:37 +0800, Xi Ruoyao wrote:
>>> On Wed, 2023-11-29 at 17:33 +0800, Xi Ruoyao wrote:
>>> On Mon, 2023-11-2
We already noticed it and will roll back in V3
With the best regards
Jivan Hakobyan
> On 29 Nov 2023, at 21:37, Joern Rennecke wrote:
>
> Why did you leave out MINUS from safe_for_live_propagation ?
Hi David.
OK. Thanks.
> The BPF "pseudo-C" assembly dialect uses semi-colon (;) to separate
> statements, not to begin line comments. The GNU assembler was recently
> changed accordingly:
>
> https://sourceware.org/pipermail/binutils/2023-November/130867.html
>
> This patch adapts the BPF bac
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 warning from
check_address_or_pointer_of_packed_member. And may
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++.dg/tc1/dr52.C just needs
a trivial testsuite tweak:
'C' is not an accessibl
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 and references in consta
On 11/29/23 13:01, Jakub Jelinek wrote:
On Tue, Nov 28, 2023 at 11:27:55AM -0500, Jason Merrill wrote:
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
The BPF "pseudo-C" assembly dialect uses semi-colon (;) to separate
statements, not to begin line comments. The GNU assembler was recently
changed accordingly:
https://sourceware.org/pipermail/binutils/2023-November/130867.html
This patch adapts the BPF backend in GCC accordingly, to use a hash
Hi!
Given that the s390 backend defines pretty much the same target hook
as rs6000, I believe it suffers (at least when using -mvx?) the same
problem as rs6000, though admittedly this is so far completely
untested.
Ok for trunk if it passes bootstrap/regtest there?
2023-11-29 Jakub Jelinek
Hi!
The rs6000 backend (and s390 one as well) diagnoses passing vector types
to unprototyped functions, which breaks the builtin-classify-type-1.c test.
The builtin isn't really unprototyped, it is just type-generic and accepting
vector types is just fine there, all it does is categorize the vecto
On Tue, Nov 28, 2023 at 11:27:55AM -0500, Jason Merrill wrote:
> 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 fo
Wilco Dijkstra writes:
> v2: further cleanups, improved comments
>
> Add support for inline memmove expansions. The generated code is identical
> as for memcpy, except that all loads are emitted before stores rather than
> being interleaved. The maximum size is 256 bytes which requires at most 1
Wilco Dijkstra writes:
> v2: Use UINTVAL, rename max_mops_size.
>
> The cpymemdi/setmemdi implementation doesn't fully support strict alignment.
> Block the expansion if the alignment is less than 16 with STRICT_ALIGNMENT.
> Clean up the condition when to use MOPS.
>
> Passes regress/bootstrap, OK
> From: Rainer Orth
> Date: Tue, 28 Nov 2023 16:13:35 +0100
> 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
On Wed, Nov 29, 2023 at 5:49 PM Liao Shihua wrote:
>
>
> 在 2023/11/29 23:03, Christoph Müllner 写道:
>
> On Mon, Nov 27, 2023 at 9:36 AM 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
Andrew Carlotti writes:
> This patch adds support for the "target_version" attribute to the middle
> end and the C++ frontend, which will be used to implement function
> multiversioning in the aarch64 backend.
>
> On targets that don't use the "target" attribute for multiversioning,
> there is no
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 unconditionally. That works too
Why did you leave out MINUS from safe_for_live_propagation ?
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 unconditionally. That works too; g++.dg/tc1/dr52.C just needs
> a trivial testsuite tweak:
> 'C' is not
On 22/11/2023 14:26, Tobias Burnus wrote:
Hi Andrew,
Side remark:
-#define MEMSPACE_CALLOC(MEMSPACE, SIZE) \ - calloc (1,
(((void)(MEMSPACE), (SIZE
This fits a bit more to previous patch, but I wonder whether that should
use (MEMSPACE, NMEMB, SIZE) instead - to fit to the actual calloc
"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, following the ABI rules where the
>> w
This patch utilizes the new check_operands_p() routine in range-ops to
verify the operands are compatible before IPA tries to call
fold_range(). I do not know if there are other places in IPA that
should be checking this, but we have a bug report for this place at least.
The other option wou
I've been going back and forth with this for the past week, and finally
settled on a solution
This patch adds an operand_check_p() (lhs_type, op1_type, op2_type)
method to range_ops which will confirm whether the types of the operands
being passed to fold_range, op1_range, and op2_range are p
在 2023/11/29 23:03, Christoph Müllner 写道:
On Mon, Nov 27, 2023 at 9:36 AM 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 manipulati
On Thu, 23 Nov 2023, Jonathan Wakely wrote:
> Here's the finished version of the std::ranges::to patch, which I've
> pushed to trunk.
>
> Tested x86_64-linux.
>
> -- >8 --
>
> This adds the std::ranges::to functions for C++23. The rest of P1206R7
> is not yet implemented, i.e. the new construct
On 08/09/2023 10:04, Tobias Burnus wrote:
Regarding patch 2/3 and MEMSPACE_VALIDATE.
In general, I wonder how to handle memory spaces (and traits) that
aren't supported. Namely, when to return 0L and when to silently use
ignore the trait / use another memory space.
The current omp_init_allocat
Hi Julian,
On 29.11.23 12:43, Julian Brown wrote:
Here is a patch incorporating your initial review comments
(hopefully!).
Thanks.
The patch LGTM - with the two remarks below addressed.
(i.e. fixing one testcase and filing two PRs (or common PR) about the features
missing and exposed by the
The 11/10/2023 19:48, Florian Weimer wrote:
> * config/aarch64/linux-unwind.h
> (aarch64_fallback_frame_state): Add cast to the expected type
> in sc assignment.
>
> (Almost a v2, but the other issue was already fixed via in r14-4183.)
>
> ---
> libgcc/config/aarch64/linux-unwi
Sorry for the very slow review on this. It LGTM apart from some
minor comments below:
"Andre Vieira (lists)" writes:
> Hey,
>
> Just a minor update to the patch, I had missed the libgomp testsuite, so
> had to make some adjustments there too.
>
> gcc/ChangeLog:
>
> * config/aarch64/aar
On Wed, 2023-11-29 at 20:37 +0800, Xi Ruoyao wrote:
> On Wed, 2023-11-29 at 17:33 +0800, Xi Ruoyao wrote:
> > On Mon, 2023-11-27 at 23:06 -0700, Jeff Law wrote:
> > > This has (of course) been tested on rv64. It's also been bootstrapped
> > > and regression tested on x86. Bootstrap and regression
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++.dg/tc1/dr52.C just needs
a trivial testsuite tweak:
'C' is not an accessible base of 'X'
v.
'C' is an inaccessible b
On 10/11/2023 11:22, Florian Weimer wrote:
This test looks like it intends to pass a small struct argument
through both a non-variadic and variadic argument, but due to
the typo, it does not achieve that.
gcc/testsuite/
* gcc.target/aarch64/aapcs64/ice_1.c (foo): Call named.
---
g
The 11/10/2023 12:22, Florian Weimer wrote:
> This test looks like it intends to pass a small struct argument
> through both a non-variadic and variadic argument, but due to
> the typo, it does not achieve that.
>
> gcc/testsuite/
>
> * gcc.target/aarch64/aapcs64/ice_1.c (foo): Call named.
On 13/11/2023 11:37, Victor Do Nascimento wrote:
The armv9.4-a architectural revision adds three new atomic operations
associated with the LSE128 feature:
* LDCLRP - Atomic AND NOT (bitclear) of a location with 128-bit
value held in a pair of registers, with original data loaded into
On Mon, Nov 27, 2023 at 9:36 AM 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 supp
On Mon, 27 Nov 2023, Tamar Christina wrote:
> Ping
>
> > -Original Message-
> > From: Tamar Christina
> > Sent: Monday, November 6, 2023 7:40 AM
> > To: gcc-patches@gcc.gnu.org
> > Cc: nd ; rguent...@suse.de; j...@ventanamicro.com
> > Subject: [PATCH 10/21]middle-end: implement relevancy
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, November 21, 2023 9:01 PM
> To: Di Zhao OS
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH v4] [tree-optimization/110279] Consider FMA in
> get_reassociation_width
>
> On Thu, Nov 9, 2023 at 6:53 PM Di Zhao OS
> wrote:
> >
On Wed, Nov 29, 2023 at 03:10:00PM +0100, Rainer Orth wrote:
> 2023-11-29 Rainer Orth
>
> config:
> * hwcaps.m4 (GCC_CHECK_ASSEMBLER_HWCAP): Require
> AC_CANONICAL_TARGET.
>
> libiberty:
> * configure.ac (GCC_CHECK_ASSEMBLER_HWCAP): Invoke.
> * configure, ac
Hi!
On 2022-11-14T21:46:15-0700, Sandra Loosemore via Gcc-patches
wrote:
> [...] I've added infrastructure to support testing on the offload
> compiler, added new test cases, and reworked the existing test cases to
> scan for interesting things written to the dump file instead of
> examining the
Hello All:
I am working on fixing the below issues and incorporating comments from Kewen
and
Michael.
Thanks & Regards
Ajit
On 28/11/23 9:11 pm, Michael Meissner wrote:
> 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
commit bf4f40cc3195eb7b900bf5535cdba1ee51fdbb8e
Author: Jakub Jelinek
Date: Tue Nov 28 13:14:05 2023 +0100
libiberty: Use x86 HW optimized sha1
broke Solaris/x86 bootstrap with the native as:
libtool: compile: /var/gcc/regression/master/11.4-gcc/build/./gcc/gccgo
-B/var/gcc/
On 29/11/2023 13:44, Thomas Schwinge wrote:
Hi!
On 2023-11-15T14:10:47+, Andrew Stubbs wrote:
* gcc.target/gcn/avgpr-mem-double.c: New test.
* gcc.target/gcn/avgpr-mem-int.c: New test.
* gcc.target/gcn/avgpr-mem-long.c: New test.
* gcc.target/gcn/avgpr-mem-sh
Rainer Orth writes:
> gcc.target/i386/apx-interrupt-1.c and two more tests FAIL on Solaris/x86
> with the native assembler. Like Darwin as, it doesn't support cfi
> directives. Instead of adding more and more targets in every affected
> test, this patch introduces a cfi effective-target keyword
On Mon, 27 Nov 2023, Tamar Christina wrote:
> Ping
>
> > -Original Message-
> > From: Tamar Christina
> > Sent: Monday, November 6, 2023 7:40 AM
> > To: gcc-patches@gcc.gnu.org
> > Cc: nd ; rguent...@suse.de; j...@ventanamicro.com
> > Subject: [PATCH 9/21]middle-end: implement vectorizab
Hi!
On 2023-11-15T14:10:47+, Andrew Stubbs wrote:
> * gcc.target/gcn/avgpr-mem-double.c: New test.
> * gcc.target/gcn/avgpr-mem-int.c: New test.
> * gcc.target/gcn/avgpr-mem-long.c: New test.
> * gcc.target/gcn/avgpr-mem-short.c: New test.
> * gcc.target/gcn/avgp
On 13/11/2023 11:37, Victor Do Nascimento wrote:
The introduction of further architectural-feature dependent ifuncs
for AArch64 makes hard-coding ifunc `_i' suffixes to functions
cumbersome to work with. It is awkward to remember which ifunc maps
onto which arch feature and makes the code har
>> overlap or group_overlap. Then change "no" to "none" and rename
>> "vconstraint_enabled" to "group_overlap_valid" (or without the group).
>> Add a comment to group_overlap_valid:
>> ; Widening instructions have group-overlap constraints. Those are only
>> ; valid for certain register-group s
On Tue, Nov 28, 2023 at 5:21 PM Jeff Law wrote:
>
> 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,
>> But don't we allow e.g. v2 and v4 with W82? Shouldn't it be % 8 == 6
>> and % 8 == 7 for W82 and W81? Or for W41, % 4 == 3? At least when looking
>> at the given spec example that would correspond to W82?
I think you are right. It should be W86 for vsext.vf4 (LMUL2 -> LMUL8)
W87 for vsext.vf
On Mon, 27 Nov 2023, Tamar Christina wrote:
> >
> > > This is a respun patch with a fix for VLA.
> > >
> > > This adds support to vectorizable_live_reduction to handle multiple
> > > exits by doing a search for which exit the live value should be
> > > materialized in.
> > >
> > > Additionally w
LGTM (in context of the last message) but please consider adding
the comments/naming I suggested.
Regards
Robin
>>> I can't really match spec and code. For the lmul = 2 case sure,
>>> but W84 e.g. allows v4 and not v6? What actually is "highest-numbered
>>>part"?
> Yes.
>
> For vwcvt, LMUL 4 -> LMUL 8.
> We allow overlap vwcvt v0 (occupy v0 - v7), v4 (occupy v4 - v7)
> This patch support the overlap ab
On Wed, Nov 29, 2023 at 1:25 PM Richard Biener
wrote:
>
> On Wed, Nov 29, 2023 at 10:35 AM Uros Bizjak wrote:
> >
> > The compiler, configured with --enable-checking=yes,rtl,extra ICEs with:
> >
> > internal compiler error: RTL check: expected elt 0 type 'e' or 'u',
> > have 'E' (rtx unspec) in t
Hi!
On 2023-11-28T12:11:22-0500, Jason Merrill wrote:
> On 11/28/23 12:08, Thomas Schwinge wrote:
>> // { dg-options "" }
>> +// Override any default-'-fno-exceptions':
>> +// { dg-additional-options -fexceptions }
>
> Might as well put the -fexceptions into the dg-options instead of having
> tw
1 - 100 of 144 matches
Mail list logo
