--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-06 06:07 ---
Subject: Bug 28952
Author: pinskia
Date: Wed Sep 6 06:06:55 2006
New Revision: 116716
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116716
Log:
2006-09-05 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-09-06 06:08 ---
Fixed on the mainline, this is a latent bug on the 4.1 branch which was not
there in 4.0 so I will also apply it to the 4.1 branch after a week or so.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-09-06 06:13
---
Subject: Bug 28937
Author: pinskia
Date: Wed Sep 6 06:13:22 2006
New Revision: 116717
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116717
Log:
2006-09-05 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-09-06 06:14
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-09-06 06:14
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-09-06 06:30 ---
And here is a testcase which is reproducible without the vectorizer:
int t[4];
__attribute__((vector_size(16))) int f(void)
{
__attribute__((vector_size(16))) int t1 = {(int)t[0], (int)t[1], (int)t[2],
(int)t[3]};
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-09-06 06:33
---
Note I think the PPC-linux-gnu crash is actually caused by:
2006-06-20 Roger Sayle [EMAIL PROTECTED]
* expr.c (expand_expr_real_1) VECTOR_CST: For vector constants with
integer modes, attempt
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-06 06:36 ---
(In reply to comment #2)
This problem is recorded in a different place, we ignore bigger alignment for
stack variables currently. I don't have the number off hand either but I know
it has been filed.
--
--- Comment #9 from thomas at reactsoft dot com 2006-09-06 06:46 ---
(In reply to comment #8)
(In reply to comment #2)
This problem is recorded in a different place, we ignore bigger alignment for
stack variables currently. I don't have the number off hand either but I know
it has
--- Comment #5 from thomas at reactsoft dot com 2006-09-06 07:14 ---
(In reply to comment #3)
Actually this is just a missed diagnostic. The compiler cannot align the
stack
variables where the alignment is greater than stack alignment that the
compiler
can give for the stack.
--- Comment #3 from tvainika at gmail dot com 2006-09-06 07:31 ---
This same bug still applies to
g++-4.0 (GCC) 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)
and
g++-4.1 (GCC) 4.1.2 20060814 (prerelease) (Debian 4.1.1-11)
--
tvainika at gmail dot com changed:
What
--- Comment #9 from william dot grant at ubuntu dot com dot au 2006-09-06
07:43 ---
I've changed both those references, and have attached a new package to the
Ubuntu bug report for the reporter to test. I'll report back with results that
the tester has.
--
THe attached code produces the ICE.
[EMAIL PROTECTED] TEMP]$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/gcc42
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.2.0 20060905 (experimental)
[EMAIL PROTECTED]
--- Comment #1 from sfilippone at uniroma2 dot it 2006-09-06 09:45 ---
Created an attachment (id=12195)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12195action=view)
TEst case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28959
--- Comment #2 from sfilippone at uniroma2 dot it 2006-09-06 10:00 ---
The patch proposed in http://gcc.gnu.org/ml/fortran/2006-09/msg00020.html seems
to work for me, both in the reduced test case and in my original applicatin
code.
--
[EMAIL PROTECTED] tmp]# cat a.cpp
#include xmmintrin.h
#include stdio.h
__m128 mm;
void test ( const __m128 vm, float r )
{
mm = _mm_add_ps( mm, _mm_set_ps( 0.0f, r, r, r) );
float vm0, vm1, vm2;
_mm_store_ss( vm0, vm );
_mm_store_ss( vm1, _mm_shuffle_ps( vm, vm,
--- Comment #9 from uros at kss-loka dot si 2006-09-06 11:33 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00162.html implements
missing i386.md RTL patterns. This is i386 target-specific fix for this bug.
The patch was bootstrapped on i686-pc-linux-gnu and
When attempting to build an armeb-linux cross compiler on a RH Enterprise Linux
3.0 system, libstdc++ is not being built in a thread-safe manner. Here is the
configure command line:
configure --cache-file=./config.cache --host=armeb-linux
--build=i686-pc-linux-gnu --enable-multilib
--- Comment #1 from sethmoore at gmail dot com 2006-09-06 12:54 ---
Created an attachment (id=12196)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12196action=view)
Test case that exhibits unsafe exchange_and_add.
Using this test code, we are able to consistently create a heap
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|c++ |target
--- Comment #4 from markus at unixforces dot net 2006-09-06 13:02 ---
any news about this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28326
cd /TMP/build-gcc-svn20060906-powerpc64
/TMP/gcc-svn20060906/configure --target=powerpc64-linux
--prefix=/usr/local/DIR/gcc-powerpc64-svn20060906 --enable-languages=c
--with-as=/usr/local/bin/powerpc64-linux-as
--with-ld=/usr/local/bin/powerpc64-linux-ld --disable-shared
--enable-threads=single
--- Comment #1 from bunk at stusta dot de 2006-09-06 14:13 ---
Created an attachment (id=12197)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12197action=view)
configure log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28962
--- Comment #2 from bunk at stusta dot de 2006-09-06 14:13 ---
Created an attachment (id=12198)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12198action=view)
make log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28962
--- Comment #3 from bunk at stusta dot de 2006-09-06 14:15 ---
Created an attachment (id=12199)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12199action=view)
powerpc64-linux/libmudflap/config.log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28962
--- Comment #4 from bunk at stusta dot de 2006-09-06 14:19 ---
Note:
checking host system type... powerpc64-unknown-linux-gnu is obviously wrong
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28962
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-09-06 14:23 ---
Confirmed. With -mfpmath=sse I get
Before TEST: 1.00 2.00 3.00
In TEST: nan 2.00 3.00
After TEST: 1.00 2.00 3.00
with -mfpmath=sse,387
Before TEST: 1.00 2.00 3.00
--- Comment #10 from hjl at lucon dot org 2006-09-06 14:26 ---
The proposed patch will slow down Core and Core 2 by 70-100% in some testcases
due to partial flag register stall. I have a followup patch to implement
TARGET_PARTIAL_FLAG_REG_STALL.
--
gcc -v output:
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,f95,java,ada
--- Comment #11 from roger at eyesopen dot com 2006-09-06 15:27 ---
Hmm, yep I guess it was caused my change, most probably this part of it:
* tree.c (build_constructor_single): Mark a CONSTRUCTOR as constant,
if all of its elements/components are constant.
--- Comment #12 from roger at eyesopen dot com 2006-09-06 15:36 ---
Here's the .102t.final_cleanup
;; Function f (f)
f ()
{
int D.1524;
int D.1522;
int D.1520;
int t.0;
bb 2:
t.0 = (int) t;
D.1520 = (int) t[1];
D.1522 = (int) t[2];
D.1524 = (int) t[3];
return {t.0,
position_stack_vars sorts stack_vars_sorted in a manner that makes the order
of stack vars with equal size undefined, thus making the compiler output
host dependent.
--
Summary: partition_stack_vars uses unstable sort
Product: gcc
Version: 4.1.1
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-09-06 16:04
---
Confirmed according to the RTL logs.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from janis at gcc dot gnu dot org 2006-09-06 16:27 ---
This test still fails intermittently. Would someone who understands OpenMP
directives please take a close look at the test to see if it's valid? If not,
this seems like a serious problem.
--
janis at gcc dot gnu
On Wed, 2006-09-06 at 14:19 +, bunk at stusta dot de wrote:
--- Comment #4 from bunk at stusta dot de 2006-09-06 14:19 ---
Note:
checking host system type... powerpc64-unknown-linux-gnu is obviously wrong
No it is not.
-- Pinski
--- Comment #5 from pinskia at physics dot uc dot edu 2006-09-06 16:28
---
Subject: Re: [4.0/4.1/4.2 regression] building a
cross compiler with --disable-multilib fails
On Wed, 2006-09-06 at 14:19 +, bunk at stusta dot de wrote:
--- Comment #4 from bunk at stusta
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-06 16:32 ---
/usr/local/DIR/gcc-powerpc64-svn20060906/powerpc64-linux/sys-include -O2 -g -O2
conftest.c 5
/usr/local/bin/powerpc64-linux-ld: crt1.o: No such file: No such file or
directory
collect2: ld returned 1 exit status
--- Comment #6 from bjoern dot m dot haase at web dot de 2006-09-06 16:51
---
To clear up the issues.
1.) libgcc provides a fp emulation based on compiled c functions that is to my
very best knowledge untested for avr and extremely inefficient.
2.) avr-libc provides fp emulation that
--- Comment #6 from jason at gcc dot gnu dot org 2006-09-06 17:06 ---
Subject: Bug 26696
Author: jason
Date: Wed Sep 6 17:06:00 2006
New Revision: 116724
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116724
Log:
PR c++/26696
* cvt.c (convert_to_void): Replace a
--- Comment #2 from pcarlini at suse dot de 2006-09-06 17:11 ---
I think this difference is ultimately due to the existenxce of a separate *_O0
version of tree_lower_complex, in tree-complex.c. Rth added it (as part of
fixing 20610), I believe the generic version is right (-0), and I'm
--- Comment #3 from pcarlini at suse dot de 2006-09-06 17:11 ---
I think we can confirm it.
--
pcarlini at suse dot de changed:
What|Removed |Added
When placing a REG_DEAD note for a global register, distribute_notes no longer
checks if the register is set in the same insn.
--
Summary: distribute_notes fails to change REG_DEAD into
REG_UNUSED notes for global registers
Product: gcc
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-09-06 17:18 ---
Created an attachment (id=12200)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12200action=view)
proposed patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28965
--- Comment #7 from bunk at stusta dot de 2006-09-06 17:22 ---
I don't have a glibc for this target.
But this might be where my problems are coming from:
I am able to compile gcc 4.1.1 for at about a dozen targets without having any
libc for these targets present. And the resulting
--- Comment #4 from pcarlini at suse dot de 2006-09-06 18:43 ---
But this issue should be recategorized, is about lowering and optimization of
complex numbers, maybe Andrew can help about that?
--
pcarlini at suse dot de changed:
What|Removed
Testcase:
int f(void)
{
return 0;
}
This produces with -maltivec -O2:
f:
stwu 1,-16(1)
li 3,0
addi 1,1,16
blr
With just -O2, we get:
f:
li 3,0
blr
--
Summary: -maltivec -m32 causes the stack to be saved and restored
--- Comment #4 from jason at gcc dot gnu dot org 2006-09-06 18:47 ---
This is also complicated by PR 16269; we don't manage the lifetime of
temporaries, so we don't know whether an initialized temporary is used again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27371
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-06 18:50 ---
There are most likely a couple of different issues here. A front-end one with
(1.0+0.0i)*(-1) being expanded incorrectly, there is a bug about a case like
that too, see PR 24581. There might even be a libstdc++
--- Comment #6 from pluto at agmk dot net 2006-09-06 19:18 ---
(In reply to comment #2)
I think this difference is ultimately due to the existenxce of a separate *_O0
version of tree_lower_complex, in tree-complex.c. Rth added it (as part of
fixing 20610), I believe the generic
--- Comment #7 from pcarlini at suse dot de 2006-09-06 20:23 ---
Both the front-ends deal with 0 * -1 in the same way, the result is -0 (just
try). Anyway, the issue is crazy, a reduced pure C testcase (in principle
identical to what the complexdouble class does) behaves exactly the
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-06 20:27 ---
(In reply to comment #7)
Both the front-ends deal with 0 * -1 in the same way, the result is -0 (just
try). Anyway, the issue is crazy, a reduced pure C testcase (in principle
identical to what the complexdouble
--- Comment #3 from jason at gcc dot gnu dot org 2006-09-06 20:56 ---
This isn't only a problem in C++. In this C testcase:
struct A
{
int i[42];
};
struct A f();
int main()
{
f();
f();
f();
}
we allocate 3 'struct A' temporaries.
--
jason at gcc dot gnu dot org
--- Comment #9 from pcarlini at suse dot de 2006-09-06 20:59 ---
(In reply to comment #8)
This is PR 24581 after all then.
I don't know, I'm afraid there is even more to it :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28408
--- Comment #21 from jason at gcc dot gnu dot org 2006-09-06 21:39 ---
I expect that indeed, the test case Kenner mentioned as motivation for the call
to mark_temp_addr_taken doesn't need it any more because of gimplification.
Any temporary that needs to live longer than a single
When I build our application on Fedora Core 5 using gcc/ld the main library of
our (quite large) application links in about 10s on an older 1.7GHz Pentium
4/Xeon system. When I build the same app on my new PCs that have gcc 4.1.1 on
them, compiling is much faster, but linking is appallingly slow,
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-06 22:26 ---
Can you give the output of ld --version on both machines. GCC does not
really control ld but another project, binutils, does.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-06 22:26 ---
Also you should have reported this to Redhat first since it was their versions
of gcc/binutils you are using.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
When configuring gcc-{4.1.0,4.1.1} as
$ CC=gcc-4.1 ../gcc-4.1.1/configure --target=i586-pc-interix3 \
--enable-languages=c \
--enable-threads=no \
--with-stabs \
--enable-nls \
--disable-shared \
--disable-libssp \
--with-gnu-as \
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-06 23:08 ---
That is the incorrect fix.
The correct fix is to copy from t-cygming to t-interix:
winnt.o: $(srcdir)/config/i386/winnt.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \
$(TM_H) $(RTL_H) $(REGS_H) hard-reg-set.h output.h
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-06 23:10 ---
And the other question is how did you get passed PR 15212?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from mkoeppe at gmx dot de 2006-09-06 23:29 ---
(In reply to comment #2)
And the other question is how did you get passed PR 15212?
Don't know if it's really related! I didn't encounter it, but I built a cross
compiler and used only make and not make bootstrap.
--
--- Comment #10 from jason at redhat dot com 2006-09-07 00:14 ---
Subject: Re: [4.2 Regression] libstdc++ vs. anonymous namespaces
bkoz at gcc dot gnu dot org wrote:
This is precisely one reason why anonymous namespaces are useful. It provides
a
very viceral way to sanity check an
--- Comment #10 from pcarlini at suse dot de 2006-09-07 00:44 ---
I'm re-reading the various floating-point standards and Annexes and I think
this issue may turn out to be a not-a-bug. Whether those standards make sense
it's another matter ;) So, what I'm reading: C99, F.8.2 says that 0
--- Comment #12 from mmitchel at gcc dot gnu dot org 2006-09-07 01:04
---
Subject: Bug 28886
Author: mmitchel
Date: Thu Sep 7 01:04:07 2006
New Revision: 116736
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116736
Log:
PR c++/28903
* pt.c (tsubst): Use
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-09-07 01:04
---
Subject: Bug 28903
Author: mmitchel
Date: Thu Sep 7 01:04:07 2006
New Revision: 116736
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116736
Log:
PR c++/28903
* pt.c (tsubst): Use
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-09-07 01:09
---
Fixed in 4.2.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from mmitchel at gcc dot gnu dot org 2006-09-07 01:10
---
Fixed in 4.2.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28886
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-09-07 01:12
---
VAX is not a primary or secondary platform.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jason at gcc dot gnu dot org 2006-09-07 01:13 ---
Subject: Bug 27371
Author: jason
Date: Thu Sep 7 01:12:00 2006
New Revision: 116737
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116737
Log:
PR c++/27371
* tree-inline.c
--- Comment #13 from mmitchel at gcc dot gnu dot org 2006-09-07 01:13
---
AVR is not a primary or secondary platform.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27986
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28504
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28940
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28946
--- Comment #11 from joseph at codesourcery dot com 2006-09-07 01:23
---
Subject: Re: What should be value of complexdouble(1.0,0.0)
*= -1?
On Thu, 7 Sep 2006, pcarlini at suse dot de wrote:
I'm re-reading the various floating-point standards and Annexes and I think
this issue
--- Comment #12 from pcarlini at suse dot de 2006-09-07 01:33 ---
(In reply to comment #11)
F.8 is *illustrative* of transformations that are *not* permitted. It
doesn't permit anything.
Where do you read that in F.8.2 ?!? I read:
0 * x - 0.0The expressions 0 * x and 0.0
--- Comment #13 from pcarlini at suse dot de 2006-09-07 01:51 ---
And, by the way, it's also generally untrue that F8 is only illustrative of not
permitted transformations. For example, a few lines above:
1 * x and x / 1 - x The expressions 1 * x, x / 1 and x are equivalent
--- Comment #14 from joseph at codesourcery dot com 2006-09-07 01:52
---
Subject: Re: What should be value of complexdouble(1.0,0.0)
*= -1?
On Thu, 7 Sep 2006, pcarlini at suse dot de wrote:
F.8 is *illustrative* of transformations that are *not* permitted. It
doesn't permit
--- Comment #15 from joseph at codesourcery dot com 2006-09-07 01:57
---
Subject: Re: What should be value of complexdouble(1.0,0.0)
*= -1?
On Thu, 7 Sep 2006, pcarlini at suse dot de wrote:
And, by the way, it's also generally untrue that F8 is only illustrative of
not
--- Comment #16 from pcarlini at suse dot de 2006-09-07 02:04 ---
(In reply to comment #15)
Such statements also are informative, not normative. The normative
requirements come from F.3 (the operations shall be the IEC 60559
operations) and IEC 60559.
If you have IEC 60559 at
--- Comment #17 from bangerth at math dot tamu dot edu 2006-09-07 02:29
---
Subject: Re: What should be value of complexdouble(1.0,0.0)
*= -1?
If you have IEC 60559 at hand, and it explicitely says, as normative, that 0 *
-finite = -0 then, I agree that this is a bug. However, I
--- Comment #18 from pcarlini at suse dot de 2006-09-07 02:47 ---
(In reply to comment #17)
It is true that Appendix F has normative in the section title, but
F.8 starts out with
... in any case, the IEC 60559 entry in C99status reads Broken ;) ;)
--
Executing on host: /home/dave/gnu/gcc-4.2/objdir/gcc/xgcc
-B/home/dave/gnu/gcc-4
.2/objdir/gcc/ /home/dave/gnu/gcc-4.2/gcc/gcc/testsuite/gcc.dg/nrv3.c -O
-fdum
p-tree-optimized -fno-show-column -S -o nrv3.s(timeout = 300)
PASS: gcc.dg/nrv3.c (test for excess errors)
FAIL: gcc.dg/nrv3.c
--- Comment #10 from patchapp at dberlin dot org 2006-09-07 03:30 ---
Subject: Bug number PR middle-end/28862
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00204.html
--
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-09-07 04:24
---
Subject: Bug 27883
Author: pinskia
Date: Thu Sep 7 04:24:24 2006
New Revision: 116739
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116739
Log:
2006-09-06 James E Wilson [EMAIL PROTECTED]
PR
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-09-07 04:24
---
Fixed at least on the mainline now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
We generate bad code for the following test case using the latest 4.1 compiler.
It compiles and runs fine using 4.2. It also compiles and runs fine with my
3.3.3 system compiler. I've tested this on both x86_64 and ppc64 systems, and
the test case fails for both when compiled as a 32-bit app
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-07 05:01 ---
Confirmed, this is a loop.c bug which is why it is not in 4.2.0 at all.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from bergner at vnet dot ibm dot com 2006-09-07 05:14
---
Ok, this also passed regression tests on powerpc64-linux (32-bit and 64-bit
testsuite runs) for c, c++, fortran, objc, obj-c++ and java.
Does the attached patch look reasonable to everyone?
--
--- Comment #4 from hollis at penguinppc dot org 2006-09-07 05:22 ---
Andrew, could you elaborate on the FC5 kernel bug and the rules that are
always used?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27702
gcc-bugs@gcc.gnu.org
CSDGIF.GIF
Description: Binary data
92 matches
Mail list logo
