xample 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 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
>>
&
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 docume
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 bug in ./co
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:
>>
>
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
on 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
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
OK f
}
```
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
"initial_pass_name&qu
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 documentation mistakes.
>> (the others were wording problems so less noticeable)
>
> That's fine, I fixed that very ea
and regression test on aarch64-none-linux-gnu native.
gcc/ChangeLog:
2019-11-12 Matthew Malcomson
PR middle-end/92410
* bb-reorder.c (pass_reorder_blocks::execute): Recompute
dataflow luids once basic blocks have been reordered.
* haifa-sched.c (reemit_no
On 11/11/2019 16:13, Matthew Malcomson wrote:
> On 07/11/2019 18:37, 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
>&
On 07/11/2019 18:37, 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
>
> I've also cleared up some nomenclature (I had previousl
On 11/11/2019 14:30, Martin Liška wrote:
> On 11/7/19 7:37 PM, Matthew Malcomson wrote:
>> +@item @samp{bootstrap-hwasan}
>> +Compiles GCC itself using HWAddress Sanitization in order to catch
>> invalid
>> +memory accesses within the GCC code. This option is on
Adding hwasan tests.
Frankly, these could be tidied up a little.
I will be tidying them up while getting feedback on the hwasan introduction.
gcc/testsuite/ChangeLog:
2019-11-07 Matthew Malcomson
* c-c++-common/hwasan/arguments.c: New test.
* c-c++-common/hwasan
-over tag.
Hence we ensure that the entire stack frame is cleared on function exit.
gcc/ChangeLog:
2019-11-07 Matthew Malcomson
* asan.c (hwasan_record_base): New function.
(hwasan_emit_untag_frame): New.
(hwasan_increment_tag): New function.
(hwasan_with_tag): New
at behaves exactly the same but has a
different name.
gcc/ChangeLog:
2019-11-07 Matthew Malcomson
* asan.c (handle_builtin_stack_restore): Account for HWASAN.
(handle_builtin_alloca): Account for HWASAN.
(get_mem_refs_of_builtin_call): Special case strlen
/ChangeLog:
2019-11-07 Matthew Malcomson
* asan.c (memory_tagging_p): New.
* asan.h (memory_tagging_p): New.
* common.opt (flag_sanitize_recover): Default for kernel
hwaddress.
(static-libhwasan): New cli option.
* config/aarch64/aarch64.c
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-11-07 Matthew Malcomson
* Makefile.am: Build libhwasan.
* Makefile.in: Build libhwasan.
* asan
passed.
ChangeLog:
2019-08-29 Matthew Malcomson
* configure: Regenerate.
* configure.ac: Add --bootstrap-hwasan option.
config/ChangeLog:
2019-11-07 Matthew Malcomson
* bootstrap-hwasan.mk: New file.
libiberty/ChangeLog:
2019-11-07 Matthew Malcomson
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:
2019-11-07 Matthew Malcomson
* Makefile.am: Condition building hwasan directory.
* Makefile.in
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
I've also cleared up some nomenclature (I had previously used the word 'colour'
a few times instead of the word 'tag' and that
On 05/11/2019 13:11, Andrey Konovalov wrote:
> On Tue, Nov 5, 2019 at 12:34 PM Matthew Malcomson
> wrote:
>>
>> NOTE:
>> --
>> I have defined a new macro of __SANITIZE_HWADDRESS__ that gets
>> automatically defined when compiling with hwasan. This is
On 05/11/2019 17:22, Martin Liška wrote:
> On 11/5/19 5:11 PM, Matthew Malcomson wrote:
>> On 05/11/2019 15:10, Martin Liška wrote:
>>> On 11/5/19 12:32 PM, Matthew Malcomson wrote:
>>>> Hello,
>>>>
>>>> This patch series adds the LLVM hardware
On 05/11/2019 15:10, Martin Liška wrote:
> On 11/5/19 12:32 PM, Matthew Malcomson wrote:
>> Hello,
>>
>> This patch series adds the LLVM hardware address sanitizer (HWASAN) to
>> GCC. The document describing HWASAN can be found here
&g
On 05/11/2019 11:32, Matthew Malcomson wrote:
>
> Testing done:
> Full bootstrap and regtest on x86_64 (no difference -- hwasan not used).
>
> Full bootstrap and regtest on AArch64 sanitizing with hwasan and running
> on recent kernel.
> Regressions all accounted for:
>
Adding hwasan tests.
Frankly, these could be tidied up a little.
I will be tidying them up while getting feedback on the hwasan introduction.
gcc/testsuite/ChangeLog:
2019-11-05 Matthew Malcomson
* c-c++-common/hwasan/arguments.c: New test.
* c-c++-common/hwasan
29); // x29
+uptr fp = *(uptr *)sp;
+if (fp == 0)
+ return rc;
#else
#error Unsupported architecture
#endif
-uptr sp = get_cfa(context);
TagMemory(sp, fp - sp, 0);
}
##
gcc/ChangeLog:
2019-11-05 Matthew Malcomson
* asan.c (hwasan_create_personality
it.
The optimisation is hence disabled for memory tagging since it provides
no benefit and would require all backends that wanted this feature to
implement a similar dummy hook.
gcc/ChangeLog:
2019-11-05 Matthew Malcomson
* asan.c (hwasan_tag_init): Choose initialisation value based
stack area with
left-over colour.
Hence we ensure that the entire stack frame is cleared on function exit.
gcc/ChangeLog:
2019-11-05 Matthew Malcomson
* asan.c (hwasan_record_base): New function.
(hwasan_emit_uncolour_frame): New.
(hwasan_increment_tag): New function
the point above.
--
gcc/ChangeLog:
2019-11-05 Matthew Malcomson
* asan.c (memory_tagging_p): New.
* asan.h (memory_tagging_p): New.
* common.opt (flag_sanitize_recover): Default for kernel
hwaddress.
(static-libhwasan): New cli option
a function that behaves exactly the same but has a
different name.
gcc/ChangeLog:
2019-11-05 Matthew Malcomson
* asan.c (handle_builtin_stack_restore): Account for HWASAN.
(handle_builtin_alloca): Account for HWASAN.
(get_mem_refs_of_builtin_call): Special case strlen
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:
2019-11-05 Matthew Malcomson
* Makefile.am: Condition building hwasan directory.
* Makefile.in
passed.
ChangeLog:
2019-08-29 Matthew Malcomson
* configure: Regenerate.
* configure.ac: Add --bootstrap-hwasan option.
config/ChangeLog:
2019-11-05 Matthew Malcomson
* bootstrap-hwasan.mk: New file.
libiberty/ChangeLog:
2019-11-05 Matthew Malcomson
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-11-05 Matthew Malcomson
* Makefile.am: Build libhwasan.
* Makefile.in: Build libhwasan.
* asan
Backport from llvm upstream (monorepo revision 612eadb).
This allows us to report tag mismatches without threading it through the
backend to generate assembly.
libsanitizer/ChangeLog:
2019-11-05 Matthew Malcomson
* hwasan/hwasan_interface_internal.h (__hwasan_tag_mismatch4
This is needed for the hwasan_personality instrumentation I've added.
Backported from llvm-svn: 369721
libsanitizer/ChangeLog:
2019-11-05 Matthew Malcomson
* hwasan/hwasan_exceptions.cpp: New file.
### Attachment also inlined for ease of reply
Backport from llvm upstream llvm-svn: 375298.
libsanitizer/ChangeLog:
2019-11-05 Matthew Malcomson
* hwasan/hwasan_exceptions.cpp (__hwasan_personality_wrapper):
Add missing interface attribute.
### Attachment also inlined for ease of reply
Backport from llvm upstream (monorepo revision 91167e2).
This was an experiment made possible by a non-standard feature of the
Android dynamic loader.
libsanitizer/ChangeLog:
2019-11-05 Matthew Malcomson
* hwasan/hwasan_interceptors.cpp (HwasanThreadStartFunc):
Re-introduce
Backported from LLVM git id 67474c60d
libsanitizer/ChangeLog:
2019-11-05 Matthew Malcomson
* hwasan/hwasan.h (__hw_jmp_buf_struct, __hw_jmp_buf,
__hw_sigjmp_buf): Define new types for internal longjmp
implementation.
* hwasan/hwasan_interceptors.cpp
Backport from llvm-svn: 375296.
This was an experiment made possible by a non-standard feature of the
Android dynamic loader.
Going without that experiment makes implementation for glibc easier.
libsanitizer/ChangeLog:
2019-11-05 Matthew Malcomson
* hwasan/hwasan_allocator.cpp
Backported from LLVM-svn 375166.
libsanitizer/ChangeLog:
2019-11-05 Matthew Malcomson
* hwasan/hwasan.cc (InitInstrumentation): Call InitPrctl.
* hwasan/hwasan.h (InitPrctl): New decl.
* hwasan/hwasan_linux.cc (InitPrctl): New function
on aarch64 with hwasan (though not a full bootstrap since it's
obvious).
gcc/ChangeLog:
2019-11-05 Matthew Malcomson
* config/aarch64/aarch64.c (aarch64_handle_attr_cpu): Allocate
enough bytes for the NULL character.
### Attachment also inlined for ease of reply
revision 368656 as
mentioned in libsanitizer/MERGE).
libsanitizer/ChangeLog:
2019-11-05 Matthew Malcomson
* README.gcc: Mention now including lib/hwasan.
* hwasan/hwasan.cpp: New file.
* hwasan/hwasan.h: New file.
* hwasan/hwasan.syms.extra: New file
Matthew Malcomson
* expr.c (build_personality_function): Fix generated type to
match actual personality functions.
### Attachment also inlined for ease of reply###
diff --git a/gcc/expr.c b/gcc/expr.c
index
2f2b53f8b6905013b4214eea137d67c666b0c795
Hi Martin,
I'm getting close to putting up a patch series that I believe could go
in before stage1 close.
I currently have to do testing on sanitizing the kernel, and track down
a bootstrap comparison diff in the code handling shadow-stack cleanup
during exception unwinding.
I just thought
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
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
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
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 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
&
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: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.
>
> Hello.
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
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
.
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
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 function.
(hwasan_with_tag
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
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_ifn): New
e 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.
(maybe_instr
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
on 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
for 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
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
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: Regenerate
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.
* config/gnu
the 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
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
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
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
to 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
> 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
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,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
f those 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
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
(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/arm.exp
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?
&g
/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
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
nch 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:
2019-02-18 Matthew Malcoms
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 --git a/gcc/tes
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
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
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
PR bootstr
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 declarations
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
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
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
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 fai
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
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
(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
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.exp
> g
/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
cd27a75e8ca2370a9d11ae6057d051ca6ce13f90
/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
cd27a75e8ca2370a9d11ae6057d051ca6ce13f90
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
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
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.
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
101 - 200 of 218 matches
Mail list logo
