https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66120
--- Comment #4 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
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 rearnsha at gcc dot gnu.org ---
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 rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Target||arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Component|target |rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65902
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65902
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Target||arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55701
Richard Earnshaw rearnsha at gcc dot gnu.org 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 rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64953
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
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
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 derived from 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64783
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64774
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Target||arm
not work propertly and all gtk applications does not
correctly handle input and xfce4-desktop shows icons with wrong coordinates
After rebuilding dosfstools and libX11 problem was solved
--- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
-mstructure-size-boundary (with size != 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63829
--- Comment #6 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63808
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64416
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Keywords||EH
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/bugzilla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64537
--- Comment #4 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64542
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64542
--- Comment #4 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
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=64149
--- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64224
--- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
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 rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63663
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63949
--- Comment #3 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63929
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63749
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63762
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
CC||doko
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63874
--- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63808
--- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
What CPU are you running this on?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63808
--- Comment #3 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63771
--- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
--with-as=/home/slug/optware/cs08q1armel/toolchain/arm-2008q1/bin/arm-none-linux-gnueabi-as
9828c9828
return \.word\\t0xe7f000f0\;
---
return \.inst\\t0xe7f000f0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63742
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59593
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
CC
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 -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63735
--- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
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 rearnsha at gcc dot gnu.org ---
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 rearnsha at gcc dot gnu.org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63735
--- Comment #6 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
Confirmed that the compilation time regression is related entirely to the extra
code generated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63521
--- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63408
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63359
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63359
--- Comment #5 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63359
--- Comment #8 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63234
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63234
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62211
--- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
-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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62014
--- Comment #12 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
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=61712
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61544
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771
--- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
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 rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.10.0
)
continue;
/* Get the register with which we are comparing. */
= pat = PATTERN (insn);
op0 = XEXP (XEXP (SET_SRC (pat), 0), 0);
pat is NULL.
--- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
*** Bug 61695 has been marked as a duplicate of this bug. ***
. */
if (INSN_CODE (insn) != CODE_FOR_cbranchsi4_insn)
continue;
/* Get the register with which we are comparing. */
= pat = PATTERN (insn);
op0 = XEXP (XEXP (SET_SRC (pat), 0), 0);
pat is NULL.
--- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61694
--- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
*** Bug 61696 has been marked as a duplicate of this bug. ***
. */
if (INSN_CODE (insn) != CODE_FOR_cbranchsi4_insn)
continue;
/* Get the register with which we are comparing. */
= pat = PATTERN (insn);
op0 = XEXP (XEXP (SET_SRC (pat), 0), 0);
pat is NULL.
--- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org
. */
if (INSN_CODE (insn) != CODE_FOR_cbranchsi4_insn)
continue;
/* Get the register with which we are comparing. */
= pat = PATTERN (insn);
op0 = XEXP (XEXP (SET_SRC (pat), 0), 0);
pat is NULL.
--- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
Dup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61694
--- Comment #3 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
*** Bug 61697 has been marked as a duplicate of this bug. ***
. */
if (INSN_CODE (insn) != CODE_FOR_cbranchsi4_insn)
continue;
/* Get the register with which we are comparing. */
= pat = PATTERN (insn);
op0 = XEXP (XEXP (SET_SRC (pat), 0), 0);
pat is NULL.
--- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
Dup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61694
--- Comment #5 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
*** 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 rearnsha at gcc dot gnu.org ---
*** Bug 61700 has been marked as a duplicate of this bug. ***
. */
if (INSN_CODE (insn) != CODE_FOR_cbranchsi4_insn)
continue;
/* Get the register with which we are comparing. */
= pat = PATTERN (insn);
op0 = XEXP (XEXP (SET_SRC (pat), 0), 0);
pat is NULL.
--- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
Dup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61694
--- Comment #7 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
*** Bug 61701 has been marked as a duplicate of this bug. ***
. */
if (INSN_CODE (insn) != CODE_FOR_cbranchsi4_insn)
continue;
/* Get the register with which we are comparing. */
= pat = PATTERN (insn);
op0 = XEXP (XEXP (SET_SRC (pat), 0), 0);
pat is NULL.
--- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
Dup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61694
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61712
--- Comment #17 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
*** 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 rearnsha at gcc dot gnu.org ---
*** Bug 61698 has been marked as a duplicate of this bug. ***
. */
if (INSN_CODE (insn) != CODE_FOR_cbranchsi4_insn)
continue;
/* Get the register with which we are comparing. */
= pat = PATTERN (insn);
op0 = XEXP (XEXP (SET_SRC (pat), 0), 0);
pat is NULL.
--- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
Dup
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61714
--- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
Author: rearnsha
Date: Fri Jul 4 10:51:56 2014
New Revision: 212295
URL: https://gcc.gnu.org/viewcvs?rev=212295root=gccview=rev
Log:
PR target/61714
* aarch64.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58692
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61208
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.8.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61208
--- Comment #5 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
Author: rearnsha
Date: Thu May 22 15:38:51 2014
New Revision: 210812
URL: http://gcc.gnu.org/viewcvs?rev=210812root=gccview=rev
Log:
PR target/61208
* arm.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61208
--- Comment #6 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
Author: rearnsha
Date: Thu May 22 15:39:46 2014
New Revision: 210813
URL: http://gcc.gnu.org/viewcvs?rev=210813root=gccview=rev
Log:
PR target/61208
* arm.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61208
--- Comment #7 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
Author: rearnsha
Date: Thu May 22 15:54:28 2014
New Revision: 210814
URL: http://gcc.gnu.org/viewcvs?rev=210814root=gccview=rev
Log:
PR target/61208
* arm.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61208
--- Comment #8 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
Author: rearnsha
Date: Thu May 22 15:56:34 2014
New Revision: 210816
URL: http://gcc.gnu.org/viewcvs?rev=210816root=gccview=rev
Log:
PR target/61208
* arm.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61208
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61223
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61208
--- Comment #4 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
Patch pending review:
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01638.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61208
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
Host: x86_64-linux
Target: arm-eabi
Compile the following with: -O2
typedef union
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
This is with r210212.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
CC||rguenth
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #4 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
Starts with r210113, ie the wide-int merge. Though that may just expose the
latent problem.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61062
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61062
--- Comment #4 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
Looks to me as though this is probably a 4.8 and later regression. Prior to
that we had arm-specific builtins to deal with vzip and friends.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60606
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60464
--- Comment #8 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59308
--- Comment #4 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
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=60133
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
CC||aoliva
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60010
--- Comment #4 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
Author: rearnsha
Date: Fri Feb 14 14:14:03 2014
New Revision: 207785
URL: http://gcc.gnu.org/viewcvs?rev=207785root=gccview=rev
Log:
PR pch/60010
2014-02-14 Kyle McMartin k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60109
--- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58622
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59896
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59857
--- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
My suspicion is that ulv is short-hand for unsigned long volatile -- since
without it this testcase is completely degenerate: val isn't used at all, so
when ulv is not volatile
901 - 1000 of 1283 matches
Mail list logo
