Assignee: sripar01 at gcc dot gnu.org
Reporter: matmal01 at gcc dot gnu.org
Target Milestone: ---
The following code ICE's on fsf-trunk.
#include "arm_mve.h"
uint8x16_t test()
{
uint8x16_t accum = (uint8x16_t)(uint32x4_t){0, 0, 0, 2};
uint8x16_t accum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94341
Matthew Malcomson changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383
--- Comment #9 from Matthew Malcomson ---
(In reply to Jakub Jelinek from comment #8)
> I'd like to ping this, it would be nice to at least decide if this should be
> handled for GCC10 or postponed to GCC11 only.
Hi Jakub -- I'm taking a look at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94711
--- Comment #3 from Matthew Malcomson ---
This has been fixed by.
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544625.html
In the email linked above I mentioned another problem using `-mabi=apcs-gnu`.
Since that ABI is obsolete (Kyrylo p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94711
Matthew Malcomson changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: matmal01 at gcc dot gnu.org
Target Milestone: ---
Target: AArch64
When splitting a function into two different sections (hot/cold).
The assembler produces
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: matmal01 at gcc dot gnu.org
Target Milestone: ---
When running the testsuite with a compiler sanitized with -fsanitize=hwaddress
(HWASAN sanitizer which is
MED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: matmal01 at gcc dot gnu.org
Target Milestone: ---
Host: aarch64-none-linux-gnu
Target: aarch64-none-linux-gnu
Bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92410
--- Comment #5 from Matthew Malcomson ---
I've had a little look into it, and the below seems promising:
Based on a comment in haifa-sched.c, notes are removed before scheduling and
added back in.
Since the insn that is larger than the df buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92410
--- Comment #6 from Matthew Malcomson ---
I believe the problem is that `remove_notes` followed by `reemit_notes` can
generate these notes with a different UID.
When `reemit_notes` adds the new note, the dataflow information is not updated
autom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92410
--- Comment #7 from Matthew Malcomson ---
(In reply to Matthew Malcomson from comment #6)
> I'm not sure whether there's any pre-existing "should not use dataflow
> queries on notes" rule. If there is, then the
> regstat_bb_compute_calls_crossed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92410
--- Comment #8 from Matthew Malcomson ---
Author: matmal01
Date: Mon Dec 9 12:03:53 2019
New Revision: 279124
URL: https://gcc.gnu.org/viewcvs?rev=279124&root=gcc&view=rev
Log:
[mid-end] Add notes to dataflow insn info when re-emitting (PR92410
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92882
--- Comment #3 from Matthew Malcomson ---
(In reply to Jakub Jelinek from comment #2)
> The question is if we just have some exception that for new labels etc. we
> don't grow the tables, while for insns we always do. If yes, the patch is a
> re
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matmal01 at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Target: aarch64-none-linux-gnu
When running the
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: matmal01 at gcc dot gnu.org
Target Milestone: ---
When compiling the attached code, with an arm-none-eabi cross compiler from
trunk,
arm-none-eabi-gcc -march=armv6-m -S test.c -o test.s -Os
incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88904
--- Comment #1 from Matthew Malcomson ---
Created attachment 45458
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45458&action=edit
Problematic testcase
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: matmal01 at gcc dot gnu.org
Target Milestone: ---
I've found a testcase where the stack protector code generated through
`-fstack-protector-all` doesn't actual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88950
--- Comment #1 from Matthew Malcomson ---
Created attachment 45480
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45480&action=edit
Testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88950
--- Comment #3 from Matthew Malcomson ---
aarch64 (both aarch64-none-linux-gnu and aarch64-none-elf)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88904
--- Comment #3 from Matthew Malcomson ---
I agree Jakub -- I've been testing a patch that does the same thing and
everything seems to be working (though my patch was not as neat).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88950
Matthew Malcomson changed:
What|Removed |Added
Known to fail||5.4.0
--- Comment #5 from Matthew Ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
Matthew Malcomson changed:
What|Removed |Added
CC||matmal01 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #31 from Matthew Malcomson ---
(In reply to Jakub Jelinek from comment #30)
> (In reply to Matthew Malcomson from comment #29)
> > I've been working on a patch that does very similar to the draft patch
> > posted
> > above, and I not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #32 from Matthew Malcomson ---
Created attachment 45584
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45584&action=edit
Single define_insn version of above patch
FWIW I've attached the patch I'd made.
The only interesting dif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #34 from Matthew Malcomson ---
Yes, I needed to redo that check for an offset of 4 -- I compared the
expression of the first MEM with the result of `plus_constant` with 4 on the
expression of the second MEM in the condition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #37 from Matthew Malcomson ---
Good point (and interesting about the HOST_WIDE_INT_MIN exception -- I didn't
know that).
To avoid duplication of effort would you prefer I make the change or do you
want to handle it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #39 from Matthew Malcomson ---
(In reply to Jakub Jelinek from comment #38)
> I don't mind if you take over, I don't really have good opportunities to
> test on arm anyway. Though, do you have copyright assignment on file (or
> cover
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #42 from Matthew Malcomson ---
Author: matmal01
Date: Thu Feb 7 14:54:15 2019
New Revision: 268644
URL: https://gcc.gnu.org/viewcvs?rev=268644&root=gcc&view=rev
Log:
[Patch] [arm] Fix 88714, Arm LDRD/STRD peepholes.
These peepholes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89324
--- Comment #3 from Matthew Malcomson ---
(In reply to ktkachov from comment #2)
> The sub3_compare1_imm pattern was introduced for GCC 9. It's probably
> something going wrong with the constraints. Matthew, could you take a look
> please?
On fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89324
--- Comment #4 from Matthew Malcomson ---
There were similar problems in handling the stack pointer with subs/adds
instructions elsewhere in the aarch64 backend.
Patch proposed & being worked on here:
https://gcc.gnu.org/ml/gcc-patches/2019-02/m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89324
--- Comment #5 from Matthew Malcomson ---
Author: matmal01
Date: Fri Feb 22 16:35:22 2019
New Revision: 269122
URL: https://gcc.gnu.org/viewcvs?rev=269122&root=gcc&view=rev
Log:
Handle stack pointer with SUBS/ADDS instructions.
In general the s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89324
Matthew Malcomson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
||2019-03-08
CC||matmal01 at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Matthew Malcomson ---
I've reproduced manually using the reproducer and a bootstrapped gcc at r268766
gcc r265397
-code, patch
Severity: normal
Priority: P3
Component: target
Assignee: matmal01 at gcc dot gnu.org
Reporter: matmal01 at gcc dot gnu.org
Target Milestone: ---
Created attachment 46111
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46111&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90024
Matthew Malcomson changed:
What|Removed |Added
Target||arm
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90024
--- Comment #2 from Matthew Malcomson ---
Author: matmal01
Date: Tue Apr 9 11:39:59 2019
New Revision: 270226
URL: https://gcc.gnu.org/viewcvs?rev=270226&root=gcc&view=rev
Log:
Hi there,
The "*neon_mov" patterns for 128 bit sized quantities us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90024
--- Comment #3 from Matthew Malcomson ---
Author: matmal01
Date: Wed Apr 10 13:34:54 2019
New Revision: 270253
URL: https://gcc.gnu.org/viewcvs?rev=270253&root=gcc&view=rev
Log:
Backport of r270226 from mainline to gcc-7-branch
The "*neon_mov"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90024
--- Comment #4 from Matthew Malcomson ---
Author: matmal01
Date: Wed Apr 10 13:41:21 2019
New Revision: 270254
URL: https://gcc.gnu.org/viewcvs?rev=270254&root=gcc&view=rev
Log:
Backport of r270226 from mainline to gcc-8-branch
The "*neon_mov"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90024
Matthew Malcomson changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90024
Matthew Malcomson changed:
What|Removed |Added
Target Milestone|7.5 |7.6
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: matmal01 at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org,
marxin at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90414
--- Comment #2 from Matthew Malcomson ---
(In reply to Richard Biener from comment #1)
> (In reply to Matthew Malcomson from comment #0)
> > Hello,
> >
> > I'm looking into how we can implement MTE in the compiler.
>
> What is MTE?
It's an arc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90414
--- Comment #4 from Matthew Malcomson ---
(In reply to Martin Liška from comment #3)
> (In reply to Matthew Malcomson from comment #0)
> > 2) Can we always find the base object that's being referenced from the
> > gimple
> >statement where m
||2019-05-23
CC||matmal01 at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |matmal01 at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Matthew Malcomson ---
Thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90588
--- Comment #2 from Matthew Malcomson ---
Author: matmal01
Date: Fri May 24 10:39:38 2019
New Revision: 271599
URL: https://gcc.gnu.org/viewcvs?rev=271599&root=gcc&view=rev
Log:
[aarch64] Change two function declaration types
Commit r271514 mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90588
Matthew Malcomson changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: matmal01 at gcc dot gnu.org
Target Milestone: ---
Since revision 265914, the testcase pr60183.c has been FAILing on
aarch64-none-linux-gnu regression tests with a timeout.
Some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88021
--- Comment #2 from Matthew Malcomson ---
Hi Richard,
Applying that on top of r265914 does fix the problem.
Thanks for the quick reply!
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: matmal01 at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97696
--- Comment #1 from Matthew Malcomson ---
I guess this may also happen for the emission of ASAN_MARK in
`gimple_target_expr`, but haven't yet been able to trigger that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97941
--- Comment #1 from Matthew Malcomson ---
Hi Akhilesh,
No that's certainly not a known issue -- thanks for reporting it!
I'm having trouble reproducing your issue, do you mind giving a little more
information on your command line and the machin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97941
Matthew Malcomson changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100665
--- Comment #1 from Matthew Malcomson ---
Hi there.
I believe this is how it should work (if I'm understanding & remembering
correctly).
When creating a nested function, we make a single object on the stack that
includes all variables used in t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100665
Matthew Malcomson changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101744
--- Comment #7 from Matthew Malcomson ---
Hi there,
I didn't check all the new tests that Christophe mentioned, but all those I
checked had `dg-require-effective-target hwaddress_exec` in them.
The test that determines that effective target sh
: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: matmal01 at gcc dot gnu.org
Target Milestone: ---
Bug observed (testcase + ICE) is below. I believe this happens
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: matmal01 at gcc dot gnu.org
Target Milestone: ---
Bug (testcase + ICE) below.
I believe this is because:
1) We save `r20` below `VG_REGNUM` in `aarch64_layout_frame` (and above the
point
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: matmal01 at gcc dot gnu.org
Target Milestone: ---
Apologies if I'm misunderstanding something here -- but I noticed this RTL
sequence and I believ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116776
--- Comment #1 from Matthew Malcomson ---
N.b. from experimentation it seems that gcc 11 didn't move any part of the
condition outside of the loop, and since gcc 12 part of the condition has been
moved outside the loop.
I don't think this hoist
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: matmal01 at gcc dot gnu.org
Target Milestone: ---
The condition in the following loop does not get hoisted at `-O3` on GCC trunk.
Simplifying the condition (by either removing some of the `shouldthischange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117991
Matthew Malcomson changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |matmal01 at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117991
--- Comment #2 from Matthew Malcomson ---
(In reply to Jeffrey A. Law from comment #1)
> Still occurring on the trunk. In my case I saw them in a native build &
> test scenario.
Ah -- apologies I missed when this was raised -- will look into t
ot gnu.org
Reporter: matmal01 at gcc dot gnu.org
Target Milestone: ---
Created attachment 60650
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60650&action=edit
Script to reproduce the observed slowdown.
Have observed a slowdown after the referenced commit.
Attaching script for repro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119108
--- Comment #9 from Matthew Malcomson ---
(In reply to Tamar Christina from comment #8)
> Ok, so having looked at this I'm not sure the compiler is at fault here.
>
> Similar to the SVN case the snappy code is misaligning the loads
> intentiona
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119108
--- Comment #3 from Matthew Malcomson ---
I only looked into VecSource/5/2, and unfortunately I looked into it on an
internal setup that compiles slightly differently.
In that slightly different compilation I noticed that `FindMatchLengthPlain`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119108
--- Comment #7 from Matthew Malcomson ---
FWIW I have managed to figure out what the difference between my internal build
and the upstream one was -- my reproduction script has the line
`-DCMAKE_BUILD_TYPE=Release` in it and the local build that
66 matches
Mail list logo
