https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90311
Richard Earnshaw changed:
What|Removed |Added
Summary|[9/10 Regression] wrong |[9 Regression] wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90311
--- Comment #10 from Richard Earnshaw ---
Initial commit in the series was r10-3970 but there were certainly follow-ups
after that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90311
--- Comment #11 from Richard Earnshaw ---
Looks like this was fixed with r10-1963. Testing that as a backport.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90311
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91913
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94172
--- Comment #4 from Richard Earnshaw ---
(In reply to Jakub Jelinek from comment #3)
> Can't reproduce on the trunk, neither on x86_64-linux with -Os -g3
> -fshort-enums, nor on arm-linux-gnueabi with -Os -g3 -fshort-enums
> -mcpu=cortex-m0 -mthu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94236
--- Comment #8 from Richard Earnshaw ---
(In reply to Andrew Pinski from comment #6)
> Note for Threos OS, please don't reuse the same target triplet as elf or
> linux; use your own triplet. Also adding long calls is not hard and such.
The corr
|when optimizing for size|when optimizing for size
Assignee|unassigned at gcc dot gnu.org |rearnsha at gcc dot
gnu.org
--- Comment #1 from Richard Earnshaw ---
Mine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94220
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94502
Richard Earnshaw changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #7 from Richard E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93674
Richard Earnshaw changed:
What|Removed |Added
Resolution|FIXED |---
Summary|[8/9/10 Regres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694
--- Comment #5 from Richard Earnshaw ---
(In reply to Richard Biener from comment #2)
> Note in another bug it was said that libgfortran requires a C99 runtime,
> when that's not available you should disable gfortran build. GCC (or
> libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94697
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2020-04-22
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94748
--- Comment #1 from Richard Earnshaw ---
A BTI that's not immediately after a label looks wrong. Either it should be
removed entirely, or it should be merged with the preceding BTI.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94763
Richard Earnshaw changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #5 from Richard Earnshaw ---
This is made more complex due to the fact that the existence of the top 16 D
registers depends on the hardware you have, so saving them might require a d32
variant of the ISA, but we can't (quickly) tell i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #7 from Richard Earnshaw ---
well, __aeabi_memcpy is required not to clobber the FP state. Sadly, GCC does
not know about it...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #10 from Richard Earnshaw ---
(In reply to Christophe Lyon from comment #9)
> > My initial thoughts are along the lines of...
> > Only try to save FP registers that this function directly clobbers.
> What's the point of saving these i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93674
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #12 from Richard Earnshaw ---
(In reply to Christophe Lyon from comment #11)
> (In reply to Richard Earnshaw from comment #10)
> > (In reply to Christophe Lyon from comment #9)
> > > > My initial thoughts are along the lines of...
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #14 from Richard Earnshaw ---
(In reply to Christophe Lyon from comment #13)
> But, in general (non-interrupt) code, what is supposed to happen if you
> compile for a d32 VFP and run on d16 one ? (and the code uses the extra
> regist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95122
--- Comment #4 from Richard Earnshaw ---
Don't use -mhard-float or -msoft-float. Instead, you should be using
-mfloat-abi=[hard|softfp|soft] as appropriate. Also, rather than encoding this
into various sets of flags you should configure the com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94995
Richard Earnshaw changed:
What|Removed |Added
Priority|P3 |P5
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95651
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95676
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96313
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96751
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2020-08-25
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96768
--- Comment #3 from Richard Earnshaw ---
Note that the switch table is in the .rodata section, so that's not a problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96882
Richard Earnshaw changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96882
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #3 from Richard Earns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96882
Richard Earnshaw changed:
What|Removed |Added
Target||arm
--- Comment #4 from Richard Earns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96882
--- Comment #6 from Richard Earnshaw ---
Yes, the problem is related to returning values in memory and the ABI variants
we have. If we have hardware floating-point we generally use registers to
return values; if we don't, then we have to return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96939
--- Comment #5 from Richard Earnshaw ---
I batted my head against this when reworking the command line options stuff a
couple of years back, but the documentation on how the different hooks should
interact (especially for LTO and streaming) is, q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96939
--- Comment #6 from Richard Earnshaw ---
(In reply to Jakub Jelinek from comment #4)
> Doesn't seem to be related to me, in the other PR everything is compiled
> with one set of options and no target attribute is involved either.
No, that's a co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96882
--- Comment #8 from Richard Earnshaw ---
(In reply to emilie.feral from comment #7)
> Hello,
> Any news on the subject?
> Would you advise in the meantime to discard the LTO (with the -fno-lto
> option) on the compilation unit containing the fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89400
--- Comment #8 from Richard Earnshaw ---
Author: rearnsha
Date: Thu Oct 17 16:45:46 2019
New Revision: 277123
URL: https://gcc.gnu.org/viewcvs?rev=277123&root=gcc&view=rev
Log:
[arm] PR target/89400 fix thumb1 unaligned access expansion
Armv6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89400
--- Comment #9 from Richard Earnshaw ---
Author: rearnsha
Date: Thu Oct 17 16:47:42 2019
New Revision: 277124
URL: https://gcc.gnu.org/viewcvs?rev=277124&root=gcc&view=rev
Log:
[arm] PR target/89400 fix thumb1 unaligned access expansion
Armv6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89400
--- Comment #10 from Richard Earnshaw ---
Author: rearnsha
Date: Thu Oct 17 16:48:39 2019
New Revision: 277125
URL: https://gcc.gnu.org/viewcvs?rev=277125&root=gcc&view=rev
Log:
[arm] PR target/89400 fix thumb1 unaligned access expansion
Armv6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89400
Richard Earnshaw changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92172
--- Comment #3 from Richard Earnshaw ---
(In reply to Seth LaForge from comment #2)
> Using R11 in ARM and R7 on Thumb is mandated by the AAPCS I believe. I don't
> think the overhead is likely to be particularly different in Thumb vs ARM.
No i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91927
--- Comment #7 from Richard Earnshaw ---
(In reply to Kamlesh Kumar from comment #6)
> This Fixes it.
>
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index 2e73f3515bb..155f4c45500 100644
> --- a/gcc/config/aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92207
--- Comment #5 from Richard Earnshaw ---
Apart from the addresses used, the traces are identical right up until the
latter version crashes.
The testcase tries to allocate 128Mb+4bytes of memory, so my suspicion is that
this is a test that needs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92207
--- Comment #8 from Richard Earnshaw ---
I'm 95%+ sure that this is a problem with qemu+newlib with the latter not
handling out-of-memory correctly. If I run the good program to the same
instruction that faults in the bad program, I see:
Breakp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92207
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92207
--- Comment #10 from Richard Earnshaw ---
A bit more trace from the gdb session as evidence.
(gdb) p HeapLimit
'HeapLimit' has unknown type; cast it to its declared type
(gdb) p &HeapLimit
$1 = ( *) 0x48f78
(gdb) x/x $1
0x48f78:0x0804a0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92207
--- Comment #11 from Richard Earnshaw ---
BTW, it looks like the libgloss implementation of the syscall API and startup
code has had this change since 2015.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88656
--- Comment #7 from Richard Earnshaw ---
This was fixed on trunk at some point, but not yet been backported.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88656
Bug 88656 depends on bug 88167, which changed state.
Bug 88167 Summary: [7/8/9 regression] [ARM] Function __builtin_return_address
returns invalid address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88167
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88167
Richard Earnshaw changed:
What|Removed |Added
Priority|P3 |P2
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88167
--- Comment #4 from Richard Earnshaw ---
Author: rearnsha
Date: Fri Oct 25 14:34:44 2019
New Revision: 277452
URL: https://gcc.gnu.org/viewcvs?rev=277452&root=gcc&view=rev
Log:
[arm][PR88167] Fix __builtin_return_address returns invalid address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88167
--- Comment #5 from Richard Earnshaw ---
Author: rearnsha
Date: Fri Oct 25 14:37:14 2019
New Revision: 277453
URL: https://gcc.gnu.org/viewcvs?rev=277453&root=gcc&view=rev
Log:
[arm][PR88167] Fix __builtin_return_address returns invalid address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88167
--- Comment #6 from Richard Earnshaw ---
Author: rearnsha
Date: Fri Oct 25 14:39:06 2019
New Revision: 277454
URL: https://gcc.gnu.org/viewcvs?rev=277454&root=gcc&view=rev
Log:
[arm][PR88167] Fix __builtin_return_address returns invalid address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88656
Bug 88656 depends on bug 88167, which changed state.
Bug 88167 Summary: [7/8/9 regression] [ARM] Function __builtin_return_address
returns invalid address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88167
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88167
Richard Earnshaw changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88656
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #63 from Richard Earnshaw ---
We need to reach closure on this, but there's nothing really concrete to make
such a decision. Which of the tests originally reported are still failing?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77882
--- Comment #5 from Richard Earnshaw ---
(In reply to Elad Lahav from comment #4)
> Created attachment 47119 [details]
> Proposed implementation of naked functions for aarch64
>
> The change is quite simple (see the proposed patch). I hope it ca
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
CC: segher at kernel dot crashing.org
Target Milestone: ---
Here are two combine attempts from a simple testcase:
arm
-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
Target Milestone: ---
Given:
t f1(t a, t b) { return a + ~b; }
if t is of type int64_t, then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92281
--- Comment #2 from Richard Earnshaw ---
(In reply to Segher Boessenkool from comment #1)
> (In reply to Richard Earnshaw from comment #0)
>
> > Failed to match this instruction:
> > (set (reg:SI 125 [+4 ])
> > (minus:SI (minus:SI (reg:SI 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92281
--- Comment #3 from Richard Earnshaw ---
As for 'special' regs and their ordering, I'm not sure. I would suggest that
if we have a commutative operation with two registers and one of the registers
is marked as a pointer, then it should appear fi
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
Target Milestone: ---
Consider this testcase which was mentioned in
https://gcc.gnu.org/ml/gcc-help/2019-10/msg00122.html.
#define BB_ADDRESS 0x43fe1800
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294
--- Comment #1 from Richard Earnshaw ---
Things go wrong in the forward-prop 1 pass.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92281
--- Comment #5 from Richard Earnshaw ---
(In reply to Segher Boessenkool from comment #4)
> (In reply to Richard Earnshaw from comment #2)
> > Yes, but since
> > (A - B) - C = A - B - C = A - C - B = (A - C) - B
> > we can clearly swap the ord
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92308
--- Comment #2 from Richard Earnshaw ---
Very few micro-architectures would benefit from auto-inc style addressing in a
sequence like this. With modern super-scaler systems you want to use offset
addressing where possible (from a common base).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92308
--- Comment #4 from Richard Earnshaw ---
So taking the example I posted in the initial report and compiling with trunk
for arm -mcpu=cortex-m4 -mthumb -Os, we get:
ldr r3, .L2
movsr2, #1
str r2, [r3, #2060]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92308
--- Comment #6 from Richard Earnshaw ---
(In reply to rguent...@suse.de from comment #5)
> On Mon, 4 Nov 2019, rearnsha at gcc dot gnu.org wrote:
> I suspect TARGET_LEGITIMIZE_ADDRESS is only applied during
> reload/LRA, correct?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92308
--- Comment #7 from Richard Earnshaw ---
Reload also had a hook TARGET_LEGITIMIZE_RELOAD_ADDRESS as well. But it had
the same problems - lack of context leading to guesswork and therefore too
local or too general fix-ups.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92342
--- Comment #5 from Richard Earnshaw ---
So if the AND-based idiom is now preferred, shouldn't the if-then-else variant
be transformed into it? Similarly for IOR, when we get
(IOR (NEG ()) (reg))
from
(IF_THEN_ELSE ()
(reg)
(const_int -1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92342
--- Comment #6 from Richard Earnshaw ---
(In reply to Richard Earnshaw from comment #5)
> So if the AND-based idiom is now preferred, shouldn't the if-then-else
> variant be transformed into it? Similarly for IOR, when we get
>
> (IOR (NEG ())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92342
--- Comment #9 from Richard Earnshaw ---
(In reply to Segher Boessenkool from comment #7)
> I think the IF_THEN_ELSE version should be canonical, and it should be
> formed in simplify_rtx, not at random spots in combine.
Why? The and/ior varia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314
--- Comment #28 from Richard Earnshaw ---
The last release of gcc-7 has now been made, so it's end-of-life and no further
fixes for it will be made.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92071
--- Comment #5 from Richard Earnshaw ---
(In reply to Jakub Jelinek from comment #4)
> I'd say this should be fixed in the arm backend, instead of asserts it
> should check whether operands are aligned and if not, perform unaligned load
> or stor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37377
--- Comment #17 from Richard Earnshaw ---
last patch was for pr37577.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70786
--- Comment #9 from Richard Earnshaw ---
comment 8 should be for pr70876.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36117
--- Comment #6 from Richard Earnshaw ---
Comment #5 was really for PR36177
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93119
--- Comment #3 from Richard Earnshaw ---
(In reply to Andrew Pinski from comment #2)
> Simplier patch, change PTR to P instead. Mine then.
>
> That is:
> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> index f114f85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93005
--- Comment #6 from Richard Earnshaw ---
(In reply to Joel Holdsworth from comment #5)
> I found that if I make modified versions of the intrinsics in arm_neon.h
> that are designed more along the lines of the x86_64 SSE intrinsics defined
> with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93005
--- Comment #8 from Richard Earnshaw ---
(In reply to Joel Holdsworth from comment #7)
> > Did you test it with big-endian?
>
> Good question. It seems to do the right thing in both cases:
> https://godbolt.org/z/7rDzAm
foo2(long*, __simd128_in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93188
Richard Earnshaw changed:
What|Removed |Added
Target||arm
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93188
--- Comment #2 from Richard Earnshaw ---
Author: rearnsha
Date: Wed Jan 8 09:29:02 2020
New Revision: 279993
URL: https://gcc.gnu.org/viewcvs?rev=279993&root=gcc&view=rev
Log:
arm: Fix rmprofile multilibs when architecture includes +mp or +sec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93188
Richard Earnshaw changed:
What|Removed |Added
Summary|[9/10-regression] a-profile |[9 regression] a-profile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93188
--- Comment #4 from Richard Earnshaw ---
Author: rearnsha
Date: Fri Jan 10 16:50:15 2020
New Revision: 280123
URL: https://gcc.gnu.org/viewcvs?rev=280123&root=gcc&view=rev
Log:
backport: arm: Fix rmprofile multilibs when architecture includes +m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93188
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92071
--- Comment #7 from Richard Earnshaw ---
(In reply to Richard Biener from comment #6)
> Agreed. Did anybody bisect what caused this?
It only came to light when we added a check in the backend. So I'm not sure a
bisect will be that helpful, exc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93341
--- Comment #5 from Richard Earnshaw ---
(In reply to Andrew Pinski from comment #3)
> /* We should be able to reverse all conditions. */
> gcc_assert (inv_cond_code != UNKNOWN);
>
> Obvious this code is broken becau
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93235
Richard Earnshaw changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93548
Richard Earnshaw changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93548
Richard Earnshaw changed:
What|Removed |Added
Status|REOPENED|NEW
--- Comment #7 from Richard Earns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93548
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93548
--- Comment #11 from Richard Earnshaw ---
I don't think so, since the write back will update the timestamp. It would
only rerun it once per make anyway.
Also, the timestamp approach is really designed for files in the build area,
not those in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91913
--- Comment #4 from Richard Earnshaw ---
Main bug fixed with https://gcc.gnu.org/ml/gcc-cvs/2020-02/msg02312.html
Awaiting commit of testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93674
--- Comment #5 from Richard Earnshaw ---
I'm seeing it on AArch64 for master. Adding an enum value with an initializer
of -1 causes the problem to go away. So it looks like the 'unsigned'
conversion is happening too soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #14 from Richard Earnshaw ---
With the simpler test case we see
Breakpoint 1, try_combine (i3=0x764d33c0, i2=0x764d3380, i1=0x0,
i0=0x0, new_direct_jump_p=0x7fffd850,
last_combined_insn=0x764d33c0)
at /h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90378
--- Comment #5 from Richard Earnshaw ---
(In reply to Vladimir Makarov from comment #4)
> > Miscompilation occurs in same configuration: arm-linux-gnueabihf at -O2
> > -flto.
> >
>
> I don't see how these two patches *directly* resulted in misc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90378
--- Comment #6 from Richard Earnshaw ---
(In reply to Richard Earnshaw from comment #5)
> (In reply to Vladimir Makarov from comment #4)
> > > Miscompilation occurs in same configuration: arm-linux-gnueabihf at -O2
> > > -flto.
> > >
> >
> > I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56441
--- Comment #8 from Richard Earnshaw 2013-02-26
17:01:36 UTC ---
Please use an open (non-proprietory) file format for attaching files. I don't
have access to RAR format.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56441
--- Comment #9 from Richard Earnshaw 2013-02-26
17:03:10 UTC ---
(In reply to comment #7)
> I was looking completely wrong, the arm_addsi3 is acting wrong.
>
> The "add%?\\t%0, %1, %2" for "=l,%0,Py" is set at a length of 2.
> (first e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56470
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
1 - 100 of 1297 matches
Mail list logo
