--- Additional Comments From steven at gcc dot gnu dot org 2005-02-25
06:39 ---
Jakub, any plans to commit your patch to mainline and 3.3?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18384
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-28
13:09 ---
How useful is this transformation for real world code?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20231
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-02
11:35 ---
Performance bugs are never critical.
--
What|Removed |Added
Severity|critical
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-02
11:36 ---
Updated patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01796.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17863
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-02
11:50 ---
Here is a nice one:
Working on insn:
(insn 215 214 216 15 (parallel [
(set (reg:DI 176)
(ashift:DI (reg:DI 175)
(const_int 3 [0x3
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-05
18:49 ---
Even with Richard Guenther's patches, the only thing that really helps is
setting --param large-function-growth=200, or more. The default is 100.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17863
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-05
23:37 ---
I don't think this will be fixed for 4.1, unless we kick out implicit
sets from gcse, or all of gcse. The former may be possible if our
const/copy prop at the tree level is good enough, but I wou
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-06
00:32 ---
The first case of comment #14 turns out to be PR20130.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-06
22:14 ---
Just to give people an idea of how close we are to optimizing well enough that
the calls to fold_rtx in CSE are almost all no-ops, here are some numbers
taken over all cc1-i files on amd64:
Number of
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-08
00:21 ---
More on the latent bug that the patch for this PR uncovers:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00448.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15784
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-10
12:48 ---
> Maybe there should be another combining pass after the duplication
> of the indirect jumps. Should I create another PR for this?
There should not be another "combining" pass (you real
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-13
17:45 ---
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01297.html would help.
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-16
00:57 ---
I really doubt my patch is to blame for this. This patch has been on
the hammer branch for ages, so it was in the system compiler of every
SUSE distribution released in the last 2 years.
Probably SMS
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-03-
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-16
01:01 ---
This is enough for me to trigger the bug. The malloc is needed,
probably it makes sure V and vector don't alias, or something like
that.
extern void * malloc (long);
int n;
float (*v
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-16
01:10 ---
For me the fatal error now happens in a block starting with this:
Breakpoint 6, verify_wide_reg (regno=136, bb=0x400a5a50)
at ../../mainline/gcc/flow.c:494
494 fatal_error ("internal consis
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-16
01:24 ---
This is at the point where die. Block 2 and block 7 both set reg 136.
Block 2 uses it, and the predecessors of block 2 are block 2 and block 7.
Reg 136 is in liveout(2). But it is not in liveout(7) for
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-16
12:30 ---
Someone should check if this is fixed now, by this patch:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01122.html
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-16
12:32 ---
Diego, this happens *a lot* in GCC itself. All suggestions
on how we can fix this problem are welcome... ;-)
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-16
12:34 ---
Since Diego is apparently not looking at this, I'll give it another look.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19789
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-17
00:04 ---
I can successfully compile your test case with the gcc that is shipped
with SUSE 9.2 ("gcc (GCC) 3.3.4 (pre 3.3.5 20040809)").
You say you are using GCC 3.3.2, but if you have any influen
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-17
00:06 ---
I should notice I tried -O2 and -O3. If you used other flags, you
should report those too. Your bug report is not very detailed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20497
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-19
18:58 ---
Actually you can get this from any trivial "implicit set"-like
code, for example:
int b;
void foo (int a) {
if (a)
a = 3;
b = a;
}
The out-of-ssa pass
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-19
19:33 ---
FWIW this bug is a major source of ifcvt1 opportunities, so fixing it
has positive downstream effects too.
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-20
00:58 ---
int b;
void foo (int a) {
if (a)
a = 3;
b = a;
}
GCC 3.3.5 (hammer-branch) on AMD64 -O2:
foo:
.LFB3:
testl %edi, %edi
movl$3, %eax
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-20
15:12 ---
Yes it is.
--
What|Removed |Added
Status|NEW
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-20
16:07 ---
Actually the original plan was to write define_expands for x86*, but easier
solution was to write a new generic expander in expr.c. As a positive side
effect, other targets also profit from that patch
t: tree-optimization
AssignedTo: dnovillo at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20580
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-21
18:41 ---
This should be fairly trivial to do on the tree-cleanup-branch, so this
is "fixable" for GCC 4.1. Let's hope it gives a real improvement... ;-)
Confirmed because I already discussed this
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-21
22:09 ---
My bad. Roger already has a proposed fix.
--
What|Removed |Added
Status
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-27
10:19 ---
Two things:
1) Test case? No test case, no way to reproduce it without re-doing the
investigating you have already done. Stop work duplication, provide
test cases to your fellow GCC hackers. I
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-28
21:04 ---
Indeed I do not have time to work on this. I should have unassigned
this bug long ago, sorry about that.
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-28
21:57 ---
Test case, thanks to Tom Tromey:
T.java:
public class T
{
int field;
public void test(int f) {
synchronized (this) {
if (field != 0)
throw new IllegalStateException
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-29
13:22 ---
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02578.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20648
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-30
11:21 ---
Is anyone going to work on these intrinsics? Is there a list somewhere
of what intrinsics we are talking about here?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16871
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-30
11:38 ---
Waiting for a test case...
--
What|Removed |Added
Status|UNCONFIRMED
--
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-03-
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-04-
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-01
10:43 ---
Seen in wxGTK on i386:
../../../../contrib/src/ogl/drawn.cpp:1019: internal compiler error: in
cp_tree_equal, at cp/tree.c:1552
../../../../contrib/src/ogl/mfutils.cpp:157: internal compiler error: in
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-03
12:49 ---
Should be fixed on mainline now, can someone confirm this for ia64?
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-03
12:51 ---
This bug disappeared today for me. Coalan, do you still see it?
--
What|Removed |Added
-on-valid-code
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
CC: aj at suse dot de,gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/s
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-03
14:33 ---
C ICE-on-valid bugs are release critical.
--
What|Removed |Added
Severity
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-03
14:49 ---
We ICE on an assert:
#ifdef ENABLE_CHECKING
tree t_op0 = TREE_TYPE (op0);
gcc_assert ((TREE_CODE (t_op0) == ARRAY_TYPE
&& POINTER_TYPE_P
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-03
15:32 ---
Introduced by rth's patch http://gcc.gnu.org/ml/gcc-cvs/2004-09/msg00682.html.
If this patch was ever posted to gcc-patches, I can't find the mail for it.
--
What
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-04
09:18 ---
Removing the patch mentioned in comment #5 indeed makes this bug go away.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20739
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-04
13:09 ---
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00321.html
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-04
13:10 ---
There is a reason why it is disabled in gcc 4.0.
--
What|Removed |Added
Status
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-04
13:11 ---
I should point out, though, that we all (me too) do appreciate
this kind of testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20743
--
What|Removed |Added
Known to fail|4.0.0 4.1.0 |4.0.0
Summary|[4.0/4.1 regression] ICE in |[4.0 regression] ICE in
|cfg_layout_re
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-07
09:10 ---
The same patch as the one on mainline should work for 4.0.
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-10
16:01 ---
Also happens with mainline.
extern struct symbol_tab_
{
void *S_nil;
} symbol_tab_data;
typedef struct
{
unsigned int length;
void *data[0];
} s;
void *
allocate_vector (unsigned int
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-10
16:03 ---
Needs "-O -mtune=k8 -fPIC" of course. -fPIC seems to cause the problem.
--
What|Removed
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-10
16:08 ---
Double *sigh*.
The old loop optimizer introduces the offending insn. From the .loop dump:
Insn 26: regno 70 (life 1), move-insn forces 25 savings 1 moved to 56
Hoisted regno 74 r/o from (mem/u/c:DI
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-10
17:24 ---
After CSE1 (t.c.04.cse) we have:
(insn 20 18 22 1 (set (reg:DI 66)
(mem/u/c:DI (const:DI (unspec:DI [
(symbol_ref:DI ("bar") [flags 0x40] )
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-10
17:39 ---
The offending insn is created by emit_move_insn in loop.c, here:
2354start_sequence ();
2355emit_move_insn (m->insert_temp ? newreg : m->set_dest,
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-10
17:52 ---
My RTL-fu is way below par, so perhaps this doesn't make sense at all, but...
It seems that emit_move_insn must always produce valid move insns. So it
should check that an immediate is a vali
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-10
19:03 ---
FWIW, smallest test case I could find:
extern struct bar_t bar;
void
foo (void)
{
void **p;
do {
*p++ = ((unsigned char *) &bar + ((unsigned long int) 1L << 31));
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-10
21:05 ---
Alexandre Oliva pointed out to me that it was probably the expander who
should produce a proper legitimate insn. I looked at this some more and
found that in legitimize_pic_address we do not check if a
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-10
23:32 ---
Yup:
Breakpoint 1, fancy_abort (file=0x82a7f8 "../../gcc-4.0/gcc/stor-layout.c",
line=221,
function=0x82a87c "smallest_mode_for_size") at diagnostic.c:556
556 internal_err
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-12
09:52 ---
There is always a bigger fish - an a smaller test case:
struct sMCB {
unsigned char type;
};
extern void foo (void);
unsigned char mem_readb(char *pt) __attribute__((nothrow));
void
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-12
09:56 ---
In addition to ICEing, PRE is also being stupid about moving out a
loop invariant expression:
Found partial redundancy for expression (char *) &0B->type
Skipping insertion of phi for partial red
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-12
13:38 ---
FWIW, I think the problem might be that there are cases where
force_gimple_operand generates more sub-expressions, but we do
not add value handles for them:
(gdb)
1369 folded = fold (build
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-13
06:28 ---
Maybe 4.0 with the patch for PR20929 triggers the ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20963
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-13
09:23 ---
Paolo Bozini mentioned this bug as an example of the 64bits arith
on 32bits host "issue".
--
What|Removed
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-13
23:50 ---
I am no longer interested in working on this DSE pass.
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-16
15:15 ---
It is apparently not possible to convince people that any optimizations
in CSE can be removed, so working on this is pointless for me. See
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01498.html
--- Comment #38 from steven at gcc dot gnu dot org 2008-09-21 13:07 ---
Fixed by Honza's patch.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #12 from steven at gcc dot gnu dot org 2008-09-21 13:13 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|steven at gcc
--- Comment #2 from steven at gcc dot gnu dot org 2008-09-21 13:13 ---
libcall notes are no more...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from steven at gcc dot gnu dot org 2008-09-21 13:14 ---
I can reproduce this on-and-off, but never with a reasonable test case.
It's unlikely that anyone is interested in fixing this, esp. given that RTL
PRE/CPROP are doing less and less these days as the
--- Comment #2 from steven at gcc dot gnu dot org 2008-09-21 13:19 ---
Libcall blocks are no more.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from steven at gcc dot gnu dot org 2008-09-21 13:21 ---
Andreas, could you adopt the patch of comment #4 and see if it still fixes this
bug?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2008-09-21 13:36 ---
A C equivalent test case "works". Once the infamous
multiple-decls-per-function issue in gfortran is fixed, this bug probably will
disappear.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23169
--- Comment #13 from steven at gcc dot gnu dot org 2008-09-21 13:49 ---
Re. comment #12
I don't see how PRE for globals would make a difference here. In any case,
AFAIU tree PRE for globals should now work, and we still don't produce any
better code. The output of today (4.4.
--- Comment #14 from steven at gcc dot gnu dot org 2008-09-21 13:52 ---
Here is the .final_cleanup dump, fwiw:
;; Function foo (foo)
foo ()
{
int a.1;
:
a.1 = a + 1;
a = a.1;
if (a.1 != 0)
goto ;
else
goto ;
:
a = [plus_expr] a.1 + 1;
:
return;
}
which
--- Comment #12 from steven at gcc dot gnu dot org 2008-09-21 13:58 ---
tree PRE now *does* handle the partially redundant global variable load. This
is the .final_cleanup dump:
;; Function bar (bar)
bar ()
{
int prephitmp.13;
:
prephitmp.13 = i;
switch (prephitmp.13) , case 0
--- Comment #2 from steven at gcc dot gnu dot org 2008-09-24 22:28 ---
I'll see this weekend if I can take care of this.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #3 from steven at gcc dot gnu dot org 2008-09-27 14:09 ---
Created an attachment (id=16414)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16414&action=view)
draft patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37635
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from steven at gcc dot gnu dot org 2008-09-28 11:57 ---
Don't know if the patch is OK, but the code is obviously doing something silly.
CC-ing ARM maintainer.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #5 from steven at gcc dot gnu dot org 2008-10-02 18:52 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from steven at gcc dot gnu dot org 2008-10-02 18:52 ---
Subject: Bug 37635
Author: steven
Date: Thu Oct 2 18:51:12 2008
New Revision: 140837
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140837
Log:
testsuite
* gfortran.fortran-torture
--- Comment #10 from steven at gcc dot gnu dot org 2008-01-18 12:04 ---
Re. comment 7:
What does the initial RTL look like with GCC 3.3 and with a post tree-ssa
compiler?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22141
--- Comment #12 from steven at gcc dot gnu dot org 2008-01-18 12:35 ---
So 3.3 expanded the initializer into sets of the individual components, but
with ANDs and ORs and a single MEM store, instead of MEM stores to the
individual components.
It seems to me that this is not something
--- Comment #6 from steven at gcc dot gnu dot org 2008-01-18 16:05 ---
I tried to avoid setting XEXP(note,0) twice (once directly and once through
gen_rtx_INSN_LIST.
But I don't feel strong either way. Your patch looks correct to me.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #1 from steven at gcc dot gnu dot org 2008-01-18 14:26 ---
Which optimization level?
Why does cross-jumping not optimize this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34849
--- Comment #4 from steven at gcc dot gnu dot org 2008-01-18 14:03 ---
Created an attachment (id=14966)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14966&action=view)
Handle REG_RETVAL notes in try_split
Untested, etc. But the ICE for the test case goes away. This patc
--- Comment #6 from steven at gcc dot gnu dot org 2008-01-18 16:53 ---
The offending insn is already produced in "expand".
GCC ICEs the first time it calls recog() on it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34831
--- Comment #5 from steven at gcc dot gnu dot org 2008-01-18 16:50 ---
Confirmed.
ignoring nonexistent directory
"/usr/local/lib/gcc/mipsel-unknown-linux-gnu/4.3.0/include"
ignoring nonexistent directory
"/usr/local/lib/gcc/mipsel-unknown-linux-gnu/4.3.0/include-
--- Comment #7 from steven at gcc dot gnu dot org 2008-01-18 16:07 ---
Ah, and of course gen_rtx_INSN_LIST does not set XEXP(0) of the REG_LIBCALL
note. Silly me ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34808
--- Comment #9 from steven at gcc dot gnu dot org 2008-01-18 17:02 ---
Does not fail unless -march=sb1 is given.
Thus not a regression until proven that older GCCs did not fail with this
option.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from steven at gcc dot gnu dot org 2008-01-18 20:05 ---
Patches welcome.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34855
--- Comment #10 from steven at gcc dot gnu dot org 2008-01-18 17:14 ---
The problem is IMHO in the div3 define_expand in mips.md:
(define_expand "div3"
[(set (match_operand:ANYF 0 "register_operand")
(div:ANYF (match_operand:ANYF
--- Comment #55 from steven at gcc dot gnu dot org 2008-01-19 09:41 ---
IMHO we can close this one now as fixed. Objections to that, anyone?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34400
--- Comment #2 from steven at gcc dot gnu dot org 2008-01-19 10:48 ---
merge_classes() itself is clear, so the problem must be in the caller.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34865
--- Comment #16 from steven at gcc dot gnu dot org 2008-01-20 23:22 ---
I favor blowing away the RD patch.
Having the LR problem (and probably the LIVE problem too?) always propagate the
REG_EQ* notes as if they were real uses sounds like a terrible idea to me.
They are not real uses
--- Comment #2 from steven at gcc dot gnu dot org 2008-01-21 09:22 ---
This is an unhandled expression. A gcc_unreachable() is hit in a switch block.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
901 - 1000 of 3051 matches
Mail list logo
