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|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115353
Richard Earnshaw changed:
What|Removed |Added
Target Milestone|--- |14.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115360
Richard Earnshaw changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115353
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2024-06-05
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115157
--- Comment #4 from Richard Earnshaw ---
The tests in the last patch fail on arm-eabi. The tests assume that
sizeof(enum) == sizeof(int), which is not true if -fshort-enum is the default.
+ Chang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115086
--- Comment #2 from Richard Earnshaw ---
And perhaps more importantly the mov can even be hoisted outside of a loop.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115083
--- Comment #5 from Richard Earnshaw ---
Please give the port developers time to finish working on the port. Only the
initial patches have been pushed so far and there is plenty of work left to do.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115058
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115058
Richard Earnshaw changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #34 from Richard Earnshaw ---
To be honest, I'm more concerned that we aren't eliminating a lot of these
copies during the gimple optimization phase. The memcpy is really a type
punning step (that's strictly ISO C compliant, rather
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #31 from Richard Earnshaw ---
While that does seem to fix the bug, it's at the cost of 6 additional stores in
the problematic test that are redundant other than changing the alias set view.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #29 from Richard Earnshaw ---
Sorry, I was looking at the wrong pair of insns. The earlier store to that
location was insn 111.
111: [r212:SI (1 MEM[(struct Vec128 *)_179]+0 S4 A64)] = {r0:SI..r3:SI}
It appears that the problem is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #27 from Richard Earnshaw ---
(In reply to Richard Earnshaw from comment #26)
> (In reply to Richard Biener from comment #25)
> > I think it's more interesting why
> >
> > * 119: [r216:SI (2 MEM[(struct Vec128 *)_179]+0 S4 A64)] =
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #26 from Richard Earnshaw ---
(In reply to Richard Biener from comment #25)
> I think it's more interesting why
>
> * 119: [r216:SI (2 MEM[(struct Vec128 *)_179]+0 S4 A64)] =
> {r0:SI..r3:SI}
>
> isn't considered as dependence? Wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #23 from Richard Earnshaw ---
#0 ptr_deref_may_alias_decl_p (ptr=0x75e0c678, decl=0x75dff000)
at /home/rearnsha/gnusrc/gcc-cross/gcc-13/gcc/tree-ssa-alias.cc:295
#1 0x01768173 in indirect_ref_may_alias_decl_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #22 from Richard Earnshaw ---
(Previous analysis is based on gcc-13 branch)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
Richard Earnshaw changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #20 from Richard Earnshaw ---
Created attachment 57928
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57928&action=edit
fully preprocessed testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #19 from Richard Earnshaw ---
This is another problem with (I suspect) incorrect aliasing information. If I
compile with -fno-strict-aliasing, I get
88: f4432a1fvst1.8 {d18-d19}, [r3 :64] // {>E} SP+96/16
8c:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114338
--- Comment #1 from Richard Earnshaw ---
Why would that be better? On a machine that does not lack registers, there's
more instruction-level parallelism in
(set (tmp) (-1))
(set (tmp) (ashift (tmp) (count)))
(and (x) (x) (tmp))
What's more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114307
--- Comment #2 from Richard Earnshaw ---
Note that it's clear from the .syntax markers that this is inline assembler
that's the source of the invalid instructions.
|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Richard Earnshaw ---
>From a full assembler dump:
.syntax divided
@ 71 "/home/rearnsha/gnusrc/gcc/master/gcc/testsuite/gcc.dg/vect/tree-vect.h" 1
vorr d6, d6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113428
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113542
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113428
--- Comment #6 from Richard Earnshaw ---
Patch here: https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647294.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100523
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110775
--- Comment #3 from Richard Earnshaw ---
Perhaps we could use
#define abort __builtin_trap
?
A quick check seems to suggest this will work ok.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113428
--- Comment #4 from Richard Earnshaw ---
/* { dg-warning {cast to pointer from integer of different size} "" { target
*-*-* } .-2 } */
I'm guessing it's this that's causing the problem because int and int* are the
same size on 32-bit targets.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113428
--- Comment #3 from Richard Earnshaw ---
The referenced patch added the test that is failing. How is that a regression?
Or are you suggesting that the test works without the rest of the patch
applied?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113510
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113510
Richard Earnshaw changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rearnsha at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113611
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337
Richard Earnshaw changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114136
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
1 - 100 of 1149 matches
Mail list logo
