[Bug target/112470] [11/12/13/14 regression] [AARCH64] stack-protector vulnerability fixing solution impact code size and performance

2023-11-13 Thread dongjianqiang2 at huawei dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112470 --- Comment #8 from John Dong --- (In reply to Richard Sandiford from comment #7) > (In reply to John Dong from comment #6) > > For applications without stack protection, there is no difference because > > the function stack frame not changed wh

[Bug target/112470] [11/12/13/14 regression] [AARCH64] stack-protector vulnerability fixing solution impact code size and performance

2023-11-13 Thread dongjianqiang2 at huawei dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112470 --- Comment #6 from John Dong --- (In reply to Richard Sandiford from comment #5) > Could you quantify the performance impact that you're seeing? Figures > relative to no protection and to unpatched -fstack-protector-strong would be > useful. >

[Bug target/112470] [11/12/13/14 regression] [AARCH64] stack-protector vulnerability fixing solution impact code size and performance

2023-11-12 Thread dongjianqiang2 at huawei dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112470 --- Comment #3 from John Dong --- (In reply to John Dong from comment #0) > Hi, after the CVE-2023-4039 patch is installed, the code size and > performance are affected after stack protection is enabled. > Refer to https://godbolt.org/z/7dWeYd5

[Bug target/112470] New: [AARCH64]stack-protector vulnerability fixing solution impact code size and performance.

2023-11-09 Thread dongjianqiang2 at huawei dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112470 Bug ID: 112470 Summary: [AARCH64]stack-protector vulnerability fixing solution impact code size and performance. Product: gcc Version: 13.1.0 Status: UNCONFIRMED

[Bug rtl-optimization/103125] New: [ARM]Useless stack initialization on aarch64 big-endian

2021-11-07 Thread dongjianqiang2 at huawei dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103125 Bug ID: 103125 Summary: [ARM]Useless stack initialization on aarch64 big-endian Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Prior

[Bug target/83466] Wrong TLS GD sequence for ILP32

2021-06-22 Thread dongjianqiang2 at huawei dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83466 --- Comment #8 from John Dong --- Created attachment 51045 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51045&action=edit patch to fix pr83466 patch to fix this issue for SYMBOL_SMALL_TLSDESC and SYMBOL_SMALL_TLSIE.

[Bug lto/96455] Partial Linking (-r) with LTO issue

2021-05-11 Thread dongjianqiang2 at huawei dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96455 John Dong changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options

2021-05-11 Thread dongjianqiang2 at huawei dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 --- Comment #5 from John Dong --- (In reply to Martin Liška from comment #3) > But expected result is end g_2823 = 32768, right? > Clang returns the same result 32768. Yes, I think so.

[Bug tree-optimization/100499] New: Different results with -fpeel-loops -ftree-loop-vectorize options

2021-05-10 Thread dongjianqiang2 at huawei dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 Bug ID: 100499 Summary: Different results with -fpeel-loops -ftree-loop-vectorize options Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal

[Bug target/83466] Wrong TLS GD sequence for ILP32

2021-04-27 Thread dongjianqiang2 at huawei dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83466 John Dong changed: What|Removed |Added CC||dongjianqiang2 at huawei dot com --- Commen

[Bug target/96892] [ARM]Wrong __stack_chk_guard for comparison

2021-01-06 Thread dongjianqiang2 at huawei dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96892 John Dong changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED

[Bug target/96892] [ARM]Wrong __stack_chk_guard for comparison

2020-12-20 Thread dongjianqiang2 at huawei dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96892 --- Comment #4 from John Dong --- diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md index 1a8e498ba4c..97c2f6a1174 100644 --- a/gcc/config/arm/arm.md +++ b/gcc/config/arm/arm.md @@ -9301,6 +9301,7 @@ (define_insn_and_split "*stack_protec

[Bug ipa/97945] New: undefined reference err when a function defined inline

2020-11-23 Thread dongjianqiang2 at huawei dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97945 Bug ID: 97945 Summary: undefined reference err when a function defined inline Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Comp

[Bug target/96892] [ARM]Wrong __stack_chk_guard for comparison

2020-10-27 Thread dongjianqiang2 at huawei dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96892 --- Comment #3 from John Dong --- (In reply to Thomas Preud'homme from comment #2) > Wouldn't it be enough to add: > > "emit_move_insn (operands[3], gen_rtx_MEM(SImode, operands[3]));" > > just before the line "if (TARGET_32BIT)" in stack_prote