https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121821
Richard Earnshaw changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|2025-09-06 00:0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121821
--- Comment #3 from Richard Earnshaw ---
Created attachment 62347
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=62347&action=edit
compressed pre-processed source
Confirmed.
Another possibility is that it's something to do with the switc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121810
Richard Earnshaw changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121810
Richard Earnshaw changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rearnsha at gcc dot
gnu.org
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
Target Milestone: ---
Target: arm
Created attachment 62317
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=62317&acti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121775
Richard Earnshaw changed:
What|Removed |Added
Known to work||16.0
--- Comment #3 from Richard Ear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121775
Richard Earnshaw changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rearnsha at gcc dot
gnu.org
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
Target Milestone: ---
Target: arm
#include
#include "arm_neon.h"
volatile uint8_t v40 = 255;
volatile uint8x8_t result = {
#if __BY
: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
CC: segher at gcc dot gnu.org
Target Milestone: ---
Target: arm
With this testcase, compiled with -march=armv7-a+simd -mfpu=auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121752
--- Comment #3 from Richard Earnshaw ---
The manual says:
> @deftypefn {Target Hook} bool TARGET_SLOW_UNALIGNED_ACCESS ...
> ...
> The hook must return true whenever @code{STRICT_ALIGNMENT} is true.
But STRICT_ALIGNMENT must be true because e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121619
Richard Earnshaw changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121618
Richard Earnshaw changed:
What|Removed |Added
Resolution|FIXED |DUPLICATE
--- Comment #8 from Richar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121679
--- Comment #5 from Richard Earnshaw ---
(In reply to Richard Biener from comment #4)
> DSE/DCE sometimes need "iteration", removing of trivially dead stmts in DSE
> helped to some extent, but yes, some of this is expected.
Is it worth iteratin
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
Target Milestone: ---
#include
struct A
{
int a;
int b;
const char *s;
uint8_t array[64];
};
static A f1(int a, int b)
{
A obj {
.a = a
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
Target Milestone: ---
The Armv8-a Arm ARM removes all references to mcrr2 and mrrc2, so the
intrinsics that expand to these instructions should be rejected when compiled
with -march=armv8-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121471
Richard Earnshaw changed:
What|Removed |Added
Keywords||accepts-invalid
Target Milestone|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121464
Richard Earnshaw changed:
What|Removed |Added
Target Milestone|--- |13.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121464
Richard Earnshaw changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117600
--- Comment #6 from Richard Earnshaw ---
libgcc is always built with the target compiler. --disable-werror is intended
to allow compliers other than the one being built to work when they generate
warnings based on different algorithms. It woul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121199
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
Richard Earnshaw changed:
What|Removed |Added
CC||hanwei62 at huawei dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121199
--- Comment #2 from Richard Earnshaw ---
It looks a bit like this was fixed in gcc-9.
Based on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714#c19
I suspect this is just a dup of that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772
Bug 86772 depends on bug 86802, which changed state.
Bug 86802 Summary: riscv port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86802
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86802
Richard Earnshaw changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117811
Richard Earnshaw changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117811
Richard Earnshaw changed:
What|Removed |Added
Summary|[12/13/14 Regression] bad |[12 Regression] bad code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120567
--- Comment #1 from Richard Earnshaw ---
Many fortran tests also use libbacktrace. So these days I just have
site.exp: set board_info(arm-qemu,extra_ldflags) "--specs=sync-none.specs"
In my bare-metal test configuration. That's enough f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116892
--- Comment #10 from Richard Earnshaw ---
(In reply to uecker from comment #9)
> (In reply to Richard Earnshaw from comment #8)
> > Forward declarations of enums in C requires c23, when you can use the size
> > type specifier. For earlier versi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116892
Richard Earnshaw changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
--- Comment #8 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120347
--- Comment #7 from Richard Earnshaw ---
The address in offsettable_address is always validated as a 'byte' sized
address (it's generic code). So it's not generally useful to use this on Arm
for validating anything that's more restricted than l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120347
--- Comment #5 from Richard Earnshaw ---
(In reply to Arnd Bergmann from comment #4)
> I have reduced another build failure (in some configurations but many files)
> and found that also to be caused by -flate-combine-instructions
>
> https://go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120351
Richard Earnshaw changed:
What|Removed |Added
Summary|[15/16 regression] Assemble |[15 regression] Assemble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120351
Richard Earnshaw changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rearnsha at gcc dot
gnu.org
||a/show_bug.cgi?id=20972
CC|richard.earnshaw at arm dot com|rearnsha at gcc dot
gnu.org
--- Comment #1 from Richard Earnshaw ---
This is somewhat of a heisenbug. The instruction is unpredictable because the
increment may take place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119644
Richard Earnshaw changed:
What|Removed |Added
Keywords|ice-on-invalid-code |ice-on-valid-code
--- Comment #4 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119550
--- Comment #4 from Richard Earnshaw ---
At some point crosstool will run GCC's 'configure' script. What I need to see
is the options it passes to that command.
Sorry, I've never used crosstool, so I can't help with that.
It is possible that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119550
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115506
--- Comment #4 from Richard Earnshaw ---
(In reply to Uroš Bizjak from comment #2)
> then RTL CSE2 pass would be able to merge:
>
> (insn 31 30 32 4 (set (reg:CCZ 17 flags)
> (compare:CCZ (reg:QI 111 [ _30 ])
> (const_int -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115827
--- Comment #7 from Richard Earnshaw ---
(In reply to Richard Biener from comment #6)
> IMO a testsuite issue then.
Why would a missing warning from
return f; /* { dg-warning "may be used" "unconditional" } */
be a testsuite issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117811
Richard Earnshaw changed:
What|Removed |Added
Assignee|pinskia at gcc dot gnu.org |rearnsha at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118939
--- Comment #19 from Richard Earnshaw ---
(In reply to Eric Botcazou from comment #18)
> > So the real question is why has the size of the frame changed once it's too
> > late to change the frame layout?
>
> The frame size has not changed, rath
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118939
--- Comment #17 from Richard Earnshaw ---
(In reply to Richard Earnshaw from comment #16)
> That can't be right. If the frame size has changed, then the frame needs to
> be laid out again and any earlier layout assumptions revisited.
Here's a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118939
--- Comment #16 from Richard Earnshaw ---
(In reply to Eric Botcazou from comment #13)
> Possible kludge to work around the questionable mechanism:
>
> diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
> index 59b41e3d046..2d51874a05b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91614
Richard Earnshaw changed:
What|Removed |Added
Summary|[12/13/14/15|[12/13/14 regression][arm]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117811
--- Comment #21 from Richard Earnshaw ---
Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2025-March/678597.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101995
--- Comment #16 from Richard Earnshaw ---
Still present.
Perhaps more significantly (and possibly related)
class x
{
public:
x ();
int func ();
private:
int a;
};
int g ()
{
x b;
return b.func();
}
generates:
g():
push
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119372
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2025-03-19
Version|14.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117931
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
Target Milestone: ---
c-c++-common/vector-compare-3.c contains the code:
void
g (T *x, T const *y, T *z, T *t)
{
*z = *x < *y | *x == *y;
*t =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119196
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118942
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117600
--- Comment #2 from Richard Earnshaw ---
libgcc should only be built with the current compiler, so I don't think it's
unreasonable to expect -Werror to be always enabled.
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
Target Milestone: ---
GCC often relies on combine to identify and eliminate redundant
(zero|sign)_extend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118221
--- Comment #10 from Richard Earnshaw ---
Fixing this properly would require rewriting all of GCC's dwarf output code so
that each function in a separate section had its own debug data (and perhaps
using section groups to describe the relationsh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117712
Richard Earnshaw changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117525
--- Comment #19 from Richard Earnshaw ---
I'm not convinced this is correct. See the discussion on the patch here:
https://gcc.gnu.org/pipermail/gcc-patches/2003-March/098380.html and the
related PR (https://gcc.gnu.org/bugzilla/show_bug.cgi?id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118089
--- Comment #4 from Richard Earnshaw ---
Partially fixed. Still to do is implementing stack deallocation by using a POP
of dead callee saved regs (for -Os).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116028
--- Comment #13 from Richard Earnshaw ---
(In reply to Surya Kumari Jangala from comment #3)
> The parameter register is
> saved in a volatile register which is saved on stack in the entry bb.
> Instead, if the volatile register is saved just be
-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
CC: jskumari at gcc dot gnu.org, vmakarov at redhat dot com
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118642
Richard Earnshaw changed:
What|Removed |Added
Keywords||rejects-valid
--- Comment #3 from Ri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118501
--- Comment #14 from Richard Earnshaw ---
(In reply to Matthias Klose from comment #13)
> the backport requires some more work:
>
> ../../src/gcc/config/aarch64/aarch64.md:7255:13: error:
> 'force_lowpart_subreg' was not declared in this scope;
|1
Assignee|unassigned at gcc dot gnu.org |rearnsha at gcc dot
gnu.org
Status|UNCONFIRMED |NEW
--- Comment #1 from Richard Earnshaw ---
mine
onent: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
Target Milestone: ---
Target: arm-none-eabi
The arm-none-eabi port provides some alternative implementations of
__sync_synchronize for different implementations of the archite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116448
--- Comment #5 from Richard Earnshaw ---
If -fno-math-errno doesn't work, then we could consider moving those specific
tests to a different file, with different optimization flags.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116448
--- Comment #4 from Richard Earnshaw ---
(In reply to Torbjorn SVENSSON from comment #3)
> Compiling the test case with -Os resolves the failed checks, but it also
> starts failing on the sqrt() and sqrtf() calls. These are no longer expanded
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116448
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118564
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118460
--- Comment #6 from Richard Earnshaw ---
Yes, that would work as a work-around. It's a bit of a hack though. The
expectation is that we would use vsel for pretty much everything when it is
available (particularly for fast-math), but we fail to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118460
--- Comment #4 from Richard Earnshaw ---
arm_vsel_comparison_operator is rejecting the comparison (LT) because it is not
one that the vsel instruction can handle. We should be reversing the order of
operands to the compare instruction and then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118136
Richard Earnshaw changed:
What|Removed |Added
Resolution|INVALID |---
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118089
--- Comment #1 from Richard Earnshaw ---
> I suspect this is a consequence of moving to an rtl-based prologue.
Or more accurately: epilogue. :)
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
Target Milestone: ---
Target: arm
This is a regression that originally appeared in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118008
--- Comment #11 from Richard Earnshaw ---
For the bare metal cross you probably need to configure with
'--with-arch=armv7-a+fp --with-float-abi=hard'
If that still doesn't trigger it, try adding '--with-mode=thumb'
,
||rearnsha at gcc dot gnu.org
--- Comment #6 from Richard Earnshaw ---
So I think this issue might be related to something Christophe and I were
discussing the other day. The arm port defaults to not creating the type _fp16
by default, but on some CPUs this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117941
--- Comment #5 from Richard Earnshaw ---
> Is it then possible to have dwarf data on ARM in addition to the EABI defined
> unwind section?
I don't know, honesty, because I've not tried it. I'd be surprised if it worked
though, at least, not wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117941
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116625
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116447
--- Comment #1 from Richard Earnshaw ---
How was the compiler configured and what's the full command line used when
building the test?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117766
--- Comment #14 from Richard Earnshaw ---
(In reply to Tom Lane from comment #13)
> After further experimentation, it seems to me that:
>
> * There was a behavioral change between gcc 9.3.1 and the later releases I
> tested. Specifically, in 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
Richard Earnshaw changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
--- Comment #40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117419
--- Comment #4 from Richard Earnshaw ---
enum size is ABI (affects data layout). So you can't use -f[no-]short-enums
for executable tests. The best way to deal with this is to ensure that the
size of the enum defaults to int (eg by adding a du
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56513
--- Comment #8 from Richard Earnshaw ---
For something this old, we should probably just close it as fixed as of Richi's
patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #36 from Richard Earnshaw ---
I've been looking at this. I think the real problem is that trunc_int_for mode
is doing something incompatible with what the later code expects. We have
/* Canonicalize BImode to 0 and STORE_FLAG_VA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116856
--- Comment #8 from Richard Earnshaw ---
BTW, rewriting the code as:
#include
typedef uint32_t __attribute__((aligned(1))) u32_u;
void f()
{
static uint8_t array[64];
for (uint8_t i = 0; i < sizeof(array); i++)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116856
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116856
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113780
Richard Earnshaw changed:
What|Removed |Added
Target Milestone|--- |13.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116597
Richard Earnshaw changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rearnsha at gcc dot
gnu.org
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
Target Milestone: ---
void (*f)(); // Or void (*f)(int, ...};
void g () { return f (1, 2, 3, 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116517
--- Comment #3 from Richard Earnshaw ---
The invalid insn is created during late-combine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116517
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2024-08-28
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116329
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86901
--- Comment #4 from Richard Earnshaw ---
But why not:
f2:
fmovw1, s0
ubfxw1, w1, 20, 11
cmp w1, 1015
bhi .L7
fmuls0, s0, s0
str s0, [x0]
ret
.L7:
b g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373
--- Comment #25 from Richard Earnshaw ---
(In reply to Kewen Lin from comment #24)
> OK, thanks for the comments, I'll mark PR108977 as won't fix then.
It would be more normal to mark it as fixed, but set the fix version to the
earliest release
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115611
Richard Earnshaw changed:
What|Removed |Added
Target Milestone|--- |11.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105090
--- Comment #9 from Richard Earnshaw ---
It looks like the compiler now merges b into a rather than a into b. The
result is the same, though and we don't need an lsr this way. Technically it
ought to be better.
But we do end up in a dance wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103100
Richard Earnshaw changed:
What|Removed |Added
Target Milestone|11.5|12.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115770
--- Comment #2 from Richard Earnshaw ---
Correction: the option to add is -fno-delete-null-pointer-checks
Sorry for the confusion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115770
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115732
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
1 - 100 of 1183 matches
Mail list logo
