g++-4.0 did not optimize const double as a const, it put it in BSS. This bug
does not exist in g++-3.4, it also exist in g++-4.1.
The versions:
g++-3.4: gcc version 3.4.5 20050821 (prerelease) (Debian 3.4.4-8)
g++-4.0: gcc version 4.0.2 20050913 (prerelease) (Debian 4.0.1-7)
g++-4.1(gcc-snapshot):
--- 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 : Change
--- 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 : Change
--- 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=9779&action=view)
Remove gratuitous calls to _S_get_pool in __mt_alloc
Since I didn't find any reason for thes
--- Additional Comments From jvdelisle at gcc dot gnu dot org 2005-09-20
05:07 ---
Fixed in 4.1
--
What|Removed |Added
Status|ASSIGNED|RESOLV
--
What|Removed |Added
CC||vapier at gentoo dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22541
--- 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,
>
--- 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=9778&action=view)
Patch generated with diff -e against gcc 4.0.1 - corrects gcc_libexec_prefix
when GCC_EXEC_PREFIX is set.
--- Additional Comments From laurent at guerby dot net 2005-09-19 22:13
---
Good idea.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever C
--- 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
St
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
21:46 ---
Reopening to ...
--
What|Removed |Added
Status|RESOLVED|REOP
--- 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: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 - () ivtmp.37D.1332_3]
>
> Where thi
--- 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 - () ivtmp.37D.1332_3]
Where this is an ARRAY_REF and a couple of the
--- 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.
--
http://gcc.gnu.org/
--- 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 i
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 S
--- 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 stm
--- 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 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: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
--
What|Removed |Added
Component|c |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23972
--- 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
CC||rakdver at gcc dot gnu dot
||org
Component|target
--- 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).
--
http://gcc.gnu.org/bugzilla/show_bu
--- 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=9777&action=view)
Preprocessed sample code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23972
--- 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=9776&action=view)
Sample C++ code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23972
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 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 tur
--- 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 tsv at solvo dot ru 2005-09-19 19:21 ---
Created an attachment (id=9775)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9775&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23971
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 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 jan
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 to
--
What|Removed |Added
Keywords||alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23969
--
What|Removed |Added
CC||rakdver at atrey dot karlin
||dot mff dot cuni dot cz
http://gc
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; khttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=23970
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
--- 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
-
--- 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 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 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=9774&action=view)
complete testcase
Combining comment #1 and the testcase, declaring some functions and exchaning
printf f
--- 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).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- 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 Milesto
--
What|Removed |Added
BugsThisDependsOn||23604
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23968
--
What|Removed |Added
OtherBugsDependingO||23968
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23445
--
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=23046
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: P
--- 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
http://gcc.gnu.org/ml/gcc-testresults/2005-09/
--- 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 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 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: Change
--- 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: Cha
--- 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: inv
--- 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 th
--- 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 pathologic
--- 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 the
--
What|Removed |Added
Severity|minor |enhancement
Keywords||diagnostic
http://gcc.gnu.org/bugzilla/show_bug.c
--- 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 bsi_remo
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 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 an
--- 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
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot
|dot org |org
URL|
--- 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 current
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
15:23 ---
(In reply to comment #1)
> where the solution for dealing with releasing ssa names now that we have
> immediate use data available all the time is to simply add a lightning fast
> pass
> which removes unuse
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-09-19
15:19 ---
Another patch that improves the code on i686:
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01159.html
(with -O2 -fomit-frame-pointer:)
.L4:
movl(%ebp,%edx,4), %eax
movl%e
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
15:14 ---
*** Bug 23962 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
15:14 ---
*** This bug has been marked as a duplicate of 19546 ***
--
What|Removed |Added
--
What|Removed |Added
Severity|critical|normal
Keywords||ice-on-valid-code
Summary|internal compiler
--
What|Removed |Added
Known to fail||4.0.2
Known to work||4.1.0
Summary|MMX intrinsics cause ICE in |[4
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
14:45 ---
I could sware this was discussed before in a bug.
--
What|Removed |Added
Severity|
--
What|Removed |Added
Component|c |target
Keywords||ice-on-valid-code, ssemmx
http://gcc.gnu.org/bugzilla/
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot
|dot org |org
URL|
For the testcase
template void foo(T);
void bar()
{
struct A a;
foo(a);
}
the we get the following error message since GCC 3.4.0:
bug.cc: In function 'void bar()':
bug.cc:5: error: aggregate 'A a' has incomplete type and cannot be defined
bug.cc:6: error: no matching funct
--- Additional Comments From amacleod at redhat dot com 2005-09-19 14:03
---
I thought there was a discussion in
http://gcc.gnu.org/ml/gcc/2005-08/msg00692.html
where the solution for dealing with releasing ssa names now that we have
immediate use data available all the time is to sim
--- Additional Comments From glebius at FreeBSD dot org 2005-09-19 13:21
---
Subject: Re: -Wparentheses doesn't catch all assignments used as truth value
On Mon, Sep 19, 2005 at 01:14:18PM -, falk at debian dot org wrote:
f> > Well, all these examples are assignments. I don't agree
--- Additional Comments From falk at debian dot org 2005-09-19 13:14
---
(In reply to comment #2)
> Well, all these examples are assignments. I don't agree that '=' is a somewhat
> unique or special assignment.
But of course it is. It is the only case where people make mistakes.
> Acc
--- Additional Comments From glebius at FreeBSD dot org 2005-09-19 13:06
---
Subject: Re: -Wparentheses doesn't catch all assignments used as truth value
On Mon, Sep 19, 2005 at 12:28:55PM -, falk at debian dot org wrote:
f> --- Additional Comments From falk at debian dot org
--- Additional Comments From falk at debian dot org 2005-09-19 12:28
---
(In reply to comment #0)
> The -Wparentheses switch (as well as -Wall) doesn't catch logical assignments
used as truth values. For example:
>
> int i = 0;
>
> if (i |= 1) {};
> if (i ^= 1) {};
> if (i &= 1) {};
W
--- Additional Comments From Erwin dot Unruh at fujitsu-siemens dot com
2005-09-19 12:25 ---
Created an attachment (id=9773)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9773&action=view)
testcase supplement
Here is some additional coding, which calls the function given in the bu
The -Wparentheses switch (as well as -Wall) doesn't catch logical assignments
used as truth values. For example:
int i = 0;
if (i |= 1) {};
if (i ^= 1) {};
if (i &= 1) {};
--
Summary: -Wparentheses doesn't catch all assignments used as
truth value
Prod
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-19
11:07 ---
Even the bad timings for postreload-gcse are almost entirely to blame on RTL
alias analysis:
CPU: P4 / Xeon with 2 hyper-threads, speed 3194.18 MHz (estimated)
Counted GLOBAL_POWER_EVENTS events (time du
The following code causes an ICE with any -O flag except -O0:
#include
#include
int main(int argc, char *argv[]) {
__m64 a, b, c;
a = b = c = (__m64)(uint64_t)argc; /* Load with arbitrary values */
a = _mm_slli_pi16(a, 3);
a = _mm_adds_pi16(a, b);
c = _mm_srli_pi16(c, 8);
gfortran -c bug3.f90
bug3.f90: In function set_value:
bug3.f90:12:
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu
TOTAL : 129.54 5.37 135.98
Peak memory usage is 468694 kB (4.0.2 20050919) vs. 532350 kB (4.1.0 20050916).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23955
--
Bug 22101 depends on bug 16606, which changed state.
Bug 16606 Summary: gfortran error with a valid derived type definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16606
What|Old Value |New Value
--
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-19
08:18 ---
*** Bug 16606 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
Bug 159
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-19
08:18 ---
*** This bug has been marked as a duplicate of 15975 ***
--
What|Removed |Added
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-19
08:15 ---
Are you sure you did mean PR23490? This talks about a rtl problem...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23955
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
07:12 ---
For anyone else.
Read http://gcc.gnu.org/bugs.html
The non bug section: "Casting does not work as expected when optimization is
turned on." part.
Also 14024 is the bug for C++ front-end not reporting possib
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
07:09 ---
*** Bug 23961 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
07:09 ---
No because you are violating C/C++ aliasing rules.
See http://gcc.gnu.org/bugs.html
"Casting does not work as expected when optimization is turned on."
It applies to both C and C++.
Yes -Wstrict-aliasing
Compiler version:
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.4/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-excep
94 matches
Mail list logo
