On 17/08/2023 10:39, Alex Coplan via Gcc-patches wrote:
> I'd like to ping this for review from C and C++ maintainers:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626178.html
Ping^2
>
> I probably should have dropped the RFC tag this time round as I think
> the patch
Hi,
This patch fixes up the code examples in the RTL-SSA documentation (the
sections on making insn changes) to reflect the current API.
The main issues are as follows:
- rtl_ssa::recog takes an obstack_watermark & as the first parameter.
Presumably this is intended to be the change attempt,
configuration where __thread can get
rejected (I don't know of one), and should cxx_binary_literals report as
a feature with -std=c2x?
Thanks,
Alex
On 03/08/2023 10:21, Alex Coplan via Gcc-patches wrote:
> Hi,
>
> This patch implements clang's __has_feature and __has_extensi
Hi,
This patch implements clang's __has_feature and __has_extension in GCC.
This is a v3 which addresses feedback for the v2 patch posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626058.html
Main changes since v2:
- As per Jason's feedback, dropped the langhook in favour of
On 26/07/2023 16:26, Jason Merrill wrote:
> On 6/28/23 06:35, Alex Coplan wrote:
> > Hi,
> >
> > This patch implements clang's __has_feature and __has_extension in GCC.
> > This is a v2 of the original RFC posted here:
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617878.html
> >
>
On 28/06/2023 11:35, Alex Coplan via Gcc-patches wrote:
> Hi,
>
> This patch implements clang's __has_feature and __has_extension in GCC.
> This is a v2 of the original RFC posted here:
Ping. The Objective-C parts have been approved, but the C, C++, and generic bits
need review.
Hi Iain,
On 20/06/2023 15:08, Iain Sandoe wrote:
> Hi Alex
>
> again, thanks for working on this and for fixing the SDK blocker.
>
> > On 20 Jun 2023, at 13:30, Alex Coplan wrote:
> >
>
> > The patch can now survive bootstrap on Darwin (it looks like we'll need
> > to adjust some
Hi Jason,
On 11/05/2023 16:25, Jason Merrill wrote:
> On 5/9/23 08:07, Alex Coplan wrote:
> > This patch implements clang's __has_feature and __has_extension in GCC.
>
> Thanks!
Thanks a lot for the review, I posted a v2 patch incorporating your
feedback here:
Hi,
This patch implements clang's __has_feature and __has_extension in GCC.
This is a v2 of the original RFC posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617878.html
Changes since v1:
- Follow the clang behaviour where -pedantic-errors means that
__has_extension behaves
Hi Dave,
On 23/06/2023 10:36, David Malcolm wrote:
> On Fri, 2023-06-23 at 12:52 +0100, Alex Coplan wrote:
> > Hi David,
> >
> > It looks like this patch breaks bootstrap on Darwin. I tried a
> > bootstrap on
> > x86_64-apple-darwin and got errors building selftest-run-tests.cc:
> >
> > In file
Hi Marc,
On 20/06/2023 15:47, Marc Poulhiès wrote:
> Hi,
>
> >> The package Interfaces.CHERI provides intrinsic bindings and
> >> helper functions to allow software to query, create, and
> >> manipulate CHERI capabilities.
> >
> > I'm curious what the motivation for these intrinsic wrappers is,
Hi,
On 20/06/2023 09:47, Marc Poulhiès via Gcc-patches wrote:
> From: Daniel King
>
> The package Interfaces.CHERI provides intrinsic bindings and
> helper functions to allow software to query, create, and
> manipulate CHERI capabilities.
I'm curious what the motivation for these intrinsic
Hi Iain,
On 14/05/2023 17:05, Iain Sandoe wrote:
> Hi Alex,
>
> thanks for working on this.
>
> I’ve applied this patch and evaluated on a few Darwin versions (which is the
> target currently most affected, I believe):
>
> > On 9 May 2023, at 13:07, Alex Coplan wrote:
>
> > This patch
On 16/06/2023 09:07, Jason Merrill wrote:
> On 6/16/23 07:58, Alex Coplan wrote:
> > Hi,
> >
> > This is a v3 patch addressing feedback for:
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621714.html
> >
> > The only change since the previous version is that the new option is
> >
Hi,
This is a v3 patch addressing feedback for:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621714.html
The only change since the previous version is that the new option is
documented in invoke.texi (and the description in c.opt was shortened as
requested).
--
macOS SDK headers
Hi,
This is a v2 patch addressing feedback for:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621050.html
macOS SDK headers using the CF_ENUM macro can expand to invalid C++ code
of the form:
typedef enum T : BaseType T;
i.e. an elaborated-type-specifier with an additional enum-base.
Hi,
macOS SDK headers using the CF_ENUM macro can expand to invalid C++ code
of the form:
typedef enum T : BaseType T;
i.e. an elaborated-type-specifier with an additional enum-base.
Upstream LLVM can be made to accept the above construct with
-Wno-error=elaborated-enum-base.
This macro
This patch refactors the ls64 builtins to allow the compiler to define them
directly instead of having wrapper functions in arm_acle.h. This should be not
only easier to maintain, but it makes two important correctness fixes:
- It fixes PR110132, where the builtins ended up getting declared with
The st64b pattern incorrectly had an output constraint on the register
operand containing the destination address for the store, leading to
wrong code. This patch fixes that.
gcc/ChangeLog:
PR target/110100
* config/aarch64/aarch64-builtins.cc (aarch64_expand_builtin_ls64):
Hi,
This patch series fixes various defects with the FEAT_LS64 ACLE
implementation in the AArch64 backend.
The series is organised as follows:
- Patch 1/3 fixes whitespace errors in the existing code.
- Patch 2/3 fixes PR110100 where we generate wrong code for the st64b
builtin.
- Patch
On 02/06/2023 18:45, Jakub Jelinek wrote:
> On Fri, Jun 02, 2023 at 06:18:38PM +0200, Rainer Orth wrote:
> > Hi Alex,
> >
> > > g:7aae58b04b92303ccda3ead600be98f0d4b7f462 introduced -Wformat errors
> > > breaking bootstrap on some targets. This patch fixes that.
> > >
> > > Committed as obvious.
Hi Iain,
On 02/06/2023 09:32, Iain Sandoe wrote:
> Hi David,
>
> > On 31 May 2023, at 07:13, Indu Bhagat via Gcc-patches
> > wrote:
> >
> > On 5/30/23 11:27, David Faust wrote:
> >> [Changes from v1:
> >> - Fix typos.
> >> - Split unrelated change into separate commit.
> >> - Improve asm
Hi,
g:7aae58b04b92303ccda3ead600be98f0d4b7f462 introduced -Wformat errors
breaking bootstrap on some targets. This patch fixes that.
Committed as obvious.
Thanks,
Alex
gcc/ChangeLog:
* btfout.cc (btf_asm_type): Use PRIu64 instead of %lu for uint64_t.
(btf_asm_datasec_type):
Hi Kyrill,
On 23/05/2023 11:14, Kyrylo Tkachov wrote:
> Hi Alex,
> diff --git a/gcc/testsuite/gcc.target/arm/pr109800.c
> b/gcc/testsuite/gcc.target/arm/pr109800.c
> new file mode 100644
> index 000..71d1ede13dd
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/pr109800.c
> @@ -0,0
Hi,
In r11-966-g9a182ef9ee011935d827ab5c6c9a7cd8e22257d8 we introduce a
simplification to emit_move_insn that attempts to simplify moves of the form:
(set (subreg:M1 (reg:M2 ...)) (constant C))
where M1 and M2 are of equal mode size. That is problematic for the splitter
Hi,
This patch implements clang's __has_feature and __has_extension in GCC.
Currently the patch aims to implement all documented features (and some
undocumented ones) following the documentation at
https://clang.llvm.org/docs/LanguageExtensions.html with the following
omissions:
- C++ type
Hi,
As the PR shows, we currently emit duplicate diagnostics for calls to
functions marked with __attribute__((unavailable)). This patch fixes
that.
I'm not sure whether it's considered acceptable to add the include of
decl.h to call.cc (in order to get at deprecated_state). It would be
useful
Hi,
As the testcase shows, this pattern had an incorrect constraint leading
to GCC's output getting rejected by the assembler.
This patch fixes the constraint accordingly.
The test is split into two: one that can run without bf16 support from
the assembler and another that checks that the
On 01/12/2022 16:12, Richard Sandiford wrote:
> Alex Coplan via Gcc-patches writes:
> > Hi,
> >
> > This patch fixes a type confusion bug in varasm.cc:assemble_variable.
> > The problem is that the current code calls:
> >
> > sect = get_variable_section (
Hi,
This patch fixes a type confusion bug in varasm.cc:assemble_variable.
The problem is that the current code calls:
sect = get_variable_section (decl, false);
and then accesses sect->named.name without checking whether the section
is in fact a named section. In the surrounding else clause,
Hi Richard,
On 25/11/2022 21:08, Richard Biener via Gcc-patches wrote:
>
>
> On Fri, 25 Nov 2022, Vaseeharan Vinayagamoorthy wrote:
>
> > Hi,
> >
> > I am seeing an internal compiler error, related to this patch:
>
> Can you please open a bugzilla for this and attach preprocessed
> source so
Hi Ramana,
On 08/11/2022 18:20, Ramana Radhakrishnan via Gcc-patches wrote:
> PR92999 is a case where the VFP calling convention does not allocate
> enough FP registers for a homogenous aggregate containing FP16 values.
> I believe this is the complete fix but would appreciate another set of
>
This is a respin of:
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592307.html
that implements Richard's suggestion around the cgraph.cc change.
Otherwise the patch is as before.
Bootstrapped and regtested on aarch64-linux-gnu, OK for trunk?
Thanks,
Alex
--
I noticed that, while the
Ping.
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592307.html
On 25/03/2022 15:07, Alex Coplan via Gcc-patches wrote:
> Hi,
>
> I noticed that, while the C/C++ frontends invoke the GENERIC match.pd
> simplifications to do early folding, the debug output from
> generi
Hi,
This patch fixes some spelling and grammar issues in the match.pd
documentation.
Pushed as obvious.
Thanks,
Alex
gcc/ChangeLog:
* doc/match-and-simplify.texi: Fix typos.
diff --git a/gcc/doc/match-and-simplify.texi b/gcc/doc/match-and-simplify.texi
index 055a5308e7d..b33d83518a7
Hi,
This is a backport of the fix for PR99977 to the GCC 9 branch. The only
case where the GCC 10 patch did not apply cleanly was on sync.md, where
some of the context has changed, but the substance of the patch has not
changed, it simply required applying by hand.
Tested as follows:
-
Hi,
I noticed that, while the C/C++ frontends invoke the GENERIC match.pd
simplifications to do early folding, the debug output from
generic-match.cc does not appear in the -fdump-tree-original output,
even with -fdump-tree-original-folding or -fdump-tree-original-all. This
patch fixes that.
For
Hi Richard,
Thanks for the review.
On 20/12/2021 13:19, Richard Sandiford wrote:
> Alex Coplan via Gcc-patches writes:
> > Hi,
> >
> > This fixes PR103500 i.e. ensuring that stack slots for
> > passed-by-reference overaligned types are appropriately al
Hi,
I'd just like to ping this for review:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585785.html
Thanks,
Alex
On 30/11/2021 16:48, Alex Coplan via Gcc-patches wrote:
> Hi,
>
> This fixes PR103500 i.e. ensuring that stack slots for
> passed-by-reference overa
Committed as obvious.
Thanks,
Alex
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/aapcs64/macro-def.h (PTR): Fix typo in
comment.
diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/macro-def.h
b/gcc/testsuite/gcc.target/aarch64/aapcs64/macro-def.h
index
On 30/11/2021 19:38, Florian Weimer wrote:
> * Alex Coplan via Gcc-patches:
>
> > Bootstrapped and regtested on aarch64-linux-gnu, x86_64-linux-gnu, and
> > arm-linux-gnueabihf: no regressions.
> >
> > I'd appreciate any feedback. Is it OK for trunk?
>
> Do
Hi,
This fixes PR103500 i.e. ensuring that stack slots for
passed-by-reference overaligned types are appropriately aligned. For the
testcase:
typedef struct __attribute__((aligned(32))) {
long x,y;
} S;
S x;
void f(S);
void g(void) { f(x); }
on AArch64, we currently generate (at -O2):
g:
Hi all,
Looking at calls.c:initialize_argument_information, I spotted some dead
code that seems to have been left behind from when MPX support was
removed.
This patch removes that code as well as the associated target hooks
(which appear to be unused).
Bootstrapped and regtested on
Hi Richi,
On 09/06/2021 14:42, Richard Biener via Gcc-patches wrote:
> On Mon, May 31, 2021 at 5:00 PM Richard Biener wrote:
> >
> > This makes SLP discovery handle associatable (including mixed
> > plus/minus) chains better by swapping operands across the whole
> > chain. To work this adds
This time with attachment.
On 19/05/2021 15:42, Alex Coplan via Gcc-patches wrote:
> Hi Richard,
>
> On 17/05/2021 17:31, Richard Earnshaw wrote:
> >
> >
> > On 30/04/2021 09:30, Alex Coplan via Gcc-patches wrote:
> > > Hi,
> > >
> > > As
Hi Richard,
On 17/05/2021 17:31, Richard Earnshaw wrote:
>
>
> On 30/04/2021 09:30, Alex Coplan via Gcc-patches wrote:
> > Hi,
> >
> > As the PR shows, we ICE shortly after expanding nonsecure calls for
> > Armv8.1-M. For Armv8.1-M, we have TAR
hnan ; Kyrylo
> > Tkachov
> > Subject: Re: [PATCH] arm: Fix ICEs with compare-and-swap and -
> > march=armv8-m.base [PR99977]
> >
> > Ping
> >
> > On 15/04/2021 15:39, Alex Coplan via Gcc-patches wrote:
> > > Hi all,
> > >
> > >
On 30/04/2021 09:30, Alex Coplan via Gcc-patches wrote:
> Hi,
>
> As the PR shows, we ICE shortly after expanding nonsecure calls for
> Armv8.1-M. For Armv8.1-M, we have TARGET_HAVE_FPCXT_CMSE. As it stands,
> the expander (arm.md:nonsecure_call_internal) moves the c
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568669.html
On 26/04/2021 11:15, Alex Coplan via Gcc-patches wrote:
> Hi,
>
> As the PR shows, we currently miscompile V2DImode loads and stores for
> MVE. We're currently using 64-bit loads/stores, but need to be using
>
Hi all,
The PR shows us attaching REG_CFA_ADJUST_CFA notes to stack pointer
adjustments emitted in cmse_nonsecure_call_inline_register_clear (when
-march=armv8.1-m.main). However, the stack pointer is not guaranteed to
be the CFA reg. If we're at -O0 or we have -fno-omit-frame-pointer, then
the
Hi Richard,
On 21/04/2021 13:05, Richard Sandiford wrote:
> Alex Coplan writes:
> > Hi Richard,
> >
> > On 15/04/2021 18:45, Richard Sandiford wrote:
> >> Looks good in general, but like you say, it's GCC 12 material.
> >
> > Thanks for the review. The attached patch addresses these comments and
Hi,
As the PR shows, we ICE shortly after expanding nonsecure calls for
Armv8.1-M. For Armv8.1-M, we have TARGET_HAVE_FPCXT_CMSE. As it stands,
the expander (arm.md:nonsecure_call_internal) moves the callee's address
to a register (with copy_to_suggested_reg) only if
!TARGET_HAVE_FPCXT_CMSE.
Ping
On 15/04/2021 15:39, Alex Coplan via Gcc-patches wrote:
> Hi all,
>
> The PR shows two ICEs with __sync_bool_compare_and_swap and
> -mcpu=cortex-m23 (equivalently, -march=armv8-m.base): one in LRA and one
> later on, after the CAS insn is split.
>
> The L
Hi,
As the PR shows, we currently miscompile V2DImode loads and stores for
MVE. We're currently using 64-bit loads/stores, but need to be using
128-bit vector loads and stores.
Some intrinsics tests were checking that we (incorrectly) used the
64-bit loads/stores: these have been updated.
On 01/04/2021 18:35, Richard Earnshaw wrote:
>
>
> On 01/04/2021 17:11, Alex Coplan via Gcc-patches wrote:
> > Hi all,
> >
> > This patch fixes PR99748 which shows us trying to pass the argument to
> > __aeabi_f2iz in the VFP register s0 when the library functio
Hi,
This simple patch fixes a mismatched operator new/delete in
early-remat.c which triggers ASan errors on (at least) AArch64 when
compiling SVE code.
Bootstrap and regtest on aarch64-linux-gnu in progress.
OK for trunk and backports (as appropriate) if testing looks good?
Thanks,
Alex
Hi,
Here is a backport of my fix for PR99216. The only change w.r.t the
original patch is a bump of lto-streamer.h:LTO_minor_version.
Bootstrapped and regtested on aarch64-linux-gnu, no issues.
OK for GCC 10 branch?
Thanks,
Alex
---
As discussed in the PR, we currently have two different
Hi Richard,
On 15/04/2021 18:45, Richard Sandiford wrote:
> Looks good in general, but like you say, it's GCC 12 material.
Thanks for the review. The attached patch addresses these comments and
bootstraps/regtests OK on aarch64-linux-gnu. OK for trunk?
Thanks,
Alex
>
> Alex Coplan writes:
>
Hi all,
The PR shows two ICEs with __sync_bool_compare_and_swap and
-mcpu=cortex-m23 (equivalently, -march=armv8-m.base): one in LRA and one
later on, after the CAS insn is split.
The LRA ICE occurs because the
@atomic_compare_and_swap_1 pattern attempts to tie
two output operands together
Hi all,
This patch fixes PR99988 which shows us generating large (> 250)
sequences of back-to-back bti j instructions.
The fix is simply to avoid inserting bti j instructions at the target of
a jump table if we've already inserted one for a given label.
Testing:
* Bootstrapped and regtested on
Hi,
Here is a v2 of my previous attempt:
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567724.html
to fix this PR.
---
This patch fixes various issues with vec_duplicate in the MVE patterns.
Currently there are two patterns named *mve_mov. The second of
these is really a vector duplicate
Hi all,
When investigating this PR, I was initially confused as to why we were
matching a vec_duplicate on the RHS of *mve_mov (since
general_operand does not match vec_duplicates). It turns out that there
are two patterns in mve.md named *mve_mov and the second one
matches vec_duplicates. I've
Hi all,
This patch fixes PR99748 which shows us trying to pass the argument to
__aeabi_f2iz in the VFP register s0 when the library function is
expecting to use the GPR r0. It also fixes the __aeabi_f2uiz case which
was broken in the same way.
For the testcase in the PR, here is the code we
Hi Jakub,
On 31/03/2021 21:30, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> In GCC8/9 we used to optimize this into a bswap, but we no longer do.
> Handling byteswapping of pointers is easy, all we need is to allow them,
> for the __builtin_bswap* we already use TYPE_PRECISION to determine
>
Hi all,
I'd like to backport the fix for PR97849 to GCC 10. The patch on trunk:
https://gcc.gnu.org/g:5700973f4a30762b4fc21687bb5f7843e55da2e4
applies cleanly to the 10 branch.
Bootstrapped and regtested on aarch64-linux-gnu, no regressions.
OK for GCC 10.3?
Thanks,
Alex
---
gcc/ChangeLog
On 09/03/2021 15:41, Alex Coplan via Gcc-patches wrote:
> Hi all,
>
> Here is a v2 patch which provides a more obviously fake answer to
> TARGET_BUILTIN_DECL: this can hopefully go in for GCC 11. For GCC 12, it
> seems that we should consider removing the target hook.
>
> Or
Hi Kyrill,
On 19/03/2021 17:18, Kyrylo Tkachov wrote:
> Hi Alex,
>
> > -Original Message-
> > From: Alex Coplan
> > Sent: 19 March 2021 16:45
> > To: gcc-patches@gcc.gnu.org
> > Cc: ni...@redhat.com; Richard Earnshaw ;
> > Ramana Radhakrishnan ; Kyrylo
> > Tkachov
> > Subject: [PATCH]
Hi all,
This patch fixes around 500 ICEs in the testsuite which can be seen when
testing with -march=armv8.1-m.main+mve -mfloat-abi=hard -mpure-code
(leaving the testsuite free of ICEs in this configuration). All of the
ICEs are in arm_print_operand (which is expecting a mem and gets another
rtx,
Hi Vladimir,
On 19/03/2021 10:21, Vladimir Makarov via Gcc-patches wrote:
> The following patch solves P1 PR99581
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
>
> The patch was successfully tested and bootstrapped on x86-64, ppc64le,
> aarch64.
>
> Is it ok for the trunk?
Can we
This patch fixes a typo in the description of
aarch64_vfp_is_call_or_return_candidate.
Committed as obvious.
Thanks,
Alex
gcc/ChangeLog:
* config/aarch64/aarch64.c (aarch64_vfp_is_call_or_return_candidate):
Fix typo in comment describing "is_ha" argument.
diff --git
Hi all,
Here is a v2 patch which provides a more obviously fake answer to
TARGET_BUILTIN_DECL: this can hopefully go in for GCC 11. For GCC 12, it
seems that we should consider removing the target hook.
Original patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566405.html
---
As
On 08/03/2021 16:21, Richard Biener wrote:
> On Mon, Mar 8, 2021 at 4:14 PM Alex Coplan wrote:
> >
> > On 08/03/2021 14:57, Richard Biener wrote:
> > > On Mon, Mar 8, 2021 at 12:44 PM Alex Coplan via Gcc-patches
> > > wrote:
> > > >
> > >
On 08/03/2021 14:57, Richard Biener wrote:
> On Mon, Mar 8, 2021 at 12:44 PM Alex Coplan via Gcc-patches
> wrote:
> >
> > Hi all,
> >
> > As discussed in the PR, we currently have two different numbering
> > schemes for SVE builtins: one for C, and one for
Hi all,
As discussed in the PR, we currently have two different numbering
schemes for SVE builtins: one for C, and one for C++. This is
problematic for LTO, where we end up getting confused about which
intrinsic we're talking about. This patch inserts placeholders into the
registered_functions
Hi!
As the PR shows, we were missing a check in
function_resolver::require_vector_type to see if the argument type was already
invalid. This was causing us to attempt to emit a diagnostic and subsequently
ICE in print_type. Fixed thusly.
Bootstrapped and regtested on aarch64-linux-gnu. OK for
Hi Andre,
Thanks for fixing this.
On 19/02/2021 10:53, Andre Vieira (lists) via Gcc-patches wrote:
> Hi,
>
> This patch makes sure that allocno copies are not created for unordered
> modes. The testcases in the PR highlighted a case where an allocno copy was
> being created for:
> (insn 121 120
Hello,
This patch adds a missing not to the SVE2 BCAX (Bitwise clear and
exclusive or) pattern, fixing the PR. Since SVE doesn't have an
unpredicated not instruction, we need to use a (vacuously) predicated
not here.
To ensure that the predicate is instantiated correctly (to all 1s) for
the
Committing this as obvious.
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 2b462869437..813875b973b 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -1634,7 +1634,7 @@ constraints with multiple alternatives, sometimes one
alternative
requires @samp{&} while others do not. See, for
This patch fixes a bug in the AArch64 backend. Currently, we accept an
odd sign_extract representation of addresses, but don't accept that same
odd form of address as an LEA.
This is the cause of PR96998. In the testcase given in the PR, combine
produces:
(insn 9 8 10 3 (set (mem:SI (plus:DI
On 28/10/2020 09:09, Alex Coplan via Gcc-patches wrote:
> On 27/10/2020 17:31, Segher Boessenkool wrote:
> > On Tue, Oct 27, 2020 at 10:35:59AM +, Alex Coplan wrote:
> > > On 26/10/2020 12:43, Segher Boessenkool wrote:
> > > > I do not like handling both mu
On 27/10/2020 17:31, Segher Boessenkool wrote:
> On Tue, Oct 27, 2020 at 10:35:59AM +, Alex Coplan wrote:
> > On 26/10/2020 12:43, Segher Boessenkool wrote:
> > > I do not like handling both mult and ashift in one case like this, it
> > > complicates things for no good reason. Write it as two
On 27/10/2020 10:35, Alex Coplan via Gcc-patches wrote:
> On 26/10/2020 12:43, Segher Boessenkool wrote:
> > I do not like handling both mult and ashift in one case like this, it
> > complicates things for no good reason. Write it as two cases, and it
> > should be good.
On 26/10/2020 12:43, Segher Boessenkool wrote:
> On Mon, Oct 26, 2020 at 01:28:42PM +, Alex Coplan wrote:
> > On 26/10/2020 07:12, Segher Boessenkool wrote:
> > > On Thu, Oct 15, 2020 at 09:59:24AM +0100, Alex Coplan wrote:
> > > Can you instead replace the mult by a shift somewhere earlier in
On 26/10/2020 07:12, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Oct 15, 2020 at 09:59:24AM +0100, Alex Coplan wrote:
> > @@ -7650,20 +7650,27 @@ make_extraction (machine_mode mode, rtx inner,
> > HOST_WIDE_INT pos,
> > is_mode = GET_MODE (SUBREG_REG (inner));
> >inner = SUBREG_REG
On 26/10/2020 06:51, Segher Boessenkool wrote:
> On Mon, Oct 26, 2020 at 11:06:22AM +, Alex Coplan wrote:
> > Well, only the low 32 bits of the subreg are valid. But because those
> > low 32 bits are shifted left 2 times, the low 34 bits of the ashift are
> > valid: the bottom 2 bits of the
On 26/10/2020 11:06, Alex Coplan via Gcc-patches wrote:
> Well, only the low 32 bits of the subreg are valid. But because those
> low 32 bits are shifted left 2 times, the low 34 bits of the ashift are
> valid: the bottom 2 bits of the ashift are zeros, and the 32 bits above
> th
On 26/10/2020 05:48, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Oct 26, 2020 at 10:09:41AM +, Alex Coplan wrote:
> > On 22/10/2020 15:39, Segher Boessenkool wrote:
> > > On Thu, Oct 15, 2020 at 09:59:24AM +0100, Alex Coplan wrote:
> > > > Currently, make_extraction() identifies where we can
Hi Segher,
On 22/10/2020 15:39, Segher Boessenkool wrote:
> On Thu, Oct 15, 2020 at 09:59:24AM +0100, Alex Coplan wrote:
> > Currently, make_extraction() identifies where we can emit an ASHIFT of
> > an extend in place of an extraction, but fails to make the corresponding
> >
Ping.
Hopefully this is easier to review/test now that we fix the AArch64 bug first
and deliberately regress code quality so that the impact of the combine patch
can be measured.
On 15/10/2020 09:59, Alex Coplan via Gcc-patches wrote:
> Currently, make_extraction() identifies where we can e
Hi Segher,
On 12/10/2020 12:14, Segher Boessenkool wrote:
> On Mon, Oct 12, 2020 at 05:19:58PM +0100, Richard Sandiford wrote:
> >
> > I agree there's a target bug here. Please see the explanation I posted
> > in: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554518.html
> >
Currently, make_extraction() identifies where we can emit an ASHIFT of
an extend in place of an extraction, but fails to make the corresponding
canonicalization/simplification when presented with a MULT by a power of
two. Such a representation is canonical when representing a left-shifted
address
This patch fixes a bug in the AArch64 backend. Currently, we accept an
odd sign_extract representation of addresses, but don't accept that same
odd form of address as an LEA.
This is the cause of PR96998. In the testcase given in the PR, combine
produces:
(insn 9 8 10 3 (set (mem:SI (plus:DI
Hi Segher,
On 08/10/2020 15:20, Segher Boessenkool wrote:
> On Thu, Oct 08, 2020 at 11:21:26AM +0100, Alex Coplan wrote:
> > Ping. The kernel is still broken on AArch64.
>
> You *cannot* fix a correctness bug with a combine addition.
Ping. The kernel is still broken on AArch64.
On 30/09/2020 11:39, Alex Coplan via Gcc-patches wrote:
> Currently, make_extraction() identifies where we can emit an ASHIFT of
> an extend in place of an extraction, but fails to make the corresponding
> canonicalization/simplification when
This patch adds the part number for Neoverse V1 which was missing from
the initial AArch32 support in GCC 8.
Bootstrapped and regtested on arm-none-linux-gnueabihf, pushing as
obvious.
Thanks,
Alex
---
gcc/ChangeLog:
* config/arm/driver-arm.c (arm_cpu_table): Add neoverse-v1.
diff
This patch backports the AArch32 support for Arm's Neoverse N2 CPU to
GCC 8.
Testing:
* Bootstrapped and regtested on arm-none-linux-gnueabihf.
OK for GCC 8 branch?
Thanks,
Alex
---
gcc/ChangeLog:
* config/arm/arm-cpus.in (neoverse-n2): New.
* config/arm/arm-tables.opt:
This patch backports the AArch32 support for Arm's Neoverse N2 CPU to
GCC 9.
Testing:
* Bootstrapped and regtested on arm-none-linux-gnueabihf.
OK for GCC 9 branch?
Thanks,
Alex
---
gcc/ChangeLog:
* config/arm/arm-cpus.in (neoverse-n2): New.
* config/arm/arm-tables.opt:
This patch backports the AArch32 support for Arm's Neoverse N2 CPU to
GCC 10.
Testing:
* Bootstrapped and regtested on arm-none-linux-gnueabihf.
OK for GCC 10 branch?
Thanks,
Alex
---
gcc/ChangeLog:
* config/arm/arm-cpus.in (neoverse-n2): New.
* config/arm/arm-tables.opt:
This patch adds vendor and part numbers which were missing from the
initial entry for Neoverse V1 in AArch32 GCC.
OK for trunk and backports to GCC 10 and 9?
I believe GCC 8 handles these differently so that will need fixing
separately.
Thanks,
Alex
---
gcc/ChangeLog:
*
This patch moves the recent entry for Neoverse N2 down and adds a
comment in order to preserve the existing order/structure in
arm-cpus.in.
Bootstrapped and tested on arm-linux-gnueabihf.
Committing as obvious.
Alex
---
gcc/ChangeLog:
* config/arm/arm-cpus.in: Fix ordering, move
1 - 100 of 106 matches
Mail list logo
