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 generates some
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 ope
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 getting it fixe
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
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.
I'm currently working on getting it fixed here
https://reviews.llvm.org/D91344#2393371 .
If this hwasan patch series gets approved and if that patch goes in w
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
Hi Richard,
I've done most of the updates you suggested, but have a few questions to
ensure I have the right end of the stick before making the remaining changes.
There are also a few clarifications I'd like to make where I hadn't explained
the rationale for certain bits of the original code, and
36 matches
Mail list logo
