On 10 Oct 2007 08:58:00 -, steven at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #33 from steven at gcc dot gnu dot org 2007-10-10 08:57
---
What happened with the suggestion to only do this in reassoc2 (see comment
#27)?
Yeah, i'm not sure why we just made both
I'm not fixing this until someone can tell me what exactly is going
wrong. There have been *so* many changes to PTA since that revision
that the majority of the code it touched doesn't even do the same
thing anymore.
My guess is that this is a case where adding extra vdefs/vuses made
some dumb
On 28 Aug 2007 15:58:29 -, jakub at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #6 from jakub at gcc dot gnu dot org 2007-08-28 15:58 ---
if (a == 0) a = bar (); isn't necessary either.
salias has:
# BLOCK 2 freq:1
# PRED: ENTRY [100.0%] (fallthru,exec)
Yes, you are right.
I wasn't thinking clearly
--- Comment #4 from bonzini at gnu dot org 2007-08-23 14:04 ---
Hmmm, a store into an int * could not touch nodekind itself, only a store
into an int ** could.
Isn't SMT.8 the VDEF saying it could touch *the thing pointed to by
Points-to memory with these is almost nothing, so don't look at meef.
It looks like size goes up for each function and is not fully
recovered by the time we start the next.
On 25 Jul 2007 22:25:22 -, debian-gcc at lists dot debian dot org
[EMAIL PROTECTED] wrote:
[forwarded from
I already submitted a patch for this (see my followup to HP that fixes
valid_gimple_expression_p).
As soon as i can bootstrap on darwin, i will commit it.
If someone wants to do so before me, all you need to do is change
is_gimple_addressable to is_gimple_id in valid_gimple_expression_p
valid_gimple_expression_p claims
((struct RegisterLayout *) (char *) SimulatedRegisters)-intmask;
is valid GIMPLE, when it is not.
On 13 Jul 2007 23:37:00 -, hp at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #4 from hp at gcc dot gnu dot org 2007-07-13 23:36 ---
The only way i can see this happening is if you have a truly
uninitialized variable, or there is something we have missed.
Does this function have cfun-static_chain_decl being used, and we
have a copy of that here?
It is theoretically safe to call set_ssa_to_val with to == vn_top, but
it's
On 4 Jul 2007 03:29:25 -, mmitchel at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--
Just as an update:
I have been working with richi (I code, he tests :P) diligently on a
patch for mainline, and have one that fixes the dealii regression (and
thus, should fix this as well).
On 26 Jun 2007 03:10:26 -, acahalan at gmail dot com
[EMAIL PROTECTED] wrote:
--- Comment #4 from acahalan at gmail dot com 2007-06-26 03:10 ---
(In reply to comment #3)
Subject: Re: Missed optimizations with -fwhole-program -combine
I would not expect this to be fixed anytime
On 20 May 2007 04:57:45 -, pluto at agmk dot net
[EMAIL PROTECTED] wrote:
--- Comment #25 from pluto at agmk dot net 2007-05-20 05:57 ---
Subject: Re: [4.2 Regression] possible quadratic behaviour.
--
Change line 4275 of the patched tree-ssa-structalias.c to be rhs.var =
On 19 May 2007 14:30:43 -, pluto at agmk dot net
[EMAIL PROTECTED] wrote:
--- Comment #21 from pluto at agmk dot net 2007-05-19 15:30 ---
with this patc gcc works much better.
xf86ScanPci.i : 84MB / ~5sec.
sipQtCorepart0.ii.bz2 : 340MB / ~440sec
There are optimizations
On 19 May 2007 17:16:35 -, pluto at agmk dot net
[EMAIL PROTECTED] wrote:
--- Comment #23 from pluto at agmk dot net 2007-05-19 18:16 ---
bad news, this patch ices fortran build:
(...)
../../../libgfortran/intrinsics/selected_int_kind.f90:22: internal compiler
error: in
On 14 May 2007 08:25:27 -, rguenth at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #60 from rguenth at gcc dot gnu dot org 2007-05-14 09:25
---
But it doesn't have a result, does it? Given that, I wonder how moving stmts
across it is prevented?
Okay, so then it
On 8 Mar 2007 20:12:16 -, amacleod at redhat dot com
[EMAIL PROTECTED] wrote:
--- Comment #7 from amacleod at redhat dot com 2007-03-08 20:12 ---
Looking at the original testcase, the complaint is that _t_8232 and _t_3 are
both used in the PHI definition of _t_7. (using mainline
okay, i'll update changelog, submit and commit.
On 13 Jan 2007 23:02:13 -, rguenth at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #21 from rguenth at gcc dot gnu dot org 2007-01-13 23:02
---
The patch fixed the freefem memory regression.
--
Try the attached, let me know how it goes.
On 9 Jan 2007 21:17:05 -, rguenth at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-01-09 21:17
---
Pling!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
---
On 1 Jan 2007 00:41:44 -, mark at codesourcery dot com
[EMAIL PROTECTED] wrote:
--- Comment #26 from mark at codesourcery dot com 2007-01-01 00:41 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
dberlin at gcc dot gnu
I will try to get back to this bug this week. I was fighting some
other fights last week, i apologize.
And what are the timings with a recent version of g++ and actually
turning on optimization?
On 13 Dec 2006 17:38:06 -, charles at rebelbase dot com
[EMAIL PROTECTED] wrote:
vector::size() in bits/stl_vector.h is currently implemented as
size_type
size() const
{ return
I would not expect this to be fixed anytime soon. I have yet to find
any real people who use either combine or -fwhole-program. They use
*way* too much memory on real programs. As a result, no real people
involved in optimization work on optimizers for them.
On 5 Dec 2006 19:38:51 -,
OK, so I'll have to find another way of using the DWARF info to see if a inline
routine, such as __task_rq_lock was used at all in the build or was just
included in the DWARF info but not referenced anywhere, have to dig more into
the available information...
BTW, if, in these cases,
On 12 Nov 2006 20:39:43 -, acme at mandriva dot com
[EMAIL PROTECTED] wrote:
--- Comment #5 from acme at mandriva dot com 2006-11-12 20:39 ---
(In reply to comment #4)
The only thing left from __task_rq_lock is a label.
SNIP
task_cpu were inlined and we constant proped the
On 13 Nov 2006 16:16:50 -, acme at mandriva dot com
[EMAIL PROTECTED] wrote:
--- Comment #8 from acme at mandriva dot com 2006-11-13 16:16 ---
OK, I thought that this was due to something like what you described, even
not
knowing that much about gcc internals, but I thought
Can you try the attached and let me know if it fixes it?
fordanglin.diff
Description: Binary data
A detailed proposal:
So here is what i was thinking of. When i say symbols below, I mean
some VAR_DECL or structure that has a name (like our memory tags
do). A symbol is *not* a real variable that occurred in the user
program. When I say varaible i mean a variable that occurred in the
user
Memory SSA brings down the number of virtual operators to exactly one per
statement.
However, it does so in a way that makes the traditional things that
actually want to do cool memory optimizations, harder.
I'm still on the fence over whether it's a good idea or not.
verified before we
In mem-ssa, you have VDEF's of the
same symbol all over the place.
version of a symbol
Zdenek, can you revert your patch until we fix this?
It might be a month or two before i get back to it.
(Yeah, i know it sucks to have to do this, but)
On 6 Nov 2006 15:12:30 -, hjl at lucon dot org
[EMAIL PROTECTED] wrote:
--- Comment #14 from hjl at lucon dot org 2006-11-06
On 5 Nov 2006 21:22:24 -, dave at hiauly1 dot hia dot nrc dot ca
[EMAIL PROTECTED] wrote:
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2006-11-05
21:22 ---
Subject: Re: jc1: out of memory allocating 4072 bytes after a total of
708630224 bytes
Can you bzip2
The change on the 19th caused a significant increase in memory
consumption http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01029.html
and java bootstrap failures on s390, s390x and ia64. See this
thread http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01058.html.
Except that all of these were fixed
Details, source, etc needed.
On 31 Oct 2006 15:02:02 -, hjl at lucon dot org
[EMAIL PROTECTED] wrote:
--- Comment #10 from hjl at lucon dot org 2006-10-31 15:02 ---
It miscompiles dwarf2out.c in gcc in SPEC CPU 2006.
On 25 Oct 2006 05:23:00 -, pinskia at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-25 05:22 ---
_ZTCN33_GLOBAL__N_t.cc__2292CFAC11NullostreamE0_13basic_ostream
# _ZTI13basic_ostream = V_MAY_DEF
On 24 Sep 2006 18:23:41 -, ebotcazou at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #37 from ebotcazou at gcc dot gnu dot org 2006-09-24 18:23
---
No, really, you don't seem to understand.
If you respect these DECL_NONADDRESSABLE_P or
TYPE_NONALIASED_COMPONENT
asm volatile
(
push %1 \n\t
call *%0 \n\t
add$4, %%esp \n\t
:
: r ( test ), r ( x )
);
asm statements are not allowed to alter control flow
Why does loop change the SMT usage?
In addition, since there are times loop doesn't do anything, you
should simply be returning PROP_smt_usage when it does do something,
and nothing otherwise.
On 4 Sep 2006 03:52:04 -, pinskia at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
---
hosking at cs dot purdue dot edu wrote:
--- Comment #13 from hosking at cs dot purdue dot edu 2006-08-24 15:27
---
Is this enough?
Here is the dump output, followed by stack traces at the resize and remove
points (the remove goes on to fail).
So, this edge can't exist.
Note:
pinskia at gcc dot gnu dot org wrote:
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-24 04:27
---
Another interesting case would be (but which could be handled by VRP):
int
foo (int a)
{
a = a!=0;
a = a!=0;
a = a!=0;
a = a!=0;
a = a!=0;
return a;
}
hosking at cs dot purdue dot edu wrote:
--- Comment #7 from hosking at cs dot purdue dot edu 2006-08-23 22:29
---
This is with the Modula-3 backend. I am porting it to 4.1.1 and encountered
this problem with -O3 turned on.
Does 4.1 have the check for EDGE_CRITICAL_P in
hosking at cs dot purdue dot edu wrote:
--- Comment #11 from hosking at cs dot purdue dot edu 2006-08-24 00:57
---
(In reply to comment #9)
Does 4.1 have the check for EDGE_CRITICAL_P in insert_aux?
Yes:
/* This can happen in the very weird case
pinskia at gcc dot gnu dot org wrote:
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-22 06:17
---
We should never had needed resize_phi_node inside PRE and resize_phi_node also
does an exact replacement so that means you are keeping a reference to the old
PHI node when
pinskia at gcc dot gnu dot org wrote:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-08 01:47
---
SSA copy prop with dce after that should really be the correct way.
Err, SSA copy prop should be enough, actually, since after copy-prop,
the phi will have no users (and
sorenj at us dot ibm dot com wrote:
--- Comment #2 from sorenj at us dot ibm dot com 2006-06-19 16:44 ---
Changing just one line of the test program to the (AFAIK) legal C code. By
casting through void *, we are addressing Andrew's concerns about violating
the
C rules.
No you
pinskia at gcc dot gnu dot org wrote:
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-13 04:41
---
Hmm, we get after dce, just:
reduced_cell_two_folds[26] = {};
And DCE removes:
this_616 = reduced_cell_two_folds[26].u;
# SMT.68_1055 = V_MAY_DEF
steven at gcc dot gnu dot org wrote:
--- Comment #4 from steven at gcc dot gnu dot org 2006-06-02 23:19
---
Real bug, despite Andrew's usual portion of x86-hate.
It'd be good to know what exactly is going wrong.
Reassociation only touches floating point because someone asked me
I haven't looked into the rev. history, to see why/when this fix was made,
but will ask the hypothetical: was this fix made to workaround the
misbehavior in create_tmp_var_raw()? Note that create_tmp_var_raw()
is exported from gimplify.c and appears to be called from quite a few
places.
On Sun, 2006-04-23 at 23:14 +, pinskia at gcc dot gnu dot org wrote:
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-04-23 23:14
---
Rewritting that loop like:
[kudzu:local/trunk/gcc] pinskia% svn diff tree-ssa-loop-niter.c
Index: tree-ssa-loop-niter.c
On Apr 13, 2006, at 1:30 PM, rspencer at x10sys dot com wrote:
--- Comment #6 from rspencer at x10sys dot com 2006-04-13
20:30 ---
Created an attachment (id=11261)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11261action=view)
Timing results with -fno-tree-salias
Andrew
--- Comment #10 from stevenb dot gcc at gmail dot com 2006-04-08 21:13
---
Subject: Re: IVs with the same evolution not eliminated
The new SCC value numberer for PRE i'm working on gets this case right (and
this is in fact, one of the advantages of SCC based value numbering).
On Thu, 2006-04-06 at 11:49 +, jakub at gcc dot gnu dot org wrote:
On the attached testcase with today's gcc-4_1-branch
-m32 -g -O2 I get ICE during copy propagation. Unfortunately, even doing
minor
changes in different routines makes the problem go away.
What I see in the dumps is:
1)
Compare pretmp.28_49 with pretmp.32_11, why are the arguments in a different
order? Is there something unstable in the PRE algorithm?
No, we just call fold on the expressions we build, and whatever it gives
us, we use :)
On Tue, 2006-03-21 at 15:02 +, malitzke at metronets dot com wrote:
--- Comment #5 from malitzke at metronets dot com 2006-03-21 15:02
---
The two if (tree_code(genop) == VALUE_HANDLE) at lines 2190 of tree-ssa-pre.c
look suspicious to me.
They aren't suspicious at all.
On Fri, 2006-03-17 at 12:40 +, mueller at gcc dot gnu dot org wrote:
--- Comment #2 from mueller at gcc dot gnu dot org 2006-03-17 12:40
---
one possible workaround would be to lower the ARRAY_REF's to indirect mem
refs,
which I don't track
Uh, no.
We are in fact, trying
On Thu, 2006-03-09 at 22:54 +, pinskia at gcc dot gnu dot org wrote:
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-09 22:54
---
The difference between copyprop and before is the following.
Before:
rv.0_3 = rv.0_2;
# VUSE NMT.7_13;
D.1900_4 = rv.0_3-d;
On Wed, 2006-03-08 at 18:59 +, pinskia at gcc dot gnu dot org wrote:
Testcase:
int *d1;
int g(int *b)
{
d1 = b;
}
int f(int a, int b, int c)
{
int i, j;
int *d;
if (a)
d = i;
else
d = j;
i = 2;
j = 3;
g(b);
if (i!=2)
link_error();
if (j!=3)
On Fri, 2006-02-24 at 13:06 +, pinskia at gcc dot gnu dot org wrote:
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-24 13:06
---
Confirmed. Though VRP2 is just doing constant propagation at this point.
Last time i looked at a bug like this, it was actually some
On Thu, 2006-02-23 at 18:37 +, jb at gcc dot gnu dot org wrote:
--- Comment #2 from jb at gcc dot gnu dot org 2006-02-23 18:37 ---
I have the current CVS of cp2k, it fails with
gfortran -c -O3 -g -ffast-math -fomit-frame-pointer message_passing.f90
...
message_passing.f90:
On Thu, 2006-02-16 at 21:40 +, pinskia at gcc dot gnu dot org wrote:
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-16 21:40
---
We get:
# bitmap_free_7 = PHI bitmap_free_1(4), bitmap_free_6(5);
L0:;
# bitmap_free_1 = PHI bitmap_free_7(3), bitmap_free_2(2);
Flags: -O3
GCC 4.0 (release branch today):
real0m24.412s 0m25.000s 0m24.771s
user0m23.921s 0m24.430s 0m24.210s
sys 0m0.368s0m0.408s0m0.420s
GCC 4.1 (release branch today):
real0m33.260s 0m33.140s 0m33.188s
user
On Sun, 2006-01-01 at 00:41 +, pinskia at gcc dot gnu dot org wrote:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-01 00:41
---
Just a clarification here, I just want the SFT for k.j to be considered call
clobbered for this testcase.
This is not anywhere near as
On Wed, 2005-11-09 at 23:45 +, steven at gcc dot gnu dot org wrote:
--- Comment #10 from steven at gcc dot gnu dot org 2005-11-09 23:45
---
Actually, flow.c does get it right.
Okay, then df.c on dataflow branch should get it right too.
On Sun, 2005-11-06 at 15:46 +, pinskia at gcc dot gnu dot org wrote:
Take the following code:
int f(int);
int g(void)
{
int i;
int *iptr = i;
int **ipp = iptr;
**ipp = 1;
f(i);
return **ipp;
}
--
Here we consider i being call clobber because we lose the fact
On Thu, 2005-10-13 at 03:34 +, pinskia at gcc dot gnu dot org wrote:
--- Comment #57 from pinskia at gcc dot gnu dot org 2005-10-13 03:34
---
A semi recent 4.1 (the 10th) gives:
tree PTA : 1.60 ( 6%) usr 0.02 ( 1%) sys 1.73 ( 6%) wall
10338 kB ( 1%) ggc
On Sun, 2 Oct 2005, ben at decadentplace dot org dot uk wrote:
--- Comment #1 from ben at decadentplace dot org dot uk 2005-10-02 23:16
---
Can someone please remove this from public view, as Mozilla does for security
bugs on their Bugzilla?
Unlike mozilla, we do not remove
On Fri, 2005-09-30 at 13:58 +, rearnsha at gcc dot gnu dot org
wrote:
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-09-30
13:58 ---
(In reply to comment #1)
volatile is needed here.
No, the manual says:
An @code{asm} instruction without any output
On Fri, 2005-09-30 at 14:07 +, pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-30
14:07 ---
I still say this is invalid.
well, that just makes you wrong.
the docs clearly say it's supposed to be treated as volatile.
On Thu, 2005-09-22 at 08:31 +, rguenth at gcc dot gnu dot org wrote:
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-22
08:31 ---
load-pre should sink the load and fix the problem at the tree level.
Uh, load PRE doesn't sink loads, it would lift it.
On Sat, 2005-09-17 at 02:12 +, pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-17
02:12 ---
Confirmed.
The new reassoc should take care of this
On Sun, 2005-08-14 at 17:32 +, pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14
17:32 ---
Here is something which is a little more reduced:
int f[100];
int g[100];
unsigned char
f1 (int a, int b)
{
unsigned ix;
On Fri, 2005-08-12 at 19:10 +, pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-12
19:10 ---
Personally, i think -funsafe-loop-optimizations should be on by default
in -O3, with a warning for when we rely on it.
It's
On Tue, 9 Aug 2005, jacob dot navia at ants dot com wrote:
--- Additional Comments From jacob dot navia at ants dot com 2005-08-09
19:57 ---
If I can't mix SJLJ exceptions with DWARF2 exceptions how this is supposed to
work?
How is what supposed to work?
I mean I have to rebuild
On Tue, 2005-08-09 at 04:11 +, woodzltc at sources dot redhat dot
com wrote:
--- Additional Comments From woodzltc at sources dot redhat dot com
2005-08-09 04:11 ---
OK. I had some time and would like to have a look into this, and I found
something inconsistent. My founding is
On Sun, 2005-08-07 at 19:50 +, jacob dot navia at ants dot com
wrote:
We have a program (c++) that needs c++ SJLJ exceptions. We have built all
compilers from 3.3.1 to 3.3.6 and they all have the same bug:
In the first throw that the program does, we get an exception in the runtime
On Fri, 2005-07-22 at 00:57 +, jacob dot navia at ants dot com
wrote:
Because there is a size limitation to 64K in this software.
I prepared a single file with no includes that faithfully reproduced the bug:
bug0.cpp: In member function 'double AtomicDouble::CompareExchange(double,
On Thu, 2005-07-14 at 17:13 +, pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-14
17:13 ---
Confirmed, patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00918.html.
I'm waiting for mainline to settle a bit
On Mon, 2005-06-20 at 16:05 +, Joseph S. Myers wrote:
On Mon, 20 Jun 2005, Daniel Berlin wrote:
The crash line is
3729 if (pedantic !DECL_IN_SYSTEM_HEADER (fundecl))
Here, fundecl is null.
Any problem with fundecl being null should also be reproducible
On Sun, 2005-05-22 at 19:36 +, rakdver at gcc dot gnu dot org wrote:
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-05-22
19:36 ---
Because do_something does not have to return, therefore
get_type2 does not necessarily have to be executed.
In this case we
.
Nevertheless, even if we are very strict with the definition, moving
get_type2 out of the loop is not a good idea, since get_type2 might
potentially be very expensive (and we have no way how to determine
that this is not the case), thus we would lose in case get_type2
should be never
On Sun, 2005-05-22 at 21:13 +, rakdver at atrey dot karlin dot mff
dot cuni dot cz wrote:
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-05-22 21:13 ---
Subject: Re: missed optimization due with const function and pulling out of
loops
On Sun, 2005-05-22 at 21:36 +, rakdver at gcc dot gnu dot org wrote:
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-05-22
21:36 ---
Do you still believe we should move gettype2 out of the loop???
Okay, let's compromise.
If i move cgraph do noreturn and infinite
On Sun, 2005-05-22 at 21:51 +, rakdver at atrey dot karlin dot mff
dot cuni dot cz wrote:
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-05-22 21:50 ---
Subject: Re: missed optimization due with const function and pulling out of
loops
on the other hand, we should not let the definition make the concept
useless. Being able to make
The definition actually matches what other compilers call isolated (no
access to global variables) combined with the property called
side-effect free (calling multiple times with same parameters
On Sat, 2005-04-23 at 16:52 +, steven at gcc dot gnu dot org wrote:
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-23
16:52 ---
Will the second part of the struct alias merge fix Dann's original
test case? (http://gcc.gnu.org/wiki/Structure Aliasing Part II)
On Mon, 2005-03-28 at 23:05 +, piaget at us dot ibm dot com wrote:
--- Additional Comments From piaget at us dot ibm dot com 2005-03-28
23:05 ---
323 compares 2 values across a function call ... somthing a programmer can
reasonably consider. My problem occurs with 2 successive
On Tue, 2005-03-08 at 03:18 +, pinskia at physics dot uc dot edu
wrote:
--- Additional Comments From pinskia at physics dot uc dot edu
2005-03-08 03:18 ---
Subject: Re: The missed-optimization of general induction variables in the
new rtl-level loop optimizer cause performance
-23 Daniel Berlin [EMAIL PROTECTED]
* tree-ssa-dom.c (record_equality): Use loop depth to determine
which way to record the equality as well.
(loop_depth_of_name): New
On Fri, 28 Jan 2005, jv244 at cam dot ac dot uk wrote:
--- Additional Comments From jv244 at cam dot ac dot uk 2005-01-28
16:31 ---
You could try gfortran -O3 -mtune=pentium4 -ffast-math -mfpmath=sse
-ftree-loop-linear -ftree-vectorize yourcode.f90 and see if it helps.
Unhappily, seems
I believe seb/zdenek already submitted patches for speeding up scev quite
recently, with the goal of alleviating this problem.
I'm pretty sure they have not been applied yet.
On Sun, 24 Jan 2005, rakdver at gcc dot gnu dot org wrote:
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-01-24
01:46 ---
On a side note, PRE also seems to have problems with the testcase. With the
patch mentioned above, the largest consumers of compile time are
The reason is dead simple: register allocation is NP-complete, so it
is even *theoretically* not possible to write register allocators that
always find a coloring.
register allocation in general is NP-complete, yes, but it seems u forget
that
this is about finding the optimal solution while gcc
On Mon, 10 Jan 2005, pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-10
21:56 ---
Confirmed, I think this is the boost ICE.
This happens because the orig_decl that we are trying to use in emitting
the using decl info appears to
On Wed, 5 Jan 2005, ghazi at gcc dot gnu dot org wrote:
When running the testsuite with -fpic/-fPIC, I get an additional failure in the
testsuite with mainline:
FAIL: gcc.c-torture/execute/921215-1.c compilation, -O3 -g
The regression appeared sometime in the last day or so between these
Accept bug should now assign the bug to you, as one expects it to.
Sorry it took so long for me to fix this, it kept falling off my todo
list since it was really a minor annoyance :)
--Dan
On Thu, 16 Dec 2004, Hugh Daniel wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Note, I gave up on GNATS after repeatedly getting this error message
no matter what I did to the text:
You have not described how to repeat the bug
You have not defined a category for the bug
If there is a
On Fri, 10 Dec 2004, andre maute wrote:
Once more i couldn't upload an attachment
with the bugzilla upload form, so i send it here.
You can email it to [EMAIL PROTECTED] with a subject of Bug 16613
(or whatever the bug number is), and it'll auto-add it to the bug for you.
Yes, it happens ta global scope too.
struct foo {}
void method () {}
will give the same error
On Sun, 8 Nov 2004, sabre at nondot dot org wrote:
On this c++ code:
struct C {
struct foo { int A; }
void method();
};
This probably also happens at global scope.
-Chris
96 matches
Mail list logo
