--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-30
12:28 ---
Here is a list of all the differences between the two profiles. r is the time
with recip, nr is without, nr-r is the difference.
r nr nr-rfunc
1.281.500.22pov::sbisect(int,
0.84
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-30
10:15 ---
To calculate the numbers I gave you, I took the sum of the percentages in the
profiling snippets, and the cumulative time for the last line of the profiling
snippets. Then pct * 100 / time obviously gives
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-30
08:51 ---
Now committed to 4.0 branch as well.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-30
08:22 ---
Uros, it seems from your comments that POVray is also 7.43% faster with the
rewritten recip pass, than without any recip pass:
time for no recip pass (comment #4): 1.43 * 100 / 10.05 = 14.22
time for new
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-30
08:14 ---
> This is really a RA issue rather than anything else.
No, this is an issue with the recip pass, that creates an absurd register
pressure -- it is quite expected that the RA cannot deal with t
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-29
08:34 ---
> But putting these inside of a class doesn't work:
>
> class Foo {
> Foo(){};
> ~Foo(){};
> static const double PI = M_PI;
> static const double TWO_PI = (2.0*PI);
>
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-29
08:30 ---
Giovanni, any news?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23437
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-25
12:48 ---
Posted the patch for the algorithm I had sketched in the previous comments.
--
What|Removed |Added
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-25
12:41 ---
Again, the patch for PR21419 fixes this.
*** This bug has been marked as a duplicate of 21419 ***
--
What|Removed |Added
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-25
12:41 ---
*** Bug 21421 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21419
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-25
12:41 ---
The patch for 21419 fixes this as well.
*** This bug has been marked as a duplicate of 21419 ***
--
What|Removed |Added
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-25
12:41 ---
*** Bug 21420 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21419
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot
|dot org |org
URL|
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-25
12:36 ---
*** Bug 21422 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21419
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-25
12:36 ---
This can be diagnosed in the middle-end, so it would work for C and C++ the
same.
*** This bug has been marked as a duplicate of 21419 ***
--
What|Removed |Added
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-25
11:37 ---
I think it is acceptable to not show the warning in this case. Does moving the
uninitialized warning above "fix" this bug? If so, it is a dup of 18501.
--
http://gcc.gnu.org/bugzilla/show_
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-25
11:37 ---
Personally, I prefer misdiagnosing uninit-5.c as a possible uninitialized use,
rather than missing this pretty nasty case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-25
11:37 ---
Does this mean that 22156 is a dup of this (or viceversa)?
--
What|Removed |Added
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-23
09:58 ---
I've rewritten execute_cse_reciprocals, I think the only useful solution is to
implement the optimal scheme for inserting reciprocals, and fix this bug in the
process.
My algorithm builds a
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-22
07:09 ---
I have a patch but it only works in the -fno-trapping-math case. Given that
trapping math is much more complex, that the code quality improves for
-ftrapping-math, and that we are late in the development
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-22
07:00 ---
I don't know the tree-cfg bits very well, but the patch seems wrong; you are not
committing the edge insertion.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23948
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-20
13:38 ---
no, it's not, sorry for the noise. it "only" does 210 synth_mult calls.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23971
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-20
13:33 ---
This one is reproducible everywhere:
long long f(long long x) { return x * 5445825408751490200ULL; }
--
What|Removed |Added
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-16
15:18 ---
fixed
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-16
09:11 ---
fold_const_aggregate_ref does not handle REALPART_EXPR and IMAGPART_EXPR.
Steven has a patch, or so I'm told.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23911
--
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |200
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-15
13:46 ---
if these ints are signed, you should be able to remove these loops.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23361
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-12
12:41 ---
The problem is that the array is mapped to a single SFmode register.
One could probably replace the assert with a run-time invocation of abort().
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23714
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-12
12:35 ---
reduced testcase, also failing with -O2 -fnon-call-exceptions
void run (void) {
float stack[1];
*(stack - 1) = 0.0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23714
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-08
12:02 ---
Even more reduced:
extern void f(char *const *);
void g (char **o)
{
static const char *const multilib_exclusions_raw[] = { 0 };
const char *const *q = multilib_exclusions_raw;
f (o);
while (*q
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-02
09:47 ---
Richard, can you write a case where it produces awful code?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22568
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-31
14:45 ---
Having a zero_extract that takes 16 bytes out of a QImode mem seems extremely
wrong. Can you find out which pass generates that thing? Just grep for
zero_extract:SI..mem[a-z/]:QI
in all the files dumped
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-31
13:36 ---
This ought to use ngettext.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21768
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Known to fail||4.0.2
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-29
15:02 ---
Maybe the patch could be backported to 4.0?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23506
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-29
15:02 ---
Maybe the patch could be backported to 4.0?
--
What|Removed |Added
CC
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-29
14:55 ---
Can anybody do a regression hunt on mainline?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21169
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-29
14:41 ---
All branches now have the "quick fix".
--
What|Removed |Added
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-29
14:37 ---
Could this apply to 4.0 as well?
--
What|Removed |Added
CC
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-29
14:36 ---
Patch applied.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-24
14:08 ---
It's not handling VCE of an integer constant (or a real constant too, for that
matter).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23546
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-24
13:50 ---
Nicer test case:
typedef int m64 __attribute__ ((__vector_size__ (8)));
void mmxCombineMaskU (m64 * mask, int width)
{
while (--width >= 0)
*mask++ = (m64) 0LL;
}
--
http://gcc.gnu.org/bugzi
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-23
18:02 ---
(note: the tree-vect-generic.c part is not needed on 4.0)
Fixed.
--
What|Removed |Added
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-23
14:51 ---
> It looks like the problem is that we don't remove the synchronization
> for nextDouble() even though the test case is single-threaded.
If we can remove even only half of the synchronization o
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-23
14:48 ---
Yes, I think that most invocations of next should be inlined, and wrapped in a
single synchronized block.
Apart from that, I am pretty sure that here
seed = (seed * 0x5DEECE66DL + 0xBL) & ((1L &
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-22
22:03 ---
SPEC results for i686-pc-linux-gnu follow. The only significant regression is
in galgel, overall it's about 1% better for SPECint and 2% better for SPECfp.
Note that crafty improves a lot becau
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-22
21:32 ---
Another patch can be found at
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01331.html
--
What|Removed |Added
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-22
11:01 ---
I'm not confident that using salq in Steven's test case is really a
pessimization. I'll consider a 32-bit target then, and this testcase
char **
VTallocbuf(char **allbuf, unsigned
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-18
13:46 ---
Sorry.
outcnt aliases with outbuf, so the load of t2 cannot be removed. The GIMPLE
code that is now emitted is something like:
void
bi_windup(unsigned char *outbuf, unsigned char bi_buf
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-18
13:44 ---
outcnt aliases with outbuf
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23455
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-18
11:51 ---
Mark, should this patch go into 4.0.2 too?
--
What|Removed |Added
CC
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-18
11:47 ---
Well all the crashes are in annotate_with_file_line, so:
- if we want to work around this issue, like in the patch attached to pr23439,
it is a duplicate
- if we want a fix in the parsers, it is a
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-08-
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-18
09:50 ---
Patch applied to branch for 4.0.2.
--
What|Removed |Added
Status|NEW
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-18
09:45 ---
The "quick fix", for the record, is
http://gcc.gnu.org/ml/gcc-patches/2005-04/txt00083.txt
It makes sense to apply this to 4.0.2, and be done with this bug, since Jeff and
others decided on mai
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-18
09:09 ---
Patch for 20155 was backported.
--
What|Removed |Added
BugsThisDependsOn
--
What|Removed |Added
BugsThisDependsOn||23455
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
t: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gcc dot gnu dot org
CC: dberlin at gcc dot gnu dot org,gcc-bugs at gcc dot gnu
dot org
OtherBugsDependingO 19721
nThis:
http://gcc.gnu.org/bugz
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-17
13:06 ---
what about times on 4.1?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18687
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-17
12:58 ---
Fix committed to 4.0 branch as part of fixing PR20155
--
What|Removed |Added
Known to
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-17
12:56 ---
Committing to 4.0 branch.
--
What|Removed |Added
Known to fail|4.0.1
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-17
12:36 ---
A solution could be to count the number of global register vars, and decrease
the number of regparm'd parameters accordingly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22362
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-17
12:29 ---
Now, on mainline, I get:
test:
pushl %ebp
movl%esp, %ebp
fldl.LC0
fdivl 8(%ebp)
leave
ret
--
What|Removed
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-17
08:03 ---
This small testcase is a typical case of the optimizations that CSE path
following catches on PowerPC:
unsigned outcnt;
extern void flush_outbuf(void);
void
bi_windup(unsigned char *outbuf
--
Bug 21015 depends on bug 17860, which changed state.
Bug 17860 Summary: [3.4 only] Wrong generated code for loop with varying bound
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17860
What|Old Value |New Value
--
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-09
08:23 ---
Patch committed.
--
What|Removed |Added
Status|ASSIGNED
--
What|Removed |Added
Known to fail||4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gcc dot gnu dot org
CC: gcc-bugs at gc
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-08
17:00 ---
Andrew, is a backport fine with you?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20155
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-08
16:32 ---
I don't like the patch, the correct way is to teach pex-win32.c about '#!'
because GCC is built under a Unix-like environment (MSYS).
Paolo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22259
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-08
10:17 ---
... though this would not help PR17236, of course.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19398
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-08
09:58 ---
The solution may as well be to make -mfpmath=sse good enough, that it can be
enabled by default when -msse -msse2 is used...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19398
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-07-28
08:20 ---
Not even that... the backend for i386 accepts an SI, not a V4SI, as the shift
count. This upsets the expander noticeably.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22480
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-07-28
07:11 ---
No, the bug is in the vectorizer that produces a LSHIFT_EXPR rather than a
VEC_LSHIFT_EXPR. There must have been problems committing the patch. :-(
Paolo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--
What|Removed |Added
CC||dalej at apple dot com
AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-07-18
09:37 ---
Will be fixed by toplevel bootstrap.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-07-14
08:55 ---
Adding Mark so that he can judge the opportunity of a backport.
Removing bug 21624 dependency, because it is indeed fixed on mainline. If bug
21624 were fixed the command line could be even shorter, but
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-07-14
08:45 ---
> But I don't see immediately how reload could be convinced to do so
> automatically, as the choice of the reload class for one insn is independend
> from the choices of reloads for the s
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-07-13
14:45 ---
Fixed by the patch above.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-07-13
14:23 ---
Michael, thank you very much. Your analysis will probably help a lot.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19653
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-07-13
14:08 ---
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01783.html crashes on richard
guenther's libsse2, fwiw.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19653
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-07-13
11:51 ---
Smaller testcase from PR22453:
extern double f(double, double);
void g (double x)
{
double z, y;
z = 0.0;
y = 1.0 - x;
again:
z = y - z;
f(z, 1.0);
if (z == 0.0)
goto again;
}
has a
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-07-13
10:07 ---
Vladimir, I believe your rematerialization pass would help a lot in this case
and in other SSE pessimizations.
--
What|Removed |Added
Status: UNCONFIRMED
Keywords: missed-optimization, ra
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,rguenth
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-07-11
07:54 ---
Almost there:
Index: Makefile.tpl
===
RCS file: /cvs/src/src/Makefile.tpl,v
retrieving revision 1.135
diff -p -u -r1.135 Makefile.tpl
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-07-07
11:32 ---
Patch under testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22085
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-06-06
15:08 ---
The patch fixes the bug because in the poster's test case we have to insert a
reciprocal computation in an empty basic block.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21921
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-06-06
09:10 ---
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00446.html
--
What|Removed |Added
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-05-31
13:11 ---
Ulrich Weigand wrote:
When building with -funit-at-a-time (which is on by default with -O2), *no*
debug info for global variables appears to be emitted at all.
The problem appears to be this piece of code
broken?
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gcc dot gnu dot org
CC: gcc-bugs
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-05-24
13:46 ---
scev_info_str should be ggc_alloc-ed.
Then, the hash table with the cache should be marked with GTY((param_is (struct
scev_info_str)))
If this fixes the bug, you can remove the TODO_ggc_collect from
201 - 300 of 380 matches
Mail list logo
