[Bug target/94993] aarch64 incompatible with -mgeneral-regs-only

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94993 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug target/95908] [AArch64] wrong code with ILP32 and -fwrapv

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95908 --- Comment #1 from Richard Earnshaw --- I'm sure the code we generate doesn't match your expectations. What's more, I don't think it's really practical to meet them. To do so would require emitting a mask operation after practically every

[Bug target/97534] [10/11 Regression] ICE in decompose, at rtl.h:2280 (arm-linux-gnueabihf)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97534 Richard Earnshaw changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug target/97534] [10/11 Regression] ICE in decompose, at rtl.h:2280 (arm-linux-gnueabihf)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97534 --- Comment #5 from Richard Earnshaw --- No, I don't think it's related to that, in fact, I think this is just a latent bug that's been in the code for a long time. At one point we have a 32-bit signed integer containing INT_MIN, which is

[Bug target/98681] [8/9/10/11 Regression] aarch64: Invalid ubfiz instruction rejected by assembler

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98681 --- Comment #5 from Richard Earnshaw --- Patch looks generally sensible, but I think all the INTVALs in that expression should be converted to UINTVAL. The mask, in particular, is unsigned and it is weird that one moment we're using a unsigned

[Bug target/98759] arm cortex-r5 single precisions flotaing point generation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98759 Richard Earnshaw changed: What|Removed |Added Resolution|--- |INVALID

[Bug target/82150] Produces a branch prefetch which causes a hang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150 Richard Earnshaw changed: What|Removed |Added Resolution|--- |INVALID

[Bug target/82150] Produces a branch prefetch which causes a hang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150 Richard Earnshaw changed: What|Removed |Added Last reconfirmed||2021-01-29 Ever confirmed|0

[Bug target/82150] Produces a branch prefetch which causes a hang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150 Richard Earnshaw changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|---

[Bug target/100563] [10/11 Regression] arm: ICE in arm_gen_dicompare_reg, at config/arm/arm.c:15976

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100563 Richard Earnshaw changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug target/99908] SIMD: negating logical + if_else has a suboptimal codegen.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99908 --- Comment #8 from Richard Earnshaw --- Never mind, the original reference to arm was not the 'arm cpu', my mistake.

[Bug target/100563] [10/11/12 Regression] arm: ICE in arm_gen_dicompare_reg, at config/arm/arm.c:15976

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100563 Richard Earnshaw changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at

[Bug target/100563] [10/11/12 Regression] arm: ICE in arm_gen_dicompare_reg, at config/arm/arm.c:15976

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100563 --- Comment #2 from Richard Earnshaw --- Er, wow, I'm surprised this hasn't come up before. The problem is that the cstore_cc pattern in arm.md has no predicates on the operands and no constraints on the modes of those operands and yet it then

[Bug target/99908] SIMD: negating logical + if_else has a suboptimal codegen.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99908 --- Comment #7 from Richard Earnshaw --- (In reply to Hongtao.liu from comment #6) > Should be fixed in trunk. The original report was about arm. None of your changes are outside of the x86 backend, so no, this is not fixed for the original

[Bug target/100563] [10/11 Regression] arm: ICE in arm_gen_dicompare_reg, at config/arm/arm.c:15976

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100563 Richard Earnshaw changed: What|Removed |Added Summary|[10/11/12 Regression] arm: |[10/11 Regression] arm: ICE

[Bug testsuite/100713] New: g++.dg/cpp1y/lambda-generic-90842.C has ambiguous pass and fail

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100713 Bug ID: 100713 Summary: g++.dg/cpp1y/lambda-generic-90842.C has ambiguous pass and fail Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal

[Bug testsuite/100713] g++.dg/cpp1y/lambda-generic-90842.C has ambiguous pass and fail

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100713 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/100767] New: arm: ice when inlining at -flto with different cpu and arch settings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100767 Bug ID: 100767 Summary: arm: ice when inlining at -flto with different cpu and arch settings Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal

[Bug target/100767] arm: ice when inlining at -flto with different cpu and arch settings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100767 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[Bug target/100767] arm: ice when inlining at -flto with different cpu and arch settings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100767 --- Comment #1 from Richard Earnshaw --- The problem is that we call arm_configure_build_target() with arm_configure_build_target (_target, caller_opts, _options_set, false); But that doesn't make sense in reality - global_options_set does

