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. :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118089
Bug ID: 118089
Summary: [12/13/14 regression] arm thumb2 return sequence is
suboptimal, especially at -O2
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywo
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'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116447
Richard Earnshaw changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org,
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116597
Bug ID: 116597
Summary: [arm] indirect tailcalls with incomplete prototypes
generate wrong code when using PACM
Product: gcc
Version: 14.0
Status: UNCONFIRMED
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 (r
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114307
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2024-03-11
Status|UNCONF
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|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114143
--- Comment #5 from Richard Earnshaw ---
(In reply to Richard Earnshaw from comment #4)
> You're going to need --with-multilib=aprofile,rmprofile if you want the full
> set of multilibs. But beware it builds a *lot* of them.
Sorry, I mean --wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114143
--- Comment #4 from Richard Earnshaw ---
You're going to need --with-multilib=aprofile,rmprofile if you want the full
set of multilibs. But beware it builds a *lot* of them.
We don't enable this by default because it conflicts with --with-arch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114143
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2024-02-28
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114136
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114136
Bug ID: 114136
Summary: wrong code for c23 fully anonymous arg lists on arm
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108120
Richard Earnshaw changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108120
Richard Earnshaw changed:
What|Removed |Added
Summary|[11/12/13 Regression] ICE: |[11/12 Regression] ICE: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108120
Richard Earnshaw changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13 Regression] ICE:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107270
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2024-02-22
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113780
Richard Earnshaw changed:
What|Removed |Added
CC||keithp at keithp dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113795
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108933
Richard Earnshaw changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113542
Richard Earnshaw changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #2 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113510
--- Comment #6 from Richard Earnshaw ---
(In reply to Andrew Pinski from comment #5)
> Yes the peephole2 in thumb1.md looks wrong:
> ```
> ;; Reloading and elimination of the frame pointer can
> ;; sometimes cause this optimization to be missed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113542
Richard Earnshaw changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113278
--- Comment #1 from Richard Earnshaw ---
newlib certainly implements fileno():
$ nm libc.a|grep fileno
libc_a-fileno.o:
T fileno
U fileno
libc_a-fileno_u.o:
T fileno_unlocked
U fileno
So perhaps the issue is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113257
--- Comment #4 from Richard Earnshaw ---
I'm not sure. My understanding was that -march=native started by looking up
the CPU ID first and then using the internal mapping of that CPU to the
architecture (which can't work if we don't recognize th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113257
--- Comment #2 from Richard Earnshaw ---
For -mcpu=native, the manual says:
Additionally on native AArch64 GNU/Linux systems the value
@samp{native} tunes performance to the host system. This option has no effect
if the compiler is unable to r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #61 from Richard Earnshaw ---
Then I don't understand what you're trying to say in c57.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #59 from Richard Earnshaw ---
Memcpy must never write beyond the end of the specified buffer, even if reading
it is safe. That wouldn't be thread safe.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #56 from Richard Earnshaw ---
I've never heard of a memcpy implementation that corrupts data if called with
memcpy (p, p, n). (The problems come from partial overlaps where the direction
of the copy may matter).
Has anybody consider
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #28 from Richard Earnshaw ---
(In reply to David Binderman from comment #5)
> No idea. I know the gcc project is over 30 years old and it is not
> feasible for me to download the entire history, it is too large.
>
> I have the last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #27 from Richard Earnshaw ---
> ==9933==by 0x151D554: search_line_fast (lex.cc:872)
This is the entry code; so the issue is with the initial alignment code (unless
the buffer is smaller than 16 bytes, when we might get both unde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #26 from Richard Earnshaw ---
I think it's more likely that this is at the start of the buffer rather than
the end, and related to rounding the address down to a 16-byte alignment. But
it could also occur at the end of the buffer as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #24 from Richard Earnshaw ---
(In reply to David Binderman from comment #22)
> Is the optimization still worthwhile some 12 years later ?
Almost certainly. Vector operations have become much better than they were at
the time the pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #21 from Richard Earnshaw ---
FTR it was this patch that added this code. So 2012!
commit e75b54a2d932929a9b2e940c5aad1ef33a86c008
Author: Richard Earnshaw
Date: Thu Mar 22 17:54:55 2012 +
* lex.c (search_line_fast): Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
Richard Earnshaw changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113030
--- Comment #4 from Richard Earnshaw ---
Yes, that looks sensible. Can you post it please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112334
--- Comment #1 from Richard Earnshaw ---
This might be a side issue, but:
@defbuiltin{{void} __builtin_return (void *@var{result})}
This built-in function returns the value described by @var{result} from
the containing function. You should spe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109166
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111096
--- Comment #8 from Richard Earnshaw ---
(In reply to Thomas Koenig from comment #7)
> Would it make sense to document this somewhere? Or did I just miss it? :-)
Possibly, but I've no idea where. It's too target-specific to put under the
gene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97807
--- Comment #4 from Richard Earnshaw ---
I can reproduce this, but only with -mfloat-abi=soft.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111096
--- Comment #6 from Richard Earnshaw ---
For completeness.
The AArch64 ABI lists 4 alternatives with respect to having a frame chain. When
-fomit-frame-pointer is used, GCC implements this one:
- It may require the frame pointer to address a v
1 - 100 of 353 matches
Mail list logo
