http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51423
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51442
--- Comment #3 from Richard Earnshaw 2011-12-07
10:55:17 UTC ---
(In reply to comment #2)
> Created attachment 26010 [details]
> Only use BLKmode for volatile accesses which are not naturally aligned.
>
> Per Julian Brown's original email at
> h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51456
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51534
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51568
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51568
--- Comment #2 from Richard Earnshaw 2011-12-15
17:27:19 UTC ---
(In reply to comment #1)
> On linux sizeof (struct rec) is 7, so how do you expect an unsigned (size = 4)
> to hold the entire value?
>
> If you want a packed enum, you need to spe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643
--- Comment #8 from Richard Earnshaw 2011-12-22
14:13:16 UTC ---
Author: rearnsha
Date: Thu Dec 22 14:13:09 2011
New Revision: 182621
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182621
Log:
PR target/51643
* arm.c (arm_function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643
--- Comment #9 from Richard Earnshaw 2011-12-22
14:28:45 UTC ---
Author: rearnsha
Date: Thu Dec 22 14:28:39 2011
New Revision: 182622
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182622
Log:
PR target/51643
* arm.c (arm_function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643
Richard Earnshaw changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Version|4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643
--- Comment #11 from Richard Earnshaw 2011-12-22
17:31:58 UTC ---
Author: rearnsha
Date: Thu Dec 22 17:31:50 2011
New Revision: 182628
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182628
Log:
PR target/51643
* arm.c (arm_functio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643
--- Comment #12 from Richard Earnshaw 2011-12-22
17:33:04 UTC ---
Author: rearnsha
Date: Thu Dec 22 17:32:58 2011
New Revision: 182629
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182629
Log:
PR target/51643
* arm.c (arm_functio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643
--- Comment #14 from Richard Earnshaw 2011-12-22
23:27:29 UTC ---
Because the ABI says it only works for bare metal.
On a system with shared libraries, you can't tell at static link time if a weak
symbol will be resolved by a shared library, so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308
--- Comment #17 from Richard Earnshaw 2012-01-06
16:02:49 UTC ---
I think it would be better to just generate a single insn early on and then to
split it once the loop optimizers have had a chance to run. Then the
optimizers should be able to th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51835
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
at gcc dot gnu.org|rearnsha at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37369
--- Comment #3 from Richard Earnshaw ---
Author: rearnsha
Date: Tue Dec 11 11:26:15 2018
New Revision: 267019
URL: https://gcc.gnu.org/viewcvs?rev=267019&root=gcc&view=rev
Log:
[aarch64] PR target/87369 Prefer bsl/bit/bif for copysign
The copys
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87369
--- Comment #2 from Richard Earnshaw ---
Author: rearnsha
Date: Tue Dec 11 11:26:15 2018
New Revision: 267019
URL: https://gcc.gnu.org/viewcvs?rev=267019&root=gcc&view=rev
Log:
[aarch64] PR target/87369 Prefer bsl/bit/bif for copysign
The copys
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87369
Richard Earnshaw changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87334
Richard Earnshaw changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86264
--- Comment #2 from Richard Earnshaw ---
libffi is an upstream project, so they can remove support for older
architectures on their own timescales.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86264
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
Richard Earnshaw changed:
What|Removed |Added
Keywords||wrong-code
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
--- Comment #4 from Richard Earnshaw ---
Simpler test-case.
struct x
{
long long a : 61;
};
void bar (int, struct x);
int foo (int a, int b, int c, struct x d)
{
bar (a, d);
return 2;
}
This does not seem to generate ldrd, but does show
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
--- Comment #5 from Richard Earnshaw ---
Tentative patch posted here.
https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01231.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88544
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88544
--- Comment #4 from Richard Earnshaw ---
One of these traces says 'illegal instruction' the other 'segmentation fault';
so *if* they are compiler bugs, then they are not the same.
However, this smells more like a system problem than a compiler p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43944
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41482
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44557
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45727
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54398
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56115
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56116
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57911
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58490
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65325
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68100
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68494
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #4 from Richard Earns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70030
--- Comment #9 from Richard Earnshaw ---
Did the need for this patch go away?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70223
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77662
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78233
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78932
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79784
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82034
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82162
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82258
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85396
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15482
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86891
--- Comment #2 from Richard Earnshaw ---
The abort goes away after r266897. It might have just gone latent, however.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86891
--- Comment #4 from Richard Earnshaw ---
Yes, the extension should be zero-extend, not sign extend. The plus operation
is correct, however, since decrementing the first operand could lead to
underflow if it was zero. So the correct rtl would be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86891
Richard Earnshaw changed:
What|Removed |Added
Assignee|wilco at gcc dot gnu.org |rearnsha at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86891
--- Comment #8 from Richard Earnshaw ---
Author: rearnsha
Date: Mon Jan 7 14:49:00 2019
New Revision: 267650
URL: https://gcc.gnu.org/viewcvs?rev=267650&root=gcc&view=rev
Log:
Investigating PR target/86891 revealed a number of issues with the w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86891
Richard Earnshaw changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #2 from Richard Earnshaw ---
> _23 = BIT_FIELD_REF <_2, 16, 0>;// WRONG: should be _2, 14, 0
_2 is declared as a 30-bit integer, so perhaps the statement is right, but
expand needs to understand that the shift extract o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #4 from Richard Earnshaw ---
manual inspection of the output from gcc-5.4.0 suggests this version produces
correct code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #5 from Richard Earnshaw ---
Also on Arm and probably other big-endian machines as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88799
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86891
--- Comment #11 from Richard Earnshaw ---
Author: rearnsha
Date: Wed Jan 16 15:18:05 2019
New Revision: 267971
URL: https://gcc.gnu.org/viewcvs?rev=267971&root=gcc&view=rev
Log:
__builtin__overflow issues on AArch64 (redux)
Further investigatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86891
--- Comment #12 from Richard Earnshaw ---
Author: rearnsha
Date: Wed Jan 16 15:22:08 2019
New Revision: 267972
URL: https://gcc.gnu.org/viewcvs?rev=267972&root=gcc&view=rev
Log:
__builtin__overflow issues on AArch64 (redux) (cont)
And the Chang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88799
--- Comment #2 from Richard Earnshaw ---
Author: rearnsha
Date: Fri Jan 18 11:49:56 2019
New Revision: 268072
URL: https://gcc.gnu.org/viewcvs?rev=268072&root=gcc&view=rev
Log:
PR target/88799 Add +mp and +sec extensions to ARMv7-a
Most armv7-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88799
--- Comment #3 from Richard Earnshaw ---
Author: rearnsha
Date: Fri Jan 18 13:25:37 2019
New Revision: 268077
URL: https://gcc.gnu.org/viewcvs?rev=268077&root=gcc&view=rev
Log:
[arm] PR target/88799 Add +mp and +sec extensions to ARMv7-a (gcc-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88799
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
--- Comment #6 from Richard Earnshaw ---
Author: rearnsha
Date: Tue Jan 22 14:03:22 2019
New Revision: 268151
URL: https://gcc.gnu.org/viewcvs?rev=268151&root=gcc&view=rev
Log:
[arm] PR target/88469 fix incorrect argument passing with 64-bit bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
Richard Earnshaw changed:
What|Removed |Added
Summary|[7/8/9 regression] AAPCS - |[7/8 regression] AAPCS -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
--- Comment #8 from Richard Earnshaw ---
Author: rearnsha
Date: Tue Jan 22 17:56:02 2019
New Revision: 268160
URL: https://gcc.gnu.org/viewcvs?rev=268160&root=gcc&view=rev
Log:
[arm] Further fixes for PR88469
A bitfield that is exactly the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #24 from Richard Earnshaw ---
(In reply to Steve Ellcey from comment #21)
> Successfully matched this instruction:
> (set (zero_extract:SI (reg/i:SI 0 x0)
> (const_int 8 [0x8])
> (const_int 12 [0xc]))
> (zero_exten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #26 from Richard Earnshaw ---
(In reply to Jakub Jelinek from comment #25)
> We have BIT_INSERT_EXPR on GIMPLE, which in the end is a quarternary
> operation previous value, value to insert, bit position and bit size (the
> last one i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #28 from Richard Earnshaw ---
Yes, it's always possible to write patterns for this, but as you point out, we
end up with many variants: insert in bottom (no left shift), insert in top
(left shift then doesn't need an additional AND ma
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
/* ./cc1 testcase.c */
struct s
{
__int128 y : 65;
};
typedef struct s T;
T a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
--- Comment #9 from Richard Earnshaw ---
Author: rearnsha
Date: Thu Jan 24 16:06:34 2019
New Revision: 268240
URL: https://gcc.gnu.org/viewcvs?rev=268240&root=gcc&view=rev
Log:
Mitigation for PR target/88469 on arm-based systems bootstrapping wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
--- Comment #10 from Richard Earnshaw ---
Author: rearnsha
Date: Thu Jan 24 16:10:06 2019
New Revision: 268241
URL: https://gcc.gnu.org/viewcvs?rev=268241&root=gcc&view=rev
Log:
Mitigation for PR target/88469 on arm-based systems bootstrapping w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
--- Comment #11 from Richard Earnshaw ---
Author: rearnsha
Date: Fri Jan 25 17:09:33 2019
New Revision: 268273
URL: https://gcc.gnu.org/viewcvs?rev=268273&root=gcc&view=rev
Log:
This is pretty unlikely in real code, but similar to Arm, the AArch
|unassigned at gcc dot gnu.org |rearnsha at gcc dot
gnu.org
--- Comment #4 from Richard Earnshaw ---
Mine. There are other cases where the precedence is wrong as well. Working on
a patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85658
--- Comment #5 from Richard Earnshaw ---
Author: rearnsha
Date: Tue May 8 10:21:34 2018
New Revision: 260032
URL: https://gcc.gnu.org/viewcvs?rev=260032&root=gcc&view=rev
Log:
[arm] PR target/85658 Fix operator precedence errors in parsecpu.awk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85658
--- Comment #6 from Richard Earnshaw ---
Author: rearnsha
Date: Tue May 8 10:33:33 2018
New Revision: 260034
URL: https://gcc.gnu.org/viewcvs?rev=260034&root=gcc&view=rev
Log:
[arm] PR target/85658 Fix operator precedence errors in parsecpu.awk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85658
Richard Earnshaw changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85616
Richard Earnshaw changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #7 from Richard E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85606
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85606
--- Comment #2 from Richard Earnshaw ---
Author: rearnsha
Date: Fri May 11 09:28:10 2018
New Revision: 260157
URL: https://gcc.gnu.org/viewcvs?rev=260157&root=gcc&view=rev
Log:
[arm] PR target/85606 prefer armv6s-m for armv6-m parts
When Arm in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85606
--- Comment #3 from Richard Earnshaw ---
Author: rearnsha
Date: Fri May 11 09:30:49 2018
New Revision: 260158
URL: https://gcc.gnu.org/viewcvs?rev=260158&root=gcc&view=rev
Log:
[arm] PR target/85606 prefer armv6s-m for armv6-m parts
When Arm in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85606
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85733
Richard Earnshaw changed:
What|Removed |Added
Keywords|documentation |
--- Comment #2 from Richard Earnshaw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85733
--- Comment #3 from Richard Earnshaw ---
Author: rearnsha
Date: Fri May 11 13:29:41 2018
New Revision: 260162
URL: https://gcc.gnu.org/viewcvs?rev=260162&root=gcc&view=rev
Log:
[arm] PR target/85733 Restore be8 linking behaviour for ARMv6-M and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85733
--- Comment #4 from Richard Earnshaw ---
Author: rearnsha
Date: Fri May 11 13:30:55 2018
New Revision: 260163
URL: https://gcc.gnu.org/viewcvs?rev=260163&root=gcc&view=rev
Log:
[arm] PR target/85733 Restore be8 linking behaviour for ARMv6-M and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85733
Richard Earnshaw changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85801
--- Comment #5 from Richard Earnshaw ---
> ld: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `progname' which may
> bind externally can not be used when making a shared object; recompile with
> -fPIC
So this is the start of the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85801
--- Comment #7 from Richard Earnshaw ---
(In reply to rguent...@suse.de from comment #6)
> Can't we decide that per symbol? Or somehow force the dynamic linker to use
> the program symbol?
At what point? We've no idea during compilation which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85801
--- Comment #9 from Richard Earnshaw ---
(In reply to rguent...@suse.de from comment #8)
>
> Sure. So I'd say common symbols that are exported may not be in an anchor
> group?
In the shared library this isn't a common symbol: it has an initia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86003
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86003
--- Comment #2 from Richard Earnshaw ---
Author: rearnsha
Date: Mon Jun 4 08:41:45 2018
New Revision: 261140
URL: https://gcc.gnu.org/viewcvs?rev=261140&root=gcc&view=rev
Log:
[arm] PR target/86003 build failures with --with-cpu=xscale
The XSc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86003
--- Comment #3 from Richard Earnshaw ---
Author: rearnsha
Date: Mon Jun 4 08:46:04 2018
New Revision: 261141
URL: https://gcc.gnu.org/viewcvs?rev=261141&root=gcc&view=rev
Log:
[arm] PR target/86003 build failures with --with-cpu=xscale
The XSc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86003
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209
--- Comment #9 from Richard Earnshaw ---
(In reply to ktkachov from comment #7)
> The other thing to consider with merging loads is how the result is used.
> In your example if you merge the 16-bit loads into a single 32-bit register
> load you'l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209
--- Comment #11 from Richard Earnshaw ---
(In reply to sameerad from comment #10)
> > subus:
> >ldr w0, [w0]
> >add w0, w0, w0, lsr #16
> >uxth w0, w0
> >ret
>
> This is interesting way in which load store combining can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91163
--- Comment #6 from Richard Earnshaw ---
Sounds like a dup of PR93069
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91163
--- Comment #7 from Richard Earnshaw ---
Suggest you run the application under "strace -f" to try to identify what is
being duplicated.
301 - 400 of 1336 matches
Mail list logo
