https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69992
--- Comment #8 from Alexander Monakov ---
Sorry, I've overlooked the mention of -m64 in comment #1. I used 'configure
--target=powerpc-linux-gnu' and didn't pass -m64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80394
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
,
||amonakov at gcc dot gnu.org
--- Comment #2 from Alexander Monakov ---
This might be a typo in treatment of EXPR_USEFULNESS in comparator, adding
Andrey.
Tentative patch:
diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c
index 87a483a231e..88d8c50b508 100644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82397
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Depends on: 82381, 82395, 82396, 82397, 82398, 82401
Target Milestone: ---
Checking qsort comparator validity (transitivity and anti-commutativity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82397
--- Comment #3 from Alexander Monakov ---
Is it possible to simply invoke data_ref_compare_tree always, without checking
operand_equal_p beforehand? It's possible to canonicalize commutative chains in
data_ref_compare_tree, or - even better - whi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82418
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82395
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
||amonakov at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #1 from Alexander Monakov ---
Thanks. Bug 82397 already has some analysis for this comparator - marking this
report as duplicate.
*** This bug has been marked as a duplicate of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82397
Alexander Monakov changed:
What|Removed |Added
CC||su at cs dot ucdavis.edu
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82395
--- Comment #4 from Alexander Monakov ---
*** Bug 82482 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82407
Bug 82407 depends on bug 82482, which changed state.
Bug 82482 Summary: ICE in qsort comparator non-negative on sorted output: 1 in
fast_allocation at ira-color.c:4821
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82482
What|Remove
||amonakov at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #1 from Alexander Monakov ---
Thanks, but this is due to the same allocator as in PR 82395,
allocno_priority_compare_func (and I've confirmed it works with my patch).
***
||amonakov at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #4 from Alexander Monakov ---
t2 needs more code simply because it does more work: in C you can read
representations of objects byte-by-byte via 'char *' pointers. Con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82395
--- Comment #5 from Alexander Monakov ---
Author: amonakov
Date: Thu Oct 19 16:48:34 2017
New Revision: 253904
URL: https://gcc.gnu.org/viewcvs?rev=253904&root=gcc&view=rev
Log:
ira-color: fix allocno_priority_compare_func for qsort (PR 82395)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82395
Alexander Monakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82407
Bug 82407 depends on bug 82395, which changed state.
Bug 82395 Summary: [8 Regression] qsort comparator non-negative on sorted
output: 1 in color_allocnos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82395
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77453
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77478
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77478
--- Comment #3 from Alexander Monakov ---
On further investigation, lack of peeling might be intentional, the vectorizer
could be deliberately using unaligned access. Previously I missed that the body
of the vectorized loop is completely unrolled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77478
--- Comment #4 from Alexander Monakov ---
Slightly reduced testcase that demonstrates the issue regardless of
stack-protector; -O3 -ffast-math is enough on x86-64 (plus -msse2 on i386).
Oddly, the #if0 block makes a difference.
static const flo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77478
--- Comment #6 from Alexander Monakov ---
Thanks, seeing alignment info in dumps helps (I think you meant -vops rather
than -alias?).
This doesn't seem to reproduce on trunk. On gcc-5 branch, I see alignment
increasing in dom2 pass.
Specificall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77478
--- Comment #7 from Alexander Monakov ---
Richard, I don't believe this is a dup. According to my git-bisect, this was
fixed or made latent during gcc-6 development by your patch:
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00120.html
[PATCH]
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
For the following C++ testcase:
#include
long foo(char *c1, char *c2)
{
long *p1 = new(c1) long;
*p1 = 100;
long long *p2 = new(c2) long long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78035
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36750
--- Comment #7 from Alexander Monakov ---
Nightstrike, is there a particular reason you want C++ warning behavior be
adjusted? Note that unlike C, in C++ you get zero-initialization by default,
so you don't need to write ' = {0};' to zero-initial
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36750
--- Comment #9 from Alexander Monakov ---
My statement about zero-initialization was inaccurate (thanks), but the general
point still stands: in C you have to write ' = {0}' since empty-braces
initializer is not supported by the language (you get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65753
--- Comment #1 from Alexander Monakov ---
Example testcase:
void *lookup_f(void);
void g()
{
void (*f)(void) = lookup_f();
f();
}
With -O2 -fPIC, on x86-64 GCC produces the desired tail call:
g:
subq$8, %rsp
calllookup_f@PL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65753
--- Comment #2 from Alexander Monakov ---
For a simpler testcase:
void g(void (*f)(void))
{
f();
}
gcc/cc1 -fPIC -O2 -m32:
g:
subl$12, %esp
call*16(%esp)
addl$12, %esp
ret
Here %ebx does not come into play at all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65753
--- Comment #4 from Alexander Monakov ---
The check rejecting indirect calls was introduced with commit
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=069db0ae0a5b5b61d64731a94eea002fb3c9d901
(gcc-patches thread starting at
https://gcc.gnu.org/ml/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48302
Alexander Monakov changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48442
Alexander Monakov changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65753
--- Comment #5 from Alexander Monakov ---
Author: amonakov
Date: Mon May 11 16:10:24 2015
New Revision: 223005
URL: https://gcc.gnu.org/viewcvs?rev=223005&root=gcc&view=rev
Log:
PR target/65753
* config/i386/i386.c (ix86_function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65753
Alexander Monakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60086
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60086
--- Comment #9 from Alexander Monakov ---
By "good code" I was referring to the fact that your 4.7 asm does not contain
stack (%rbp) references in the vectorized loop.
Historically, first scheduling (-fschedule-insns) was problematic for 32-bit
x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65099
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Minimal testcase:
$ cat >test.c <
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703
--- Comment #10 from Alexander Monakov ---
Bug 64420, which was marked as a duplicate, presents an example where there's
no diagnostics at build time (linking succeeds), but the resulting code is
wrong and will fail at runtime.
I believe the cor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144
Alexander Monakov changed:
What|Removed |Added
Attachment #32830|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62011
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
||amonakov at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #7 from Alexander Monakov ---
I have filed this issue previously as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655 (unfixed, has minimized
repro). A workaround on gcc side
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
Alexander Monakov changed:
What|Removed |Added
CC||kfischer at college dot
harvard.ed
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
When multiple OpenMP reductions are specified, GCC
ty: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Compiling and running the following testcase with non-shared-memory accelerator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69090
--- Comment #2 from Alexander Monakov ---
I've assigned 'fortran' category to the bug because "allocatable arrays" are
specific to Fortran, and the gfortran front-end already does some processing of
allocatable arrays for OpenMP directives. I wou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69090
--- Comment #5 from Alexander Monakov ---
Ilya, 'omp declare target' is not applicable to arrays with automatic storage,
is it? The array needs to be either global, or have the SAVE attribute (similar
to 'static' keyword for local vars in C) — ei
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
--- Comment #30 from Alexander Monakov ---
Nick, can you please post the patch to gcc-patches too, to avoid confusing
future people who wouldn't be able to find the explanation of the patch in the
archives?
(did you get approval for this patch o
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
The following testcase:
int p(void) __attribute__((const));
void g(int);
void f()
{
for (;;)
g(p());
}
is optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66512
--- Comment #2 from Alexander Monakov ---
In that case I'd like to contribute a documentation patch to make that clear in
the pure/const attribute information, but I need more explanation. I see that
int p(void) __attribute__((const));
void f()
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-w64-mingw32
Created attachment 35846
--> https://gcc.gnu.org/bugzi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48215
--- Comment #3 from Alexander Monakov 2011-03-21
15:53:43 UTC ---
Looks like PR 46518 (the fix was not propagated from trunk to 4.5-branch). Can
you please check whether below patch fixes these problems?
diff --git a/gcc/sel-sched-ir.c b/gcc/se
||2011.03.22 13:56:01
CC||amonakov at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Alexander Monakov 2011-03-22
13:56:01 UTC ---
Confirmed. We get tripped by re-using cached pointer to the last
||amonakov at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |amonakov at gcc dot gnu.org
|gnu.org |
--- Comment #4 from Alexander Monakov 2011-03-24
17:32:39 UTC ---
So the assert disagrees with the rest of the scheduler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48442
--- Comment #1 from Alexander Monakov 2011-04-06
13:39:44 UTC ---
Created attachment 23899
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23899
proposed patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48442
--- Comment #2 from Alexander Monakov 2011-04-06
13:41:33 UTC ---
Confirmed. The 4.4/4.5 failure is most likely a dup of PR 46204. The 4.6/4.7
failure is due to selective scheduler removing a conditional jump during
purge_empty_blocks in sel_sc
||2011.04.06 13:41:57
CC||amonakov at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |amonakov at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48273
--- Comment #5 from Alexander Monakov 2011-04-06
14:40:28 UTC ---
There's little value in allowing bookkeeping for calls, and the (untested yet)
patch below forces calls to be unique. The test case also shows that our
remove_insns_that_need_book
||2011.04.06 16:08:13
CC||amonakov at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |amonakov at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496
Summary: [4.7 Regression] 'asm' operand requires impossible
reload in libffi/src/ia64/ffi.c
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priori
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496
Alexander Monakov changed:
What|Removed |Added
CC||vmakarov at redhat dot com
Known
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48442
--- Comment #4 from Alexander Monakov 2011-04-08
11:44:54 UTC ---
Author: amonakov
Date: Fri Apr 8 11:44:51 2011
New Revision: 172173
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172173
Log:
PR rtl-optimization/48442
* sel-sche
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48273
--- Comment #8 from Alexander Monakov 2011-04-08
11:49:47 UTC ---
Author: amonakov
Date: Fri Apr 8 11:49:43 2011
New Revision: 172175
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172175
Log:
PR target/48273
* cfgloop.h (loop_ha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48302
--- Comment #2 from Alexander Monakov 2011-04-08
11:53:28 UTC ---
Author: amonakov
Date: Fri Apr 8 11:53:25 2011
New Revision: 172176
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172176
Log:
PR rtl-optimization/48302
* sel-sche
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48235
--- Comment #2 from Alexander Monakov 2011-04-08
11:58:25 UTC ---
Author: amonakov
Date: Fri Apr 8 11:58:23 2011
New Revision: 172177
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172177
Log:
PR rtl-optimization/48235
* sel-sche
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48442
Alexander Monakov changed:
What|Removed |Added
Known to work||4.7.0
Known to fail|4.7.0
||abel at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |amonakov at gcc dot gnu.org
|gnu.org |
--- Comment #3 from Alexander Monakov 2011-04-18
17:25:06 UTC ---
The logic of the assert is that the only way we can see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48562
Alexander Monakov changed:
What|Removed |Added
CC||bkoz at gcc dot gnu.org
--- Comment #
||amonakov at gcc dot gnu.org
Resolution||DUPLICATE
--- Comment #1 from Alexander Monakov 2011-04-19
09:20:05 UTC ---
This is a dup of a previously reported LTO bootstrap problem, which has been
fixed on the trunk.
*** This bug has been
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48652
Alexander Monakov changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48652
Alexander Monakov changed:
What|Removed |Added
CC||bkoz at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48669
--- Comment #2 from Alexander Monakov 2011-04-19
09:26:55 UTC ---
*** This bug has been marked as a duplicate of bug 48652 ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36750
--- Comment #3 from Alexander Monakov 2011-04-22
11:53:05 UTC ---
Author: amonakov
Date: Fri Apr 22 11:53:01 2011
New Revision: 172857
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172857
Log:
PR c/36750
* c-typeck.c (pop_init_le
||amonakov at gcc dot gnu.org
Resolution||FIXED
--- Comment #4 from Alexander Monakov 2011-04-22
11:56:39 UTC ---
The above patch suppresses the warning in C regardless of whether the trailing
comma is present. Closing as fixed.
|UNCONFIRMED |NEW
Last reconfirmed||2011.04.28 11:48:26
CC||amonakov at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #3 from Alexander Monakov 2011-04-28
11:48:26 UTC ---
The
||amonakov at gcc dot gnu.org
--- Comment #2 from Alexander Monakov 2010-11-02
17:30:54 UTC ---
The scheduler is confused by a conditional jump to the next instruction (and
the fact that the containing BB has only one outgoing edge, which is also
marked fallthru). When we
||amonakov at gcc dot gnu.org
Resolution||DUPLICATE
--- Comment #2 from Alexander Monakov 2010-11-12
11:58:25 UTC ---
(In reply to comment #1)
> Sorry, this seems to be a dup of PR44691. Is there a reason not to backport
> that to 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44691
--- Comment #8 from Alexander Monakov 2010-11-12
11:58:25 UTC ---
*** Bug 46441 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44691
--- Comment #9 from Alexander Monakov 2010-11-12
15:47:46 UTC ---
Author: amonakov
Date: Fri Nov 12 15:47:38 2010
New Revision: 166653
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166653
Log:
Backport from mainline:
2010-08-19
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46204
Alexander Monakov changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46204
--- Comment #3 from Alexander Monakov 2010-11-13
09:28:55 UTC ---
Author: amonakov
Date: Sat Nov 13 09:28:52 2010
New Revision: 166697
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166697
Log:
PR rtl-optimization/46204
* sel-sche
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518
--- Comment #4 from Alexander Monakov 2010-11-17
15:29:33 UTC ---
(In reply to comment #2)
> Only occurs for -fPIC on x86_64-apple-darwin10. Adding -fno-PIC on darwin
> suppresses the ICE.
Is that in relation to bootstrap flags? There's no PIC
|unassigned at gcc dot |amonakov at gcc dot gnu.org
|gnu.org |
--- Comment #9 from Alexander Monakov 2010-11-17
15:39:57 UTC ---
(In reply to comment #8)
> > Btw, the scheduler guys have a fix in the works already.
>
> Then they should assign the P
||2010.11.17 18:18:14
AssignedTo|unassigned at gcc dot |amonakov at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #10 from Alexander Monakov 2010-11-17
18:18:14 UTC ---
Thanks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518
--- Comment #13 from Alexander Monakov 2010-11-18
10:24:38 UTC ---
Author: amonakov
Date: Thu Nov 18 10:24:31 2010
New Revision: 166898
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166898
Log:
PR middle-end/46518
* sel-s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518
Alexander Monakov changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45652
--- Comment #10 from Alexander Monakov 2010-11-22
10:35:10 UTC ---
Author: amonakov
Date: Mon Nov 22 10:35:06 2010
New Revision: 167025
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167025
Log:
PR rtl-optimization/45652
* alias.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45652
Alexander Monakov changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46602
Summary: [4.6 Regression] gcc.dg/pr42245-2.c ICE on ia64
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Ass
|unassigned at gcc dot |amonakov at gcc dot gnu.org
|gnu.org |
--- Comment #3 from Alexander Monakov 2010-11-22
13:30:14 UTC ---
Investigating
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46585
--- Comment #4 from Alexander Monakov 2010-11-24
14:19:09 UTC ---
sel-sched doesn't expect to see nops in the function, and uses them internally
as markers in place of recently removed insns; luckily, we can easily switch
to some other pattern,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46585
--- Comment #6 from Alexander Monakov 2010-11-24
14:38:47 UTC ---
(In reply to comment #5)
> + nop_pattern = gen_rtx_CONST_INT (VOIDmode, -1);
>
> You could just use
> nop_pattern = constm1_rtx;
> or just #define nop_pattern constm1_rtx
Than
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46585
--- Comment #7 from Alexander Monakov 2010-11-25
09:42:35 UTC ---
*** Bug 46649 has been marked as a duplicate of this bug. ***
||amonakov at gcc dot gnu.org
Resolution||DUPLICATE
--- Comment #3 from Alexander Monakov 2010-11-25
09:42:35 UTC ---
Known issue: sel-sched chokes on NOPs in input stream. A fix will land on
trunk soon.
*** This bug has been marked as a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46602
--- Comment #1 from Alexander Monakov 2010-11-25
09:59:17 UTC ---
Author: amonakov
Date: Thu Nov 25 09:59:03 2010
New Revision: 167140
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167140
Log:
PR rtl-optimization/46602
* sel-sche
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46585
--- Comment #8 from Alexander Monakov 2010-11-25
10:05:08 UTC ---
Author: amonakov
Date: Thu Nov 25 10:05:00 2010
New Revision: 167141
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167141
Log:
PR rtl-optimization/46585
* sel-sche
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46602
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
601 - 700 of 1205 matches
Mail list logo
