http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60109
--- Comment #1 from Richard Earnshaw ---
This is an unresolvable problem.
If we made __builtin_frame_address(N > 0) always return 0, then some useful use
cases for debugging would be excluded.
On the other hand, it is impossible to know whether
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60010
--- Comment #4 from Richard Earnshaw ---
Author: rearnsha
Date: Fri Feb 14 14:14:03 2014
New Revision: 207785
URL: http://gcc.gnu.org/viewcvs?rev=207785&root=gcc&view=rev
Log:
PR pch/60010
2014-02-14 Kyle McMartin
* config/host-linux.c (T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60133
Richard Earnshaw changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59308
--- Comment #4 from Richard Earnshaw ---
It's not as simple as updating the target selector. LONSC_P depends on
BRANCH_COST, which can vary depending on the specific micro-architecture for
the target system.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60464
--- Comment #8 from Richard Earnshaw ---
(In reply to Jeremy Cooper from comment #7)
> Is there a reason these were commented out? Is the armv7 multilib unstable?
Volume of variants that have to be compiled at build time. Each enabled entry
pra
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=67624
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67624
--- Comment #3 from Richard Earnshaw ---
Author: rearnsha
Date: Thu Sep 24 09:40:06 2015
New Revision: 228082
URL: https://gcc.gnu.org/viewcvs?rev=228082&root=gcc&view=rev
Log:
ARM: fp16 Fix PR 67624 - Incorrect conversion of float Infinity to _
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67624
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68099
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68178
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68178
--- Comment #5 from Richard Earnshaw ---
This particular case is a very specific situation.
A definition of foo is guaranteed to exist (you've provided one); but it can be
overridden.
The definition (due to the use of hidden) has to exist in th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68178
--- Comment #6 from Richard Earnshaw ---
Oh, and another point; since this is a function symbol, not a data symbol, it
can't be subject to a copy relocation at run time, so even protected symbols
should be acceptable here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68178
Richard Earnshaw changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
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=64542
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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.
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=63808
Richard Earnshaw changed:
What|Removed |Added
Priority|P3 |P4
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=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=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=64774
Richard Earnshaw changed:
What|Removed |Added
Target||arm
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64783
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64953
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64953
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
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=55701
Richard Earnshaw changed:
What|Removed |Added
Target Milestone|--- |5.0
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
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=63735
--- Comment #2 from Richard Earnshaw ---
I'll try, but with build breakage as well, it may not prove very much.
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 #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 #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=63742
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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=63808
--- Comment #1 from Richard Earnshaw ---
What CPU are you running this on?
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=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=63929
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=63762
Richard Earnshaw changed:
What|Removed |Added
CC||doko at gcc dot gnu.org
--- Comment #
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=63663
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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=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
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=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.
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=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
--- 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=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=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=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=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=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=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=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=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=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
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
--- 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=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=61561
Richard Earnshaw changed:
What|Removed |Added
Target Milestone|--- |4.10.0
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=61712
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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=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=63234
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
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=63304
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=63359
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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
--- 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=63408
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64818
Richard Earnshaw changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68854
--- Comment #1 from Richard Earnshaw ---
ANSI is a dialect of C. Why are you passing that flag to an assembler file?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68934
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68674
Richard Earnshaw changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69004
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69004
--- Comment #8 from Richard Earnshaw ---
(In reply to PeteVine from comment #7)
> I think I erroneously attached the preprocessed source from the profile-use
> stage; you wanted from profile-generate, right?
We need the one from the phase where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69004
--- Comment #10 from Richard Earnshaw ---
(In reply to PeteVine from comment #4)
> The above error (using -mcpu=cortex-a5 -ffast-math) is a little different
> from this one (after taking those two flags out, leaving just -O3
> -fomit-frame-pointe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69004
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #12 from Richard Earn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68793
Richard Earnshaw changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67797
Richard Earnshaw changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69119
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69119
--- Comment #6 from Richard Earnshaw ---
(In reply to PeteVine from comment #5)
> Wait, what about #1?
Sorry, I hadn't spotted that there were two issues in the one report. Please
create separate bug reports for each issue - it's much easier to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69135
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69124
--- Comment #4 from Richard Earnshaw ---
Does -fno-strict-aliasing help?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69082
--- Comment #7 from Richard Earnshaw ---
Ah! And the maximum range of offset for these relocations in REL format is
-32768,+32767.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69082
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #9 from Richard Earns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69082
Richard Earnshaw changed:
What|Removed |Added
CC||renlin at gcc dot gnu.org
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69248
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
801 - 900 of 1354 matches
Mail list logo
