https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67624
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67415
--- Comment #5 from Richard Earnshaw ---
Your GCC-4.9 is a Linaro build which contains some extensions of their own.
It's possible that they've made some changes in the way search paths work. I'd
start by asking them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67415
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67383
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366
--- Comment #9 from Richard Earnshaw ---
Does that really do the right thing? That is, does force_reg understand a
misaligned memory op?
Also, what if one memory operand is aligned, but the other not? Don't we want
to have the right combinatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366
--- Comment #2 from Richard Earnshaw ---
(In reply to Richard Biener from comment #1)
> I think this boils down to the fact that memcpy expansion is done too late
> and
> that (with more recent GCC) the "inlining" done on the GIMPLE level is
> re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917
Richard Earnshaw changed:
What|Removed |Added
Component|target |tree-optimization
--- Comment #12 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66912
--- Comment #1 from Richard Earnshaw ---
Erm, isn't that the whole point of marking the symbol 'protected'?
>From the ELF spec:
STV_PROTECTED
A symbol defined in the current component is protected if it is visible in
other components but n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66599
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66547
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #13 from Richard Earn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66198
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66198
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #6 from Richard E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66090
Richard Earnshaw changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66120
--- Comment #4 from Richard Earnshaw ---
Mul doesn't produce useful overflow bits when the flags are set. We could do
negv3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66120
--- Comment #3 from Richard Earnshaw ---
That's what I meant. Still can't find any info on them in md.texi, though!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66081
Richard Earnshaw changed:
What|Removed |Added
Target||arm
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66120
Richard Earnshaw changed:
What|Removed |Added
Target|arm*-*gnueabi |arm
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932
Richard Earnshaw changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65902
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65902
Richard Earnshaw changed:
What|Removed |Added
Target||arm-eabi
--- Comment #2 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55701
Richard Earnshaw changed:
What|Removed |Added
Target Milestone|--- |5.0
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
Target: x86_64, arm
The following code fragment, when compiled at -O3 is quite reasonably optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64953
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64953
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
Priority: P3
Component: target
Assignee: pinskia at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
CC: pinskia at gcc dot gnu.org
According to https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02118.html the
thunderX processors should not default to crypto
IRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
A comment in gcov-io.h reads:
" Although the ident and version are formally 32 bit numbers, they
are deri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64783
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64774
Richard Earnshaw changed:
What|Removed |Added
Target||arm
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64789
Bug ID: 64789
Summary: gcc generates unreliable code on arm with
-mstructure-size-boundary=32
Product: gcc
Version: 4.8.3
Status: RESOLVED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63829
--- Comment #6 from Richard Earnshaw ---
arm linux code should always be using the _S_atomic sequences. When the
processor doesn't have the required instructions, kernel helper routines will
be used. This ensures that code is forwards compatibl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64416
Richard Earnshaw changed:
What|Removed |Added
Keywords||EH
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63808
Richard Earnshaw changed:
What|Removed |Added
Priority|P3 |P4
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
CC: dehao at gcc dot gnu.org
Target: x86_64-linux-gnu
Created attachment 34446
--> https://gcc.gnu.org/bugzi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64542
--- Comment #4 from Richard Earnshaw ---
Note that armv6-m doesn't support ARM instructions at all, so the .arm
directive is meaningless.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64542
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64537
--- Comment #4 from Richard Earnshaw ---
b is used twice, once shifted left by 3 and once directly.
We could write this as
subsx3, x0, x1, sxth 3
beq .L5
add w0, w2, w1, sxth <= Now extended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64149
--- Comment #2 from Richard Earnshaw ---
Sounds sensible to me.
We switched to LRA quite late in gcc-4.9, so keeping a way to switch back in
case of problems was pragmatic. But we've been running with the new code now
for a year and not encou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64224
--- Comment #2 from Richard Earnshaw ---
Might be better to just deprecate -mapcs; it's a feature of the old ABI anyway,
so there's not much point in trying to make it fully conform to the latest
specs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63663
Richard Earnshaw changed:
What|Removed |Added
Target Milestone|--- |5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63663
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63949
--- Comment #3 from Richard Earnshaw ---
make_extraction is unable to generate bit-field extractions in more than one
mode. This causes the extractions that it does generate to be wrapped in
subregs when SImode results are wanted.
Ideally, we s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63762
Richard Earnshaw changed:
What|Removed |Added
CC||doko at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63749
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63929
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63874
--- Comment #1 from Richard Earnshaw ---
Sounds like this might be confusion between weak definitions and weak
references. If we have a weak reference to the object, we cannot convert it
into a pc-relative expression, since that would mean we co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63808
--- Comment #3 from Richard Earnshaw ---
(In reply to Sergey Belyashov from comment #2)
> Target is armv4: I use gcc options: -marm -march=armv4
Which doesn't really answer my question. Which *CPU* are you seeing this on?
My reading of the Arc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63808
--- Comment #1 from Richard Earnshaw ---
What CPU are you running this on?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63771
--- Comment #1 from Richard Earnshaw ---
> --with-as=/home/slug/optware/cs08q1armel/toolchain/arm-2008q1/bin/arm-none-linux-gnueabi-as
>
> 9828c9828
> < return \".word\\t0xe7f000f0\";
> ---
> > return \".inst\\t0xe7f000f0\";
> 9830c9830
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59593
Richard Earnshaw changed:
What|Removed |Added
CC||fei.yang0953 at gmail dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63742
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63735
--- Comment #6 from Richard Earnshaw ---
Confirmed that the compilation time regression is related entirely to the extra
code generated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63735
--- Comment #5 from Richard Earnshaw ---
Yeah, all the changes are in the linux kernel module. It's only one component
of the benchmark (though probably the largest).
Adding -fgnu89-inline is also sufficient to fix the code size regression.
In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63735
--- Comment #3 from Richard Earnshaw ---
regression is caused by the switch to GNU11. Adding -std=gnu90 gives expected
numbers.
That's a pretty big penalty for using GNU11 coding!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63735
--- Comment #2 from Richard Earnshaw ---
I'll try, but with build breakage as well, it may not prove very much.
mal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
Target: arm aarch64
Since 2014/10/13 there have been a number of commits that have contributed to a
significant overall code-size regression at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63521
--- Comment #2 from Richard Earnshaw ---
Ideally, a port should not need to define reg_alloc_order; it's rather a blunt
instrument.
Better would be for the register allocator to have a better understanding of
which registers are being used for p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63408
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63359
--- Comment #8 from Richard Earnshaw ---
(In reply to James Molloy from comment #6)
> Good example, although I might argue slightly pathological.
>
Agreed, this is somewhat pathological, but I only need to find one valid
counter-example :-)
Fu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63359
--- Comment #5 from Richard Earnshaw ---
So consider:
int f(int i){
long x;
asm("lsl %0, %1, 33" : "=r"(x) : "r"(i)); // lshift by more than sizeof(int)
return x;
}
We really don't care about the top bits in i, so we don't want to extend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63359
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304
Richard Earnshaw changed:
What|Removed |Added
Priority|P3 |P5
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63234
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63234
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62211
--- Comment #1 from Richard Earnshaw ---
-m{soft,hard}-float for arm should be considered deprecated (we try to support
them by mapping them onto the -mfloat-abi option), and deliberately no-longer
document them.
Rather than clarifying what th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62014
--- Comment #12 from Richard Earnshaw ---
aarch64_conditional_register_usage() marks all FP registers as unavailable if
!TARGET_FLOAT. So the real question is why this isn't sufficient to disable
use of FP registers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61544
Richard Earnshaw changed:
What|Removed |Added
CC||manjian2006 at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61712
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771
--- Comment #1 from Richard Earnshaw ---
The ABI does not document a model for stack chains, so any use of a frame
pointer is, by definition, purely private to that function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61561
Richard Earnshaw changed:
What|Removed |Added
Target Milestone|--- |4.10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61694
--- Comment #4 from Richard Earnshaw ---
*** Bug 61698 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61712
--- Comment #17 from Richard Earnshaw ---
*** Bug 61694 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61694
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61694
--- Comment #7 from Richard Earnshaw ---
*** Bug 61701 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61700
Bug ID: 61700
Summary: thumb1_reorg crashes
Product: gcc
Version: 4.9.0
Status: RESOLVED
Severity: normal
Priority: P3
Component: rtl-optimization
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61701
Bug ID: 61701
Summary: thumb1_reorg crashes
Product: gcc
Version: 4.9.0
Status: RESOLVED
Severity: normal
Priority: P3
Component: rtl-optimization
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61694
--- Comment #6 from Richard Earnshaw ---
*** Bug 61700 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61694
--- Comment #5 from Richard Earnshaw ---
*** Bug 61699 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61699
Bug ID: 61699
Summary: thumb1_reorg crashes
Product: gcc
Version: 4.9.0
Status: RESOLVED
Severity: normal
Priority: P3
Component: rtl-optimization
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61698
Bug ID: 61698
Summary: thumb1_reorg crashes
Product: gcc
Version: 4.9.0
Status: RESOLVED
Severity: normal
Priority: P3
Component: rtl-optimization
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61694
--- Comment #3 from Richard Earnshaw ---
*** Bug 61697 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61697
Bug ID: 61697
Summary: thumb1_reorg crashes
Product: gcc
Version: 4.9.0
Status: RESOLVED
Severity: normal
Priority: P3
Component: rtl-optimization
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61696
Bug ID: 61696
Summary: thumb1_reorg crashes
Product: gcc
Version: 4.9.0
Status: RESOLVED
Severity: normal
Priority: P3
Component: rtl-optimization
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61694
--- Comment #2 from Richard Earnshaw ---
*** Bug 61696 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61695
Bug ID: 61695
Summary: thumb1_reorg crashes
Product: gcc
Version: 4.9.0
Status: RESOLVED
Severity: normal
Priority: P3
Component: rtl-optimization
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61694
Bug ID: 61694
Summary: thumb1_reorg crashes
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61714
--- Comment #1 from Richard Earnshaw ---
Author: rearnsha
Date: Fri Jul 4 10:51:56 2014
New Revision: 212295
URL: https://gcc.gnu.org/viewcvs?rev=212295&root=gcc&view=rev
Log:
PR target/61714
* aarch64.h (OPTION_DEFAULT_SPECS): Define.
Priority: P3
Component: target
Assignee: rearnsha at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
Target: aarch64
The --with-arch and --with-cpu options on aarch64 are accepted and validated
during configure but have no effect on the compiler. This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58692
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61208
Richard Earnshaw changed:
What|Removed |Added
Target Milestone|--- |4.8.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61208
Richard Earnshaw changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61208
--- Comment #8 from Richard Earnshaw ---
Author: rearnsha
Date: Thu May 22 15:56:34 2014
New Revision: 210816
URL: http://gcc.gnu.org/viewcvs?rev=210816&root=gcc&view=rev
Log:
PR target/61208
* arm.md (arm_cmpdi_unsigned): Fix length cal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61208
--- Comment #7 from Richard Earnshaw ---
Author: rearnsha
Date: Thu May 22 15:54:28 2014
New Revision: 210814
URL: http://gcc.gnu.org/viewcvs?rev=210814&root=gcc&view=rev
Log:
PR target/61208
* arm.md (arm_cmpdi_unsigned): Fix length cal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61208
--- Comment #6 from Richard Earnshaw ---
Author: rearnsha
Date: Thu May 22 15:39:46 2014
New Revision: 210813
URL: http://gcc.gnu.org/viewcvs?rev=210813&root=gcc&view=rev
Log:
PR target/61208
* arm.md (arm_cmpdi_unsigned): Fix length cal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61208
--- Comment #5 from Richard Earnshaw ---
Author: rearnsha
Date: Thu May 22 15:38:51 2014
New Revision: 210812
URL: http://gcc.gnu.org/viewcvs?rev=210812&root=gcc&view=rev
Log:
PR target/61208
* arm.md (arm_cmpdi_unsigned): Fix length cal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61208
--- Comment #4 from Richard Earnshaw ---
Patch pending review:
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01638.html
901 - 1000 of 1300 matches
Mail list logo