[Bug target/100767] arm: ice when inlining at -flto with different cpu and arch settings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100767 --- Comment #5 from Richard Earnshaw --- Also fixed for gcc-11. Will consider backporting further, but patches no-longer apply cleanly on gcc-10.

[Bug target/100767] arm: ice when inlining at -flto with different cpu and arch settings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100767 --- Comment #3 from Richard Earnshaw --- fixed on master so far.

[Bug target/84467] Choosing between Integer and NEON for 64-bit operations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84467 Richard Earnshaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug rtl-optimization/87871] [9/10/11/12 Regression] testcases fail after r265398 on arm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871 --- Comment #68 from Richard Earnshaw --- (In reply to Christophe Lyon from comment #67) > According to gcc-testresults, we still see: > FAIL: gcc.dg/ira-shrinkwrap-prep-1.c scan-rtl-dump pro_and_epilogue > "Performing shrink-wrapping" > FAIL:

[Bug rtl-optimization/87871] [9/10/11/12 Regression] testcases fail after r265398 on arm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871 Richard Earnshaw changed: What|Removed |Added Status|NEW |WAITING --- Comment #66 from Richard

[Bug target/95650] aarch64: Missed optimization storing addition of two shorts

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95650 --- Comment #6 from Richard Earnshaw --- AArch32 is able to produce the optimal sequence because the ABI specifies caller widening of parameters. For safety reasons AArch64 takes the opposite approach and requires the callee to narrow

[Bug target/101325] [12 Regression] arm: Wrong code with MVE vcmpeqq intrinsic since r12-671-gd083fbf72

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101325 --- Comment #9 from Richard Earnshaw --- (insn 7 4 8 2 (set (reg:HI 117) (eq:HI (reg:V16QI 119) (reg:V16QI 120))) {mve_vcmpeqq_v16qi} (expr_list:REG_DEAD (reg:V16QI 120) (expr_list:REG_DEAD (reg:V16QI 119)

[Bug target/101325] [12 Regression] arm: Wrong code with MVE vcmpeqq intrinsic since r12-671-gd083fbf72

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101325 --- Comment #11 from Richard Earnshaw --- (In reply to Christophe Lyon from comment #10) > This was introduced by my change at r12-671 in mve.md: > -;; [vcmpneq_]) > +;; [vcmpneq_, vcmpcsq_, vcmpeqq_, vcmpgeq_, vcmpgtq_, vcmphiq_, vcmpleq_, >

[Bug target/101284] conflicting arch/fpu result in unexpected preprocessor defines

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101284 --- Comment #1 from Richard Earnshaw --- I think this combination of options should result in an error. As we move away from -mfpu to permitting only the 'auto' model, we are increasingly adding 'fpu' features that cannot be expressed via this

[Bug target/101220] arm: iwmmxt2: generating bad assembler ?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101220 --- Comment #2 from Richard Earnshaw --- Was broken by the binutils commit f439988037a589de3798f44e7268301adaec21a9

[Bug target/101220] arm: iwmmxt2: generating bad assembler ?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101220 --- Comment #1 from Richard Earnshaw --- The same problem exists in gcc-10 and gcc-11 (gcc-9 does not generate the wldrd/wstrd insructions), but I think this is a gas bug rather than a bug in gcc. The output from the gcc-12 compiler does

[Bug target/101220] arm: iwmmxt2: generating bad assembler ?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101220 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/101220] arm: iwmmxt2: generating bad assembler ?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101220 --- Comment #4 from Richard Earnshaw --- FTR I've committed fixes to binutils on the master and 2.36 branches. Although I think this affects binutils 2.34 and later older branches of binutils are no-longer maintained.

[Bug target/100236] arm: UB in arm_compute_save_core_reg_mask (shift exponent 4294967295 is too large for 32-bit type 'int')

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100236 Richard Earnshaw changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed|

[Bug target/100236] arm: UB in arm_compute_save_core_reg_mask (shift exponent 4294967295 is too large for 32-bit type 'int')

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100236 --- Comment #4 from Richard Earnshaw --- Fixed on master so far.

