--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-13 06:46 ---
Dump shows:
static char string[4][1:20] = {"A ", "B ",
"C ", "D ", "E " }
Check should probably be in resolve.c's check_data
--- Comment #4 from echristo at apple dot com 2007-06-13 06:36 ---
Patch looks reasonable.
--
echristo at apple dot com changed:
What|Removed |Added
CC|
--- Comment #3 from daney at gcc dot gnu dot org 2007-06-13 06:26 ---
Created an attachment (id=13696)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13696&action=view)
Proposed fix.
I will try to bootstrap the Proposed fix tomorrow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-13 06:26 ---
> Maybe some people should read __carefully__ both the C standard and the new
> GPL3
What does that mean? There is a working draft of dfp in the C standards
committee
See http://www.open-std.org/jtc1/sc22/wg14/ww
Found at:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/34f509b6b4241c6d/
program chkdata
character(len=20), dimension(4) :: string
data ( string(i) ,i=1,5 ) / &
'A', 'B', 'C', 'D', 'E' /
write(*,*) string
end program chkdata
gfortran gives no warning/e
--- Comment #3 from malitzke at metronets dot com 2007-06-13 06:06 ---
Maybe some people should read __carefully__ both the C standard and the new
GPL3
--
malitzke at metronets dot com changed:
What|Removed |Added
--
--- Comment #2 from daney at gcc dot gnu dot org 2007-06-13 05:58 ---
I have a prototype patch that I think fixes this problem.
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
---
--
malitzke at metronets dot com changed:
What|Removed |Added
CC||pluto at agmk dot net
Severity|normal |
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-13 05:46 ---
The main reason why you still need libdecnumber is because other front-ends
could support dfp even without the C/C++ front-ends supporting it.
--
pinskia at gcc dot gnu dot org changed:
What|Remov
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-13 05:44 ---
Even if you disable dfp, libdecnumber is still needed to compile gcc as
disable-decimal-float really just disables the C interface.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
disable-decimal-float not working on i686, powerpc, sparc neither gcc-4.2.1 nor
gcc-4.3.0
Proof; below is a compossite from directory libdecnumber(top of config.status
and ls -l)
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a m
--- Comment #6 from stevenb dot gcc at gmail dot com 2007-06-13 05:22
---
Subject: Re: [4.3 Regression] ICE in remove_insn, at emit-rtl.c:3579 at -O3
I'll take a look this weekend.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31987
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-06-13 05:16
---
Found the problem. We are checking the iterator variable type but not the
start, end, and step value types. Patch will come sometime in the next few
days.
--
jvdelisle at gcc dot gnu dot org changed:
--- Comment #4 from kargl at gcc dot gnu dot org 2007-06-13 05:09 ---
(In reply to comment #3)
> (In reply to comment #2)
> > Until I know for sure, i am moving this back to the fortran component, it
> > might
> > be a front end issuse still.
> >
> Andrew,
>
> I think that you are pro
--- Comment #3 from pault at gcc dot gnu dot org 2007-06-13 04:58 ---
(In reply to comment #2)
> Until I know for sure, i am moving this back to the fortran component, it
> might
> be a front end issuse still.
>
Andrew,
I think that you are probably right - it looks like my patch for
--- Comment #9 from spark at gcc dot gnu dot org 2007-06-13 03:48 ---
(In reply to comment #8)
> Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
>
> > I think the solution is to remove this check from the insn definition
> > in pa.md and change the check in hppa_
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-13
03:45 ---
Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
> I think the solution is to remove this check from the insn definition
> in pa.md and change the check in hppa_can_use_return_insn_p(
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-06-13 00:55
---
Also see failure at optimizations -O1, -O2, -O3 on x86-64-gnu-linuz (intel)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140
disable-jvmpi --disable-static --disable-libmudflap
--enable-languages=c,c++,java
Thread model: posix
gcc version 4.3.0 20070612 (experimental)
/home/build/gcc-build/./prev-gcc/cc1 -fpreprocessed build/gengtype.i -quiet
-dumpbase gengtype.i -march=mips32 -msoft-float -mno-shared -auxbase-stri
--- Comment #4 from alf dot lacis at aiscientific dot com 2007-06-12 23:33
---
I did *not* say I wanted a new format for __DATE__ & __TIME__ (reread my
request).
I wanted *new* macros. For example:
Macro: Expands to:
___MM_DD__ 2007-02-20 also know as 'Swedish format' (ne
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-12
23:30 ---
Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
> hppa_can_use_return_insn_p() is called
> from "return" insn pattern in pa.md.
> The pattern looks:
>
> (define_insn "return"
> [
--- Comment #6 from spark at gcc dot gnu dot org 2007-06-12 23:07 ---
(In reply to comment #5)
> Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
>
> > @@ -4384,7 +4385,7 @@ hppa_can_use_return_insn_p (void)
> > {
> >return (reload_completed
> > &&
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-12
22:59 ---
Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
> @@ -4384,7 +4385,7 @@ hppa_can_use_return_insn_p (void)
> {
>return (reload_completed
> && (compute_frame_size (get_f
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
At revision 125625 (and 125652) There is a bootstrap failure due to a SIGSEGV
while running gengtype in stage 2.
A successful bootstrap was done for r125494.
I think the dataflow branch merge is a likely culprit here.
The problem is that $gp is not being restored before a call to a local
functio
--- Comment #14 from reimer dot daniel at freenet dot de 2007-06-12 22:13
---
http://www.reactos.org/paste/index.php/1aa48fc/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30335
--- Comment #13 from reimer dot daniel at freenet dot de 2007-06-12 22:07
---
I tried the second Patch from danny and got the same results when I tried to
build ReactOS in MultiCore, as with this one I used before.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30335
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-06-12 22:03
---
I can't reduce that any more, it depends on the module files being huge: if you
trim them down to a lower number of symbols, they ICE disapears. And I can't
reproduced it either on x86_64-linux.
--
http://gcc
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-06-12 22:01 ---
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00586.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-06-12 21:57 ---
The difference is that we iterated jump threading in DOM in 4.1 but do so no
longer. On the mainline each dom and vrp pass figures more jump threading
opportunities - just not enough. With 4.1 the third and last DO
--- Comment #4 from spark at gcc dot gnu dot org 2007-06-12 21:43 ---
This patch should fix the bootstrap. I was in the process of running some
regtests when gsyprf11 got reset.
diff -r f78a38a8334b gcc/config/pa/pa.c
--- a/gcc/config/pa/pa.cThu May 31 11:43:34 2007 -0700
+++ b/
--- Comment #6 from pranav dot bhandarkar at gmail dot com 2007-06-12
21:14 ---
dom, in 4.1 is able to combine the if conditions unlike 4.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
--- Comment #5 from pranav dot bhandarkar at gmail dot com 2007-06-12
21:10 ---
Created an attachment (id=13694)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13694&action=view)
A smaller Testcase that displays the said behaviour
Reduced the testcase. Reducing to less than b1 thr
--- Comment #2 from ghazi at gcc dot gnu dot org 2007-06-12 20:59 ---
Created an attachment (id=13693)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13693&action=view)
testcase for ICE
Target sparc-sun-solaris2.10 and run:
cc1 -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- 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"
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
/usr/local/s
--- 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 work
--- 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 #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=gcc&view=rev&rev=125655
Log:
2007-06-12 Andrew Pinski <[EMAIL PROTECTED]>
PR mi
--- 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 #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 #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 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 differe
--- 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: "CTemp" is not a class template
template int CTemp< int >::sta;
^
--
rguenth at gcc dot gnu dot org changed:
--- 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 #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)
@@ -269,6
--- 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 #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 #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=13692&action=view)
Testcase and module files that generate the ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32310
--- 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 awa
--- 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
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 (short)((short)
--- 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:
> (shor
--- 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 provides:
--- 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=gcc&view=rev&rev=125653
Log:
./:
PR libstdc++/29286
* tree.def: Add CHANGE_DYNAM
--- 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 #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 do
--- 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 #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 + (int)short
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 strin
--- 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 i
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.
Reaso
--- 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
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 #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
--- 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
bug
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
|
--- 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=13691&action=view)
The ii file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32308
--- 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 significa
--- 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;
+S.
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
--program-suffix=-4
--- 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
--
--- 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
-fprefetch-
--- 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 va
--- 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=13690&action=view)
alternate version of bug file which has if 0 around offensive code
I hacked on the file that tripped the bug and n
--- 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|Rem
--- 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 #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=13689&action=view)
preprocessed code to generate problem
The following should reproduce the error:
m68k-rtems4.8-gcc -m528x -c log_
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 .deps/libshtt
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
--- 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,
--- 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 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
t.ii: In member function 'void S2::f2()':
t.ii
--- 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 #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=13688&action=view)
Code Generated by 4.3
--
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=13687&action=view)
Code Generated by 4.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
--- 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=13686&action=view)
Tes
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
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 && b1
--- 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 set
--- 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 #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 #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
> 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
tree-into-ssa.c
--- 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 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 #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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- 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?
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
Priori
1 - 100 of 135 matches
Mail list logo
