--- Comment #9 from uros at kss-loka dot si 2006-09-07 06:58 ---
I have built and run a testsuite of HDF5 library on i686-pc-linux-gnu with:
gcc version 4.2.0 20060906 (experimental)
hdf5-1.6.5 (production):
(CFLAGS="-fno-strict-aliasing" is needed before configure)
All
--- Comment #12 from jason at gcc dot gnu dot org 2006-09-07 06:53 ---
Subject: Bug 26195
Author: jason
Date: Thu Sep 7 06:53:21 2006
New Revision: 116740
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116740
Log:
PR c++/26195
* decl.c (make_rtl_for_nonlocal_dec
gcc-bugs@gcc.gnu.org
CSDGIF.GIF
Description: Binary data
--- 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
--- 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?
--
http://gcc.gnu.
--- 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
-
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 and
--- 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
---
--- 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=gcc&view=rev&rev=116739
Log:
2006-09-06 James E Wilson <[EMAIL PROTECTED]>
PR
--- 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
--
http://gcc.gnu.or
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 scan-
--- 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" ;) ;)
--
http://gcc.gnu.org/bugz
--- Comment #17 from bangerth at math dot tamu dot edu 2006-09-07 02:29
---
Subject: Re: What should be value of complex(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 have
--- 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 h
--- Comment #15 from joseph at codesourcery dot com 2006-09-07 01:57
---
Subject: Re: What should be value of complex(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
> permitted t
--- Comment #14 from joseph at codesourcery dot com 2006-09-07 01:52
---
Subject: Re: What should be value of complex(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 any
--- 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 #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 #11 from joseph at codesourcery dot com 2006-09-07 01:23
---
Subject: Re: What should be value of complex(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 may tur
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28946
--
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=28504
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27986
--- 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
-
--- 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=gcc&view=rev&rev=116737
Log:
PR c++/27371
* tree-inline.c (copy_result_decl_to
--- 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 #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:09
---
Fixed in 4.2.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- 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=gcc&view=rev&rev=116736
Log:
PR c++/28903
* pt.c (tsubst): Use fold_non
--- 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=gcc&view=rev&rev=116736
Log:
PR c++/28903
* pt.c (tsubst): Use fold_no
--- 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 #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
--- 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 #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
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- 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 $(
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 \
--w
--- 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
---
--- 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
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, a
--- 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 gimple
--- 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 #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 changed:
--- 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 complex clas
--- 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 complex class does) behaves exactly the other way
--- 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 ver
--- 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++ one
--- 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
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 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 |Adde
--- 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 com
--- 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=12200&action=view)
proposed patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28965
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
Versio
--- 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
Status|UNC
--- 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 h
--- 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=gcc&view=rev&rev=116724
Log:
PR c++/26696
* cvt.c (convert_to_void): Replace a
--- 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 i
--- 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 statu
--- 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
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 #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
--- 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
---
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
Statu
--- 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;
:
t.0 = (int) &t;
D.1520 = (int) &t[1];
D.1522 = (int) &t[2];
D.1524 = (int) &t[3];
return {t.0, D
--- 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.
(buil
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 --disab
--- 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.
--
http://gcc.gnu.org/bugzilla/show_b
--- 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 #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 #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=12199&action=view)
powerpc64-linux/libmudflap/config.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=12198&action=view)
make log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28962
--- 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=12197&action=view)
configure log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28962
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 #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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|c++ |target
http:
--- 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=12196&action=view)
Test case that exhibits unsafe exchange_and_add.
Using this test code, we are able to consistently create a heap co
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 --with-cross-h
--- 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 x86_64-pc-linux-g
[EMAIL PROTECTED] tmp]# cat a.cpp
#include
#include
__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, 1 ) );
--- 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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=289
--- 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=12195&action=view)
TEst case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28959
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] TEMP
--- 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.
--
http://gcc.gnu.org/bugzil
--- 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 #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
85 matches
Mail list logo