[Bug rtl-optimization/100311] UB in sel-sched.c:init_regs_for_mode with -march=armv8-m.base

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100311 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug rtl-optimization/100311] UB in sel-sched.c:init_regs_for_mode with -march=armv8-m.base

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100311 Richard Earnshaw changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 100311, which changed state. Bug 100311 Summary: UB in sel-sched.c:init_regs_for_mode with -march=armv8-m.base https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100311 What|Removed |Added

[Bug target/100432] gcc arm compilation binary output is bigger with -Os than -O2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100432 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0

[Bug c++/100412] New: [11/12 regression] PASS & FAIL for same test aarch64-qemu: gcc.dg/Wvla-parameter-[23].c pr?????

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100412 Bug ID: 100412 Summary: [11/12 regression] PASS & FAIL for same test aarch64-qemu: gcc.dg/Wvla-parameter-[23].c pr? Product: gcc Version: 11.0 Status: UNCONFIRMED

[Bug target/63521] The AArch64 backend doesn't define REG_ALLOC_ORDER.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63521 Richard Earnshaw changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|jiwang at gcc

[Bug c++/100412] [11/12 regression] PASS & FAIL for same test aarch64-qemu: gcc.dg/Wvla-parameter-[23].c pr?????

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100412 --- Comment #2 from Richard Earnshaw --- The test name comes from the file name, the 'test for warnings' and the line number. Since both warnings are on the same line, that would require some major hackery (unless that can be encoded in the

[Bug target/86209] Peephole does not happen because the type of zero/sign extended operands is not the same.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209 Richard Earnshaw changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|sameerad at

[Bug target/99724] [11 Regression] CE in in extract_insn, at recog.c:2770

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99724 Richard Earnshaw changed: What|Removed |Added Last reconfirmed||2021-03-23

[Bug target/99773] ARM v8.1-m MVE interaction with -mfloat-abi not clear

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773 --- Comment #1 from Richard Earnshaw --- -march=armv8.1-m.main+mve -mfloat-abi=hard should use the VFP registers for passing any FP arguments so the build attribute for Tag_ABI_VFP_args should be set to show that. It's true that soft-float

[Bug target/99836] aarch64: -fpatchable-function-entry=N[,0] should place .cfi_startproc before NOPs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99836 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug debug/98776] DW_AT_low_pc is inconsistent with function entry address, when enabling -fpatchable-function-entry

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98776 Richard Earnshaw changed: What|Removed |Added CC||i at maskray dot me --- Comment #1

[Bug target/99773] ARM v8.1-m MVE interaction with -mfloat-abi not clear

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773 --- Comment #4 from Richard Earnshaw --- (In reply to Christophe Lyon from comment #3) > I tried changing TARGET_HARD_FLOAT_SUB in arm.h to: > #define TARGET_HARD_FLOAT_SUB (arm_float_abi != ARM_FLOAT_ABI_SOFT\ >

[Bug target/99890] The -mstrict-align doesn't support the ARM targets

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99890 Richard Earnshaw changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|---

[Bug target/99551] aarch64: csel is used for cold scalar computation which affects performance

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99551 --- Comment #1 from Richard Earnshaw --- probably one of the if-conversion passes.

[Bug target/99271] New: [10/11 regression] Wrong code for Arm-v8-m.main CMSE calling __gnu_cmse_nonsecure_call

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99271 Bug ID: 99271 Summary: [10/11 regression] Wrong code for Arm-v8-m.main CMSE calling __gnu_cmse_nonsecure_call Product: gcc Version: 10.0 Status: UNCONFIRMED

[Bug target/99271] [10 regression] Wrong code for Arm-v8-m.main CMSE calling __gnu_cmse_nonsecure_call

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99271 Richard Earnshaw changed: What|Removed |Added Summary|[10/11 regression] Wrong|[10 regression] Wrong code

[Bug target/99271] [10/11 regression] Wrong code for Arm-v8-m.main CMSE calling __gnu_cmse_nonsecure_call

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99271 Richard Earnshaw changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed|

