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)\
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 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
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
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
{
return 200;
}
```
Now it silently ignores the __RTL function and successfully compiles foo_a.
regtest done on aarch64
regtest done on x86_64
OK for trunk?
gcc/ChangeLog:
2019-11-14 Matthew Malcomson
* run-rtl-passes.c (run_rtl_passes): Accept and handle empty
"initi
set (reg:DI x19) (reg:DI x0)))
(cinsn 10 (use (reg/i:SI x19)))
(edge-to exit (flags "FALLTHRU"))
) ;; block 2
) ;; insn-chain
) ;; function "foo2"
}
```
Now it silently ignores the __RTL function and successfully compiles foo2.
regtest done on aarch64
regtest done on x86_64
native x64_86
gcc/ChangeLog:
2019-11-15 Matthew Malcomson
* passes.c (skip_pass): Set epilogue_completed if skipping the
pro_and_epilogue pass.
gcc/testsuite/ChangeLog:
2019-11-15 Matthew Malcomson
* gcc.dg/rtl/aarch64/test-epilogue-set.c: New test
The documentation for __RTL tests (see "(gccint) RTL Tests" info node) has the
following snippet.
```
The parser expects the RTL body to be in the format emitted by this
dumping function:
DEBUG_FUNCTION void
print_rtx_function (FILE *outfile, function *fn, bool compact);
when "compac
Hi Martin,
Thanks for the review,
I'll get working on your comments now, but since I really enjoyed
finding this bug in ./configure when I hit it I thought I'd answer this
right away.
On 20/11/2019 14:02, Martin Liška wrote:
> On 11/7/19 7:37 PM, Matthew Malcomson wrote:
>&
On 20/11/2019 14:46, Martin Liška wrote:
> On 11/20/19 3:37 PM, Matthew Malcomson wrote:
>> Hi Martin,
>>
>> Thanks for the review,
>
> You're welcome.
>
>> I'll get working on your comments now, but since I really enjoyed
>> finding this b
On 20/11/2019 14:33, Martin Liška wrote:
> On 11/13/19 4:24 PM, Matthew Malcomson wrote:
>> On 12/11/2019 12:08, Martin Liška wrote:
>>> On 11/11/19 5:03 PM, Matthew Malcomson wrote:
>>>> Ah!
>>>> My apologies -- I sent up a series with a few documentati
On 20/11/2019 14:29, Martin Liška wrote:
> On 11/7/19 7:37 PM, Matthew Malcomson wrote:
>> I have rebased this series onto Martin Liska's patches that take the most
>> recent libhwasan from upstream LLVM.
>> https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00340.html
>&
ple by implementing this
hook for the AArch64 backend.
regtested on x86_64 and aarch64.
gcc/ChangeLog:
2019-11-20 Matthew Malcomson
* config/aarch64/aarch64.c (aarch64_skip_pass): New.
(TARGET_BACKEND_SKIP_PASS): New.
* doc/tm.texi: Document BACKEND_SKIP_PASS hook.
On 21/11/2019 13:10, Martin Liška wrote:
> On 11/20/19 6:40 PM, Matthew Malcomson wrote:
>> On 20/11/2019 14:29, Martin Liška wrote:
>>> On 11/7/19 7:37 PM, Matthew Malcomson wrote:
>>>> I have rebased this series onto Martin Liska's patches that take the
&
Ping
On 12/11/2019 09:11, Matthew Malcomson wrote:
> In scheduling passes, notes are removed with `remove_notes` before the
> scheduling is done, and added back in with `reemit_notes` once the
> scheduling has been decided.
>
> This process leaves the notes in the RTL chain with
/gcc/testsuite/ChangeLog
@@ -18,7 +18,7 @@
2018-07-24 Matthew Malcomson
- * gcc.target/aarch64/vect-su-add-sub.c: New.
+ * gcc.target/aarch64/simd/vect_su_add_sub.c: New.
2018-07-24 Jakub Jelinek
clearly.
Ok for trunk?
gcc/testsuite/Changelog
2018-07-31 Matthew Malcomson
* gcc.target/aarch64/simd/vect_su_add_sub.c: Use stdint types
diff --git a/gcc/testsuite/gcc.target/aarch64/simd/vect_su_add_sub.c
b/gcc/testsuite/gcc.target/aarch64/simd/vect_su_add_sub.c
index
and regression test done on aarch64.
Ok for trunk?
gcc/
2018-07-26 Matthew Malcomson
* config/aarch64/aarch64-protos.h
(aarch64_offset_9bit_signed_unscaled_p): New declaration.
* config/aarch64/aarch64.c
(aarch64_offset_9bit_signed_unscaled_p): Rename from
On 02/08/18 20:18, James Greenhalgh wrote:
On Tue, Jul 31, 2018 at 04:53:19AM -0500, Matthew Malcomson wrote:
Fixing the ilp32 issue that Christophe found.
The existing testcase uses `long` to represent a 64 bit integer.
This breaks when compiled using the `-mabi=ilp32` flag.
We switch the use
sted.
New changelog:
gcc/
2018-08-06 Matthew Malcomson
* config/aarch64/aarch64-protos.h
(aarch64_offset_9bit_signed_unscaled_p): New declaration.
* config/aarch64/aarch64.c
(aarch64_offset_9bit_signed_unscaled_p): Rename from
offset_9bit_signed_unscaled_p.
* config/aarch64
Hello everyone,
This is an updated patch where I've made what was a predicate into a
pure C function based on some feedback outside the mailing list.
Ok for trunk?
Matthew
gcc/
2018-08-07 Matthew Malcomson
* config/aarch64/aarch64-pro
)
Ok for trunk?
2018-08-15 Matthew Malcomson
gcc/
* doc/rtl.texi: Replace old RTX class names with new names.
### Attachment also inlined for ease of reply###
diff --git a/gcc/doc/rtl.texi b/gcc/doc/rtl.texi
index
On 15/08/18 20:26, Sandra Loosemore wrote:
Use @item for the first item in a group, @itemx for all the others.
-Sandra
Thanks for the spot, updated patch attached.
diff --git a/gcc/doc/rtl.texi b/gcc/doc/rtl.texi
index a37d9ac538991c507985bda4f825023534321b76..f406a99ed78b6ce1fd24e768eefb0e
")` as the file is
reused by the arm.md machine description whose 'arch' attribute doesn't have an
'fp' value.
Full bootstrap and regression test done on aarch64.
Ok for trunk?
I don't have commit rights, so could someone commit it if accepted.
gcc/Cha
8_4" after this
feature flag.
Full bootstrap and regression test done on aarch64-none-linux-gnu.
Ok for trunk?
gcc/
2018-09-18 Matthew Malcomson
* config/aarch64/aarch64-protos.h
(aarch64_offset_9bit_signed_unscaled_p): New declaration.
* config/aarch64/aarch64.md (a
diff --git a/gcc/config/aarch64/atomics.md b/gcc/config/aarch64/atomics.md
index
36c06756a1f94cadae097b3aad654fbeba1cf2f3..73078e412d01a43c05195f01488b95a2bc7a20ec
100644
--- a/gcc/config/aarch64/atomics.md
+++ b/gcc/config/aarch64/atomics.md
@@ -481,9 +481,9 @@
)
(define_insn "atomic_
.
Full bootstrap and regression test plus cross-compilation regression tests done
on arm-none-linux-gnueabihf.
Ok for trunk?
gcc/ChangeLog:
2018-09-24 Matthew Malcomson
* config/arm/arm.c (arm_split_compare_and_swap, arm_split_atomic_op):
Use new helper functions
Hi Richard,
I don't have any comment on the overall aim of the patch series, but in
this particular
patch implementing casp it looks like you doesn't ensure the register
pairs for casp are
even-odd.
This is the restriction in the Arm Arm decode for casp variants as
if Rs<0> == '1' then Unall
n Armv8.4-a and use these to decide
which to use when -matomic-128bit-instructions is provided on the command line.
Tested with full bootstrap and make check on aarch64-none-linux-gnu.
Ok for trunk?
gcc/ChangeLog:
2018-09-27 Matthew Malcomson
* config/aarch64/a
Requiring a TImode register to be allocated from one of these classes ensures
the register will be allocated an even-odd pair.
Using constraint letters Uep and Uex (for U and U).
Full bootstrap and regtest done on aarch64-none-linux-gnu.
Ok for trunk?
gcc/ChangeLog:
2018-09-27 Matthew Malcomson
I had a superfluous #include in the testcase and some
spelling mistakes in documentation -- corrected patch attached.
On 27/09/18 15:02, Matthew Malcomson wrote:
Hello,
LSE instructions like casp require even-odd pairs of registers.
Other instructions that take a pair of registers don't
On 27/09/18 17:32, Richard Henderson wrote:
On 9/27/18 6:04 AM, Matthew Malcomson wrote:
Hi Richard,
On 26/09/18 06:03, rth7...@gmail.com wrote:
From: Richard Henderson
This pattern will only be used with the __sync functions, because
we do not yet have a bare TImode atomic load.
I
Hi Wilko,
On 28/09/18 13:33, Wilco Dijkstra wrote:
Matthew wrote:
The canonical way to require even-odd pairs of registers to implement a TImode
pseudo register as mentioned in the documentation is to limit *all* TImode
registers to being even-odd by using the TARGET_HARD_REGNO_MODE_OK hook.
Hi Richard,
On 26/09/18 06:03, rth7...@gmail.com wrote:
From: Richard Henderson
This pattern will only be used with the __sync functions, because
we do not yet have a bare TImode atomic load.
Does this mean that the libatomic `defined(atomic_compare_exchange_n)`
checks would return false fo
see that
-march=armv8-a+typo prints out the expected flags while using the new
feature flags does not complain about missing flags.
gcc/ChangeLog:
2019-05-24 Matthew Malcomson
PR target/90588
* common/config/aarch64/aarch64-common.c
(aarch64_rewrite_selected_cpu): Change
Ping
On 27/09/18 14:43, Matthew Malcomson wrote:
> [PATCH][GCC][AARCH64] Introduce aarch64 atomic_{load,store}ti patterns
>
> In Armv8.4-a these patterns use the LDP/STP instructions that are guaranteed
> to
> be single-copy atomic, ensure correct memory ordering semantics by
Hello,
This patch series is a WORK-IN-PROGRESS towards porting the LLVM hardware
address sanitizer (HWASAN) in GCC. The document describing HWASAN can be found
here http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html.
The current patch series is far from complete, but I'm post
sanitizer libraries are taken from (SVN revision 345033 as
mentioned in libsanitizer/MERGE).
libsanitizer/ChangeLog:
2019-09-06 Matthew Malcomson
* hwasan/hwasan.cc: New file.
* hwasan/hwasan.h: New file.
* hwasan/hwasan.syms.extra: New file.
* hwasan
This is a port of the LLVM-svn commit number 359914, it allows
compilation of the library without using interceptors.
This has been useful for testing.
libsanitizer/ChangeLog:
2019-09-06 Matthew Malcomson
* hwasan/hwasan_linux.cc: Allow compilation without
interceptors
This flag 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.
gcc/ChangeLog:
2019-09-06 Matthew Malcomson
* common.opt (static-libhwasan): New cli option.
* confi
commit
does not apply cleanly.
libsanitizer/ChangeLog:
2019-09-06 Matthew Malcomson
* hwasan/hwasan.cc (CheckAddressSized): Use new sized SigTrap.
(SigTrap): Record pointer in x0 for error report and add an
overloaded version that takes both pointer and size
ll be able to
handle sigsetjmp we manually define a __sigset_t structure and similarly
we define data structures to use for the intercepting setjmp/longjmp.
libsanitizer/ChangeLog:
2019-09-06 Matthew Malcomson
* hwasan/Makefile.am: Add hwasan_setjmp.S.
* hwasan/Makefile.in: Regen
This patch does tries to tie libhwasan into the GCC build system in the
same way that the other sanitizer runtime libraries are handled.
libsanitizer/ChangeLog:
2019-09-06 Matthew Malcomson
* Makefile.am: Build libhwasan.
* Makefile.in: Build libhwasan.
* asan
the current frame.
This patch also adds some macros defining how the HWASAN shadow memory
is stored and how a tag is stored in a pointer.
gcc/ChangeLog:
2019-09-06 Matthew Malcomson
* asan.h (HWASAN_TAG_SIZE): New macro.
(HWASAN_TAG_GRANULE_SIZE):New macro
a tag mismatch, and always
check tags via a library call to libhwasan. Allowing a program to
continue from tag mismatch, and implementing inline checks are intended
for a later revision.
gcc/ChangeLog:
2019-09-06 Matthew Malcomson
* asan.c (build_check_stmt): Generate HWASAN_CHECK
passed.
ChangeLog:
2019-08-29 Matthew Malcomson
* configure: Regenerate.
* configure.ac: Add --bootstrap-hwasan option.
config/ChangeLog:
2019-09-06 Matthew Malcomson
* bootstrap-hwasan.mk: New file.
gcc/ChangeLog:
2019-09-06 Matthew Malcomson
* asan.c
rchitecture specific handling of such stack modifications.
gcc/ChangeLog:
2019-09-06 Matthew Malcomson
* asan.c (handle_builtin_stack_restore): Handle HWASAN.
(handle_builtin_alloca): Handle HWASAN.
(get_mem_refs_of_builtin_call): Avoid strlen for HWASAN.
(m
ative that the naming may be a little confusing, but a
positive that handling of the internal function doesn't have to be
duplicated for a function that behaves exactly the same but has a
different name.
gcc/ChangeLog:
2019-09-06 Matthew Malcomson
* asan.c (asan_expand_mark
Matthew Malcomson
* hwasan/Makefile.am: Set HWASAN_WITH_INTERCEPTORS macro.
* hwasan/Makefile.in: Regenerate.
### Attachment also inlined for ease of reply###
diff --git a/libsanitizer/hwasan/Makefile.am b/libsanitizer/hwasan/Makefile.am
index
the tag addition -- by using a hook in force_operand and
hwasan_with_tag -- the method of adding a new RTL expression is under
flux).
gcc/ChangeLog:
2019-09-06 Matthew Malcomson
* asan.c (hwasan_record_base): New function.
(hwasan_increment_tag):New func
.
This is the first patch where we use the HWASAN shadow space, so we need
to add in the libhwasan initialisation code that creates this shadow
memory region into the binary we produce. This instrumentation is done
in `compile_file`.
gcc/ChangeLog:
2019-09-06 Matthew Malcomson
* asan.c
tagging since it provides no benefit without the HWASAN_CHECK
functions.
This patch also gives backends extra control over how a tag is stored in
a pointer and how many real-memory bytes is represented by each byte in
the shadow space.
gcc/ChangeLog:
2019-09-06 Matthew Malcomson
* asan.c
with left-over colour causing a false-positive.
Here we ensure that the entire stack frame is cleared on function exit.
gcc/ChangeLog:
2019-09-06 Matthew Malcomson
* asan.c (hwasan_emit_uncolour_frame): New.
* asan.h (hwasan_emit_uncolour_frame): New.
* cfgexpand.c
On 09/09/19 11:06, Martin Liška wrote:
> On 9/6/19 4:46 PM, Matthew Malcomson wrote:
>> This flag 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.
>
> He
On 09/09/19 11:01, Martin Liška wrote:
> Hi.
>
> On 9/6/19 4:46 PM, Matthew Malcomson wrote:
>> Ensuring that the shadow stack is cleared on normal function exit will
>> be done by adding instrumentation to the function epilogue through the
>> compiler.
>> lon
On 09/09/19 11:47, Martin Liška wrote:
> On 9/6/19 4:46 PM, Matthew Malcomson wrote:
>> Hello,
>>
>> This patch series is a WORK-IN-PROGRESS towards porting the LLVM hardware
>> address sanitizer (HWASAN) in GCC. The document describing HWASAN can be
>> found
&
Resending because I forgot to avoid the disclaimer and hence my email
didn't go to the gcc-patches list.
On 09/09/19 21:55, Prathamesh Kulkarni wrote:
> On Mon, 9 Sep 2019 at 22:06, Prathamesh Kulkarni
> wrote:
>>
>> On Mon, 9 Sep 2019 at 16:45, Richard Sandiford
>> wrote:
>>>
>>>
>>> Thanks
On 11/09/19 12:53, Martin Liška wrote:
> On 9/9/19 5:54 PM, Matthew Malcomson wrote:
>> On 09/09/19 11:47, Martin Liška wrote:
>>> On 9/6/19 4:46 PM, Matthew Malcomson wrote:
>>>> Hello,
>>>>
>> As I understand it, `hwasan-abi=interceptor` vs `pla
On 19/09/19 16:14, Kyrill Tkachov wrote:
>
> On 9/19/19 4:13 PM, Christophe Lyon wrote:
>> On Tue, 17 Sep 2019 at 14:08, Christophe Lyon
>> wrote:
>> >
>> > On 17/09/2019 13:38, Wilco Dijkstra wrote:
>> > > Hi Christophe,
>> > >
>> > > Can you explain this in more detail - it doesn't make sense
Hello,
I'm nearing the point where I think the hardware-asan patch series could
go in and would appreciate some feedback on what features need to be
implemented before it could be put into trunk.
(The RFC can be found at
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00387.html, the only
change to
ping
On 27/09/18 14:43, Matthew Malcomson wrote:
[PATCH][GCC][AARCH64] Introduce aarch64 atomic_{load,store}ti patterns
In Armv8.4-a these patterns use the LDP/STP instructions that are guaranteed to
be single-copy atomic, ensure correct memory ordering semantics by using
the DMB instruction
it rights.
gdb/ChangeLog:
2018-11-02 Matthew Malcomson
* symtab.c (info_functions_command): Initialise quiet flag.
### Attachment also inlined for ease of reply###
diff --git a/gdb/symtab.c b/gdb/symtab.c
index
cd27a75e8ca2370a9d11ae605
it rights.
gdb/ChangeLog:
2018-11-02 Matthew Malcomson
* symtab.c (info_functions_command): Initialise quiet flag.
### Attachment also inlined for ease of reply###
diff --git a/gdb/symtab.c b/gdb/symtab.c
index
cd27a75e8ca2370a9d11ae605
Oops -- wrong list -- please ignore.
On 02/11/18 11:27, Matthew Malcomson wrote:
> With this flag unset, using 'info functions' without a set quiet flag
> was not deterministic and was causing some flaky test failures.
>
> Failures seen in (at least).
> gdb.base/info_qt.
(Third attempt to put this on the mailing list now -- today is not a good day
for my email skills :-[)
Hi there,
This patch has caused a few g++ and libstdc++ regression test failures on arm,
I've included the g++ failures below.
Do you mind looking into this?
Cheers,
Matthew
dg-cmp-results
Hello Martin,
The new testcase Wattribute-alias.c fails on targets without ifunc
support (e.g. aarch64-none-elf cross-build).
It seems that just adding a directive `{ dg-require-ifunc "" }` to the
test file changes the test to unsupported instead of having a fail.
I don't know much about this
On 02/11/18 09:54, Christophe Lyon wrote:
> Hi,
>
> I've noticed failure on targets using newlib (aarch64-elf and arm-eabi):
> FAIL: gcc.c-torture/execute/printf-2.c
> FAIL: gcc.c-torture/execute/user-printf.c
>
> my gcc.log contains:
> gcc.c-torture/execute/user-printf.c -O0 execution test (rea
On 16/11/18 16:04, Jeff Law wrote:
> On 11/15/18 12:06 PM, Martin Sebor wrote:
>> On 11/15/2018 02:39 AM, Matthew Malcomson wrote:
>>> If not we could add an
>>> { dg-require-effective-target unwrapped }
>>> directive in the testcases to stop the failure
bunch of RTL testcases that I used in development, these
don't exercise much of the compiler and are pretty specific to the backend as it
currently is, so I'm not sure they give much value. I'd appreciate feedback on
whether this is in general considered useful.
gcc/ChangeLog:
20
Hi James,
On 22/02/19 00:09, James Greenhalgh wrote:
> On Mon, Feb 18, 2019 at 08:40:12AM -0600, Matthew Malcomson wrote:
>>
>> Additionally, this patch contains two tidy-ups (happy to remove them or put
>> in
>> a separate patch if people want):
>
> Gener
/neon.md (*neon_mov): Account for TImode and DImode
differences directly.
(*smax3_neon, vashl3, vashr3_imm): Use Dm constraint.
gcc/testsuite/ChangeLog:
2019-04-05 Matthew Malcomson
* gcc.dg/torture/neon-immediate-timode.c: New test.
### Attachment also in
On 08/04/19 14:00, Kyrill Tkachov wrote:
> Hi Matthew,
>
> On 4/5/19 12:06 PM, Matthew Malcomson wrote:
>>
>> Bootstrapped and regtested on arm-none-linux-gnueabihf
>> Regtested on cross-compiler arm-none-eabi
>>
>
> Does this fix a PR?
>
> If so
tions (e.g.
arm-eabi-aem/-marm/-march=armv7-a/-mfpu=vfpv3-d16/-mfloat-abi=softfp).
Regtested arm.exp with cross-compiler arm-none-eabi
gcc/testsuite/ChangeLog:
2019-04-11 Matthew Malcomson
* g++.target/arm/arm.exp: Change format of default prune regex.
* gcc.target/arm/ar
On 12/04/19 15:16, Christophe Lyon wrote:
> On Thu, 11 Apr 2019 at 11:26, Matthew Malcomson
> wrote:
>>
>> r269586 changed the format of some warning messages.
>>
>> Each switch in the warning message is now surrounded by single quotes.
>>
>> This com
se variables working with these feature flags to ensure they use
64 bit quantities.
Tested with bootstrap on aarch64-none-linux-gnu and manually seeing that
-march=armv8-a+typo prints out the expected flags while using the new
feature flags does not complain about a missing flag (until reaching th
> Matthew Malcomson writes:
>> @@ -326,16 +326,18 @@ int opt_ext_cmp (const void* a, const void* b)
>> turns on as a dependency. As an example +dotprod turns on FL_DOTPROD
>> and
>> FL_SIMD. As such the set of bits represented by this option is
&g
On 15/05/19 09:46, Matthew Malcomson wrote:
>> Matthew Malcomson writes:
Oops ... messed up my email there.
Patch is attached to this email.
diff --git a/gcc/common/config/aarch64/aarch64-common.c b/gcc/common/config/aarch64/aarch64-common.c
index bab3ab3fa36c66906d1b4367e2b7bfb1bf
> Matthew Malcomson writes:
>> @@ -326,16 +326,22 @@ int opt_ext_cmp (const void* a, const void* b)
Cheers Richard -- modified patch attached and inlined.
MM
### Attachment also inlined for ease of reply###
diff --git a/gcc/common/config/aarch6
Manual tests done on resulting debug information -- yet to be automated.
gcc/ChangeLog:
2019-01-10 Matthew Malcomson
PR debug/88432
* cfgexpand.c (pass_expand::execute): Insert
NOTE_INSN_DEBUG_FUNCTION_BEG.
* function.c (thread_prologue_and_epilogue_insns):
Ping.
(note -- when running the GDB testsuite ensuring that
-fstack-protector-all is used for compiling each testcase, this patch
fixes over 1500 FAIL's)
On 10/01/19 13:28, Matthew Malcomson wrote:
> At the moment NOTE_INSN_FUNCTION_BEG is used for three different purposes.
> The fi
otstrapped and regtested on arm-none-linux-gnu.
Demonstrated fix of bug 88714 by bootstrapping on armv7l.
gcc/ChangeLog:
2019-02-05 Matthew Malcomson
PR bootstrap/88714
* config/arm/arm-protos.h (valid_operands_ldrd_strd,
arm_count_ldrdstrd_insns): New de
s well.
>
> This looks ok to me.
> Thanks for fixing this and thanks Jakub for the analysis and fixes too!
>
> Kyrill
>
Thanks Kyrill,
I've committed with the changelog below.
gcc/ChangeLog:
2019-02-07 Matthew Malcomson
Jakub Jelinek
My previous patch failed to only run an arm test on arm architecture.
This adds that condition to the test.
Committed to trunk as obvious.
gcc/testsuite/ChangeLog:
2019-02-07 Matthew Malcomson
* gcc.dg/rtl/arm/ldrd-peepholes.c: Only run on arm
### Attachment also
On 08/02/19 10:23, Jakub Jelinek wrote:
> On Fri, Feb 08, 2019 at 11:06:02AM +0100, Christophe Lyon wrote:
>> On Fri, 8 Feb 2019 at 10:51, Jakub Jelinek wrote:
>>>
>>> On Fri, Feb 08, 2019 at 10:18:03AM +0100, Christophe Lyon wrote:
I'm afaid this patch causes several regressions. Maybe they
e-eabi and arm-none-linux-gnueabihf.
Also ran this testcase with `make check` natively.
Ok for trunk?
gcc/testsuite/ChangeLog:
2019-02-11 Matthew Malcomson
* gcc.dg/rtl/arm/ldrd-peepholes.c: Restrict testcase.
* lib/target-supports.exp: Add procedure to check for ldrd.
diff
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
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
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
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
: 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
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
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 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:
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
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
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.
lt): Likewise.
Signed-off-by: Matthew Malcomson
Co-authored-by: Jonathan Wakely
---
On 2/8/25 14:05, Jonathan Wakely wrote:
External email: Use caution opening links or attachments
On Sat, 8 Feb 2025 at 10:55, Matthew Malcomson wrote:
Hi Jonathan!
Many thanks! Will learn the libstdc++ sty
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
101 - 200 of 246 matches
Mail list logo
