[Bug sanitizer/97696] New: ICE since ASAN_MARK does not handle poly_int sized varibales

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97696 Bug ID: 97696 Summary: ICE since ASAN_MARK does not handle poly_int sized varibales Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: ice-checking

[Bug sanitizer/97696] ICE since ASAN_MARK does not handle poly_int sized varibales

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.

[Bug sanitizer/97941] [HWASAN] use After free not working as per expectation

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

[Bug sanitizer/97941] [HWASAN] use After free not working as per expectation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97941 Matthew Malcomson changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW

[Bug sanitizer/100665] [hwsanitizer] nested funtion pointer is tagged but never checked.

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

[Bug sanitizer/100665] [hwsanitizer] nested funtion pointer is tagged but never checked.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100665 Matthew Malcomson changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIR

[Bug sanitizer/101744] [12 regression] hwasan new failures since r12-2424

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

[Bug target/114905] New: aarch64 locally_streaming function ICE in dwarf2cfi due to mismatched CFA instructions in prologue/epilogue

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114905 Bug ID: 114905 Summary: aarch64 locally_streaming function ICE in dwarf2cfi due to mismatched CFA instructions in prologue/epilogue Product: gcc Version: unknown

[Bug target/114906] New: aarch64 locally_streaming ICE in aarch64_expand_prologue

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114906 Bug ID: 114906 Summary: aarch64 locally_streaming ICE in aarch64_expand_prologue Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal P

[Bug target/115043] New: aarch64 locally_streaming function appears to have CFA note on wrong instruction in prologue

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115043 Bug ID: 115043 Summary: aarch64 locally_streaming function appears to have CFA note on wrong instruction in prologue Product: gcc Version: unknown Status: UNCONFIRMED

[Bug tree-optimization/116776] Complex if conditions not hoisted from loop

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

[Bug tree-optimization/116776] New: Complex if conditions not hoisted from loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116776 Bug ID: 116776 Summary: Complex if conditions not hoisted from loop Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree

[Bug target/117991] [15 regression] RISC-V: g++/template/builtin-speculation-overloads[14].C assertion error since addition in r15-6042-g9ed094a817e

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

[Bug target/117991] [15 regression] RISC-V: g++/template/builtin-speculation-overloads[14].C assertion error since addition in r15-6042-g9ed094a817e

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

[Bug middle-end/119108] New: [15 Regression] AArch64 Commit 'vect: Force alignment peeling ...' (https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=68326d5d1a593d) causes regression in Snappy workload for

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119108 Bug ID: 119108 Summary: [15 Regression] AArch64 Commit 'vect: Force alignment peeling ...' (https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=68326d5 d1a593d) causes r

[Bug target/119108] [15 Regression] AArch64 Commit 'vect: Force alignment peeling ...' (r15-6807-g68326d5d1a593d) causes regression in Snappy workload for -mcpu=neoverse-v2.

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

[Bug target/119108] [15 Regression] AArch64 Commit 'vect: Force alignment peeling ...' (r15-6807-g68326d5d1a593d) causes regression in Snappy workload for -mcpu=neoverse-v2.

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`

[Bug target/119108] [15 Regression] AArch64 Commit 'vect: Force alignment peeling ...' (r15-6807-g68326d5d1a593d) causes regression in Snappy workload for -mcpu=neoverse-v2.

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

[Bug libgomp/119588] New: Possible improvement in locking strategies for libgomp

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119588 Bug ID: 119588 Summary: Possible improvement in locking strategies for libgomp Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 C