[Bug target/99271] [10 regression] Wrong code for Arm-v8-m.main CMSE calling __gnu_cmse_nonsecure_call

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99271 Richard Earnshaw changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug target/99143] Bad section alignment on AArch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143 Richard Earnshaw changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|---

[Bug target/100067] Unexpected warning for -mcpu=neoverse-n1 when configured with --with-fpu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100067 --- Comment #4 from Richard Earnshaw --- (In reply to Christophe Lyon from comment #3) > Unfortunately this is causing many regressions in the GCC testsuite. Sigh! I'm not entirely surprised. I suspect most of this is testisms, though. > >

[Bug target/84547] Suboptimal code for int128 masked shifts (ARM64)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84547 --- Comment #2 from Richard Earnshaw --- (In reply to Andrew Pinski from comment #1) > Yes int128 (or rather double wide register) shifts are not optimized that > well. They are not used by many people even. I wonder if there is a way to > use

[Bug target/100067] Unexpected warning for -mcpu=neoverse-n1 when configured with --with-fpu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100067 Richard Earnshaw changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed|

[Bug target/100067] New: Unexpected warning for -mcpu=neoverse-n1 when configured with --with-fpu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100067 Bug ID: 100067 Summary: Unexpected warning for -mcpu=neoverse-n1 when configured with --with-fpu Product: gcc Version: 11.0 Status: UNCONFIRMED Severity:

[Bug target/95816] Aarch64 jumps between Hot/Cold sections does not clobber registers x16/x17

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95816 --- Comment #2 from Richard Earnshaw --- (In reply to Andrew Pinski from comment #1) > Confirmed, I wonder if x16 and x17 should not be considered as temps alive > across all jumps in aarch64 really; not just jumps between hot and cold >

[Bug target/95816] Aarch64 jumps between Hot/Cold sections does not clobber registers x16/x17

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95816 --- Comment #3 from Richard Earnshaw --- The best thing to do for now is to disable hot/cold partitioning, as we do on Arm.

[Bug target/100214] UB in arm.c:optimal_immediate_sequence_1 (left shift of 255 by 30 places cannot be represented in type 'int')

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100214 Richard Earnshaw changed: What|Removed |Added Last reconfirmed||2021-04-23

[Bug target/100216] arm: UB in arm_canonicalize_comparison (shift exponent 127 is too large for 64-bit type)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100216 Richard Earnshaw changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed|

[Bug target/97807] ICE in output_move_double, at config/arm/arm.c:19689

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97807 --- Comment #2 from Richard Earnshaw --- In Arm mode the compiler restricts 64-bit sized objects to be even/odd pairs of core registers (ie starting in r0, r2, etc). However, the ABI for this packed object is trying to use (r1,r2) for passing

[Bug target/102035] arm/m-profile/cmse add mitigation for CVE-2021-35465

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102035 Richard Earnshaw changed: What|Removed |Added Target Milestone|--- |10.5

[Bug target/102035] arm/m-profile/cmse add mitigation for CVE-2021-35465

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102035 Richard Earnshaw changed: What|Removed |Added Target Milestone|10.5|10.4

[Bug target/102035] arm/m-profile/cmse add mitigation for CVE-2021-35465

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102035 Richard Earnshaw changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug target/102035] New: arm/m-profile/cmse add mitigation for CVE-2021-35465

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102035 Bug ID: 102035 Summary: arm/m-profile/cmse add mitigation for CVE-2021-35465 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug target/102035] arm/m-profile/cmse add mitigation for CVE-2021-35465

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102035 Richard Earnshaw changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rearnsha at gcc dot gnu.org

[Bug target/102135] (ARM Cortex-M3 and newer) changing operation order may reduce number of instructions needed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102135 --- Comment #1 from Richard Earnshaw --- A small change to the testcase shows that this is highly dependent on the constrained registers from the calling convention. uint64_t foo64(int dummy, const uint8_t *rData1) { uint64_t buffer;

[Bug target/102125] (ARM Cortex-M3 and newer) missed optimization. memcpy not needed operations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102125 --- Comment #5 from Richard Earnshaw --- Testcase was not quite complete. Extending it to: typedef unsigned long long uint64_t; typedef unsigned long uint32_t; typedef unsigned char uint8_t; uint64_t bar64(const uint8_t *rData1) {

