rts while the GCC built binary passes.
Thanks again!
Matthew
On 2/7/25 15:33, Jonathan Wakely wrote:
External email: Use caution opening links or attachments
On 05/02/25 13:43 +, Jonathan Wakely wrote:
On 28/10/24 17:15 +, mmalcom...@nvidia.com wrote:
From: Matthew Malcomson
I not
email: Use caution opening links or attachments
On Fri, Jan 03, 2025 at 05:48:12PM +0000, Matthew Malcomson wrote:
On 1/3/25 17:14, Joseph Myers wrote:
Does this patch cover everything dealt with by
<https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672242.html>
([PATCH] testsu
Again -- apologies for the noise
On 1/22/25 16:16, Matthew Malcomson wrote:
*External email: Use caution opening links or attachments*
Apologies for the noise.
Apologies for the noise.
On 11/14/24 13:55, mmalcom...@nvidia.com wrote:
From: Matthew Malcomson
Hello,
This is the revision of the RFC posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663355.html
This patchset introduces floating point versions of atomic fetch_add,
fetch_sub, add_fetc
Ah -- I didn't notice that patch.
It looks like both do essentially the same thing.
That one identifies the use of the c++ test runner by checking for the
presence of the `lang_test_file` variable, and in that case
`libitm_target_compile` adds the options, while in my patch the c++ test
runne
taching a patch with this approach -- which is much simpler than the
previous patch.
How does that look to you?
On 1/2/25 15:58, Richard Sandiford wrote:
External email: Use caution opening links or attachments
Matthew Malcomson writes:
On 1/2/25 12:08, Richard Sandiford wrote:
+# This
was unset at start
=> saved_TEST_ALWAYS_FLAGS is unset.
- Has been set in libitm_init and was set at start
=> saved_TEST_ALWAYS_FLAGS is set.
- Has already been reset => some other flag.
Have attached the adjusted patch to this email.
From fbce3b25e8ccad80697f1596f566b268fff71221 Mon Sep
Attempting to resend my response differently since my last email seems
to have had problems with email permissions.
Apologies for the duplication.
On 12/2/24 16:48, Jason Merrill wrote:
External email: Use caution opening links or attachments
On 10/21/24 6:43 AM, Matthew Malcomson wrote
Ping 4
Also adding those that I've Cc'd in the patchset for FP atomics since this
patch is enabling that one.
____
From: Matthew Malcomson
Sent: 26 November 2024 10:26 AM
To: gcc-patches@gcc.gnu.org
Cc: Jason Merrill ; Nathan Sidwell
Subject: Re: Ping:
n 11/22/24 11:47, Matthew Malcomson wrote:
External email: Use caution opening links or attachments
Wanted to provide a link to the current patch that Prathamesh has worked
on for automatically linking in libatomic (since this patch relies on
that for the idea approach).
https://gcc.gnu.org/pip
Ping 3
On 11/18/24 13:22, Matthew Malcomson wrote:
External email: Use caution opening links or attachments
Ping 2
On 10/21/24 11:43, Matthew Malcomson wrote:
External email: Use caution opening links or attachments
Ping (re-sending ping because previous message body too large for list
: Matthew Malcomson
Hello,
This is the revision of the RFC posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663355.html
This patchset introduces floating point versions of atomic fetch_add,
fetch_sub, add_fetch and sub_fetch. Instructions for performing these
operations have
Attempting to resend since got rejected from gcc-patches mailing list.
(Apologies about the duplication to those on Cc).
On 11/18/24 11:25, Matthew Malcomson wrote:
On 11/14/24 18:44, Joseph Myers wrote:
External email: Use caution opening links or attachments
On Thu, 14 Nov 2024,mmalcom
Ping 2
On 10/21/24 11:43, Matthew Malcomson wrote:
External email: Use caution opening links or attachments
Ping (re-sending ping because previous message body too large for list --
apologies for duplication to those on Cc).
Attaching update on testsuite to fix testism on Arm that Linaro CI
27;t look like there's any
>objection to implementing that.
Seems that the testsuite and build system are the main things to watch out for
here right?
Does that seem reasonable to others?
From: Joseph Myers
Sent: 14 October 2024 6:47 PM
To: Matthew Malcomso
27;m unfamiliar with.
From: Jonathan Wakely
Sent: 14 October 2024 2:36 PM
To: Matthew Malcomson
Cc: Joseph Myers ; gcc-patches@gcc.gnu.org
Subject: Re: libstdc++ fetch_add & fenv -- ecosystem questions
External email: Use caution opening links or attachments
O
re your thoughts?
Regards,
Matthew
From: Joseph Myers
Sent: 19 September 2024 10:38 PM
To: Matthew Malcomson
Cc: gcc-patches@gcc.gnu.org ; Jonathan Wakely
; Richard Biener
Subject: Re: [PATCH 0/8] [RFC] Introduce floating point fetch_add builtins
External email: Use caution ope
ecific builtins)?
From: Jonathan Wakely
Sent: 19 September 2024 3:47 PM
To: Matthew Malcomson
Cc: gcc-patches@gcc.gnu.org ; Joseph Myers
; Richard Biener
Subject: Re: [PATCH 0/8] [RFC] Introduce floating point fetch_add builtins
External email: Use caution opening links
On 7/10/24 13:42, Rainer Orth wrote:
N.b. one alternative would be to remove this effective target and try to
move all tests which currently use this into directories which run their
tests between calls to `asan_finish` and `asan_init`. This seems like
it might ensure a clearer division of "asan
property that uses a different name to cache under, given that this is
testing something different than the original function.
Have again tested that the problematic tests run without an install
directory.
On 7/10/24 13:19, Matthew Malcomson wrote:
The current no_fsanitize_address effective
The current no_fsanitize_address effective target check (implemented in
target-supports.exp rather than in asan.exp) has some problems with the
link path.
Because it is not called from in between asan_init and asan_finish the
link paths of the compiler are not changed to point at the build
directo
t; in any way.
On 4/8/24 11:34, Matthew Malcomson wrote:
The `function_attribute_inlinable_p` hook documentation described it
returning the value if it is OK to inline the provided fndecl into "the
current function". AFAICS This hook is only called when
`current_function_decl` is the
The `function_attribute_inlinable_p` hook documentation described it
returning the value if it is OK to inline the provided fndecl into "the
current function". AFAICS This hook is only called when
`current_function_decl` is the same as the `fndecl` argument that the
hook is given, hence asking whe
Hi Alexandre,
I don't have the ability to OK the patch, but I'm attempting to do a
review in
order to reduce the workload for any maintainer. (Apologies for the slow
response).
I think you're right that the AAPCS32 requires all arguments to be passed in
registers for this testcase.
(Nit on th
On 8/9/23 19:14, Jakub Jelinek via Gcc-patches wrote:
It is enabled only on targets which have agreed on processor specific
ABI how to lay those out or pass as function arguments/return values,
which currently is just x86-64 I believe, would be nice if target maintainers
helped to get agreement
Hopefully last update ...
> Specifically, please try compiling with
>-ftime-report -fdiagnostics-format=sarif-file
> and have a look at the generated .sarif file, e.g. via
>python -m json.tool foo.c.sarif
> which will pretty-print the JSON to stdout.
Rebasing onto the JSON output was quit
On 8/3/23 15:09, David Malcolm wrote:
Hi Matthew. I recently touched the timevar code (in r14-2881-
g75d623946d4b6e) to add support for serializing the timevar data in
JSON form as part of the SARIF output (PR analyzer/109361).
Looking at your patch, it looks like the baseline for the patch se
>
> I think this is undesriable. With fused you mean we use FMA?
> I think you could use -ffp-contract=off for the TU instead.
>
> Note you can't use __attribute__((noinline)) literally since the
> host compiler might not support this.
>
> Richard.
>
Trying to make the timevar store integral
Also reformat a comment that had too long lines.
Commit c5bd0e5870a introduced both these problems to fix.
Committed as obvious after ensuring that when running the testcase on
AArch64 it still fails before the original c5bd0e5870a commit and passes
after it.
gcc/ChangeLog:
* tree-vect-s
On 7/21/23 14:45, Xi Ruoyao wrote:
On Fri, 2023-07-21 at 14:11 +0100, Matthew Malcomson wrote:
My understanding is that this is not a hardware bug and that it's
specified that rounding does not happen on the multiply "sub-part" in
`FNMSUB`, but rounding happens on the `FMUL` that
Responding to two emails at the same time ;-)
On 7/21/23 13:47, Richard Biener wrote:
On Fri, 21 Jul 2023, Matthew Malcomson wrote:
On some AArch64 bootstrapped builds, we were getting a flaky test
because the floating point operations in `get_time` were being fused
with the floating point
On some AArch64 bootstrapped builds, we were getting a flaky test
because the floating point operations in `get_time` were being fused
with the floating point operations in `timevar_accumulate`.
This meant that the rounding behaviour of our multiplication with
`ticks_to_msec` was different when us
Tamar pointed out it would be good to have a `scan-tree-dump` in the testcase
just to make sure that when something is currently vectorizing it stays
vectorizing (and hence that the new code is still likely running).
Attached patch has that change, also inlined for ease of reply.
Our checks for whether the vectorization of a given loop would make an
out of bounds access miss the case when the vector we load is so large
as to span multiple iterations worth of data (while only being there to
implement a single iteration).
This patch adds a check for such an access.
Example
The original documentation added to mention the clash between
-fsanitize=address and -fsanitize=hwaddress used confusing wording trying to
say that -fsanitize=hwaddress is only available on AArch64.
It read as if -fsanitize=address were only supported on AArch64.
This patch fixes that wording by
gcc-11/changes: Document new Hardware-assisted AddressSanitizer.
I have put it in the "general" section rather than AArch64 since the feature
does add a general framework, so I believe the news is interesting for people
interesting in architectures other than AArch64 that may want to implement thi
Hello,
-
This test should ensure that we can compile with hwasan, that such a compiled
binary runs as expected, *and* that we're running on a kernel which implements
the capability to ignore the top bytes of pointers in syscalls.
It was expected that a basic test of `int main(void) { return
an obvious fix after the
patchset as it is now goes in.
That way I can say I ran all my tests on the patch series that I applied
without going through the all the tests again.
Thanks for the catch!
Matthew
On Sat, Nov 21, 2020 at 2:48 AM Matthew Malcomson via Gcc-patches
wrote:
On 24/11/2020 15:53, Kyrylo Tkachov wrote:
Hi Matthew,
-Original Message-
From: Gcc-patches On Behalf Of
Matthew Malcomson via Gcc-patches
Sent: 24 November 2020 15:47
To: gcc-patches@gcc.gnu.org
Cc: Richard Sandiford
Subject: libsanitizer: Hwasan reporting check for dladdr failing
Hello there,
This is the compiler-rt patch I'd like to cherry-pick so that the hwasan tests
pass.
It is in LLVM as commit 83ac18205ec69a00ac2be3b603bc3a61293fbe89.
Ok for trunk?
Also is the libhwasan library merge from the below email OK for trunk?
https://gcc.gnu.org/pipermail/gcc-patches/2020
Hello,
Update of the hwasan tests attached.
Ok for trunk?
(NOTE on the state of the entire patch series:
Currently re-testing everything from scratch to ensure I didn't get tripped up
from old state carried around.
Also looking into PR 97941 on hwasan. As yet don't understand what's goin
Hi there,
I was just doing some double-checks and noticed I'd placed the
documentation in the wrong section of tm.texi. The `MEMTAG` hooks were
documented in the `Register Classes` section, so I've now moved it to
the `Misc` section.
That's the only change, Ok for trunk?
Matthew
-
Hi there,
I was just doing some double-checks and noticed I'd placed the
documentation in the wrong section of tm.texi. The `MEMTAG` hooks were
documented in the `Register Classes` section, so I've now moved it to
the `Misc` section.
That's the only change, Ok for trunk?
Matthew
---
On 13/11/2020 17:22, Martin Liška wrote:
On 11/13/20 5:57 PM, Matthew Malcomson wrote:
Hi there,
Thanks for the heads-up.
As it turns out the most recent `libhwasan` crashes when displaying an
address on the stack in Linux.
Hello.
What a bad luck.
I'm currently working on getti
On 13/01/2020 10:40, Matthew Malcomson wrote:
On 11/01/2020 07:19, Gerald Pfeifer wrote:
On Thu, 12 Dec 2019, Matthew Malcomson wrote:
gcc/ChangeLog:
2019-12-12 Matthew Malcomson
* doc/install.texi: Document bootstrap-asan configuration option.
I see this introduces a new table
Updates after latest review.
(testing underway)
---
There are four main features to this change:
1) Check pointer tags match address tags.
When sanitizing for hwasan we now put HWASAN_CHECK internal functions before
memory accesses in the `asan` pass. This checks that a tag in
Update to match the change in initialisation for patch 5/X.
MM
---
There are four main features to this change:
1) Check pointer tags match address tags.
When sanitizing for hwasan we now put HWASAN_CHECK internal functions before
memory accesses in the `asan` pass. This checks that a tag in
Hi there,
After offline discussion with Richard I've modified the way in which the
initialisation for the hwasan base pointer is emitted.
Originally it was getting emitted during `expand_used_vars`, and
requiring `handle_builtin_alloca` to register a need for it to be
emitted so that `expand_HWASA
There are four main features to this change:
1) Check pointer tags match address tags.
When sanitizing for hwasan we now put HWASAN_CHECK internal functions before
memory accesses in the `asan` pass. This checks that a tag in the pointer
being used match the tag stored in shadow memory for the m
Handling stack variables has three features.
1) Ensure HWASAN required alignment for stack variables
When tagging shadow memory, we need to ensure that each tag granule is
only used by one variable at a time.
This is done by ensuring that each tagged variable is aligned to the tag
granule repres
This patch tries to tie libhwasan into the GCC build system in the same way
that the other sanitizer runtime libraries are handled.
libsanitizer/ChangeLog:
* Makefile.am: Build libhwasan.
* Makefile.in: Build libhwasan.
* asan/Makefile.in: Build libhwasan.
* con
These flags can't be used at the same time as any of the other
sanitizers.
We add an equivalent flag to -static-libasan in -static-libhwasan to
ensure static linking.
The -fsanitize=kernel-hwaddress option is for compiling targeting the
kernel. This flag has defaults to match the LLVM implementat
This is an analogous option to --bootstrap-asan to configure. It allows
bootstrapping GCC using HWASAN.
For the same reasons as for ASAN we have to avoid using the HWASAN
sanitizer when compiling libiberty and the lto-plugin.
Also add a function to query whether -fsanitize=hwaddress has been
pas
Adding hwasan tests.
Only interesting thing here is that we have to make sure the tagging mechanism
is deterministic to avoid flaky tests.
gcc/testsuite/ChangeLog:
* c-c++-common/ubsan/sanitize-recover-7.c:
* c-c++-common/hwasan/aligned-alloc.c: New test.
* c-c++-common/h
Though the library has limited support for x86, we don't have any
support for generating code targeting x86 so there is no point building
for that target.
Ensure we build for AArch64 but not for AArch64 ilp32.
libsanitizer/ChangeLog:
* Makefile.am: Condition Build hwasan directory.
Hello,
Bootstrapped and regression tested on AArch64
(have not finished running tests on the Linux Kernel yet).
Sending upstream to catch next set of comments early.
This version mainly just consists of requested changes.
Some notable exceptions:
Have rebased onto a newer version, there was a c
16:33
To: Matthew Malcomson ; gcc-patches@gcc.gnu.org
Cc: ja...@redhat.com ; Richard Earnshaw
; k...@google.com ; do...@redhat.com
; jos...@codesourcery.com
Subject: Re: [Patch 0/X] HWASAN v4
On 10/16/20 11:03 AM, Martin Li�ka wrote:
> Hello.
>
> I've just merged libsaniti
Hello,
In a recent review for one of the hwasan patches Richard S. noticed there are
quite a few errors of the form "% is incompatible with
".
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556137.html
In order to avoid this creating extra work for translators we would like to
change thes
Hi Richard,
I'm sending up the revised patch 5 (introducing stack variable handling)
without the other changes to other patches.
I figure there's been quite a lot of changes to this patch and I wanted
to give you time to review them while I worked on finishing the less
widespread changes in patch
efer to have the "hwasan" pass separate (I liked having the
"correct" names for the -fdump-tree* arguments and dump files).
That said -- if you feel strongly about this I'll happily change it.
From: Richard Sandiford
Sent: 13 October 202
These flags can't be used at the same time as any of the other
sanitizers.
We add an equivalent flag to -static-libasan in -static-libhwasan to
ensure static linking.
The -fsanitize=kernel-hwaddress option is for compiling targeting the
kernel. This flag has defaults that allow compiling KASAN wi
There are four main features to this change:
1) Check pointer tags match address tags.
In the new `hwasan` pass we put HWASAN_CHECK internal functions before
all memory accesses to check that tags in the pointer being used match
the tag stored in shadow memory for the memory region being used.
T
Handling stack variables has three features.
1) Ensure HWASAN required alignment for stack variables
When tagging shadow memory, we need to ensure that each tag granule is
only used by one variable at a time.
This is done by ensuring that each tagged variable is aligned to the tag
granule repres
Adding hwasan tests.
Only interesting thing here is that we have to make sure the tagging mechanism
is deterministic to avoid flaky tests.
gcc/testsuite/ChangeLog:
* c-c++-common/hwasan/aligned-alloc.c: New test.
* c-c++-common/hwasan/alloca-array-accessible.c: New test.
This patch tries to tie libhwasan into the GCC build system in the same way
that the other sanitizer runtime libraries are handled.
libsanitizer/ChangeLog:
* Makefile.am: Build libhwasan.
* Makefile.in: Build libhwasan.
* asan/Makefile.in: Build libhwasan.
* con
Though the library has limited support for x86, we don't have any
support for generating code targeting x86 so there is no point building
for that target.
libsanitizer/ChangeLog:
* Makefile.am: Condition building hwasan directory.
* Makefile.in: Regenerate.
* configure: Re
This is an analogous option to --bootstrap-asan to configure. It allows
bootstrapping GCC using HWASAN.
For the same reasons as for ASAN we have to avoid using the HWASAN
sanitizer when compiling libiberty and the lto-plugin.
Also add a function to query whether -fsanitize=hwaddress has been
pas
On 24/07/2020 12:01, Kyrylo Tkachov wrote:
Hi Matthew,
-Original Message-
From: Matthew Malcomson
Sent: 21 July 2020 16:16
To: gcc-patches@gcc.gnu.org
Cc: Richard Earnshaw ; Kyrylo Tkachov
; Ross Burton
Subject: SLS Mitigation patches backported for GCC9
Hello,
Eventually we will
Here we introduce the flags that will be used for straight line speculation.
The new flag introduced is `-mharden-sls=`.
This flag can take arguments of `none`, `all`, or a comma seperated list
of one or more of `retbr` or `blr`.
`none` indicates no special mitigation of the straight line speculat
Instructions following RET or BR are not necessarily executed. In order
to avoid speculation past RET and BR we can simply append a speculation
barrier.
Since these speculation barriers will not be architecturally executed,
they are not expected to add a high performance penalty.
The speculation
This patch introduces the mitigation for Straight Line Speculation past
the BLR instruction.
This mitigation replaces BLR instructions with a BL to a stub which uses
a BR to jump to the original value. These function stubs are then
appended with a speculation barrier to ensure no straight line
sp
Hello,
Eventually we will want to backport the SLS patches to older branches.
When the GCC10 release is unfrozen we will work on getting the same patches
already posted backported to that branch. The patches already posted on the
mailing list apply cleanly to the current releases/gcc-10 branch.
BR is immediately
followed by a speculation barrier.
gcc/ChangeLog:
2020-07-03 Matthew Malcomson
* config/aarch64/aarch64-protos.h (aarch64_sls_barrier): New.
* config/aarch64/aarch64.c (aarch64_output_casesi): Emit
speculation barrier after BR instruction if nee
speculation barrier after it.
Setting this on a per-function basis using attributes or the like is not
enabled, but may be in the future.
gcc/ChangeLog:
2020-07-03 Matthew Malcomson
* config/aarch64/aarch64-protos.h (aarch64_harden_sls_retbr_p):
New
On 23/06/2020 16:48, Richard Sandiford wrote:
Matthew Malcomson writes:
@@ -14466,6 +14466,81 @@ aarch64_validate_mcpu (const char *str, const struct
processor **res,
return false;
mfix-cortex-a53-835769
Target Report Var(aarch64_fix_a53_err835769) Init(2) Save
Workaround for ARM
On 23/06/2020 17:56, Richard Sandiford wrote:
Matthew Malcomson writes:
On 23/06/2020 17:17, Richard Sandiford wrote:
Matthew Malcomson writes:
--- a/gcc/config/aarch64/aarch64-protos.h
+/* Ensure there are no BR or RET instructions which are not directly followed
+ by a speculation
On 23/06/2020 17:17, Richard Sandiford wrote:
Matthew Malcomson writes:
--- a/gcc/config/aarch64/aarch64-protos.h
+/* Ensure there are no BR or RET instructions which are not directly followed
+ by a speculation barrier. */
+/* { dg-final { scan-assembler-not
"\t(br|ret|retaa|retab)\
is immediately followed by a speculation barrier.
b) No BLR instruction is emitted by compiler.
gcc/ChangeLog:
2020-06-23 Matthew Malcomson
* config/aarch64/aarch64-protos.h (aarch64_indirect_call_asm):
New declaration.
* config/aarch64/aarch64.c (aarch64_regno_regcla
every RET or BR is immediately
followed by a speculation barrier.
gcc/ChangeLog:
2020-06-08 Matthew Malcomson
* config/aarch64/aarch64-protos.h (aarch64_sls_barrier): New.
* config/aarch64/aarch64.c (aarch64_output_casesi): Emit
speculation barrier after BR instruction
ted by compiler.
gcc/ChangeLog:
2020-06-08 Matthew Malcomson
* config/aarch64/aarch64-protos.h (aarch64_indirect_call_asm):
New declaration.
* config/aarch64/aarch64.c (aarch64_use_return_insn_p): Return
false if hardening BLR instructions.
(aarch64_sl
.
Setting this on a per-function basis using attributes or the like is not
enabled, but may be in the future.
gcc/ChangeLog:
2020-06-08 Matthew Malcomson
* config/aarch64/aarch64-protos.h (aarch64_harden_sls_retbr_p):
New.
(aarch64_harden_sls_blr_p): New.
* config
Hi,
A new speculative cache side-channel vulnerability has been published at
the link below, named "straight-line speculation" (SLS in this patch series).
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation
This vulnerabili
-April/544204.html
Regression tested on arm-none-eabi.
gcc/ChangeLog:
2020-04-27 Matthew Malcomson
Jakub Jelinek
PR target/94383
* config/arm/arm.c (aapcs_vfp_sub_candidate): Account for C++17 empty
base class
:
2020-04-23 Matthew Malcomson
Jakub Jelinek
PR target/94383
* config/aarch64/aarch64.c (aapcs_vfp_sub_candidate): Account for C++17
empty base class artificial fields.
(aarch64_vfp_is_call_or_return_candidate): Warn when ABI PCS decision is
di
gcc/ChangeLog:
2020-04-21 Matthew Malcomson
Jakub Jelinek
PR target/94383
* config/aarch64/aarch64.c (enum cpp17empty_state): New.
(aapcs_vfp_sub_candidate): Account for C++17 empty base class
artificial fields.
(aarch64_vfp_is_call_or_return_can
On 20/04/2020 08:47, Christophe Lyon via Gcc-patches wrote:
Since arm_cde.h includes stdint.h, its use requires the presence of
the right gnu/stub-*.h, so make sure to include it when checking the
arm_v8*m_main_cde* effective targets, otherwise we can decide CDE is
supported while it's not really
04-15 Matthew Malcomson
* config/arm/arm.md (arm_movdi): Disallow for MVE.
### Attachment also inlined for ease of reply###
diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index
7bc55cce61b2e45e5875a233dd4546d5939
thout name
mangling. Hence all the function names are the same and we have many
conflicting declarations.
Testing Done:
Regression tested for arm-none-eabi.
gcc/ChangeLog:
2020-04-09 Matthew Malcomson
* config/arm/arm_cde.h: Remove `extern "C"` when compiling for
New in GCC 10.
### Attachment also inlined for ease of reply###
diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index
3d8e0ba989e860d307310378a2be99b32a27261f..389561d13c69b650528e8ed8859ebbb5760438c6
100644
--- a/htdocs/gcc-10/changes.html
generation for
-Os when producing the cx*d instructions.
Testing done:
Bootstrapped and regtested for arm-none-linux-gnueabihf.
gcc/ChangeLog:
2020-04-08 Matthew Malcomson
* config/arm/arm.c (arm_hard_regno_mode_ok): DImode registers forced
into even-odd register pairs for
with CDE -- this avoids faulty code generation for
-Os
when producing the cx*d instructions.
Testing done:
Bootstrapped and regtested for arm-none-linux-gnueabihf.
gcc/ChangeLog:
2020-04-08 Matthew Malcomson
* config/arm/arm.c (arm_hard_regno_mode_ok): DImode registers forced
into
pace
between the mnemonic and the first argument, but in one case it just has
a tab -- making all the same helps make test regexps simpler.
Testing Done:
Bootstrap and full regtest on arm-none-linux-gnueabihf
Full regtest on arm-none-eabi
gcc/ChangeLog:
2020-04-08 Matthew Malcomson
Ok for trunk?
gcc/ChangeLog:
2020-04-08 Matthew Malcomson
* config.gcc (arm_mve_types.h): New extra_header for arm.
* config/arm/arm-builtins.c (arm_resolve_overloaded_builtin): New.
(arm_init_cde_builtins): New.
(arm_init_acle_builtins): Remove initialisation
ug.cgi?id=94341
gcc/ChangeLog:
2020-04-07 Matthew Malcomson
* config/arm/arm-builtins.c (CX_UNARY_UNONE_QUALIFIERS): New.
(CX_BINARY_UNONE_QUALIFIERS): New.
(CX_TERNARY_UNONE_QUALIFIERS): New.
(arm_resolve_overloaded_builtin): Move to arm-c.c.
(arm_expa
by
Dennis.
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542008.html
Ok for trunk?
gcc/ChangeLog:
2020-03-26 Matthew Malcomson
* config.gcc (arm_mve_types.h): New extra_header for arm.
* config/arm/arm-builtins.c (arm_resolve_overloaded_builtin): New
Cc'ing maintainers and original author of `check-function-bodies`.
It looks like I missed that the first time around.
Forwarded Message
Subject: [testsuite] Add @ lines to check-function-bodies fluff
Date: Tue, 10 Mar 2020 17:22:52 +
From: Matthew Malcomson
To
o I'd like to remove such `@` lines automatically.
gcc/testsuite/ChangeLog:
2020-03-10 Matthew Malcomson
* lib/scanasm.exp (parse_function_bodies): Lines starting with '@' also
counted as fluff.
### Attachment also inlined for ease of reply
read.
Testing Done:
Checked on a cross-compiler that:
Tests running for binutils commit e264b5b7a are listed as UNSUPPORTED.
Tests running for binutils commit 26916852e all pass.
gcc/testsuite/ChangeLog:
2020-01-21 Matthew Malcomson
* gcc.target/aarch64/sve/acle/asm/ld1ro_f16.c: Use re
On 20/01/2020 14:53, Christophe Lyon wrote:
> On Thu, 9 Jan 2020 at 16:53, Matthew Malcomson
> wrote:
>>
>> + (match_test "aarch64_sve_ld1ro_operand_p (op, DImode)")))
>> +
>
>
>> (define_predicate "aarch64_sve_ldff1_operand"
&
1 - 100 of 241 matches
Mail list logo
