Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43854
-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43855
--- Comment #2 from dann at godzilla dot ics dot uci dot edu 2010-04-22
19:54 ---
(In reply to comment #1)
Also pretmp prehitmp and ivtmp prefixes are too long,
They might be too long but they are useful long without looking too much into
the code to figure out what kind of temp
--- Comment #8 from dann at godzilla dot ics dot uci dot edu 2009-06-25
15:31 ---
(In reply to comment #7)
With the new restrict implementation baz() works and all the rest would work
as well if the calls to link_error () would not cause the malloced memory
to be clobbered
ReportedBy: dann at godzilla dot ics dot uci dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39075
--- Comment #1 from dann at godzilla dot ics dot uci dot edu 2009-02-02
14:50 ---
This code:
unsigned short a[1];
void test()
{
int i;
for (i = 0; i 1; ++i) a[i] = 5;
}
will be vectorized with -O3 -march=core2 to this:
.L2:
movdqa %xmm0, a(%eax)
addl
--- Comment #3 from dann at godzilla dot ics dot uci dot edu 2009-02-02
16:42 ---
(In reply to comment #2)
(reminds me of a couple missed-optimization PRs where vectorization is also
failing due to casts - PR31873 , PR26128 - don't know if this is related)
Are the casts actually
: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39069
: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39068
at godzilla dot ics dot uci dot edu
GCC host triplet: i386-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38204
--- Comment #4 from dann at godzilla dot ics dot uci dot edu 2008-11-20
18:43 ---
Still happens with 4.4.0:
qqq (int a)
{
int result.0;
int D.1236;
int result;
result.0 = bar (a);
result = result.0;
D.1236 = result;
return D.1236;
}
--
dann at godzilla dot ics dot
--- Comment #6 from dann at godzilla dot ics dot uci dot edu 2008-11-20
23:27 ---
Still happens in 4.4.
--
dann at godzilla dot ics dot uci dot edu changed:
What|Removed |Added
--- Comment #8 from dann at godzilla dot ics dot uci dot edu 2008-03-15
00:28 ---
(In reply to comment #7)
The testcase is fixed by the SCCVN alias-oracle patch.
Are you sure? I still see the problem (.final_cleanup dump):
void bar(first*, multi*) (s1, s3)
{
bb 2:
s1-f1 = 0;
s3
--- Comment #5 from dann at godzilla dot ics dot uci dot edu 2008-03-04
21:19 ---
(In reply to comment #4)
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00243.html
Thanks for working on this!
Have you looked at the impact?
Probably the generated code won't too different because
--- Comment #7 from dann at godzilla dot ics dot uci dot edu 2008-03-04
21:32 ---
(In reply to comment #6)
Actually RTL alias is just using the same routines.
Might be, but the RTL level code that optimizes away the abort() in both
testcases (if I remember well
--- Comment #9 from dann at godzilla dot ics dot uci dot edu 2008-03-04
21:43 ---
(In reply to comment #8)
Subject: Re: adding unused char field inhibits
optimization
On Tue, 4 Mar 2008, dann at godzilla dot ics dot uci dot edu wrote:
--- Comment #7 from dann at godzilla
: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31575
--- Comment #2 from dann at godzilla dot ics dot uci dot edu 2007-04-14
21:03 ---
(In reply to comment #1)
This looks completely a register allocator issue and I think 4.2.0 and before
were just getting lucky.
Also note that the extra push+pop are NOT generated when using -march
: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30643
--- Comment #5 from dann at godzilla dot ics dot uci dot edu 2007-01-28
22:04 ---
(In reply to comment #2)
i.e. it misses to initialize the temporary with the result. Otherwise you
can play with variants of the following patch:
Richard, have you tried to make this patch work
--- Comment #6 from dann at godzilla dot ics dot uci dot edu 2006-12-12
06:07 ---
(In reply to comment #5)
(In reply to comment #1)
Confirmed (but it's not PRE).
The second is smaller, and no more or less efficient since the addition is
calculated on both paths anyway.
Both
--- Comment #4 from dann at godzilla dot ics dot uci dot edu 2006-12-07
18:24 ---
(In reply to comment #3)
unswitching would duplicate the whole loop here, so not exactly I think. But
if-conversion to
j = COND_EXPR p, 1, 2
or
j = 2 - (int)p;
would make j loop
: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC target triplet: i686-pc-linux-gnu
http
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi
: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30101
: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http://gcc.gnu.org/bugzilla
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30103
structures)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30105
--- Comment #3 from dann at godzilla dot ics dot uci dot edu 2006-09-04
17:56 ---
This specific case can probably be solved at the tree level by changing the
test:
(nb 5) != 0
to
nb 32
--
dann at godzilla dot ics dot uci dot edu changed:
What|Removed
--- Comment #3 from dann at godzilla dot ics dot uci dot edu 2006-06-20
19:09 ---
More data: for PR8361 the number of functions in the .gimple dump is 5045, the
number of functions in the cleanup_cfg dump is 1341. The majority of the
functions that are eliminated are small functions
--- Comment #2 from dann at godzilla dot ics dot uci dot edu 2006-06-13
14:18 ---
Add Diego to the CC list as per his request.
--
dann at godzilla dot ics dot uci dot edu changed:
What|Removed |Added
--- Comment #3 from dann at godzilla dot ics dot uci dot edu 2006-06-13
14:22 ---
(In reply to comment #2)
(In reply to comment #1)
Hmm, it should have produced G.3, G.n, at least I would have thought.
No, we intentionally use the same variable for the lexically identical
--- Comment #3 from dann at godzilla dot ics dot uci dot edu 2006-06-13
14:42 ---
One of the issues with this PR and also 27800, 27809 and 27810 is that this
extra work/memory allocation done for a number of functions that are never
used: like all the inline functions present
lowering for return
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
--- Comment #2 from dann at godzilla dot ics dot uci dot edu 2006-05-31
21:47 ---
My guesstimate is that for combine.i about 5-8% of the total number of
expressions
in the gimple dump are due to the gimplification inefficiencies shown in
PRs 27798 27800 27809 27810, so these issues
: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27798
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27799
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27800
--- Comment #1 from dann at godzilla dot ics dot uci dot edu 2006-05-29
20:51 ---
An even simpler example which occurs quite frequently in programs:
int jjj (int a){ return bar (a); }
jjj (a)
{
int D.1891;
int D.1892;
D.1892 = bar (a);
D.1891 = D.1892;
return D.1891
of globals
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http
: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27810
: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27440
--- Comment #2 from dann at godzilla dot ics dot uci dot edu 2006-05-04
23:09 ---
(In reply to comment #1)
IV-OPTs just gets info from the target. Now if the target says weird
addressing mode is the same as cheap ones, what do you think will happen?
Does IV-OPTs also take
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http://gcc.gnu.org/bugzilla
--- Comment #5 from dann at godzilla dot ics dot uci dot edu 2006-05-03
18:54 ---
IMO Comment #4 does not look close enough at what is actually happening.
IMO tree-ch is the root cause here.
The code looks like this before .ch
Before .ch
goto bb 2 (L1);
L0:;
D.1301_54 = Int_Loc
--- Comment #8 from dann at godzilla dot ics dot uci dot edu 2006-05-03
21:53 ---
WRT this code generated by tree-ch:
D.1305_41 = Int_Loc_3 + 1;
if (Int_Loc_3 = D.1305_41) goto L0; else goto L2;
AFAICT there's exactly one value for which the comparison can be false, IMO it
would
: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27365
--- Comment #28 from dann at godzilla dot ics dot uci dot edu 2006-04-30
19:25 ---
Just a note, fixing the problem in this PR would fix the only remaining failure
for cprop in Brigg's compiler benchmarks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15911
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26944
--- Comment #2 from dann at godzilla dot ics dot uci dot edu 2006-03-30
16:43 ---
(In reply to comment #1)
Note that this may be also PRE confusing SCEV in presence of loop headers.
Talking about PRE, here's a maybe interesting observation in the PRE dump:
L7:;
pretmp.30_53
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26949
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26850
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26537
--- Comment #18 from dann at godzilla dot ics dot uci dot edu 2006-03-03
02:14 ---
(In reply to comment #17)
(In reply to comment #5)
It's strange that the load(*) does not get optimized, given that it's in the
same BB as the store that precedes it...
movl%eax
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26249
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26251
--- Comment #4 from dann at godzilla dot ics dot uci dot edu 2006-02-13
02:34 ---
Here's another testcase of what seems to be the same problem.
The 4.2 assembly contains 2 calls for TabSet, 4.0 only has 1.
(both this and the first example are function from xterm in case anybody
--- Comment #9 from dann at godzilla dot ics dot uci dot edu 2006-01-05
20:22 ---
(In reply to comment #7)
*** Bug 23338 has been marked as a duplicate of this bug. ***
Bug 23338 contained a patch that might fixed this issue. Here it is, so
that it can be evaluated.
*** i386.md
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC target triplet
--- Comment #6 from dann at godzilla dot ics dot uci dot edu 2005-12-18
22:57 ---
(In reply to comment #5)
Simplified testcase seems to work for me on 4.1 branch:
restore_fpu:
movl4(%esp), %edx
movlboot_cpu_data+12, %eax
testl $16777216, %eax
4.0
--- Comment #2 from dann at godzilla dot ics dot uci dot edu 2005-11-13
02:47 ---
Simplified testcase:
struct cpuinfo_x86 {
unsigned char x86;
unsigned char x86_vendor;
unsigned char x86_model;
unsigned char x86_mask;
char wp_works_ok;
char hlt_works_ok;
char hard_math
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC target triplet: i686-pc-linux-gnu
http
--- Comment #1 from dann at godzilla dot ics dot uci dot edu 2005-11-11
19:29 ---
Created an attachment (id=10220)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10220action=view)
Preprocessed code containing the functions that exhibit the problem
--
http://gcc.gnu.org
--- Comment #10 from dann at godzilla dot ics dot uci dot edu 2005-11-03
00:53 ---
(In reply to comment #9)
What are the flags for the sizes in comment #7 and comment #8?
-O2 -march=i686
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23153
--- Comment #11 from dann at godzilla dot ics dot uci dot edu 2005-11-03
00:59 ---
A very useful tool for comparing function sizes in 2 binaries/object file is:
ftp://ftp.firstfloor.org/pub/ak/bloat-o-meter
it displays the function names, the size, the size difference as absolute
--- Comment #5 from dann at godzilla dot ics dot uci dot edu 2005-11-03
01:27 ---
(In reply to comment #4)
This is actually invalid as nothing happens for -Os case so what you are
seeing
is just an atrifact.
Sorry but this explanation for marking the PR invalid does not make sense
--- Comment #8 from dann at godzilla dot ics dot uci dot edu 2005-11-03
02:12 ---
(In reply to comment #6)
The use of ax vs cx will not matter in the real world.
This is from a real world program (xterm) and it seems to matter, when using
eax the code is smaller.
Are you sure
--- Comment #10 from dann at godzilla dot ics dot uci dot edu 2005-11-03
02:34 ---
(In reply to comment #9)
Have you tested the speed? As I said I really doubt it makes a real world
change in terms of speed. This is different from code size.
I am not sure what kind of answer you
--- Comment #16 from dann at godzilla dot ics dot uci dot edu 2005-11-03
06:42 ---
(In reply to comment #15)
(In reply to comment #11)
And FWIW there is also a problem with this insn, the length is wrong:
#(insn 11 46 47 0x2a955cc840 (set (reg:SI 0 eax [orig:61 x ] [61
--- Comment #12 from dann at godzilla dot ics dot uci dot edu 2005-11-03
07:51 ---
(In reply to comment #11)
(In reply to comment #10)
I am not sure what kind of answer you expect here.
Speed and code size are not disjoint. Think about I-cache and I-TLB misses.
But again who
--- Comment #7 from dann at godzilla dot ics dot uci dot edu 2005-11-01
15:15 ---
(In reply to comment #5)
Hmm,
I am still not sure if it matters too much, but since there are actually
dupes of this problem, I think we can simply add peep2 fixing this
particular common case.
I
--- Comment #8 from dann at godzilla dot ics dot uci dot edu 2005-10-31
04:15 ---
More data, the Linux kernel compiled for i686:
size -f *
textdata bss dec hex filename
2625471 534012 611768 3771251 398b73 vmlinux.4.0
3023306 429364 347384 3800054 39fbf6
--- Comment #13 from dann at godzilla dot ics dot uci dot edu 2005-10-31
04:50 ---
(In reply to comment #12)
A more interesting test would be to see the Linux kernel size difference,
There's such a comparison now in comment #8 in PR23153. It confirms the size
increase.
--
http
--- Comment #8 from dann at godzilla dot ics dot uci dot edu 2005-10-27
16:43 ---
(In reply to comment #7)
Could the dear reported at least try to provide a small test case?
The testcase in the attachment contains only a 4 lines function:
HandleDeIconify, the rest is just fluff
--- Comment #12 from dann at godzilla dot ics dot uci dot edu 2005-10-27
18:08 ---
(In reply to comment #9)
And CSiBE tells you the story that GCC 4.1 produces smaller code overall.
http://www.inf.u-szeged.hu/csibe/draw-diag.php?draw=sum-osbasephp=s-i686-linux
Well, it obviously
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC target triplet: sparc-sun-solaris2.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24209
--- Comment #1 from dann at godzilla dot ics dot uci dot edu 2005-10-05
05:13 ---
Created an attachment (id=9889)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9889action=view)
preprocessed code for this bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24209
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-29 20:10 ---
(In reply to comment #9)
Subject: Re: Unconditional warning when using -combine
On Mon, Sep 26, 2005 at 08:46:20PM -, dann at godzilla dot ics dot uci dot
edu wrote:
So this about
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-28 17:29 ---
(In reply to comment #2)
While it might be probably possible to design peephole or combiner insn patter
I am tempted to close this and PR 23303 as WONTFIX as it seems to me we was
optimizing
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-26 19:25 ---
Created an attachment (id=9807)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9807action=view)
xterm.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-26 19:25 ---
Created an attachment (id=9808)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9808action=view)
xlwmenu.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-26 19:54 ---
(In reply to comment #4)
Because one file uses KR style function defintions and the other uses a
prototype which is ANSI/ISO
style.
Simple example:
[snip]
So I don't think
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-26 20:46 ---
(In reply to comment #4)
So this about the following:
int f(a)
int a;
{
return a;
}
int f(int);
Which is questionable.
So I don't think this is not an inappropriate warning
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-21 17:43 ---
(In reply to comment #8)
(In reply to comment #4)
Instead of the above check, change it to:
if (local_regparm == 3 DECL_STRUCT_FUNCTION (fn)-static_chain_decl)
local_regparm = 2
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-13 20:45 ---
The fact that the dump is different depending on function order or compilation
flags seems to point to either an uninitialized variable or some memory
corruption.
--
http://gcc.gnu.org
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-13 22:36 ---
It looks like the -fwhole-program version of ClearLeft only passes the
first 2 arguments to the ClearInLine call in register, the 3rd one is
passed on the stack.
The reason for that is this code
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-13 22:57 ---
(In reply to comment #6)
Maybe a better check would be check in the decl's function struct's
field
static_chain_decl is set.
I am not sure I understand what you mean here...
Maybe adding
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-13 23:09 ---
Additional data:
For the testcase in PR8361:
size -f generate-3.4*.o
textdata bss dec hex filename
297025 4 181 297210 488fa generate-3.4-4.0.o
318366 8
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-12 23:30 ---
(In reply to comment #1)
If it changes calling-conventions
in single-file compile mode the function must be declared static, so it
definitely may be changed in whole-program mode, too.
Yep
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-07 22:05 ---
It seems that expand generates different insns in 4.0 and 4.1 for the comparison
in question:
4.0 generates: (from .00.expand)
(insn 15 13 16 1 (set (reg/f:SI 62)
(mem/s/f:SI (plus:SI
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-08-25 02:49 ---
This message:
http://gcc.gnu.org/ml/gcc/2005-08/msg00208.html
was asking for the reason for the slowdown for S05e
AFAICT the inner loop for the benchmark (in s05e_test) gets compiled
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-08-25 05:43 ---
The issue is the peephole2 pass in 4.1. Before it the insn looks like:
(insn:HI 36 34 37 0 (set (mem/i:SI (symbol_ref:SI (waiting_for_initial_map)
[flags 0x40] var_decl 0xb7b71898
: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23525
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-08-23 18:05 ---
(In reply to comment #2)
You really should know that we only care about code size at -Os. We care
about performance
regressions though at -O2.
Code size is important for performance
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-08-23 18:15 ---
(In reply to comment #4)
Then use -Os every where instead. You will see that the overall code
size for 4.1
has reduced from 4.0.
That might be true, but -Os is not always an option
1 - 100 of 132 matches
Mail list logo