[Bug target/101723] arm: incorrect order of .fpu and .arch_extension directives leads to unsupported instructions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101723 --- Comment #15 from Richard Earnshaw --- (In reply to Christophe Lyon from comment #14) > I think you forgot to backport > r12-2790-ga22b3e022c2b45047a28d901042888eb77620499 to gcc-9 ? I don't think so. I think that patch collapsed away due

[Bug target/102125] (ARM Cortex-M3 and newer) missed optimization. memcpy not needed operations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102125 --- Comment #6 from Richard Earnshaw --- (In reply to Richard Biener from comment #2) > One common source of missed optimizations is gimple_fold_builtin_memory_op > which has [...] Yes, this is the source of the problem. I wonder if this

[Bug target/101723] arm: incorrect order of .fpu and .arch_extension directives leads to unsupported instructions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101723 Richard Earnshaw changed: What|Removed |Added Target Milestone|--- |9.5 Resolution|---

[Bug libgcc/102017] libgcc ieee754-df.S for arm does not support exceptions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102017 --- Comment #1 from Richard Earnshaw --- There are a number of complications here: - What's the code size overhead? Even if the performance overhead is trivial, I suspect the additional code might be non-trivial on an m-profile device, so is

[Bug tree-optimization/102072] New test case gcc.dg/vect/pr101145_3.c in r12-3136 fails on armeb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102072 Richard Earnshaw changed: What|Removed |Added Resolution|DUPLICATE |--- CC|

[Bug tree-optimization/102072] New test case gcc.dg/vect/pr101145_3.c in r12-3136 fails on armeb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102072 --- Comment #5 from Richard Earnshaw --- (In reply to Jiu Fu Guo from comment #4) > I did not find arm big-endian yet, I'm trying to reproduce this issue on > other targets... For testing purposes you should be able to build a standard

[Bug target/89604] Type conversion from signed char to a wider integer generates wrong assembly for ARM,

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89604 --- Comment #6 from Richard Earnshaw --- For the record, the choice of unsigned for the default char type dates back to the original Arm architecture, which only had unsigned byte load instructions (and sign-extending values required two further

[Bug target/100767] arm: ice when inlining at -flto with different cpu and arch settings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100767 Richard Earnshaw changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|---

[Bug c/102279] Bad codegen with ILP32, packed struct field pointer, static variable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102279 --- Comment #1 from Richard Earnshaw --- Looks to me like this code violates the aliasing rules. Compiling with -fno-strict-aliasing looks generate what your are expecting (although your expectations are wrong by the C standard). Oddly,

[Bug target/102125] (ARM Cortex-M3 and newer) missed optimization. memcpy not needed operations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102125 Richard Earnshaw changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug c/102279] Bad codegen with ILP32, packed struct field pointer, static variable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102279 --- Comment #3 from Richard Earnshaw --- (In reply to Will from comment #2) > Thanks Richard! This is obviously a gap in my knowledge I need to fill in. The aliasing rules say (in essence) that a pointer to an object of type T1 cannot point

[Bug target/102309] thumb2-replicated-constant2.c fails on cortex-m7

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102309 --- Comment #1 from Richard Earnshaw --- A constant limit of zero doesn't make sense to me, that would theoretically push everything into the literal pool regardless of the number of insns needed.

[Bug target/101448] Use GCC 9.3.0 to build Ceph crimson-osd on Arm64, linker failed for relocation truncated to fit: R_AARCH64_CALL26 against symbol

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101448 --- Comment #3 from Richard Earnshaw --- What optimization level are you building with? The R_AARCH64_CALL26 relocation has a branch range of +/-2^27 bytes, or 128MBytes, so that puts a limit on the size of the code segment of a binary. If

[Bug target/101723] New: arm: incorrect order of .fpu and .arch_extension directives leads to unsupported instructions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101723 Bug ID: 101723 Summary: arm: incorrect order of .fpu and .arch_extension directives leads to unsupported instructions Product: gcc Version: 11.0 Status: UNCONFIRMED

