--- Additional Comments From amacleod at redhat dot com 2005-09-19 15:45
---
Did you read the original thread?
We aren't going back and forth over anything.
Diego added release_defs in 08/2004 because we did not have immediate_use
information freely available at the time. The
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot
|dot org |org
URL|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
15:49 ---
(In reply to comment #3)
Did you read the original thread?
Well then you do it since you made this mess in the first place.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23940
--- Additional Comments From amacleod at redhat dot com 2005-09-19 15:59
---
I don't understand. Exactly what mess did I make?
We also probably have to set SSA_NAME_DEF_STMT to NULL in bsi_remove in order to
be sure that an SSA name with no uses isn't actually associated with a stmt
The namespace reference in the code below is ambiguous. gcc 4.0.1 shows the
misleading error message
tst.cc: In function 'int main()':
tst.cc:16: error: 'N' has not been declared
tst.cc:16: error: 'f' was not declared in this scope
namespace N {
void f();
}
namespace A {
namespace N {
--- Additional Comments From pinskia at physics dot uc dot edu 2005-09-19
16:05 ---
Subject: Re: SSA_NAMEs are not released after no longer being used.
On Sep 19, 2005, at 11:59 AM, amacleod at redhat dot com wrote:
We also probably have to set SSA_NAME_DEF_STMT to NULL in
--
What|Removed |Added
Severity|minor |enhancement
Keywords||diagnostic
--- Additional Comments From amacleod at redhat dot com 2005-09-19 16:33
---
Its not the same thing since we arent actually releasing an SSA_NAME until
between passes. All we are doing is clearing the SSA_NAME_DEF_STMT field.
True that inserting a stmt after bsi_remove will not set
--- Additional Comments From amacleod at redhat dot com 2005-09-19 16:41
---
The culprit is in fact correct_uses. It was originally a linear function, and I
had added some short cut attempts which reduced it in many cases to not have to
traverse an entire list. Apparently the
--- Additional Comments From pinskia at physics dot uc dot edu 2005-09-19
16:44 ---
Subject: Re: SSA_NAMEs are not released after no longer being used.
On Sep 19, 2005, at 12:33 PM, amacleod at redhat dot com wrote:
And that will not work for the SSA_NAMEs used for aliasing and
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-19
16:52 ---
Subject: Bug 20211
CVSROOT:/cvs/gcc
Module name:gcc
Branch: sh-elf-4_1-branch
Changes by: [EMAIL PROTECTED] 2005-09-19 16:52:39
Modified files:
gcc/doc:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-19
16:54 ---
Subject: Bug 20211
CVSROOT:/cvs/gcc
Module name:gcc
Branch: sh-elf-4_1-branch
Changes by: [EMAIL PROTECTED] 2005-09-19 16:54:05
Modified files:
gcc:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-19
16:56 ---
Subject: Bug 23941
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-19 16:56:24
Modified files:
gcc:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-19
17:01 ---
Subject: Bug 23941
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-19 17:01:41
Modified files:
gcc: ChangeLog real.c
Added files:
--- Additional Comments From rth at gcc dot gnu dot org 2005-09-19 17:10
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-09-19
17:30 ---
Test results for sh-elf-4_1-branch with
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01176.html
are:
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00925.html
This bug represents all of the ICEs and wrong code because of VRP.
--
Summary: [meta-bug] VRP bug reports
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: wrong-code, ice-on-valid-code
Severity: normal
Priority:
--
What|Removed |Added
OtherBugsDependingO||23968
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23046
--
What|Removed |Added
OtherBugsDependingO||23968
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23960
--
What|Removed |Added
OtherBugsDependingO||23968
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23445
--
What|Removed |Added
BugsThisDependsOn||23604
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23968
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
17:46 ---
i?86-solaris is not a primary or a secondary target.
--
What|Removed |Added
Target
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
17:57 ---
: Search converges between 2004-05-11-trunk (#454) and 2004-05-14-trunk (#455).
: Search converges between 2003-10-30-ssa (#120) and 2003-10-31-ssa (#121).
--
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-19
17:57 ---
Created an attachment (id=9774)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9774action=view)
complete testcase
Combining comment #1 and the testcase, declaring some functions and exchaning
printf
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
17:58 ---
Obviously caused by:
2003-10-30 Richard Henderson [EMAIL PROTECTED]
* decl.c (pop_switch): Call c_do_switch_warnings.
--
What|Removed |Added
--- Additional Comments From amacleod at redhat dot com 2005-09-19 18:10
---
Do you mean SSA_NAME_DEF_FOR_STMT for i_4 would NOT be NULLed since we didnt
call bsi_remove on it?
if it is NULL, then it has no uses and we can simply remove it with the trip
through the SSA_NAME table.
If
--- Additional Comments From janis at gcc dot gnu dot org 2005-09-19 18:22
---
A reghunt on powerpc-linux shows the segfault starts with this patch from
[EMAIL PROTECTED]:
http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00537.html
--
What|Removed |Added
PRE fails to merge flow-sensitive alias-information for
void Ekin(double *e, int *stridee,
double *vx, int *stridevx,
double *vy, int *stridevy,
double *vz, int *stridevz,
int *sz)
{
int i1 = sz[0];
int j1 = sz[1];
int k1 = sz[2];
int i, j, k;
for
void Ekin(double *e, int *stridee,
double *vx, int *stridevx,
double *vy, int *stridevy,
double *vz, int *stridevz,
int *sz)
{
int i1 = sz[0];
int j1 = sz[1];
int k1 = sz[2];
int i, j, k;
for (k=0; kk1; ++k)
for (j=0; jj1; ++j)
for (i=0;
--
What|Removed |Added
CC||rakdver at atrey dot karlin
||dot mff dot cuni dot cz
--
What|Removed |Added
Keywords||alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23969
On Sep 19, 2005, at 2:22 PM, janis at gcc dot gnu dot org wrote:
--- Additional Comments From janis at gcc dot gnu dot org
2005-09-19 18:22 ---
A reghunt on powerpc-linux shows the segfault starts with this patch
from
[EMAIL PROTECTED]:
Then this is a latent bug as it does not
--- Additional Comments From pinskia at physics dot uc dot edu 2005-09-19
18:53 ---
Subject: Re: [4.1 Regression] segfault in expand_simple_operations,
tree-ssa-loop-niter.c:637
On Sep 19, 2005, at 2:22 PM, janis at gcc dot gnu dot org wrote:
--- Additional Comments From
gcc version 4.1.0 20050918 (experimental)
Compilation of attached file takes a long time with -O2 option.
If I use -O0 or -O2 -fno-ivopts it takes just 6 secs to complete (the
cross-compiler for alpha on x86-64 gcc version 4.0.1 20050727 (Red Hat
4.0.1-5) takes about 200 secs, but the native
--- Additional Comments From tsv at solvo dot ru 2005-09-19 19:21 ---
Created an attachment (id=9775)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9775action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23971
--- Additional Comments From janis187 at us dot ibm dot com 2005-09-19
19:42 ---
A regression hunt on i686-linux showed the failure starting with this patch
from [EMAIL PROTECTED]:
http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00640.html
--
What|Removed
--- Additional Comments From dj at redhat dot com 2005-09-19 19:57 ---
Subject: Re: [4.1 regression] ICE: no-op convert from 8 to 4 bytes in
initializer
DJ, apparently you caused this one.
Yup, and I had reservations about that portion of the patch at the
time, too, which have
When building the attached file with -O3 (to enable inlining), Saturate16 () is
inlined in Mul16_all () and its return value is lost:
movq%mm0, -24(%rsp) #
emms
movw%cx, (%r8) # tmp83,* pDst
Note that the %cx is not loaded from the slot at -24(%rsp) before
--- Additional Comments From evandro at yahoo dot com 2005-09-19 20:05
---
Created an attachment (id=9776)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9776action=view)
Sample C++ code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23972
--- Additional Comments From evandro at yahoo dot com 2005-09-19 20:06
---
Created an attachment (id=9777)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9777action=view)
Preprocessed sample code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23972
--- Additional Comments From Steve at Zook dot com 2005-09-19 20:06 ---
Test using i686-pc-cygwin with revision 4.0.1 shows problem resolved and good
code being emitted (although two new warnings are output about non-local
anonymous variables).
--
--
What|Removed |Added
CC||rakdver at gcc dot gnu dot
||org
Component|target
--- Additional Comments From evandro at yahoo dot com 2005-09-19 20:08
---
(In reply to comment #0)
Better yet:
movq%mm0, (%r8) #
emms
Ahem, never mind...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23972
--
What|Removed |Added
Component|c |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23972
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
20:17 ---
First try -fno-strict-aliasing, since:
return *(short*)tmp;
is violating them.
Second I think this is a known issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23972
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
20:25 ---
Yes this is a case where you are violating C/C++ aliasing rules.
*** This bug has been marked as a duplicate of 21920 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
20:25 ---
*** Bug 23972 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
--- Additional Comments From amacleod at redhat dot com 2005-09-19 20:34
---
Actually, it occurs to me that we might be able to make the entire
SSA_NAME_DEF_STMT process completely transparent, including the setting of it.
The operand cache knows whenever an SSA_NAME is added to any
Consider
package Ip is
type T is interface;
end Ip;
GNATMAKE 4.1.0 20050915 (experimental)
Copyright 1995-2004 Free Software Foundation, Inc.
ip.ali being checked ...
- ip.ali missing.
gcc -c -gnatwa -gnatf -gnatv ip.ads
GNAT 4.1.0 20050915 (experimental)
Copyright 1992-2005 Free
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-09-19
21:04 ---
(In reply to comment #3)
A regression hunt on i686-linux showed the failure starting with this patch
from [EMAIL PROTECTED]:
http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00640.html
If the lreg dump is
--- Additional Comments From janis187 at us dot ibm dot com 2005-09-19
21:08 ---
It is not true that the function that contains a bug that causes a segfault is
always in the backtrace for the failure; this isn't enough information to claim
this is a latent bug.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
21:12 ---
it is even more obvious it was a latent bug from looking at what we looking at
when we are scanning
over the operands:
lineD.1272[318 - (unnamed type) ivtmp.37D.1332_3]
Where this is an ARRAY_REF and a
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
21:14 ---
(In reply to comment #10)
it is even more obvious it was a latent bug from looking at what we looking
at when we are scanning
over the operands:
lineD.1272[318 - (unnamed type) ivtmp.37D.1332_3]
--- Additional Comments From falk at debian dot org 2005-09-19 21:18
---
Confirmed. Test case:
void rgb_ycc_start(long *rgb_ycc_tab) {
long i;
for (i = 0; i = 255; i++)
rgb_ycc_tab[i] = 19595 * i;
}
These 4 lines take 27 seconds to compile, nearly all of which is spent
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
21:46 ---
Reopening to ...
--
What|Removed |Added
Status|RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
21:47 ---
Closing as invalid as that is the official resolution.
--
What|Removed |Added
--- Additional Comments From laurent at guerby dot net 2005-09-19 22:13
---
Good idea.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever
--- Additional Comments From jason_gouger at mentor dot com 2005-09-20
02:14 ---
Created an attachment (id=9778)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9778action=view)
Patch generated with diff -e against gcc 4.0.1 - corrects gcc_libexec_prefix
when GCC_EXEC_PREFIX is set.
--- Additional Comments From jason_gouger at mentor dot com 2005-09-20
02:17 ---
(In reply to comment #0)
looking at gcc.c it looks like the problem is coming from the following line:
gcc_libexec_prefix = make_relative_prefix
(gcc_exec_prefix,
standard_exec_prefix,
--
What|Removed |Added
CC||vapier at gentoo dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22541
--- Additional Comments From jvdelisle at gcc dot gnu dot org 2005-09-20
05:07 ---
Fixed in 4.1
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From guillaume dot melquiond at ens-lyon dot fr
2005-09-20 05:07 ---
Created an attachment (id=9779)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9779action=view)
Remove gratuitous calls to _S_get_pool in __mt_alloc
Since I didn't find any reason for these
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-20
05:25 ---
Subject: Bug 19265
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-20 05:24:50
Modified files:
libstdc++-v3 :
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-20
05:25 ---
Subject: Bug 22309
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-20 05:24:50
Modified files:
libstdc++-v3 :
101 - 164 of 164 matches
Mail list logo
