--- Comment #9 from ubizjak at gmail dot com 2007-06-12 07:01 ---
Following patch should fix the ICE:
Index: combine.c
===
--- combine.c (revision 125636)
+++ combine.c (working copy)
@@ -5210,11 +5210,17 @@
The following source code:
!-
PROGRAM ERR_MINLOC
INTEGER, PARAMETER :: N = 7
DOUBLE PRECISION, DIMENSION (N), PARAMETER :: A
= (/ 0.3D0, 0.455D0, 0.6D0, 0.7D0, 0.72D0, 0.76D0, 0.79D0 /)
DOUBLE PRECISION :: B
INTEGER :: I, J, K
DO I = 1, N
--- Comment #10 from ubizjak at gmail dot com 2007-06-12 08:26 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00759.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
$ gcc -v -c gcc43.adb
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../SOURCES/gcc-4.3-20070608/configure --prefix=/usr
--enable-languages=c,c++,ada
Thread model: posix
gcc version 4.3.0 20070608 (experimental)
/usr/libexec/gcc/i686-pc-linux-gnu/4.3.0/gnat1 -quiet -dumpbase
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-06-12 10:05 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #11 from uros at gcc dot gnu dot org 2007-06-12 10:31 ---
Subject: Bug 32293
Author: uros
Date: Tue Jun 12 10:31:04 2007
New Revision: 125643
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125643
Log:
PR rtl-optimization/32293
* combine.c
--- Comment #8 from rob1weld at aol dot com 2007-06-12 10:53 ---
should be many more tests.
It's OK. I followed the advice on page http://gcc.gnu.org/install/test.html -
Section 0.1 How can you run the testsuite on selected tests?.
make check-gcc RUNTESTFLAGS=dg-torture.exp
I did
--- Comment #5 from rob1weld at aol dot com 2007-06-12 11:11 ---
Here is another, this caught some errors! See end of:
http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00573.html
print grep -e undefined\\ reference\\ to
/opt/gcc-4_3-build/gcc/testsuite/gcc/gcc.log | sort -u -k 2 |
--- Comment #3 from rob1weld at aol dot com 2007-06-12 11:16 ---
FIX - Altered dg-timeout:
/root/downloads/gcc-4_3-trunk/libmudflap/testsuite/libmudflap.cth/pass37-frag-Origonal.c
/* { dg-output 100 100 100 100 100 100 100 100 100 100 } */
/* { dg-repetitions 20 } */
/* { dg-timeout
--- Comment #5 from rob1weld at aol dot com 2007-06-12 11:21 ---
[EMAIL PROTECTED]
Fixed.
Nope.
Results for 4.3.0 20070611 (experimental) testsuite on i686-pc-linux-gnu
http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00573.html
A portion of this bug report is duplicated at:
--- Comment #4 from tbm at cyrius dot com 2007-06-12 11:22 ---
This works with 4.3.0 20070604 on mips.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32289
--- Comment #1 from rob1weld at aol dot com 2007-06-12 11:24 ---
These bug were first mentioned in report:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31681
Confirmed for similar target:
Results for 4.3.0 20070611 (experimental) testsuite on i686-pc-linux-gnu
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-06-12 11:29 ---
mainline uses 10MB to compile reduced-problem.ii.nocrap. So this is actually
a dup of PR29433.
*** This bug has been marked as a duplicate of 29433 ***
--
rguenth at gcc dot gnu dot org changed:
--- Comment #24 from rguenth at gcc dot gnu dot org 2007-06-12 11:29
---
*** Bug 32290 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-06-12 11:31
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
cat bug.ii
struct vector {
int *start, *finish;
unsigned long size() { return finish - start; }
};
void f(vector v) {
for (unsigned i = 0; i v.size(); ++i);
}
g++ -O2 -fsee bug.ii
bug.ii: In function void f(vector):
bug.ii:7: internal compiler error: Segmentation
--- Comment #3 from rob1weld at aol dot com 2007-06-12 11:37 ---
Even if they did change it back people may still have one of these versions
since _all_ my versions of gas are less than a year old.
Oneis the newest that apt-get will fetch (IE: the standard OS version),
another is the
--- Comment #5 from tbm at cyrius dot com 2007-06-12 11:43 ---
I can reproduce this with current 4.1 from SVN, but not with 4.2 from SVN.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32289
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-12 12:06 ---
Subject: Bug 31657
Author: rguenth
Date: Tue Jun 12 12:06:19 2007
New Revision: 125644
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125644
Log:
2007-06-12 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-06-12 12:06
---
Subject: Bug 15353
Author: rguenth
Date: Tue Jun 12 12:06:19 2007
New Revision: 125644
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125644
Log:
2007-06-12 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-06-12 12:08
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-12 12:08 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-06-12 12:10 ---
The new if-combining pass can be told to make the transformation suggested in
the description.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-12 12:36 ---
Confirmed. A dataflow merge fallout probably:
Program received signal SIGSEGV, Segmentation fault.
0x007c449c in df_insn_refs_verify (collection_rec=0x7fff1ab011c0,
bb=0x2aec90911360,
When the code below is compiled with -march=pentium4 -msse2 -O3
-fomit-frame-pointer, when N == 4 f() is correct:
f:
movdqa b, %xmm0
paddd a, %xmm0
movdqa %xmm0, c
ret
However for N == 2 gcc 4.2.0 doesn't use %mm0 any more (gcc 4.0.0 worked OK).
OK, for some
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-12 12:40 ---
FYI
(gdb) bt
#0 0x007c449c in df_insn_refs_verify (collection_rec=0x70a74130,
bb=0x2aaeba99e360, insn=0x2aaeba7dafa0, abort_if_fail=1 '\001')
at
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-12 12:42 ---
This is on purpose as if the compiler used the MMX registers it would need to
emit emms but it does not do that yet. There are two other bugs about this
issue already too.
--
pinskia at gcc dot gnu dot org
--- Comment #3 from zadeck at naturalbridge dot com 2007-06-12 12:46
---
I am not surprised at this at all. Given that there are no regression tests
that use -fsee and this pass is never on by default.
I will look into this.
However, the big picture is that we need to make a
--- Comment #6 from ubizjak at gmail dot com 2007-06-12 12:48 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-06-12 13:37 ---
Yes, those should be at least excercised by the tortures. So, if enabling at
-O3
regtests ok I'd vote for enabling it there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300
--- Comment #1 from alessandro dot mei at elsagdatamat dot com 2007-06-12
13:30 ---
Created an attachment (id=13685)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13685action=view)
compiler output and warnings; the preprocessed file (*.ii) that triggers the
bug
the complete
The output of this program is correct when using -g, but incorrect with -O3 -
[dranta:~/junk] dir% cp dyna3dTest01.F Test01.F
[dranta:~/junk] dir% gfortran -g -O3 -std=legacy -DSGI -DWKSTN -DUNIX
-DVECLEN=32 -DDP -fcray-pointer -fno-automatic -o Test01 Test01.F
Test01.F:47.19:
--- Comment #2 from alessandro dot mei at elsagdatamat dot com 2007-06-12
13:42 ---
(From update of attachment 13685)
the complete command line that triggers the bug:
/home/mag/sviluppo/bin/bkeuti /home/mag/sviluppo/config/bkeuti.xml
/home/mag/sviluppo/config/processi.dtd /dev/null
--- Comment #3 from alessandro dot mei at elsagdatamat dot com 2007-06-12
13:48 ---
the exact version of GCC;
the system type;
the options given when GCC was configured/built;
gcc -v
Using built-in specs.
Target: powerpc-ibm-aix5.3.0.0
Configured with:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|c++ |target
GCC
See PR30252 comment #30 for bug analysis and a patch.
--
Summary: [4.3 Regression] SPEC2006 447.dealII miscompiled at -O3
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code, alias
Severity: normal
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-12 14:01 ---
And why do you think GCC is at fault? It is hard to debug this huge sources
really. Have you tried to pin point exactly where the issue. Do you have any
uninitialized variables? Are you going over array bounds?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #6 from michael dot a dot richmond at nasa dot gov 2007-06-12
14:04 ---
When you build gcc and gfortran on your mips box, do you specify your system
type as mips-unknown-linux-gnu or as mips64-unknown-linux-gnu?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32289
cat bug.ii
struct S {
S() {}
};
S f() {
static S s;
return s;
}
g++ -O bug.ii
bug2.ii: In function S f():
bug2.ii:6: internal compiler error: in set_mem_attributes_minus_bitpos, at
emit-rtl.c:1573
--
Summary: ICE in set_mem_attributes_minus_bitpos
--- Comment #7 from tbm at cyrius dot com 2007-06-12 14:12 ---
mips-linux-gnu, as the Debian package does. Why?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32289
cat bug.ii
struct S1 {
S1() {}
};
struct S2 {
void f2() {
static S1 s1;
}
};
void f(S2 s2) {
s2.f2();
}
g++ -O -fipa-pta bug.ii
bug1.ii: In function void f(S2):
bug1.ii:9: internal compiler error: in initialize_flags_in_bb, at
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-12 14:20 ---
readonly is set on this decl which is wrong.
I think I know what is wrong.
ipa-reference.c sets TREE_READONLY on the decl when it really should not be
(even though it is readonly now).
--
pinskia at gcc dot gnu
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-12 14:22 ---
*** Bug 31685 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-12 14:22 ---
I am going to mark this as a dup of bug 32304 (even though that is newer)
because it has a short testcase and I added some anyalsis to the problem there.
*** This bug has been marked as a duplicate of 32304 ***
--- Comment #8 from michael dot a dot richmond at nasa dot gov 2007-06-12
14:33 ---
(In reply to comment #7)
mips-linux-gnu, as the Debian package does. Why?
When I run the configure script on an SGI Indy under Debian 4.0, it sets the
system type to mips64-unknown-linux-gnu, and
For the following Code Snippet
void bar ()
{
b1 = foo(1);
b2 = foo(1);
b3 = foo(1);
b4 = foo(1);
b5 = foo(1);
b6 = foo(1);
b7 = foo(1);
b8 = foo(1);
b9 = foo(1);
b10 = foo(1);
b11 = foo(1);
b12 = foo(1);
array[0] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
--- Comment #1 from pranav dot bhandarkar at gmail dot com 2007-06-12
14:48 ---
Created an attachment (id=13686)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13686action=view)
Tes
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
--- Comment #2 from pranav dot bhandarkar at gmail dot com 2007-06-12
14:50 ---
Created an attachment (id=13687)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13687action=view)
Code Generated by 4.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
--- Comment #3 from pranav dot bhandarkar at gmail dot com 2007-06-12
14:50 ---
Created an attachment (id=13688)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13688action=view)
Code Generated by 4.3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-06-12 15:06 ---
Try to narrow it down to sth shorter. (Looks like a jump-threading issue)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-12 15:08 ---
trunk-g/gcc ./cc1plus -O -fipa-pta t.ii
S1::S1() S1::S1() S1::S1() void S2::f2() void f(S2)
Analyzing compilation unit
Performing interprocedural optimizations
visibility early_local_cleanups inline static-var
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-12 15:09 ---
Until I know for sure, i am moving this back to the fortran component, it might
be a front end issuse still.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-12 15:03 ---
Works with 4.1.3 20070521.
Fails with 4.2.1 20070604.
Fails with 4.3.0 20070612. (On x86_64 Linux)
Result is ok (1.0 1.0) for real(4), but not for real(8) (0.25 0.25).
-O1 is also ok, but not -O2.
I used gfortran
4.3.0 20070612 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.3.0 20070612 (experimental), GMP version
4.2.1, MPFR version 2.2.0.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32258
The full command line is below. It appears to be triggered by -m528x and is
indepdendent of selected optimization level.
m68k-rtems4.8-gcc --pipe -DHAVE_CONFIG_H -I..
-I../../cpukit/../../../uC5282/lib/include -DHAVE_MD5 -Wall -fasm -m528x -O2
-g -MT libshttpd_a-log.o -MD -MP -MF
--- Comment #1 from joel at gcc dot gnu dot org 2007-06-12 15:17 ---
Created an attachment (id=13689)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13689action=view)
preprocessed code to generate problem
The following should reproduce the error:
m68k-rtems4.8-gcc -m528x -c
--- Comment #2 from joel at gcc dot gnu dot org 2007-06-12 15:21 ---
Tested using RTEMS cross RPMs for RTEMS 4.6 (gcc 3.2.3) and RTEMS 4.7 (gcc
4.1.1).
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-06-12 15:31
---
This is not a bug.
Here is the deal, the reporter compiled GCC with the new headers but is using
the old library (which is known to be buggy).
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #3 from joel at gcc dot gnu dot org 2007-06-12 15:39 ---
Created an attachment (id=13690)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13690action=view)
alternate version of bug file which has if 0 around offensive code
I hacked on the file that tripped the bug and
--- Comment #5 from alessandro dot mei at elsagdatamat dot com 2007-06-12
15:41 ---
(In reply to comment #4)
And why do you think GCC is at fault? It is hard to debug this huge sources
really. Have you tried to pin point exactly where the issue. Do you have any
uninitialized
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-06-12 15:44
---
(In reply to comment #1)
While the assert is occurs in the middle end, I think it is very likely a
tree-type mismatch in the front end.
I think it is. It also fails for me on i686-darwin, with -O2
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-06-12 15:47
---
I see it also with today's compiler on i686-darwin:
$ gfortran test.f90 -O2 ./a.out
a.bb ccc
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
gcc -v :
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-12 16:05 ---
The result is ok, if one removes PARAMETER.
If one looks at the dump one find the following difference between arrays which
are parameters and those which are variables:
-S.3 = 0;
+
--- Comment #7 from dcb314 at hotmail dot com 2007-06-12 16:05 ---
(In reply to comment #5)
I am finally getting around to testing the patch (been busy with a release of
our own toolchain last week).
I can confirm that this bug still exists in gcc snapshot
20070608.
Is it
--- Comment #1 from cxcxcxcx at gmail dot com 2007-06-12 16:08 ---
Created an attachment (id=13691)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13691action=view)
The ii file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32308
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
|
--- Comment #9 from tbm at cyrius dot com 2007-06-12 16:31 ---
O32, just like Debian. Note that 4.0 also uses O32, although the kernel is
64-bit, so that might explain why it's configuring mips64 for you.
I don't see the point of these questions though. After all, I confirmed your
--- Comment #2 from tomash dot brechko at gmail dot com 2007-06-12 16:43
---
Sorry, I failed to find two other reports you reference, maybe I'm repeating
someone's questions then. Okay, there are reasons not to use %mm0, but why
%xmm0 is not used then? Something like
f:
movq
void Sub(short * __restrict src1row, short * __restrict src2row, int
num_in_row) {
for(int i=num_in_row; i--;) {
*src1row -= *src2row;
++src1row;
++src2row;
}
}
In the test case above, GCC inserts several explicit conversions soon after the
gimple transformation stage and gets,
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-12 17:20 ---
The conversions are not Unnecessary, they are necessary because
short_var+short_var when that would overflow the range of short is still
defined.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32309
I'm working towards reducing this, but it's coming slowly :(
The code attached leads to an ICE with:
$ gfortran -c -O0 qs_mo_types.f90
gfortran: Internal error: Illegal instruction (program f951)
The backtrace for the ICE is:
Program received signal EXC_BAD_ACCESS, Could not access memory.
--- Comment #2 from gangren at google dot com 2007-06-12 17:28 ---
(In reply to comment #1)
The conversions are not Unnecessary, they are necessary because
short_var+short_var when that would overflow the range of short is still
defined.
Do you mean that short_var + short_var is
when I do
FILE *f = fopen(...);
double k = 10;
fprintf(file, k\x00%f, k);
only the string k will be written to the file (And this is the problem, since
I want the strings k and 10.0 to be separated by the symbol with the code
0).
If I do
fprintf(file, k\0x20%f, k);
then the correct string k 10.0
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-12 17:36 ---
Do you mean that short_var + short_var is defined as
(short)((unsigned short)short_var + (unsigned short)short_var)?
Kinda, because it is really defined by the C standard as:
(short)((int)short_var +
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-12 17:36 ---
*** Bug 32309 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-12 17:40 ---
This is correct behavior because strings are really char arrays terminated by
the null character (0 aka '\x00') so when you write k\x00%f, you really have
a string that is only of length 1.
--
pinskia at gcc dot
--- Comment #4 from dorit at il dot ibm dot com 2007-06-12 17:46 ---
it's on my (long) todo list...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32309
--- Comment #177 from ian at gcc dot gnu dot org 2007-06-12 17:47 ---
Subject: Bug 29286
Author: ian
Date: Tue Jun 12 17:47:37 2007
New Revision: 125653
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125653
Log:
./:
PR libstdc++/29286
* tree.def: Add
--- Comment #15 from rob1weld at aol dot com 2007-06-12 17:50 ---
Correctly Rounded mathematical library
http://lipforge.ens-lyon.fr/www/crlibm/index.html
CRlibm, an efficient and proven correctly-rounded mathematical library
CRlibm is a free mathematical library (libm) which
--- Comment #5 from gangren at google dot com 2007-06-12 17:53 ---
(In reply to comment #3)
Do you mean that short_var + short_var is defined as
(short)((unsigned short)short_var + (unsigned short)short_var)?
Kinda, because it is really defined by the C standard as:
On 12 Jun 2007 17:53:19 -, gangren at google dot com
[EMAIL PROTECTED] wrote:
I'm aware of integral promotion. But not quite understand why we can optimize
(short)((int)short_var + (int)short_var) to (short)((unsigned short)short_var +
(unsigned short)short_var), but not to
--- Comment #6 from pinskia at gmail dot com 2007-06-12 17:56 ---
Subject: Re: Unnecessary conversion from short to unsigend short breaks
vectorization
On 12 Jun 2007 17:53:19 -, gangren at google dot com
[EMAIL PROTECTED] wrote:
I'm aware of integral promotion. But not quite
--- Comment #7 from gangren at google dot com 2007-06-12 18:10 ---
(In reply to comment #6)
Subject: Re: Unnecessary conversion from short to unsigend short breaks
vectorization
On 12 Jun 2007 17:53:19 -, gangren at google dot com
[EMAIL PROTECTED] wrote:
I'm aware of
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-06-12 18:10
---
Created an attachment (id=13692)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13692action=view)
Testcase and module files that generate the ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32310
--- Comment #178 from ian at airs dot com 2007-06-12 18:10 ---
Fixed on mainline. No plans to backport the patch to previous releases.
--
ian at airs dot com changed:
What|Removed |Added
--- Comment #5 from zadeck at naturalbridge dot com 2007-06-12 18:13
---
This bug should be assigned to Mircea Namolaru [EMAIL PROTECTED]. I have
sent him mail asking that he get a proper bugzilla id.
==
The underlying problem is that see.c:2732 uses
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-12 18:16 ---
The patch which fixes the problem:
Index: ipa-reference.c
===
--- ipa-reference.c (revision 125637)
+++ ipa-reference.c (working copy)
@@
--- Comment #8 from ian at airs dot com 2007-06-12 18:25 ---
Undefined signed overflow is a language issue, not a processor issue. When
signed overflow is undefined, the compiler can and does make certain
assumptions about the results of operations. For example, it assumes that a +
1
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-12 18:46 ---
should read
template int CTemp int ::sta;
because
t.C(13): error: CTempint is not a class template
template class T int CTemp int ::sta;
^
--
rguenth at gcc dot gnu dot org
--- Comment #9 from gangren at google dot com 2007-06-12 18:58 ---
(In reply to comment #8)
if later compilation passes could prove that the computation
overflowed in short, then the result would be different than if the
computation
were done in int.
The result could be different.
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-12 19:02 ---
*** This bug has been marked as a duplicate of 24791 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-06-12 19:02 ---
*** Bug 32308 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-06-12 19:13 ---
Looks like the dataflow merge now exposes this to SPEC2000 FDO runs on x86_64
for wupwise and gcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31987
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-12 19:16 ---
Subject: Bug 31579
Author: pinskia
Date: Tue Jun 12 19:15:50 2007
New Revision: 125655
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125655
Log:
2007-06-12 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-06-12 19:16 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-06-12 19:17 ---
Now in mainline.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to
I'm getting a new bootstrap failure on sparc-sun-solaris2.10 in stage1 building
libgcc2.a:
/tmp/kg/pat/build/./gcc/xgcc -B/tmp/kg/pat/build/./gcc/
-B/usr/local/sparc-sun-solaris2.10/bin/ -B/usr/local/sparc-sun-solaris2.10/lib/
-isystem /usr/local/sparc-sun-solaris2.10/include -isystem
--- Comment #1 from ghazi at gcc dot gnu dot org 2007-06-12 20:37 ---
This worked as of June 9th, so it's recent.
The SEGV happens because df (used in the macro DF_REG_DEF_COUNT) is nil:
signal SEGV (no mapping at the fault address) in sparc_check_64 at line 7677 in
file sparc.c
1 - 100 of 129 matches
Mail list logo