[Bug target/101723] arm: incorrect order of .fpu and .arch_extension directives leads to unsupported instructions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101723 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |NEW Assignee|unassigned

[Bug target/101723] arm: incorrect order of .fpu and .arch_extension directives leads to unsupported instructions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101723 Richard Earnshaw changed: What|Removed |Added Keywords||assemble-failure

[Bug ada/102450] GCC error: in set_min_and_max_values_for_integral_type, at stor-layout.c:2851

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102450 --- Comment #6 from Richard Earnshaw --- So I think we need a way of checking that this won't fail before we call it. Any idea? tree type = lang_hooks.types.type_for_size (ilen * 8, 1);

[Bug ada/102450] GCC error: in set_min_and_max_values_for_integral_type, at stor-layout.c:2851

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102450 --- Comment #8 from Richard Earnshaw --- I suspect go has a similar issue, but it looks as though c, c++, fortran and d are all ok.

[Bug ada/102450] GCC error: in set_min_and_max_values_for_integral_type, at stor-layout.c:2851

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102450 --- Comment #7 from Richard Earnshaw --- (In reply to Richard Earnshaw from comment #6) > So I think we need a way of checking that this won't fail before we call it. > > Any idea? > > tree type = lang_hooks.types.type_for_size

[Bug target/102767] ICE in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.c:5216

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102767 --- Comment #5 from Richard Earnshaw --- We have the type unit-size and movmisalign pattern is enabled for this. but the vectorization cost doesn't handle the case of elements=1, which is the case when mode is TImode. So I think

[Bug target/102604] arm v7m_extra_costs for SFmode inaccurate?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102604 --- Comment #3 from Richard Earnshaw --- (In reply to Christophe Lyon from comment #2) > Right, using -Os makes these tests pass (but vsqrt.f32 and vsqrt.f64 would > fail), Ah, because sqrt() is expected to set errno? Would changing the code

[Bug target/102411] arm/vfp18.c fails with -march=armv7e-m+fp for cortex-m4

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102411 --- Comment #1 from Richard Earnshaw --- The AAPCS tests are executable tests, so rely on a number of features of the support libraries (ie libraries compatible with the options used for the compilation). I don't think they should be adding

[Bug target/102604] arm v7m_extra_costs for SFmode inaccurate?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102604 --- Comment #1 from Richard Earnshaw --- I wonder if it might be better to change this test to use -Os, since then the cost model is much more consistent as it's based on size rather than speed.

[Bug target/36409] Additional instructions in prologue and epilogue.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36409 Richard Earnshaw changed: What|Removed |Added Last reconfirmed|2009-04-21 14:42:20 |2021-12-20 --- Comment #3 from

[Bug target/103395] [9/10/11/12 Regression] ICE on qemu in arm create_fix_barrier

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103395 --- Comment #4 from Richard Earnshaw --- I suspect the best we're likely to be able to do is to downgrade the ICE into an error if there's a long inline ASM in the code, much like the way we handle invalid constraints in inline ASMs.

[Bug target/103395] [9/10/11/12 Regression] ICE on qemu in arm create_fix_barrier

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103395 --- Comment #6 from Richard Earnshaw --- It depends on the the reference. Some minipool references can only be forwards due to the nature of the instruction making the reference. I'll need to take a look, and I might also need a real

[Bug target/103395] [9/10/11/12 Regression] ICE on qemu in arm create_fix_barrier

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103395 --- Comment #10 from Richard Earnshaw --- It's been this way now for over 20 years. A single instruction cannot take a constant and a memory for the same operand, so this has been used in the backend to trigger the minipool generation: a

[Bug target/103395] [9/10/11/12 Regression] ICE on qemu in arm create_fix_barrier

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103395 --- Comment #8 from Richard Earnshaw --- OK, so the real problem in the test case is the constraint ("nor") is meaningless on Arm (because there is no instruction in the architecture that can accept both a constant and a memref) and this

[Bug middle-end/103393] [12 Regression] Generating 256bit register usage with -mprefer-avx128 -mprefer-vector-width=128

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393 --- Comment #19 from Richard Earnshaw --- It sounds to me like you're trying to keep your cake and eat it.

  1   2   3   4   >