It's fixed by this commit:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d40b3c1e439db05c835b6bd4fd5bba58fda71dd6
juzhe.zh...@rivai.ai
From: Edwin Lu
Date: 2024-01-17 09:45
To: juzhe.zh...@rivai.ai; gcc-patches
CC: Patrick O'Neill
Subject: Re: [Committed V2] RISC-V: Fix regression (GCC-14
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_load_tls):
Load all types of tls symbols through one function.
(loongarch_got_load_tls_gd): Delete.
(loongarch_got_load_tls_ld): Delete.
(loongarch_got_load_tls_ie): Delete.
gcc/ChangeLog:
* config/loongarch/loongarch-protos.h (loongarch_symbol_extreme_p):
Add function declaration.
* config/loongarch/loongarch.cc (loongarch_symbolic_constant_p):
For SYMBOL_PCREL64, non-zero addend of "la.local $rd,$rt,sym+addend"
is not allowed
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_call_tls_get_addr):
Add support for call36.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/explicit-relocs-medium-call36-auto-tls-ld-gd.c:
New test.
---
gcc/config/loongarch/loongarch.cc | 20
Binutils does not support relaxation using four instructions to obtain
symbol addresses
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_explicit_relocs_p):
When the code model of the symbol is extreme and -mexplicit-relocs=auto,
the macro instruction loading
v3 -> v4:
1. Add macro support for TLS symbols
2. Added support for loading __get_tls_addr symbol address using call36.
3. Merge template got_load_tls_{ld/gd/le/ie}.
4. Enable explicit reloc for extreme TLS GD/LD with -mexplicit-relocs=auto.
v2 -> v3:
1. Modify the detection rules of a
On Fri, Jan 26, 2024 at 7:23 AM chenxiaolong wrote:
>
> gcc/testsuite/ChangeLog:
OK
> * gcc.dg/signbit-2.c: Added additional "-mlsx" compilation options.
> * gfortran.dg/graphite/vect-pr40979.f90: Dito.
> * gfortran.dg/vect/fast-math-mgrid-resid.f: Dito.
> ---
>
On Fri, Jan 26, 2024 at 6:01 AM Andrew Pinski wrote:
>
> The 2 loops in octfapg_universe can and will be vectorized now
> after r14-333-g6d4b59a9356ac4 on targets that support multiplication
> in the long type. But the testcase does not check vect_long_mult for
> that, so this patch corrects that
On Fri, Jan 26, 2024 at 12:04 AM Tobias Burnus wrote:
>
> When targeting AMD GPUs, the LLVM assembler (and linker) are used.
>
> Two days ago LLVM changed the default for the AMDHSA code object
> version (COV) from 4 to 5.
>
> In principle, we do not care which COV is used as long as it works;
>
This patch causes the following regression:
FAIL: gcc.target/riscv/rvv/vsetvl/pr113429.c -O0 (test for excess errors)
FAIL: gcc.target/riscv/rvv/vsetvl/pr113429.c -O1 (test for excess errors)
FAIL: gcc.target/riscv/rvv/vsetvl/pr113429.c -O2 (test for excess errors)
FAIL:
This patch fixes the recent noticed bug in RV32 glibc.
We incorrectly deleted a vsetvl:
...
and a4,a4,a3
vmv.v.i v1,0 ---> Missed vsetvl cause illegal
instruction report.
vse8.v v1,0(a5)
The root cause the laterin in LCM is incorrect.
gcc/testsuite/ChangeLog:
* gcc.dg/signbit-2.c: Added additional "-mlsx" compilation options.
* gfortran.dg/graphite/vect-pr40979.f90: Dito.
* gfortran.dg/vect/fast-math-mgrid-resid.f: Dito.
---
gcc/testsuite/gcc.dg/signbit-2.c | 1 +
The problem here is we don't check the return value of exact_log2
and always use that result as shifter. This fixes the issue by avoiding
the shift if the value was `-1` (which means the value was not exact a power of
2);
in this case we could either check if the values was equal to -1 or not
The 2 loops in octfapg_universe can and will be vectorized now
after r14-333-g6d4b59a9356ac4 on targets that support multiplication
in the long type. But the testcase does not check vect_long_mult for
that, so this patch corrects that error and now the testcase passes correctly
on
On 1/25/24 21:28, Nathaniel Shead wrote:
On Wed, Jan 24, 2024 at 03:24:42PM -0500, Jason Merrill wrote:
On 1/20/24 05:45, Nathaniel Shead wrote:
I also included
your change to only add class variable templates to 'pending_statics'
(and the normal 'static_decl's for non-class otherwise) as
On 1/25/24 20:36, Marek Polacek wrote:
Better version:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Real-world experience shows that -Wdangling-reference triggers for
user-defined std::span-like classes a lot. We can easily avoid that
by considering classes like
On Thu, Jan 25, 2024 at 08:37:36PM -0500, Marek Polacek wrote:
> +/* Handle a "non_owning" attribute; arguments as in
> + struct attribute_spec.handler. */
> +
> +tree
> +handle_non_owning_attribute (tree *node, tree name, tree args, int,
> + bool *no_add_attrs)
I
On Wed, Jan 24, 2024 at 03:24:42PM -0500, Jason Merrill wrote:
> On 1/20/24 05:45, Nathaniel Shead wrote:
> > I also included
> > your change to only add class variable templates to 'pending_statics'
> > (and the normal 'static_decl's for non-class otherwise) as otherwise I
> > could imagine that
Low prio and not a regression. Feel free to ignore till GCC 15.
Bootstrapped/regtested on x86_64-pc-linux-gnu.
-- >8 --
The PR complains that
void do_something(){
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-label"
start:;
#pragma GCC diagnostic pop
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Since -Wdangling-reference has false positives that can't be
prevented, we should offer an easy way to suppress the warning.
Currently, that is only possible by using a #pragma, either around the
enclosing class or around the
Better version:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Real-world experience shows that -Wdangling-reference triggers for
user-defined std::span-like classes a lot. We can easily avoid that
by considering classes like
template
struct Span {
T*
On Fri, Jan 26, 2024 at 3:03 AM Roger Sayle wrote:
>
>
> Hi Hongtao,
> Many thanks for the review. Here's a revised version of my patch
> that addresses (most of) the issues you've raised. Firstly the
> handling of zero and all_ones in this function is mostly for
> completeness/documentation,
Hi,
This patch creates an insn_and_split pattern which helps the duplicated
constant vector replace the source pseudo of store insn in fwprop pass.
Thus the store can be implemented by a single stxvd2x and it eliminates the
unnecessary byte swap insn on P8 LE. The test case shows the
Hi,
This patch replaces rtx_cost with insn_cost in forward propagation.
In the PR, one constant vector should be propagated and replace a
pseudo in a store insn if we know it's a duplicated constant vector.
It reduces the insn cost but not rtx cost. In this case, the kind of
destination operand
On 1/25/24 14:14, Jakub Jelinek wrote:
Hi!
The following testcase reduced from GDB is miscompiled starting with
r14-5503 PR112427 change.
The problem is in the build_m_component_ref hunk, which changed
- datum = fold_build_pointer_plus (fold_convert (ptype, datum), component);
+ datum
When targeting AMD GPUs, the LLVM assembler (and linker) are used.
Two days ago LLVM changed the default for theAMDHSA code object version (COV) from 4 to 5. In principle, we do not
care which COV is used as long as it works; unfortunately,
"mkoffload.cc" also generates an object file
Hello-
May I please ping this small patch? Thanks
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639467.html
-Lewis
On Wed, Dec 20, 2023 at 8:02 PM Lewis Hyatt wrote:
>
> Hello-
>
> May I please ping this PCH patch? Thanks!
>
On Thu, Jan 25, 2024 at 11:53 AM Björn Schäpers wrote:
>
> Am 23.01.2024 um 23:37 schrieb Ian Lance Taylor:
> > On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers wrote:
> >>
> >> Am 03.01.2024 um 00:12 schrieb Björn Schäpers:
> >>> Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor:
> On Fri, Jan
May I please ask again about this one? It's just a couple lines, and I
think it fixes an important gap in the logic for #pragma GCC
diagnostic. The PR was not reported by me so I think at least one
other person does care about it :). Thanks!
Dear all,
this is the third patch in a series that addresses dummy arguments
with the VALUE attribute, now handling the passing of NULL actual
arguments. It is based on the refactoring in the previous patch
and reuses the handling of absent arguments.
Regtested on x86_64-pc-linux-gnu. OK for
Thanks for the review!
On Wed, 2024-01-24 at 13:10 -0500, David Malcolm wrote:
> On Thu, 2024-01-11 at 18:42 -0500, Antoni Boucher wrote:
> > Hi.
> > This patch fixes the bug 113343.
> > I'm wondering if there's a better solution than using mpfr.
> > The only other solution I found is
On Thu, Jan 25, 2024 at 08:08:23PM +, Joseph Myers wrote:
> On Wed, 24 Jan 2024, Andi Kleen wrote:
>
> > Implement a C23 clang compatible musttail attribute similar to the earlier
> > C++ implementation in the C parser.
>
> I'd expect diagnostics, and associated tests of those diagnostics,
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Here AGGREGATE_TYPE_P includes pointers to member functions, which is not
what we want. Instead we should use class||array, as elsewhere in the
function.
PR c++/113598
gcc/cp/ChangeLog:
* init.cc (build_vec_init): Don't
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Here we end up with an initializer_list of 'aa', a type with a non-trivial
destructor, and need to destroy it. The code called
build_special_member_call for cleanups, but that doesn't work for arrays, so
use cxx_maybe_build_cleanup
Thanks a lot for the testing.
Yes, I can repeat the issue with the following small example:
#include
#include
#include
#define MAX(a, b) ((a) > (b) ? (a) : (b))
struct untracked {
int size;
int array[] __attribute__((counted_by (size)));
} *a;
struct untracked * alloc_buf
On Wed, 24 Jan 2024, Andi Kleen wrote:
> Implement a C23 clang compatible musttail attribute similar to the earlier
> C++ implementation in the C parser.
I'd expect diagnostics, and associated tests of those diagnostics, for:
* musttail attribute used with any arguments, even empty
The J constraint can invoke undefined behavior due to it taking the
negative of the ival if ival was HWI_MIN. The fix is simple as casting
to `unsigned HOST_WIDE_INT` before doing the negative of it. This
does that.
Committed as obvious after build/test for aarch64-linux-gnu.
gcc/ChangeLog:
Am 23.01.2024 um 23:37 schrieb Ian Lance Taylor:
On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers wrote:
Am 03.01.2024 um 00:12 schrieb Björn Schäpers:
Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor:
On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers wrote:
From: Björn Schäpers
Fixes
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113526
The patch was successfully bootstrapped and tested on x86-64, ppc64le,
and aarch64.
commit 5c617df410602d0e51d61c84d1ae7e9b3f51efa4
Author: Vladimir N. Makarov
Date: Thu Jan 25 14:41:17 2024 -0500
Andre Vieira writes:
> This patch adds support for C23's _BitInt for the AArch64 port when compiling
> for little endianness. Big Endianness requires further target-agnostic
> support and we therefor disable it for now.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64.cc
On Thu, 25 Jan 2024, Patrick Palka wrote:
> On Thu, 25 Jan 2024, Jakub Jelinek wrote:
>
> > Hi!
> >
> > The following testcase reduced from GDB is miscompiled starting with
> > r14-5503 PR112427 change.
> > The problem is in the build_m_component_ref hunk, which changed
> > - datum =
On Thu, 25 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> The following testcase reduced from GDB is miscompiled starting with
> r14-5503 PR112427 change.
> The problem is in the build_m_component_ref hunk, which changed
> - datum = fold_build_pointer_plus (fold_convert (ptype, datum),
>
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/13? This isn't a very satisfactory fix, but at least
it safely fixes these testcases I guess. Note that there's
implementation disagreement about the second testcase, GCC always
accepted it but Clang/MSVC/icc reject
Hi!
The following testcase reduced from GDB is miscompiled starting with
r14-5503 PR112427 change.
The problem is in the build_m_component_ref hunk, which changed
- datum = fold_build_pointer_plus (fold_convert (ptype, datum), component);
+ datum = cp_convert (ptype, datum, complain);
+
Hi Hongtao,
Many thanks for the review. Here's a revised version of my patch
that addresses (most of) the issues you've raised. Firstly the
handling of zero and all_ones in this function is mostly for
completeness/documentation, these standard_sse_constant_p
values are (currently/normally)
Updated my email address.
Thanks,
Chung-Lin
From ffeab69e1ffc0405da3a9222c7b9f7a000252702 Mon Sep 17 00:00:00 2001
From: Chung-Lin Tang
Date: Thu, 25 Jan 2024 18:20:43 +
Subject: [PATCH] MAINTAINERS: Update my work email address
* MAINTAINERS: Update my work email address.
---
this patch added double notes on crt*.o and lse derived objects.
(which does not seem to cause build break but some linkers may
not like it)
after #include "aarch64-asm.h" all gnu-stack and gnu-property
related stuff should be removed since the header takes care of it.
The 01/15/2024 17:21, Radek Barton wrote:
v4-0001-Ifdef-.hidden-.type-and-.size-pseudo-ops-for-aarc.patch
Description: v4-0001-Ifdef-.hidden-.type-and-.size-pseudo-ops-for-aarc.patch
This patch adds support for C23's _BitInt for the AArch64 port when compiling
for little endianness. Big Endianness requires further target-agnostic
support and we therefor disable it for now.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (TARGET_C_BITINT_TYPE_INFO): Declare MACRO.
This patch ensures we use TARGET_ARRAY_MODE to determine the storage mode of
large bitints that are represented as arrays in memory. This is required to
support such bitints for aarch64 and potential other targets with similar
bitint specifications. Existing tests like
Hi,
This patch series adds support for _BitInt for AArch64 when compiling for
Little Endian. The first patch in the series fixes an issue that arises with
support for AArch64, the second patch adds the backend support for it.
Andre Vieira (2):
bitint: Use TARGET_ARRAY_MODE for large bitints
Victor Do Nascimento writes:
> At present, Evaluation of both `has_lse2(hwcap)' and
> `has_lse128(hwcap)' may require issuing an `mrs' instruction to query
> a system register. This instruction, when issued from user-space
> results in a trap by the kernel which then returns the value read in
>
Victor Do Nascimento writes:
> 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
> the same 2
Victor Do Nascimento writes:
> With support for new atomic features in Armv9.4-a being indicated by
> HWCAP2 bits, Libatomic's ifunc resolver must now query its second
> argument, of type __ifunc_arg_t*.
>
> We therefore make this argument known to libatomic, allowing us to
> query hwcap2 bits in
On 1/11/24 15:55, Roger Sayle wrote:
Hi Richard,
As you've recommended, this issue has now been filed in bugzilla
as PR other/113336. As explained in the new PR, libatomic's testsuite
used to pass on armv6 (raspberry pi) in previous GCC releases, but
the code was incorrect/non-synchronous;
Victor Do Nascimento writes:
> 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 harder to maintain
> -Original Message-
> From: Wilco Dijkstra
> Sent: Thursday, January 25, 2024 5:00 PM
> To: Kyrylo Tkachov ; GCC Patches patc...@gcc.gnu.org>
> Cc: Richard Earnshaw ; Richard Sandiford
>
> Subject: Re: [PATCH] AArch64: Add -mcpu=cobalt-100
>
> Hi,
>
> >> Add support for
>/* If we ever encounter an insn without an insn reservation, trip
> an assert so we can find and fix this problem. */
> -#if 0
> + if (! insn_has_dfa_reservation_p (insn)) {
> +print_rtl(stderr, insn);
> +fprintf(stderr, "%d", get_attr_type (insn));
> + }
>gcc_assert
> Use default cost model scheduling on these test cases. All these tests
> introduce scan dump failures with -mtune generic-ooo. Since the vector
> cost models are the same across all three tunes, some of the tests
> in PR113249 will be fixed with this patch series.
This is OK, thanks.
> 39
Thanks, that looks better IMHO.
> +;; Copyright (C) 2011-2024 Free Software Foundation, Inc.
> +;; Contributed by Andrew Waterman (and...@sifive.com).
> +;; Based on MIPS target for GNU compiler.
You might want to change that, as well as the date. While at
it you can also fix the broken date in
LGTM, thanks.
Regards
Robin
Hi,
>> Add support for -mcpu=cobalt-100 (Neoverse N2 with a different implementer
>> ID).
>>
>> Passes regress, OK for commit?
>
> Ok.
Also OK to backport to GCC 13, 12 and 11?
Cheers,
Wilco
Andrew Carlotti writes:
> It would be neater if the middle end for target_clones used a target
> hook for version name mangling, so we only do version name mangling
> once. However, that would require more intrusive refactoring that will
> have to wait till Stage 1.
>
>
> This patch builds upon
The non-test parts are OK IMHO.
Regards
Robin
On Wed, 24 Jan 2024 at 12:02, Jonathan Wakely wrote:
>
> On Wed, 24 Jan 2024 at 10:48, Christophe Lyon wrote:
> >
> > GDB emits end of lines as \r\n, we currently match the reverse \n\r,
>
> We currently match [\n\r]+ which should match any of \n, \r, \n\r or \r\n
>
Hmm, right, sorry I had this
Confusion in binding_cluster::maybe_get_compound_binding about whether
offsets are relative to the start of the region or to the start of the
cluster was leading to incorrect handling of default values, leading
to false positives from -Wanalyzer-use-of-uninitialized-value, from
pushed :)
On Thu, Jan 25, 2024 at 9:53 PM Kito Cheng wrote:
>
> It's stage 4, so I think it would be great to not disturb code base
> too much, and adding intrinsic without adding VLS modes should be
> better way to go, and here is not really something serious coding
> style issue, just few
On 25/01/2024 12:44, Tobias Burnus wrote:
This patch avoids assembler warnings for gfx908 and gfx90a such as
'-xnack-mattr=-sramecc' is not a recognized feature for this target(ignoring
feature)
as we pass -mattr=-xnack-mattr=-sramecc to the llvm-mc assembler.
Solution: Add a space
Szabolcs Nagy writes:
> Recent commit introduced a conditional branch in eh_return epilogues
> that is not compatible with speculation tracking:
>
> commit 426fddcbdad6746fe70e031f707fb07f55dfb405
> Author: Szabolcs Nagy
> CommitDate: 2023-11-27 15:52:48 +
>
> aarch64: Use br
This patch series presents the comprehensive implementation of the BITMANIP
extension for CORE-V.
Tested with riscv-gnu-toolchain on binutils, ld, gas and gcc testsuites to
ensure its correctness and compatibility with the existing codebase.
However, your input, reviews, and suggestions are
Spec:
github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md
Contributors:
Mary Bennett
Nandni Jamnadas
Pietra Ferreira
Charlie Keaney
Jessica Mills
Craig Blackmore
Simon Cook
Jeremy Bennett
Helene Chelin
gcc/ChangeLog:
*
XCVmem adds more loads and stores. To prevent non-XCVmem loads and
stores from generating illegal XCVmem specific operands, constraint
'm' was redefined. 'm' does not accept POST_MODIFY or reg + reg
addresses.
Spec:
This patch series presents the comprehensive implementation of the MEM
extension for CORE-V.
Tested with riscv-gnu-toolchain on binutils, ld, gas and gcc testsuites to
ensure its correctness and compatibility with the existing codebase.
However, your input, reviews, and suggestions are invaluable
Recent commit introduced a conditional branch in eh_return epilogues
that is not compatible with speculation tracking:
commit 426fddcbdad6746fe70e031f707fb07f55dfb405
Author: Szabolcs Nagy
CommitDate: 2023-11-27 15:52:48 +
aarch64: Use br instead of ret for eh_return
Refactor
It's stage 4, so I think it would be great to not disturb code base
too much, and adding intrinsic without adding VLS modes should be
better way to go, and here is not really something serious coding
style issue, just few minor indentation issue, so I gonna run
regression to make not break
Use this reduced testcase, but please verify this in your end again.
For the code change part, I would like to let other to review :P
struct a {
int b;
int c : 1;
int : 1;
} d();
typedef struct
{
int e;
struct {
int f;
};
} g;
int i;
char k, l, n;
void *m;
char *o;
void h();
char *j();
Committed, thanks Juzhe.
Pan
From: juzhe.zhong
Sent: Thursday, January 25, 2024 9:08 PM
To: Wang, Yanzhang
Cc: gcc-patches@gcc.gnu.org; kito.ch...@sifive.com; Li, Pan2
; Wang, Yanzhang
Subject: Re: [PATCH v2] RISC-V: remove param riscv-vector-abi. [PR113538]
lgtm
Replied Message
lgtm Replied Message Fromyanzhang.w...@intel.comDate01/25/2024 21:06 Togcc-patches@gcc.gnu.org Ccjuzhe.zh...@rivai.ai,kito.ch...@sifive.com,pan2...@intel.com,yanzhang.w...@intel.comSubject[PATCH v2] RISC-V: remove param riscv-vector-abi. [PR113538]
From: Yanzhang Wang
Also adjust some of the tests for scan-assembly. The behavior is the
same as --param=riscv-vector-abi before.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_get_arg_info): Remove the flag.
(riscv_fntype_abi): Ditto.
* config/riscv/riscv.opt: Ditto.
From: Yanzhang Wang
Also adjust some of the tests for scan-assembly. The behavior is the
same as --param=riscv-vector-abi before.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_get_arg_info): Remove the flag.
(riscv_fntype_abi): Ditto.
* config/riscv/riscv.opt: Ditto.
Thanks.
Can we please agree on some wording to use so I know when the patch can
be pushed. Especially since we're now in stage 4, it would help me if
you say something like "you can push to master".
Regards.
On Wed, 2024-01-24 at 12:14 -0500, David Malcolm wrote:
> On Fri, 2024-01-19 at 16:55
This patch avoids assembler warnings for gfx908 and gfx90a such as
'-xnack-mattr=-sramecc' is not a recognized feature for this target(ignoring
feature)
as we pass -mattr=-xnack-mattr=-sramecc to the llvm-mc assembler.
Solution: Add a space before the second '-mattr='.
OK for mainline?
This patch fixes the recent noticed bug in RV32 glibc.
We incorrectly deleted a vsetvl:
...
and a4,a4,a3
vmv.v.i v1,0 ---> Missed vsetvl cause illegal
instruction report.
vse8.v v1,0(a5)
The root cause the laterin in LCM is incorrect.
Some programing styles use a lot of inline assembler, and it is common
to use very complex preprocessor macros to generate the assembler
strings for the asm statements. In C++ there would be a typesafe alternative
using templates and constexpr to generate the assembler strings, but
unfortunately
When generalising vector_cst_all_same, I'd forgotten to update
VECTOR_CST_ENCODED_ELT to VECTOR_CST_ELT. The check deliberately
looks at implicitly encoded elements in some cases.
Tested on aarch64-linux-gnu & pushed.
Richard
gcc/
PR target/113572
*
Andrew Pinski writes:
> The split for movv8di is not ready to handle the case where the setting
> register overlaps with the address of the memory that is being load.
> Fixing the split than just making the output constraint as an early clobber
> for this alternative. The split would first need
g:74e3e839ab2d36841320 handled the UXTL{,2}-ZIP[12] optimisation
in split1. The UXTL input is a 64-bit vector of N-bit elements
and the result is a 128-bit vector of 2N-bit elements. The
corresponding ZIP1 operates on 128-bit vectors of N-bit elements.
This meant that the ZIP1 input had to be a
On 25/01/2024 10:29, Maxim Kuvyrkov wrote:
> After fwprop improvement in r14-8319-g86de9b66480, codegen in
> bics_3.c test changed from "bics" to "bic" instruction, with
> the overall instruction stream remaining at the same quality.
>
> This patch makes the scan-assembler directive accept both
>
> On Jan 24, 2024, at 18:40, Richard Biener wrote:
>
> We can't support niters with may_be_zero when we end up with a
> non-empty latch due to early exit peeling. At least not in
> the simplistic way the vectorizer handles this now. Disallow
> it again for exits that are not the last one.
>
>
After fwprop improvement in r14-8319-g86de9b66480, codegen in
bics_3.c test changed from "bics" to "bic" instruction, with
the overall instruction stream remaining at the same quality.
This patch makes the scan-assembler directive accept both
"bics" and "bic".
BEFORE r14-8319-g86de9b66480:
On 24/01/2024 22:12, Tobias Burnus wrote:
This patch fixes "-g" debug compilation for gfx1100 and gfx1030,
which fail to link when "-g" is specified. The reason is:
When using gfx1100 and compiling with '-g' I was running into an error
because the eflags used for the debugger file has
Hi David,
> On 24 Jan 2024, at 18:31, David Malcolm wrote:
>
> On Tue, 2024-01-16 at 11:10 +, Iain Sandoe wrote:
>> Tested on x86_64, i686 Darwin and x86_64 Linux,
>> OK for trunk? when ?
>> thanks,
>> Iain
>
> Hi Iain, thanks for the patch.
>
> I'll have to defer to your Darwin expertise
Hi Mike,
on 2024/1/6 07:38, Michael Meissner wrote:
> The MMA subsystem added the notion of accumulator registers as an optional
> feature of ISA 3.1 (power10). In ISA 3.1, these accumulators overlapped with
> the traditional floating point registers 0..31, but logically the accumulator
>
On Wed, Jan 24, 2024 at 4:50 PM Georg-Johann Lay wrote:
>
>
>
> Am 22.01.24 um 08:45 schrieb Richard Biener:
> > On Fri, Jan 19, 2024 at 5:06 PM Georg-Johann Lay wrote:
> >>
> >>
> >>
> >> Am 18.01.24 um 20:54 schrieb Roger Sayle:
> >>>
> >>> This patch tweaks RTL expansion of multi-word shifts
LGTM, it's always good to improve some debug for vsetvli insertion
pass, it's really non-trivial optimization.
On Thu, Jan 25, 2024 at 4:59 PM Juzhe-Zhong wrote:
>
> While looking into PR113469, I notice the LCM delete a vsetvl incorrectly.
>
> This patch add dump information of all predecessors
On Thu, 25 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> The following patch is miscompiled, because convert_to_integer_1 for
> LSHIFT_EXPR tests if the INTEGER_CST shift count is too high, but
> incorrectly compares it against TYPE_SIZE rather than TYPE_PRECISION.
> The type in question is unsigned
While looking into PR113469, I notice the LCM delete a vsetvl incorrectly.
This patch add dump information of all predecessors for LCM delete vsetvl block
for better debugging.
Tested no regression.
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (get_all_predecessors): New function.
On Thu, Jan 25, 2024 at 07:51:21AM +0100, rep.dot@gmail.com wrote:
> On 24 January 2024 20:30:45 CET, Andi Kleen wrote:
> >---
> > gcc/doc/extend.texi | 16
> > 1 file changed, 16 insertions(+)
> >
> >diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> >index
On Thu, Jan 25, 2024 at 1:46 AM Andrew Pinski wrote:
>
> This fixes of the vect testcases which uses the gimple FE for LLP64 targets.
> The testcases use directly `unsigned long` for the addition to pointers
> when they should be using `__SIZETYPE__`. This changes to use that instead.
OK
>
Notice full available is computed evey round of earliest fusion which is
redundant.
Actually we only need to compute it once in phase 3.
It's NFC patch and tested no regression. Committed.
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (pre_vsetvl::compute_vsetvl_def_data):
Remove
1 - 100 of 102 matches
Mail list logo
