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!
: 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=edit
Problematic 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=88950
--- Comment #1 from Matthew Malcomson ---
Created attachment 45480
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45480=edit
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 actually protect
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89324
Matthew Malcomson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=gcc=rev
Log:
Handle stack pointer with SUBS/ADDS instructions.
In general the stack
||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 does
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/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
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=gcc=rev
Log:
[Patch] [arm] Fix 88714, Arm LDRD/STRD peepholes.
These peepholes match a
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=edit
Single define_insn version of above patch
FWIW I've attached the patch I'd made.
The only interesting
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
>
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
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 #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
||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=gcc=rev
Log:
[aarch64] Change two function declaration types
Commit r271514 missed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90588
Matthew Malcomson changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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
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=gcc=rev
Log:
Backport of r270226 from mainline to gcc-7-branch
The "*neon_mov" patterns
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
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=gcc=rev
Log:
Backport of r270226 from mainline to gcc-8-branch
The "*neon_mov" patterns
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=gcc=rev
Log:
Hi there,
The "*neon_mov" patterns for 128 bit sized quantities uses the
-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=e
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=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
>
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
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
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=gcc=rev
Log:
[mid-end] Add notes to dataflow insn info when re-emitting (PR92410)
In
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
>
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
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
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 accum2 = (
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=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
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
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
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=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.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100665
Matthew Malcomson changed:
What|Removed |Added
Resolution|--- |INVALID
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
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
55 matches
Mail list logo
