Hans-Peter Nilsson wrote:
On Thu, 16 Feb 2006, Sylvain Munaut wrote:
Move/Load/Store without flag is no problem. But for add, to allow
multiword add, carry is needed and I can't make it optionnal.
As I hinted, perhaps you can have the multiword carry a separate
one from the flags carry,
Mark Mitchell wrote:
Mark, is it ok for Olivier to apply the patch mentioned here on
4.1?
Yes, thanks.
I have been away for a couple of days and see that the patch has been
committed to the various branches. Thanks :)
Andrew Pinski [EMAIL PROTECTED] writes:
Now I run into another problem:
/Users/pinskia/src/gcc/local/gcc/objdir.objc/./prev-gcc/xgcc
-B/Users/pinskia/src/gcc/local/gcc/objdir.objc/./prev-gcc/
-B/Volumes/temp/gcc/local.objc/powerpc-apple-darwin7.9.0/bin/ -c -g
-O2 -mdynamic-no-pic
Mark Mitchell wrote:
Please download, build, and test. Please use these tarballs, rather
than the current SVN branch, so that we test packaging, and other
similar issues.
Here it looks good so far on i686-pc-linux-gnu
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01036.html
Regards
Greg
No help? :-)
BTW Is there any documenation on machine?
I am looking at this one:
http://www.mhatt.aps.anl.gov/dohn/programming/gcc/gccint.html#SEC_Top
it might have been something else?
Thank you.
- Forwarded message from [EMAIL PROTECTED] -
Date: Wed, 08 Feb 2006 08:02:20 -0600
Andrew Haley wrote:
As a comparison point, I get
real73m39.275s
user113m19.549s
sys 15m26.010s
for the bootstrap: that's 1h14 elapsed time. That's on a AMD
Athlon(tm) 64 X2 Dual Core Processor 4800+ (2.4 GHz) with make -j3.
That's 129min of CPU time in 74min of elapsed time, a
Joern RENNECKE writes:
Andrew Haley wrote:
As a comparison point, I get
real73m39.275s
user113m19.549s
sys 15m26.010s
for the bootstrap: that's 1h14 elapsed time. That's on a AMD
Athlon(tm) 64 X2 Dual Core Processor 4800+ (2.4 GHz) with make -j3.
That's
Joern RENNECKE writes:
Andrew Haley wrote:
Is that using the i686 or amd64 instruction set? If the latter, does it
use 32 or 64 bit pointers?
The latter. Yes.
So which pointer size does the host compiler use, and which pointer size
is used in
the gcc that is
On Wed, 1 Feb 2006, H. J. Lu wrote:
My memory hog patch for make has 2 typos. This patch fixes them.
Thanks, H. J. What's the upstream status of your patches? Did you
submit your updated patch there as well?
(As long as this patch, or a similar change, has not become part of a
released
In libjava/classpath there are two .cvsignore files which haven't been
deleted yet:
native/jni/midi-alsa/.cvsignore
native/jni/midi-dssi/.cvsignore
Should they go, too?
They are also in GCC 4.1.0 RC1.
Regards,
Volker
In libjava/classpath there are two .cvsignore files which haven't been
deleted yet:
native/jni/midi-alsa/.cvsignore
native/jni/midi-dssi/.cvsignore
Should they go, too?
They are also in GCC 4.1.0 RC1.
They are imported from upstream :).
-- Pinski
Hello,
I have the interesting and somewhat taunting task of providing a
toolchain that assumes -msoft-float unless told otherwise. Obviously,
this can be arranged with appropriate changes to the specs, however I'd
like to integrate this in a way that would benefit everybody.
The general
On Mon, Feb 20, 2006 at 06:54:07PM +0100, Simon Richter wrote:
Hello,
I have the interesting and somewhat taunting task of providing a
toolchain that assumes -msoft-float unless told otherwise. Obviously,
this can be arranged with appropriate changes to the specs, however I'd
like to
Andrew Pinski writes:
In libjava/classpath there are two .cvsignore files which haven't been
deleted yet:
native/jni/midi-alsa/.cvsignore
native/jni/midi-dssi/.cvsignore
Should they go, too?
They are also in GCC 4.1.0 RC1.
They are imported from upstream :).
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bootstrap failure in libjava on ia64-unknown-linux-gnu.
Failure in building jv-convert:
/bin/sh ./libtool --tag=GCJ --mode=link
/disk1/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/gcc-4.1.0-RC1/gcc-4.1.0-RC1/gcc/gcj
-
Hello,
Working on an arm-vxworks port for Ada, we noticed that both
NO_DOT_IN_LABEL and NO_DOLLAR_IN_LABEL are defined, the former from
config/vxworks.h and the latter from arm/aout.h.
Is it really intended this way ?
NO_DOT_IN_LABEL is actually #undef'ed from config/vxworks.h, but the
Gerald wrote:
On Wed, 1 Feb 2006, H. J. Lu wrote:
My memory hog patch for make has 2 typos. This patch fixes them.
Thanks, H. J. What's the upstream status of your patches?
I think they're in upstream (hopefully H.J. will confirm that).
I know that the O(N^2) bug that Jeff Evarts found and
On Mon, Feb 20, 2006 at 10:51:13AM -0800, Dan Kegel wrote:
Gerald wrote:
On Wed, 1 Feb 2006, H. J. Lu wrote:
My memory hog patch for make has 2 typos. This patch fixes them.
Thanks, H. J. What's the upstream status of your patches?
I think they're in upstream (hopefully H.J. will confirm
DJ Delorie wrote:
There's not much difference between multi-core and multi-cpu, and I've
been building multi-cpu for years.
Some multi-core processors come with less L2 cache than their multi-CPU
counterparts.
Also, multi-cpu itself comes in different varieties, with Intels Xeons going
for
On Wed, Feb 01, 2006 at 01:21:03PM -0500, Andrew Pinski wrote:
We ran into a problem building KDE on HP-UX 11.23/IA with the HP C++
compiler. The compiler mangled a function name in a .cpp file though
it was declared extern C in the .h file. After a post to the HP C++
developers list,
On Feb 17, 2006, at 8:04 PM, Serge Dundich wrote:
I need to define the constant memory address/offset in i386 gcc
inline asm,
i.e. immediate value without $ prefix, so I can use it as a
constant offset for
some memory address statement.
Is there any way to do that?
Sure, the manual
On Mon, Feb 20, 2006 at 07:30:41PM +, Joern RENNECKE wrote:
the bottleneck of a shared memory bus, but the operating system must
allocate
most memory locally to each CPU to avoid a bottleneck in the cross-connect
of the processors.
Linux kernel 2.6.16-rc1 and above supports
H. J. Lu wrote:
On Mon, Feb 20, 2006 at 07:30:41PM +, Joern RENNECKE wrote:
the bottleneck of a shared memory bus, but the operating system must
allocate
most memory locally to each CPU to avoid a bottleneck in the cross-connect
of the processors.
Linux kernel 2.6.16-rc1 and
Laurent GUERBY wrote:
On a Pentium III 1GHz, bootstrap is 5h55 and check 5h30
(on an older version of the tree),
Was this before top-level bootstrap?
On Mon, Feb 20, 2006 at 07:58:35PM +, Joern RENNECKE wrote:
H. J. Lu wrote:
On Mon, Feb 20, 2006 at 07:30:41PM +, Joern RENNECKE wrote:
the bottleneck of a shared memory bus, but the operating system must
allocate
most memory locally to each CPU to avoid a bottleneck in the
On Sun, 2006-02-19 at 20:43 +0100, Laurent GUERBY wrote:
On Sun, 2006-02-19 at 14:23 -0500, Richard Kenner wrote:
Second, for a given integer type (such as
natural___XDLU_0_2147483647), the type for the nodes in TYPE_MIN_VALUE
and TYPE_MAX_VALUE really should be a
On 2/20/06, Jeffrey A Law [EMAIL PROTECTED] wrote:
On Sun, 2006-02-19 at 20:43 +0100, Laurent GUERBY wrote:
On Sun, 2006-02-19 at 14:23 -0500, Richard Kenner wrote:
Second, for a given integer type (such as
natural___XDLU_0_2147483647), the type for the nodes in TYPE_MIN_VALUE
Which leaves us with a very fundamental issue. Namely that we can not
use TYPE_MIN_VALUE or TYPE_MAX_VALUE for ranges.
The point is that it *is* supposed to be usable in general. If it can't
be used in a specific case, let's address that specific case and understand
what needs
Indeed. Ada should in this case generate
R = (T)( (basetype)100 + (basetype)X - (basetype)X )
i.e. carry out all arithmetic explicitly in the basetype and only for
stores and loads use the subtype.
That is indeed required by the language and what is normally generated.
It
Some multi-core processors come with less L2 cache than their multi-CPU
counterparts.
This, and your other arguments, while valid, apply independently of
the CPU. There are a lot of factors that determine compile speed.
FYI SGIs tend to have crossbars.
Was that UMA or NUMA, and how far up
On 2/20/06, Richard Kenner [EMAIL PROTECTED] wrote:
Indeed. Ada should in this case generate
R = (T)( (basetype)100 + (basetype)X - (basetype)X )
i.e. carry out all arithmetic explicitly in the basetype and only for
stores and loads use the subtype.
That is indeed
On Mon, 2006-02-20 at 19:40 +1100, Greg Schafer wrote:
Mark Mitchell wrote:
Please download, build, and test. Please use these tarballs, rather
than the current SVN branch, so that we test packaging, and other
similar issues.
Here it looks good so far on i686-pc-linux-gnu
On Feb 20, 2006, at 6:30 PM, Laurent GUERBY wrote:
one libstdc++ amd64 FAIL:
FAIL: abi_check
That is because you did not supply --enable-__cxa_atexit
to configure. This has been mentioned so many times it
might as well enabled it by default for GNU/Linux.
-- Pinski
Mark Mitchell wrote:
GCC 4.1.0 RC1 is here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.0-20060219
Looking fine on s390-ibm-linux and s390x-ibm-linux:
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01094.html
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01095.html
except for the recently
On Mon, 2006-02-20 at 18:34 -0500, Andrew Pinski wrote:
On Feb 20, 2006, at 6:30 PM, Laurent GUERBY wrote:
one libstdc++ amd64 FAIL:
FAIL: abi_check
That is because you did not supply --enable-__cxa_atexit
to configure. This has been mentioned so many times it
might as well enabled
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01095.html
FAIL: cc1010b
Artifact or real failure?
--
Eric Botcazou
Eric Botcazou [EMAIL PROTECTED] wrote on 21.02.2006 01:10:58:
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01095.html
FAIL: cc1010b
Artifact or real failure?
One of the usual artifacts ...
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand
GNU
One of the usual artifacts ...
Thanks. I've personally got them on Linux only, never ever on Solaris.
--
Eric Botcazou
[EMAIL PROTECTED] trunk]$ ../trunk/configure --enable-languages=c,fortran
--prefix=/home/wf/local
[EMAIL PROTECTED] trunk]$ make
[snip]
make[3]: Entering directory `/home/wf/svngcc/trunkbld/libiberty'
if [ x != x ]; then \
gcc -c -DHAVE_CONFIG_H -g -I. -I../../trunk/libiberty/../include -W
I think this is caused by a typos error in libiberty/pexecute.c. Doesn't
anyone
else see it?
Already fixed.
--- DJ Delorie [EMAIL PROTECTED]写道:
I think this is caused by a typos error in libiberty/pexecute.c. Doesn't
anyone
else see it?
Already fixed.
OK. Thanks.
Feng Wang
___
雅虎1G免费邮箱百分百防垃圾信
Hi,
I've been testing gcc-4.1 RC1 on x86-linux-gnu with SPEC CPU 2000.
There are two main reasons I did this:
a) gcc is used for research experimentation and many research folks rely
on SPECCPU2000
b) I, in particular, need SPEC CPU 2000 to work with profile driven
feedback.
On Feb 21, 2006, at 12:05 AM, Andrew Pinski wrote:
You need the alliterative source for this test.
s/alliterative/alternative/
-- Pinski
Hi,
While I read the mips.md, I find there are some constraints used in
function call templates, such as 'c' and 'j'. But these two
constraints seem not be defined and I can't find their explanation
both in source files and gcc internal. Well, aren't there anywhere I
missed? Otherwise, how can
Eric Fisher [EMAIL PROTECTED] writes:
While I read the mips.md, I find there are some constraints used in
function call templates, such as 'c' and 'j'. But these two
constraints seem not be defined and I can't find their explanation
both in source files and gcc internal. Well, aren't there
On Tue, Feb 21, 2006 at 12:45:15AM +0100, Ulrich Weigand wrote:
except for the recently introduced test case
FAIL: gcc.dg/20060218-1.c (test for errors, line 6)
FAIL: gcc.dg/20060218-1.c (test for excess errors)
This one should be already fixed on gcc-4_1-branch (after RC1
was released I
gcc 4.1.0 rc1 failes to bootstrap on my amd64 gentoo-box; the last release
gcc-4.1.0-20060217 bootstraps fine so it seems to be rc1 and not my gentoo
setup.
../gcc-4.1.0-20060219/configure --prefix=/home/xtv --program-prefix=x
--program-suffix=41rc1 --enable-languages=c,c++,objc,obj-c++,fortran
--- Comment #4 from mtodorov at alu dot hr 2006-02-20 08:18 ---
Subject: Re: LROTATE_EXPR/RROTATE_EXPR misexpanded by
middle-end/back-end for bitfields
On Thu, 16 Feb 2006, steven at gcc dot gnu dot org wrote:
--- Comment #3 from steven at gcc dot gnu dot org 2006-02-16
--- Comment #6 from dn dot tlp at gmx dot net 2006-02-20 08:20 ---
(In reply to comment #5)
I got the same problems for gcc-3.4.3. I fixed the iovec error by inserting
struct iovec {
void *iov_base;
size_t iov_len;
};
ssize_t writev (int filedes, const struct iovec
--- Comment #10 from walter dot zimmer at dlr dot de 2006-02-20 08:23
---
(In reply to comment #9)
Negative. The following valid code still fails on i386:
Strange: with gfortran gcc-4.1-20060210+fix x86_64-unknown-linux-gnu
it compiles and runs fine:
bash gfortran gfcbug31.f -Wall
--- Comment #6 from bonzini at gnu dot org 2006-02-20 08:29 ---
Subject: Bug 25476
Author: bonzini
Date: Mon Feb 20 08:29:17 2006
New Revision: 111295
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111295
Log:
2006-02-20 Paolo Bonzini [EMAIL PROTECTED]
PR
--- Comment #6 from bonzini at gnu dot org 2006-02-20 08:29 ---
Subject: Bug 25670
Author: bonzini
Date: Mon Feb 20 08:29:17 2006
New Revision: 111295
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111295
Log:
2006-02-20 Paolo Bonzini [EMAIL PROTECTED]
PR
--- Comment #5 from bonzini at gnu dot org 2006-02-20 08:35 ---
Fixed by patch for bugs 25670 and 25476
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #7 from bonzini at gnu dot org 2006-02-20 08:35 ---
patch committed
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from bonzini at gnu dot org 2006-02-20 08:36 ---
Please confirm that your usual command-lines work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25670
--- Comment #1 from themis_hv at yahoo dot co dot uk 2006-02-20 09:19
---
GCC here is expecting ld to be located at /home/xtv/bin/xld
Try adding --with-ld=/path/to/ld and --with-as=/path/to/as to configury
See if this makes any difference
--
--- Comment #11 from jakub at gcc dot gnu dot org 2006-02-20 09:26 ---
Subject: Bug 26334
Author: jakub
Date: Mon Feb 20 09:26:29 2006
New Revision: 111297
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111297
Log:
PR middle-end/26334
* gcc.dg/20060218-1.c: Moved
--- Comment #2 from xtv at tveith dot homelinux dot com 2006-02-20 09:52
---
(In reply to comment #1)
GCC here is expecting ld to be located at /home/xtv/bin/xld
Try adding --with-ld=/path/to/ld and --with-as=/path/to/as to configury
See if this makes any difference
The
Description:
We are targetting the compilers for a system-on-chip solution we are
developing based on an ARM 926 which is without an FPU so we have
defaulted on SOFTWARE FLOATING POINT.
#define TARGET_DEFAULT (ARM_FLAG_SOFT_FLOAT | ARM_FLAG_APCS_32 | \
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-02-20 10:51
---
*** This bug has been marked as a duplicate of 26337 ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-02-20 10:51
---
*** Bug 26378 has been marked as a duplicate of this bug. ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
#include mmintrin.h
void
foo (__m64 *p)
{
__m64 m;
m = p[0];
m = _mm_srli_pi16(m, 2);
m = _mm_slli_pi16(m, 8);
p[0] = m;
_mm_empty();
}
ICEs with both -O2 -m32 and -O2 -m64, in GCC 4.0.2, 4.1rc1 as well as trunk.
--
Summary: ICE on vector shift RTL simplification
--- Comment #1 from jakub at gcc dot gnu dot org 2006-02-20 11:01 ---
Obviously with -O2 -m32 -mmmx for 32-bit compiles.
The testcase compiles in GCC 3.2.3 and 3.4.5, so a regression.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pcarlini at suse dot de 2006-02-20 11:15 ---
... but DR 342 should be also taken into account...
--
pcarlini at suse dot de changed:
What|Removed |Added
Hello,
gcc 3.4.3 compiles and links the following code successfully:
#include iostream
class X
{};
template typename T
void g (const T t)
{
std::cout Function g was called std::endl;
}
template typename T
voidf()
{
T a;
gtypename S(a); //
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #3 from xtv at tveith dot homelinux dot com 2006-02-20 12:33
---
Without --program-prefix it bootstraps fine. So it seems to be a problem with
the configure-machinery.
Shall I close this bug and open a new one regarding configure?
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-20 12:52 ---
It did work at least in 4.1.0 20051026.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-20 12:57 ---
Fixed in 3.4.5 at least.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-20 13:06 ---
If this worked with 20060217 and does not with the RC1, this actually does
not make sense as there have been no configuring changes made between that
time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26377
--- Comment #5 from themis_hv at yahoo dot co dot uk 2006-02-20 13:12
---
--program-prefix works fine on i686-pc-linux with GCC 4.1.0 RC 1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26377
gcc-4.1.0-20060219.tar.bz2 won't untar with Solaris native tar.
x gcc-4.1.0-20060219/gcc/testsuite/gcc.dg/cpp/frame/one.framework/Frameworks, 0
bytes, 0 tape blocks
x
gcc-4.1.0-20060219/gcc/testsuite/gcc.dg/cpp/frame/one.framework/Frameworks/OneSub.framework,
0 bytes, 0 tape blocks
x
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-20 13:51 ---
Please read:
http://gcc.gnu.org/install/prerequisites.html
GNU tar version 1.12 (or later)
Necessary (only on some platforms) to untar the source code. Many systems' tar
programs will also work, only try GNU tar if
--- Comment #5 from ben dot midgley at ultra-datel dot com 2006-02-20
14:21 ---
I believe this is the same problem, if not it is a very similar and likely
related problem. I have nested the data types from the first code into an array
and have a similar message.
$ gcc -v
Using
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #4 from pcarlini at suse dot de 2006-02-20 14:24 ---
Suspended, waiting for 342 (now reopened) to reach the final resolution.
--
pcarlini at suse dot de changed:
What|Removed |Added
Hi,
We have found a bug for SuperH when trying for crossjumping and
-fif-conversion2 for gcc-3.4.4 and gcc-3.4.5.
Following is the simple test case,
//xfs2.c
1. void func (void)
2. {
3.if (foo3())
4. {
5.
--- Comment #3 from bonzini at gnu dot org 2006-02-20 14:46 ---
Note for posterity, a better patch for this has been inserted as part as fixing
PR12730, and this patch has been sort of reverted.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12512
--- Comment #9 from bonzini at gnu dot org 2006-02-20 14:47 ---
Just for the record, this patch also fixed PR12512 in a better way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12730
--- Comment #2 from sayle at gcc dot gnu dot org 2006-02-20 15:05 ---
Subject: Bug 26236
Author: sayle
Date: Mon Feb 20 15:05:15 2006
New Revision: 111305
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111305
Log:
PR middle-end/26236
* doc/c-tree.texi
--- Comment #3 from roger at eyesopen dot com 2006-02-20 15:05 ---
Fixed on mainline.
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-02-20
15:25 ---
(In reply to comment #1)
Confirmed, I think Paul Thomas is looking into this.
Yes, I got sidetracked into it!
Something is awry with the adding of variables to an equivalence segment in
anything other
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-02-20 16:13
---
This is indeed a dup of 19543 (at least, it's fixed by the same patch).
*** This bug has been marked as a duplicate of 19543 ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2006-02-20 16:13
---
*** Bug 20066 has been marked as a duplicate of this bug. ***
--
Bug 19543 depends on bug 20066, which changed state.
Bug 20066 Summary: Ordering of logical constants determines if they're
correctly emitted
--- Comment #6 from jv244 at cam dot ac dot uk 2006-02-20 16:13 ---
#4 0x006714fb in compensate_edge (e=0x2a959776c0, file=0x0) at
/scratch/vondele/gcc_40_branch/gcc/gcc/reg-stack.c:2795
this assert was last modified by nathan (from svn ann, revision 87244), who
seems to be
--- Comment #7 from nathan at gcc dot gnu dot org 2006-02-20 16:24 ---
I'm guessing my change was in converting an if () abort () into gcc_assert, and
not directly to blame for whatever's happening here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25218
--- Comment #8 from jv244 at cam dot ac dot uk 2006-02-20 16:32 ---
(In reply to comment #7)
I'm guessing my change was in converting an if () abort () into gcc_assert,
and
not directly to blame for whatever's happening here.
Looks like you're right... I must have been reading too
gcc version 4.1.0 20060219 (prerelease) produces spurious warnings when
used with -Wall and -O3 together. Previous released versions haven't had this
behaviour. It appears to be issuing multiple warnings when string functions are
inlined using the __builtin_ versions eg __builtin_strcmp. For
--- Comment #1 from andrew dot m dot roberts at tesco dot net 2006-02-20
16:41 ---
Created an attachment (id=10880)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10880action=view)
gcc -v -save-temps -O3 -Wall output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26383
--- Comment #1 from dorit at il dot ibm dot com 2006-02-20 16:45 ---
Looks like the vectorizer detects a strided access in this testcase. Strided
accesses are not entirely supported for SSE right now (work in progress...),
but it is enabled, so currently all strided testcases brake on
--- Comment #2 from dorit at il dot ibm dot com 2006-02-20 17:09 ---
Actually there's this patch by rth that seems to fix this ICE; it's from a
while back, I don't think it was fully tested at the time, and I'm not sure it
provides all the missing bits/fixes for SSE support.
===
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-20 17:17 ---
This is really a glibc bug as far as I can tell.
Lets look into what glibc exands the string functions to:
i=__extension__ ({ size_t __s1_len, __s2_len; (__builtin_constant_p (data)
__builtin_constant_p (s)
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-02-20 17:35
---
If make all-gcc works, I am happy so this is a dup of bug 25670.
*** This bug has been marked as a duplicate of 25670 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-02-20 17:35 ---
*** Bug 25455 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from hjl at lucon dot org 2006-02-20 17:46 ---
A testcase patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01391.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25603
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-20 17:47 ---
Subject: Bug 25879
Author: pinskia
Date: Mon Feb 20 17:47:34 2006
New Revision: 111308
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111308
Log:
2006-02-20 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-20 17:47 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26361
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25985
1 - 100 of 161 matches
Mail list logo
