> I see it now from Richard B.. Also I noticed you missed Richard S.'s
> suggestion of using a typedef which will definitely help in the future
> where we could even replace this with an enum class and overload the
> bitwise operators to do the right thing.
>
Indeed, I've missed that message. Do
Hi,
>
> Currently, the data type of sanitizer flags is unsigned int, with
> SANITIZE_SHADOW_CALL_STACK (1UL << 31) being highest individual
> enumerator for enum sanitize_code. Use 'uint64_t' data type to allow
> for more distinct instrumentation modes be added when needed.
>
>
From: Claudiu Zissulescu
Memory tagging is used for detecting memory safety bugs. On AArch64, the
memory tagging extension (MTE) helps in reducing the overheads of memory
tagging:
- CPU: MTE instructions for efficiently tagging and untagging memory.
- Memory: New memory type, Normal Tagged Mem
From: Claudiu Zissulescu
Add a new target hook TARGET_MEMTAG_COMPOSE_OFFSET_TAG to perform
addition between two tags.
The default of this hook is to byte add the inputs.
Hardware-assisted sanitizers on architectures providing instructions
to compose (add) two tags like in the case of AArch64.
From: Indu Bhagat
Define new constants to be used by the MTE pattern definitions.
gcc/
* config/aarch64/aarch64.md (MEMTAG_TAG_MASK): New define
constant.
(MEMTAG_ADDR_MASK): Likewise.
(irg, subp, ldg): Use new constants.
Signed-off-by: Claudiu Zissulescu
---
From: Indu Bhagat
Currently, the data type of sanitizer flags is unsigned int, with
SANITIZE_SHADOW_CALL_STACK (1UL << 31) being highest individual
enumerator for enum sanitize_code. Use 'uint64_t' data type to allow
for more distinct instrumentation modes be added when needed.
gcc/ChangeLog:
From: Indu Bhagat
Add basic tests for memtag-stack sanitizer. Memtag stack sanitizer
uses target hooks to emit AArch64 specific MTE instructions.
gcc/testsuite:
* lib/target-supports.exp:
* gcc.target/aarch64/memtag/alloca-1.c: New test.
* gcc.target/aarch64/memtag/allo
From: Claudiu Zissulescu
MEMTAG sanitizer, which is based on the HWASAN sanitizer, will invoke
the target-specific hooks to create a random tag, add tag to memory
address, and finally tag and untag memory.
Implement the target hooks to emit MTE instructions if MEMTAG sanitizer
is in effect. Con
From: Indu Bhagat
Add new command line option -fsanitize=memtag-stack with the following
new params:
--param memtag-instrument-alloca [0,1] (default 1) to use MTE insns
for enabling dynamic checking of stack allocas.
Along with the new SANITIZE_MEMTAG_STACK, define a SANITIZE_MEMTAG
which will b
From: Claudiu Zissulescu
Add a new target instruction. Hardware-assisted sanitizers on
architectures providing insstructions to tag/untag memory can then
make use of this new instruction pattern. For example, the
memtag-stack sanitizer uses these instructions to tag and untag a
memory granule.
g
From: Indu Bhagat
gcc/Changelog:
* asan.h (HWASAN_TAG_SIZE): Use targetm.memtag.tag_bitsize.
* config/i386/i386.cc (ix86_memtag_tag_size): Rename to
ix86_memtag_tag_bitsize.
(TARGET_MEMTAG_TAG_SIZE): Renamed to TARGET_MEMTAG_TAG_BITSIZE.
* doc/tm.texi (TAR
From: Claudiu Zissulescu
Hi,
Please find a new series of patches that implememnts stack sanitizer
using AArch64 MTE instructions. This new series is based on Indu
previous patch series.
What is new:
- Introduces a new target instruction tag_memory.
- Introduces a new target hook to deal with
Hi Jeff,
Indeed, Luis should have been using "umulti". The other attributes are
not required. I'll fix it before pushing to the mainline.
Thanks,
Claudiu
On Fri, Apr 18, 2025 at 8:41 PM Jeff Law wrote:
>
>
>
> On 3/18/25 10:22 AM, Luis Silva wrote:
> > This patch introduces two new instruction
Adding missing email addresses.
-- Forwarded message -
From: Claudiu Zissulescu Ianculescu
Date: Thu, Apr 24, 2025 at 8:48 PM
Subject: Re: [PATCH 2/2] arc: Use intrinsics for __builtin_mul_overflow ()
To: Jeff Law
Hi Jeff,
The other attributes are not required as the pattern
Hi Jeff,
There is one patch missing, I'll add it to mainline as soon as the
main is open for commits.
Best,
Claudiu
On Fri, Apr 18, 2025 at 12:10 AM Jeff Law wrote:
>
>
>
> On 3/18/25 10:23 AM, Luis Silva wrote:
> > Due to the patch by Roger Sayle,
> > 09881218137f4af9b7c894c2d350cf2ff8e0ee23,
LGTM,
Cheers,
Claudiu
On Tue, Mar 18, 2025 at 6:23 PM Luis Silva wrote:
>
> This patch handles both signed and unsigned
> builtin multiplication overflow.
>
> Uses the "mpy.f" instruction to set the condition
> codes based on the result. In the event of an
> overflow, the V flag is set, trigger
LGTM, I'll merge it once stage 1 is open.
Cheers,
Claudiu
On Tue, Mar 18, 2025 at 6:22 PM Luis Silva wrote:
>
> This patch introduces two new instruction patterns:
>
> `*mulsi3_cmp0`: This pattern performs a multiplication
> and sets the CC_Z register based on the result, while
> al
LGTM. I'll merge it once stage one is open.
Cheers,
Claudiu
On Tue, Mar 18, 2025 at 6:23 PM Luis Silva wrote:
>
> Due to the patch by Roger Sayle,
> 09881218137f4af9b7c894c2d350cf2ff8e0ee23, which
> introduces the use of the `rlc rX,0` instruction in place
> of the `mov.hs`, the add overflow tes
I'll include your comment in my second patch where I clean some
patterns used by reload.
Thank you,
claudiu
On Mon, Sep 23, 2024 at 5:05 PM Andreas Schwab wrote:
>
> On Sep 23 2024, Claudiu Zissulescu wrote:
>
> > diff --git a/gcc/config/arc/arc.cc b/gcc/config/arc/arc.cc
> > index c800226b179..
Missed this one.
Ok, please proceed with the commit.
Thank you for your contribution,
Claudiu
On Sat, Oct 28, 2023 at 4:05 PM Roger Sayle wrote:
>
>
> This patch improves the code generated for X << 1 (and for X + X) when
> X is 64-bit DImode, using the same two instruction code sequence used
>
Hi Roger,
Do you want to say bmsk_s instead of msk_s here:
+/* { dg-final { scan-assembler "msk_s\\s+r0,r0,0" } } */
Anyhow, the patch looks good. Proceed with your commit.
Thank you,
Claudiu
On Mon, Oct 30, 2023 at 5:05 AM Jeff Law wrote:
>
>
>
> On 10/28/23 10:47, Roger Sayle wrote:
> >
> >
Hi Roger,
You have a block of 8 spaces that needs to be replaced by tabs:
gcc/config/arc/arc.cc:5538:0: if (n < 4)
Please fix the above, and proceed with your commit.
Thank you,
Claudiu
On Sun, Oct 29, 2023 at 11:16 AM Roger Sayle wrote:
>
>
> This patch overhauls the ARC backend's insn_
Hi Roger,
+(define_insn "si2_cnt16"
+ [(set (match_operand:SI 0 "dest_reg_operand" "=w")
Please use "register_operand", and "r" constraint.
+(ANY_ROTATE:SI (match_operand:SI 1 "register_operand" "c")
Please use "r" constraint instead of "c".
+ (const_int 16)))]
+ "TARGET_SW
Hi Roger,
Your patch doesn't introduce new regressions. However, before pushing
to the mainline you need to fix some issues:
1. Please fix the trailing spaces and blocks of 8 spaces which should
be replaced with tabs. You can use check_GNU_style.py script to spot
them.
2. Please use capital letter
Hi Roger,
Indeed, I was missing the patch file.
Approved.
Thank you for your contribution,
Claudiu
On Sun, Oct 15, 2023 at 11:14 AM Roger Sayle wrote:
>
> I’ve done it again. ENOPATCH.
>
>
>
> From: Roger Sayle
> Sent: 15 October 2023 09:13
> To: 'gcc-patches@gcc.gnu.org'
> Cc: 'Claudiu Zis
Hi Roger,
The patch as it is passed the validation, and it is in general OK.
Although it doesn't address the elephant in the room, namely
output_shift function, it is a welcome cleanup.
I would like you to split the patch in two. One which deals with
improvements on shifts in absence of a barrel s
Hi Roger,
It is not necessary to do any mods on your patch. I've just answered
the questions which you asked me. The adds are faster for the ARC CPUs
which are still in production, and I suppose we can leverage the LP
instruction use with DBNZ instructions for implementing loops. I'll
come back to
OK,
Thank you for your contribution,
Claudiu
On Wed, Sep 6, 2023 at 3:50 PM Shahab Vahedi wrote:
>
> This patch covers signed and unsigned subtractions. The generated code
> would be something along these lines:
>
> signed:
> sub.f r0, r1, r2
> b.v @label
>
> unsigned:
> sub.f r0,
Ok.
Thank you for your contribution,
Claudiu
On Wed, Sep 6, 2023 at 3:50 PM Shahab Vahedi wrote:
>
> This patch covers signed and unsigned additions. The generated code
> would be something along these lines:
>
> signed:
> add.f r0, r1, r2
> b.v @label
>
> unsigned:
> add.f r0, r1
Thanks, I haven't observed it.
Waiting for it,
Claudiu
On Mon, Sep 26, 2022 at 2:49 PM Thomas Neumann wrote:
>
> Hi Claudiu,
>
> > This change prohibits compiling of ARC backend:
> >
> >> + gcc_assert (in_shutdown || ob);
> >
> > in_shutdown is only defined when ATOMIC_FDE_FAST_PATH is defined,
Hi Thomas,
This change prohibits compiling of ARC backend:
> + gcc_assert (in_shutdown || ob);
in_shutdown is only defined when ATOMIC_FDE_FAST_PATH is defined,
while gcc_assert is outside of any ifdef. Please can you revisit this
line and change it accordingly.
Thanks,
Claudiu
Hi Robin,
The patch looks good. Please go ahead and merge it, please let me know if
you cannot.
Thank you,
Claudiu
On Mon, Feb 21, 2022 at 9:57 AM Robin Dapp via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> Hi,
>
> I figured I'd just go ahead and post this patch as well since it seems
> to h
Hi Robin,
I don't know how I missed your arc related patch, I'll bootstrap and test
your patch asap.
Thanks,
Claudiu
On Fri, Feb 25, 2022 at 3:29 PM Robin Dapp wrote:
> > If the movcc comparison is not valid it triggers an assert in the
> > current implementation. This behavior is not needed
Thanks a lot guys. Patch is pushed.
//Claudiu
On Mon, Jun 14, 2021 at 12:34 AM Jeff Law wrote:
>
>
>
> On 6/13/2021 4:06 AM, Bernhard Reutner-Fischer wrote:
> > On Fri, 11 Jun 2021 14:25:24 +0300
> > Claudiu Zissulescu wrote:
> >
> >> Hi Bernhard,
> >>
> >> Please find attached my latest patch,
Gentle PING.
On Wed, Oct 7, 2020 at 12:39 PM Claudiu Zissulescu wrote:
>
> From: Claudiu Zissulescu
>
> The compiler can match mpyd.eq r0,r1,r0 as a predicated instruction,
> which is incorrect. The mpyd(u) instruction takes as input two 32-bit
> registers, returning into a double 64-bit even-od
Gentle PING.
On Fri, Oct 9, 2020 at 5:24 PM Claudiu Zissulescu wrote:
>
> From: Claudiu Zissulescu
>
> ARC MYP7+ instructions add MAC instructions for vector and scalar data
> types. This patch adds a madd pattern for 16it datum that is using the
> 32bit MAC instruction, and dot_prod patterns fo
Done.
Thank you for your support,
Claudiu
On Thu, Apr 9, 2020 at 2:38 AM Vineet Gupta wrote:
>
> Hi Claudiu,
>
> For glibc needs can this be backported to gcc-9 please !
>
> Thx,
> -Vineet
>
> On 3/31/20 3:06 AM, Claudiu Zissulescu Ianculescu wrote:
> > Pushe
Pushed.
Thank you,
Claudiu
On Sun, Mar 29, 2020 at 2:05 AM Vineet Gupta via Gcc-patches
wrote:
>
> Enable big-endian suffixed dynamic linker per glibc multi-abi support.
>
> And to avoid a future churn and version pairingi hassles, also allow
> arc700 although glibc for ARC currently doesn't sup
> My only worry would be asking for the length early in the RTL pipeline
> may not be as accurate, but it's supposed to work, so if you're
> comfortable with the end results, then OK.
>
Indeed, the length is not accurate, but the results seem slightly
better than using COST_RTX. Using INSN_COSTS se
Yes, I know :(
Thank you for your help. All four patches pushed.
Claudiu
On Wed, Jan 22, 2020 at 10:31 PM Jeff Law wrote:
>
> On Wed, 2020-01-22 at 10:14 +0200, Claudiu Zissulescu wrote:
> > ARC600 when configured with mul64 instructions uses mlo and mhi
> > registers to store the 64 result of t
It is already ported :)
https://github.com/gcc-mirror/gcc/commit/555e4a053951a0ae24835a266e71819336d7f637#diff-5b8bd26eec6c2b9f560870c205416edc
Cheers,
Claudiu
On Wed, Jan 15, 2020 at 1:49 AM Vineet Gupta wrote:
>
> On 12/9/19 1:52 AM, Claudiu Zissulescu wrote:
> > Although the FDCMP (the double
Pushed. Thank you for your contribution,
Claudiu
On Wed, Dec 11, 2019 at 12:47 AM Vineet Gupta
wrote:
>
> On 12/10/19 1:12 AM, Claudiu Zissulescu wrote:
> > Hi,
> >
> > Thank you for your contribution, I'll push it asap. As far as I understand,
> > you need this patch both in gcc9 branch and mai
Thank you for your review. Patch pushed to mainline and gcc9 branch.
//Claudiu
On Wed, Dec 11, 2019 at 8:59 PM Jeff Law wrote:
>
> On Mon, 2019-12-09 at 11:52 +0200, Claudiu Zissulescu wrote:
> > Although the FDCMP (the double precision floating point compare
> > instruction) is added to the com
43 matches
Mail list logo
