https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052
--- Comment #14 from amker at gcc dot gnu.org ---
Author: amker
Date: Tue Jun 2 10:19:18 2015
New Revision: 224020
URL: https://gcc.gnu.org/viewcvs?rev=224020&root=gcc&view=rev
Log:
PR tree-optimization/48052
* c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173
--- Comment #39 from amker at gcc dot gnu.org ---
Author: amker
Date: Tue Jun 2 03:33:35 2015
New Revision: 224009
URL: https://gcc.gnu.org/viewcvs?rev=224009&root=gcc&view=rev
Log:
PR tree-optimization/52563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52563
--- Comment #9 from amker at gcc dot gnu.org ---
Author: amker
Date: Tue Jun 2 03:33:35 2015
New Revision: 224009
URL: https://gcc.gnu.org/viewcvs?rev=224009&root=gcc&view=rev
Log:
PR tree-optimization/52563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65447
--- Comment #3 from amker at gcc dot gnu.org ---
Author: amker
Date: Wed May 20 05:15:56 2015
New Revision: 223433
URL: https://gcc.gnu.org/viewcvs?rev=223433&root=gcc&view=rev
Log:
PR tree-optimization/65447
* tree-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65767
--- Comment #8 from amker at gcc dot gnu.org ---
Oh, missed messages. Will look into it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65447
--- Comment #2 from amker at gcc dot gnu.org ---
Patch for review at https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00641.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66003
--- Comment #2 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> Hmm, I think IVOPTs should be able to undo this code motion?
It can't. Address of all pointer dereferences except the first one are
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amker at gcc dot gnu.org
Target Milestone: ---
Below simple case is reduced from spec,
typedef struct
{
int x;
int y;
} coord;
extern unsigned short **org;
extern
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amker at gcc dot gnu.org
Target Milestone: ---
Newly introduced test case failed on
arm-none-linux-gnueabi/arm-none-linux-gnueabihf
arm-none-linux-gnueabi GCC was configured
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64835
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65767
--- Comment #4 from amker at gcc dot gnu.org ---
Author: amker
Date: Wed Apr 22 09:37:52 2015
New Revision: 222319
URL: https://gcc.gnu.org/viewcvs?rev=222319&root=gcc&view=rev
Log:
Backport from trunk r55
2015-04-21 B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65767
--- Comment #3 from amker at gcc dot gnu.org ---
Author: amker
Date: Tue Apr 21 02:23:18 2015
New Revision: 55
URL: https://gcc.gnu.org/viewcvs?rev=55&root=gcc&view=rev
Log:
PR testsuite/65767
* g++.dg/lto/pr65276_0.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65767
--- Comment #2 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> Same cause though. See my comment there, can you prepare and verify a patch?
Yeah. Will do that.
Assignee: unassigned at gcc dot gnu.org
Reporter: amker at gcc dot gnu.org
Hi,
The test failed on arm-none-eabi with below error messages
Executing on host: /arm-none-eabi/obj/gcc2/gcc/testsuite/g++8/../../xg++
-B/arm-none-eabi/obj/gcc2/gcc/testsuite/g++8/../../ cp_lto_pr65276_0.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42172
--- Comment #10 from amker at gcc dot gnu.org ---
The optimal code is generated on pre-armv7 processors. The difference starts
from expand. On armv7-processors, zero_extract operator is generated, rather
than logic operation. Seem combiner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42172
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55190
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34010
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amker at gcc dot gnu.org
Hi,
For below case extracted from spec2006 (and even worse in real case), loops
containing a significant number of memory accesses generate very inefficient
code. This is due to iv-opt hitting a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173
--- Comment #38 from amker at gcc dot gnu.org ---
The first patch actually helping this case is at
https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00836.html
But the real problem lies in scev/ivopt about how type conversion and scev
overflow are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64705
amker at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55701
amker at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amker at gcc dot gnu.org
For below example
extern int listXsize[8];
void foo (int len, int list_offset)
{
int list;
if (list_offset < 0)
list_offset = 0;
else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64705
--- Comment #6 from amker at gcc dot gnu.org ---
Since it works on gcc 3.4, so I consider this as a regression and applied the
patch. Should be fixed now.
Hi Vlad, could you please help me verify that the original benchmark is fixed
too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64705
--- Comment #5 from amker at gcc dot gnu.org ---
Author: amker
Date: Fri Feb 13 05:44:46 2015
New Revision: 220676
URL: https://gcc.gnu.org/viewcvs?rev=220676&root=gcc&view=rev
Log:
PR tree-optimization/64705
* tree-ssa-loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43378
amker at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43378
--- Comment #1 from amker at gcc dot gnu.org ---
Author: amker
Date: Tue Feb 10 02:34:41 2015
New Revision: 220563
URL: https://gcc.gnu.org/viewcvs?rev=220563&root=gcc&view=rev
Log:
PR tree-optimization/43378
* gcc.dg/tree-ssa/p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #33 from amker at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #31)
> The test also fails on PowerPC, the 2 IVs are kept by ivopts.
On targets like ARM, the biv(i) is eliminated with biv(p). PowerPC is
different,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #32 from amker at gcc dot gnu.org ---
(In reply to dave.anglin from comment #30)
> On 2015-02-08, at 9:09 AM, amker at gcc dot gnu.org wrote:
>
> > Ah, candidate 5 is considered cheaper according to the cost table.
&g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #29 from amker at gcc dot gnu.org ---
(In reply to amker from comment #28)
> On hppa 32, the two iv uses are:
> use 0
> address
> in statement *p_1 = 0;
>
> at position *p_1
> type int *
> base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #28 from amker at gcc dot gnu.org ---
On hppa 32, the two iv uses are:
use 0
address
in statement *p_1 = 0;
at position *p_1
type int *
base p_7
step 4
base object (void *) p_7
related candidates
use 1
compare
in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #20 from amker at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #19)
> > The assembly is as below on sparc64:
> > f1:
> > .register %g2, #scratch
> > sllx%o1, 2, %g1
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #18 from amker at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #16)
> > The cost of expression "p + ((sizetype)(99 - i_6(D)) + 1) * 4" computed
> > using normal +/-/* operators on sparc64 is 18,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173
--- Comment #33 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #32)
> "So I take the other way around by passing the IV's ssa_name into
> scev_probably_wraps_p along call sequence
> "idx_find_s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64705
--- Comment #4 from amker at gcc dot gnu.org ---
I had a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #15 from amker at gcc dot gnu.org ---
(In reply to amker from comment #14)
> (In reply to Eric Botcazou from comment #12)
> > I'm about to install a patch that changes the costs on SPARC 64-bit to:
> >
> &g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #14 from amker at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #12)
> I'm about to install a patch that changes the costs on SPARC 64-bit to:
>
> Use 1:
> cand costcompl. depends on
&g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56590
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173
--- Comment #31 from amker at gcc dot gnu.org ---
So cand_value_at (loop, cand, use->stmt, desc->niter, &bnd) with arguments as
below:
cand->iv->base:
(unsigned long) ((char *) &A + (sizetype) i_6(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173
--- Comment #30 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #17)
> I really wonder why IVOPTs calls convert_affine_scev with
> !use_overflow_semantics.
>
> Note that for the original testcase 'i&#x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173
--- Comment #27 from amker at gcc dot gnu.org ---
(In reply to Jiong Wang from comment #24)
> (In reply to amker from comment #23)
>
> partially agree.
>
> at least for the single use case given by Seb, I think tree ivopt sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173
--- Comment #26 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #17)
> I really wonder why IVOPTs calls convert_affine_scev with
> !use_overflow_semantics.
I don't understand below code in convert_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173
--- Comment #25 from amker at gcc dot gnu.org ---
(In reply to Jiong Wang from comment #24)
> (In reply to amker from comment #23)
>
> partially agree.
>
> at least for the single use case given by Seb, I think tree ivopt sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173
--- Comment #23 from amker at gcc dot gnu.org ---
Now I am less convinced that it's a tree ivopt issue. Tree optimizer has no
knowledge about stack frame information for local array variables. With the
original test, on 32-bits targets,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173
--- Comment #20 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #18)
> It's probably not correct to simply transfer range info from *idx to
> iv->base.
> Instead SCEV analysis needs to track the range o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64705
amker at gcc dot gnu.org changed:
What|Removed |Added
Target|x86_64-*-* |x86_64-*-*, aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64705
--- Comment #2 from amker at gcc dot gnu.org ---
Loop dump before IVOPT is like below:
Loop 4, basic blocks 28/30;
:
count_54 = count_172 + 1;
_55 = i_161 + i_161;
prime_56 = _55 + 3;
k_57 = prime_56 + i_161;
if (size_26 >= k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64705
amker at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64348
--- Comment #4 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #3)
> Fixed(?)
Yes, thanks!
I forgot to close it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64348
--- Comment #2 from amker at gcc dot gnu.org ---
Author: amker
Date: Fri Jan 9 06:19:32 2015
New Revision: 219375
URL: https://gcc.gnu.org/viewcvs?rev=219375&root=gcc&view=rev
Log:
2015-01-09 Kito Cheng
PR rtl-optimizati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62178
amker at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
amker at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
--- Comment #17 from amker at gcc dot gnu.org ---
Author: amker
Date: Mon Dec 22 10:25:10 2014
New Revision: 219008
URL: https://gcc.gnu.org/viewcvs?rev=219008&root=gcc&view=rev
Log:
PR rtl-optimization/62151
* combine.c (try
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64348
--- Comment #1 from amker at gcc dot gnu.org ---
IRA made below decision:
;; a299(r989,l0) conflicts: a57(r1696,l0) a177(r130,l0) a221(r131,l0)
a63(r1714,l0) a178(r822,l0) a224(r823,l0) a69(r1713,l0) a180(r815,l0)
a227(r816,l0) a75(r1712,l0
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amker at gcc dot gnu.org
Case scal-to-vec1.c failed because of ICE on arm-linux-gnueabi with -fPIC. The
compilation command line is:
./arm-none-linux-gnueabi-gcc scal-to-vec1.c -fno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58623
--- Comment #7 from amker at gcc dot gnu.org ---
Hi Evandro,
There is specific PR for this issue. But as we know, fwprop often corrupts
optimizations on address expression, for below example:
add rb, r1, r2
ldr rx, [rb]
add rb, rb, #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62178
--- Comment #7 from amker at gcc dot gnu.org ---
Should be fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62178
--- Comment #6 from amker at gcc dot gnu.org ---
Author: amker
Date: Thu Dec 18 02:53:42 2014
New Revision: 218855
URL: https://gcc.gnu.org/viewcvs?rev=218855&root=gcc&view=rev
Log:
PR tree-optimization/62178
* tree-ssa-loop-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58623
amker at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
--- Comment #16 from amker at gcc dot gnu.org ---
For calls of distribute_notes with from_insn != NULL, I kind of understand why
it is vulnerable, at least when handling REG_DEAD notes.
When we distribute REG_DEAD note of one register from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
--- Comment #14 from amker at gcc dot gnu.org ---
Working on a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63821
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63821
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||joel at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63817
amker at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63817
amker at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63411
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55701
--- Comment #6 from amker at gcc dot gnu.org ---
Author: amker
Date: Fri Sep 5 03:45:57 2014
New Revision: 214937
URL: https://gcc.gnu.org/viewcvs?rev=214937&root=gcc&view=rev
Log:
PR target/55701
* config/arm/arm.md (setm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61943
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62289
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62265
amker at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62262
--- Comment #8 from amker at gcc dot gnu.org ---
(In reply to Carrot from comment #5)
> (In reply to amker from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > (insn 27 26 40 5 (set (reg:SI 73 [ D.2590 ])
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62262
--- Comment #4 from amker at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #3)
> (In reply to amker from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > (insn 27 26 40 5 (set (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62262
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61825
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62220
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62032
amker at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
--- Comment #9 from amker at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #8)
> > I will try to test a patch, meanwhile, I am wondering if any combine expert
> > has something to share.
>
> distribute_notes is ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62178
--- Comment #2 from amker at gcc dot gnu.org ---
Yes, the patch changes addressing modes choosing and further changes ivopts's
decision. I shall take this one if you are ok.
Thanks,
bin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
--- Comment #7 from amker at gcc dot gnu.org ---
It's a combine pass issue and it happens on x86 too. Dump before combine pass
is fine as below.
30: r83:SI=0
71: flags:CC=cmp(r83:SI,0x1)
REG_DEAD r83:SI
72: {r83:SI=-ltu(fla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
--- Comment #6 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #5)
> Note that probably also made a latent issue pop up.
Indeed. After preliminary investigation, I think this case reveals two latent
issues. The fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62032
amker at gcc dot gnu.org changed:
What|Removed |Added
Known to work|4.9.1 |
Known to fail|4.10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62032
--- Comment #6 from amker at gcc dot gnu.org ---
Author: amker
Date: Fri Aug 15 05:49:56 2014
New Revision: 214000
URL: https://gcc.gnu.org/viewcvs?rev=214000&root=gcc&view=rev
Log:
Backport from mainline
2014-08-08 Bin Cheng
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #12 from amker at gcc dot gnu.org ---
Hi,
I can reproduce the exact mis-scheduled instruction issue as in Jakub's comment
with/without the ivopt patch (204497). Turns out gcc chooses candidate like
{&K512, 128}_loop with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62032
--- Comment #5 from amker at gcc dot gnu.org ---
Author: amker
Date: Fri Aug 8 10:21:12 2014
New Revision: 213755
URL: https://gcc.gnu.org/viewcvs?rev=213755&root=gcc&view=rev
Log:
PR lto/62032
* lto/lto-lang.c (lto_init): Sw
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amker at gcc dot gnu.org
For simple case like below,
typedef unsigned int wchar_t;
struct printf_info
{
int prec;
int width;
wchar_t spec;
unsigned int is_long_double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55701
--- Comment #4 from amker at gcc dot gnu.org ---
Author: amker
Date: Wed Jul 23 16:02:15 2014
New Revision: 212948
URL: https://gcc.gnu.org/viewcvs?rev=212948&root=gcc&view=rev
Log:
Revert r212893:
PR target/55701
* co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55701
--- Comment #3 from amker at gcc dot gnu.org ---
Author: amker
Date: Mon Jul 21 12:24:06 2014
New Revision: 212893
URL: https://gcc.gnu.org/viewcvs?rev=212893&root=gcc&view=rev
Log:
PR target/55701
* config/arm/arm.md (setm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61748
--- Comment #1 from amker at gcc dot gnu.org ---
Created attachment 33090
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33090&action=edit
Dump file of einline pass
Assignee: unassigned at gcc dot gnu.org
Reporter: amker at gcc dot gnu.org
Hi,
The newly added test check fails on
arm-none-linux-gnueabi/arm-none-linux-gnueabihf.
Compiled with below command:
$ g++ -O2 -S imm-devirt-2.C -o imm-devirt-2.S -fdump-tree-einline(-details)
The gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61544
amker at gcc dot gnu.org changed:
What|Removed |Added
Target||arm
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61712
--- Comment #15 from amker at gcc dot gnu.org ---
I think this is fixed on trunk by:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=3df31d76aa8c14ff871fc15b931d277b8d68626a
2014-06-18 Terry Guo
PR target/61544
* config/arm/arm.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60947
amker at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60947
--- Comment #17 from amker at gcc dot gnu.org ---
(In reply to Mikael Pettersson from comment #16)
> (In reply to amker from comment #15)
> > Well, only thing suspicious that I can see, the memset function is a special
> > impleme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60947
--- Comment #15 from amker at gcc dot gnu.org ---
Well, only thing suspicious that I can see, the memset function is a special
implementation and not from C standard library. Basically it doesn't need to
follow the standard, which mean
701 - 800 of 827 matches
Mail list logo
