Rask,
On Thursday 01 June 2006 16:13, Rask Ingemann Lambertsen wrote:
I think you will need to remove the '+' as already suggested and add
(clobber (match_scratch:QI =X,X,X,1)) to tell GCC that the register
allocated to operand 1 is clobbered by the instruction for this
particular
On Fri, Jun 02, 2006 at 08:23:49AM +0200, Wolfgang Mües wrote:
Rask,
(_only_ adding the clobber statement),
I get
0/newlib/li bc/argz/argz_create_sep.c:60: error: unrecognizable insn:
(insn 192 21 24 0 (set (reg:QI 1 r1) (reg:QI 4 r4)) -1
(nil) (nil))
What do you mean with
You
Hi, all
This patch results a performance increase of 4% for SPECfp2000 and 13% for NAS
benchmark suite on
Itanium-2 system, respectively. More performance increase is hopeful by further
tuning the
parameters and improving the prefetch algorithm at tree level.
Details of NAS benchmarks are
On Thu, 1 Jun 2006, Joe Buck wrote:
Let's just add the info to the table. Here is a proposed patch.
Note that I resorted by date and added an explanation. I think
that the attempt to sort by release number became increasingly
untenable after 3.4, because we now have heavy overlapping.
Canqun Yang wrote:
Hi, all
This patch results a performance increase of 4% for SPECfp2000 and 13% for NAS
benchmark suite on
Itanium-2 system, respectively. More performance increase is hopeful by further
tuning the
parameters and improving the prefetch algorithm at tree level.
Hi Canqun,
On 6/2/06, Canqun Yang [EMAIL PROTECTED] wrote:
This patch results a performance increase of 4% for SPECfp2000 and 13% for NAS
benchmark suite on
Itanium-2 system, respectively. More performance increase is hopeful by further
tuning the
parameters and improving the prefetch algorithm at tree
--- Andrey Belevantsev [EMAIL PROTECTED]:
Canqun Yang wrote:
Hi, all
This patch results a performance increase of 4% for SPECfp2000 and 13% for
NAS benchmark suite
on
Itanium-2 system, respectively. More performance increase is hopeful by
further tuning the
parameters and
Hello,
First a short description of a problem we are seeing, then a couple
of related questions on addressability checks in the gimplifier.
From a simple Ada testcase which I can provide if need be, the front-end
is producing a MODIFY_EXPR with a lhs of the following shape when we get
to
On Thu, 2006-06-01 at 16:05, Mark Shinwell wrote:
Mark Mitchell wrote:
Mark Shinwell wrote:
As for the remaining problem, I suggest that we could:
(i) always return the hard frame pointer, and disable FP elimination in
the current function; or
(iii) ...the same as option (i), but
Richard Earnshaw wrote:
I'm not keen on this. On some machines a frame pointer is *very*
expensive, both in terms of the code required to set it up, and the
resulting loss of a register which affects code quality (in addition, on
Thumb, the frame pointer can access much less data on the stack
Mark Shinwell writes:
Mark If the hard frame pointer is forced by default, then targets which are
Mark particularly badly affected can simply define INITIAL_FRAME_ADDRESS_RTX.
Mark Since such targets would presumably not have to force reload to keep
Mark the frame pointer, then definitions of
On 6/2/06, Gerald Pfeifer [EMAIL PROTECTED] wrote:
Mind to send/commit a patch to complete releases.html with 4.x
releases and add a step to releasing.html? (Basically you just
need to revert revision 1.26 of that file.)
Joe Buck beat me to it and you applied it for him. Thanks to
both of
David Edelsohn wrote:
Mark Shinwell writes:
Mark If the hard frame pointer is forced by default, then targets which are
Mark particularly badly affected can simply define INITIAL_FRAME_ADDRESS_RTX.
Mark Since such targets would presumably not have to force reload to keep
Mark the frame
On Fri, 2006-06-02 at 14:57, Mark Shinwell wrote:
Richard Earnshaw wrote:
I'm not keen on this. On some machines a frame pointer is *very*
expensive, both in terms of the code required to set it up, and the
resulting loss of a register which affects code quality (in addition, on
Thumb,
On Fri, 2006-06-02 at 15:30, Mark Shinwell wrote:
However when dealing with __builtin_frame_address, we must return the
correct value from this function no matter what the value of count. This
patch therefore forces use of a hard FP in such situations.
Eh? The manual explicitly says that
Canqun,
Nice job getting this ready for the current version of gcc!
Question: does gcc now know the difference between prefetching to cache L1 via
lfetch, as opposed to prefetching only to level L2 via lfetch.nt1? For
floating point data, the latter is the only interesting case because float
On Fri, Jun 02, 2006 at 04:20:21PM +0100, Richard Earnshaw wrote:
On Fri, 2006-06-02 at 15:30, Mark Shinwell wrote:
However when dealing with __builtin_frame_address, we must return the
correct value from this function no matter what the value of count. This
patch therefore forces use of
__builtin_frame_address(n) is not required to work for any value other
than n=0. It's not clear what it means anyway on a function that
eliminates the frame pointer.
On ARM you *cannot* walk the stack frames without additional
information. Frames are private to each function and there is
On Fri, 2006-06-02 at 16:28, Paul Brook wrote:
I agree that in general you need ancillary information way to get a backtrace
on Arm. However if you assume only Arm code code and -fno-omit-frame-pointer
then you can walk the frames. Given this assumption I think it make sense to
have
On Fri, Jun 02, 2006 at 04:32:07PM +0100, Richard Earnshaw wrote:
On Fri, 2006-06-02 at 16:28, Paul Brook wrote:
I agree that in general you need ancillary information way to get a
backtrace
on Arm. However if you assume only Arm code code and
-fno-omit-frame-pointer
then you can
How to reproduce this problem
-
1) Take some C file. I used for instance dwarf.c from
the new binutils distribution.
2) Generate an assembler listing of this file
3) Using objdump -s dwarf.o I dump all the
sections of the executable in hexadecimal format.
Put
Richard Earnshaw wrote:
The only chance you have for producing a backtrace() is to have
unwinding information similar to that provided for exception unwinding.
This would describe to the unwinder how that frames code is laid out so
that it can unpick it.
I'd suggest we leave backtrace()
On Fri, 2006-06-02 at 16:35, Daniel Jacobowitz wrote:
On Fri, Jun 02, 2006 at 04:32:07PM +0100, Richard Earnshaw wrote:
On Fri, 2006-06-02 at 16:28, Paul Brook wrote:
I agree that in general you need ancillary information way to get a
backtrace
on Arm. However if you assume only Arm
On Friday 02 June 2006 16:44, Richard Earnshaw wrote:
On Fri, 2006-06-02 at 16:35, Daniel Jacobowitz wrote:
On Fri, Jun 02, 2006 at 04:32:07PM +0100, Richard Earnshaw wrote:
On Fri, 2006-06-02 at 16:28, Paul Brook wrote:
I agree that in general you need ancillary information way to get a
On Fri, 2006-06-02 at 16:46, Mark Mitchell wrote:
Richard, I can't tell from your comments how you think _b_f_a(0) should
be implemented on ARM. We could use Mark's logic (forcing a hard frame
pointer), but stuff it into INITIAL_FRAME_ADDRESS_RTX. We could also
try to reimplement the thing
On Jun 2, 2006, at 8:46 AM, jacob navia wrote:
How to reproduce this problem
-
WHERE AM I WRONG ?
You should write to [EMAIL PROTECTED] if you want
a high probility of your question about the assembler
being answered.
-- Pinski
Richard stallman write last night:
I agree to the use of the Eclipse front end to generate
Java byte codes.
Note this does not mean importing Eclispe code into the gcc source or
release tree. We need to decide on a practical way to have people
grab a compatible version of ecj.
--
I took a quick pass at implementing the comparisons in a more suitable
lanugage. Run time is now a few seconds on both platforms. About the
same as compare_tests on my old ibook/OSX and much faster on FC3.
Trials show the same results as before.
For anyone interested, the new version is
On Fri, Jun 02, 2006 at 10:59:58AM -0700, Per Bothner wrote:
Richard stallman write last night:
I agree to the use of the Eclipse front end to generate
Java byte codes.
Note this does not mean importing Eclispe code into the gcc source or
release tree. We need to decide on a
Hi,
Here are some gcc 4.1.1 build reports.
#1: i686-pc-linux-gnu, Red Hat EL3: C, C++, ObjC, and Java.
Native tools were used.
Test results: http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00019.html
#2: ia64-unknown-linux-gnu, Red Hat Advanced Workstation 2.1AW. C, C++, ObjC.
I haven't tried to build Java on Solaris in quite a while because it
takes so long.
My attempt to build on Solaris 2.8 with binutils 2.16.1 died with
/bin/ksh ./libtool --tag=GCJ --mode=link
/remote/atg2/jbuck/solaris.tmp/411/gcc/gcj
On 6/2/06, Davis, Mark [EMAIL PROTECTED] wrote:
Question: does gcc now know the difference between prefetching to cache L1 via
lfetch, as opposed to prefetching only to level L2 via lfetch.nt1?
The ia64 backend knows the difference, see the prefetch pattern in ia64.md.
But ia64 is the only
On 6/3/06, Steven Bosscher [EMAIL PROTECTED] wrote:
For floating point data, the latter is the only interesting case because
float loads only
access the L2. Thus using lfetch for floating point arrays will
unnecessarily wipe out
the contents of L1. (gcc 3.2.3 only seems to generate
Snapshot gcc-4.1-20060602 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060602/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Jun 2, 2006, at 11:08 AM, James Lemke wrote:
I took a quick pass at implementing the comparisons in a more suitable
lanugage. Run time is now a few seconds on both platforms. About the
same as compare_tests on my old ibook/OSX and much faster on FC3.
Since Ben and I seem interested in
--- Davis, Mark [EMAIL PROTECTED]:
Canqun,
Nice job getting this ready for the current version of gcc!
Question: does gcc now know the difference between prefetching to cache L1
via lfetch, as
opposed to prefetching only to level L2 via lfetch.nt1? For floating point
data, the
h8300 has an HImode insv pattern. If you try to use it with an SImode
argument, expmed.c uses gen_lowpart to force it into the desired mode.
However, gen_lowpart eventually fails for pseudos on big endian:
rtx
gen_rtx_SUBREG (enum machine_mode mode, rtx reg, int offset)
{
gcc_assert
Steven Bosscher [EMAIL PROTECTED] writes:
On 6/2/06, Davis, Mark [EMAIL PROTECTED] wrote:
Question: does gcc now know the difference between prefetching to cache L1
via
lfetch, as opposed to prefetching only to level L2 via lfetch.nt1?
The ia64 backend knows the difference, see the
This testcase will cause an internel error when compiled with options -O3
-fprefetch-loop-arrays on IA-64 + Linux.
SUBROUTINE EBJFT()
dimension nmw(140)
if(k.eq.0) goto 10
go to 30
10 continue
do 20 l=1, 140
20nmw(l)= 0.0D0
30 continue
go to
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|minor |normal
Component|tree-optimization
--- Comment #3 from patchapp at dberlin dot org 2006-06-02 09:45 ---
Subject: Bug number PR c++/27804
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-06/msg00060.html
--
--- Comment #2 from uros at kss-loka dot si 2006-06-02 10:04 ---
(In reply to comment #1)
There is nothing special about reassociation at all. In fact what you are
seeing is register allocator going funky. This what you get with x87.
This is also what you get with SSE.
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-02 10:19 ---
(In reply to comment #2)
This is also what you get with SSE.
And how many registers does SSE have, not many. Try it on PPC or any processor
have more registers?
--
--- Comment #2 from tijl at ulyssis dot org 2006-06-02 11:02 ---
Created an attachment (id=11578)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11578action=view)
proposed patch
This patch fixes my problems, but I'm not sure I got all cases and I'm not sure
if the _finite versions
--- Comment #4 from jakub at gcc dot gnu dot org 2006-06-02 11:57 ---
This is a dup of PR27416 - the ICE on invalid part of that bug.
The testcase violates OpenMP 2.5 section 2.8.3 restriction:
A list item that appears in a reduction clause of a work-sharing construct
must be shared in
--- Comment #4 from jakub at gcc dot gnu dot org 2006-06-02 11:57 ---
*** Bug 27870 has been marked as a duplicate of this bug. ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
$ cat forall_3.f90
type t
integer :: p(1)
end type
type (t), dimension (1) :: v
integer i
forall (i=1:1,.false.)
v(i)%p = v(i+1)%p
end forall
end
$ gfortran forall_3.f90 -fbounds-check ./a.out
Fortran runtime error: Array reference out of bounds
--
Summary:
Note: This problems happens only on trunk compiler configured with
--target=powerpc-unknown-linux-gnuspe --enable-e500_double
I have lots of dejagnu failures that looks just like this one:
/temp/gnu_toolchain/build_area/obj_gcc-trunk_e500v2/gcc/xgcc
--- Comment #1 from edmar at freescale dot com 2006-06-02 15:41 ---
Created an attachment (id=11579)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11579action=view)
file generated with --save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27875
When I am trying to build GCC 4.1.1 I am getting the following error:
/root/Downloads/gcc-4.1.1/host-i686-pc-linux-gnu/gcc/xgcc -shared-libgcc
-B/root/Downloads/gcc-4.1.1/host-i686-pc-linux-gnu/gcc -nostdinc++
-L/root/Downloads/gcc-4.1.1/i686-pc-linux-gnu/libstdc++-v3/src
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-02 15:51 ---
/usr/bin/ld: BFD 2.15.92.0.2 20040927 internal error, aborting at
../../bfd/elf32-i386.c line 2262 in elf_i386_relocate_section
Two things, first this is a bug in binutils.
Second the version of binutils
--- Comment #2 from razin at avaya dot com 2006-06-02 15:55 ---
Subject: RE: Getting an error when building GCC 4.1.1
If you do not mind can you explain a little bit in details the
difference between FSF and HJL binutils.
Thanks!
-Original Message-
From: pinskia at gcc dot
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-02 15:58 ---
(In reply to comment #2)
Subject: RE: Getting an error when building GCC 4.1.1
If you do not mind can you explain a little bit in details the
difference between FSF and HJL binutils.
HJL does not care about
--- Comment #4 from razin at avaya dot com 2006-06-02 15:59 ---
Subject: RE: Getting an error when building GCC 4.1.1
Thanks! I will make a note of that.
Sergey
-Original Message-
From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED]
Sent: Friday, June 02, 2006
--- Comment #6 from patchapp at dberlin dot org 2006-06-02 16:00 ---
Subject: Bug number PR target/27842
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-06/msg00078.html
--
--- Comment #3 from green at redhat dot com 2006-06-02 16:09 ---
This bug may also be what's causing rssowl to suddenly fail in FC5. Both
Eclipse (swt) and gcc were updated in FC5 recently, and one of those triggered
the failure.
--- Comment #8 from idht4n at hotmail dot com 2006-06-02 16:22 ---
(In reply to comment #7)
g++f4 -o hello hello.o -lmudflap
You need both -fmudlfap and -lmudflap when linking.
This is not a bug.
OK - mostly my bad then. Sorry. But if you need them both, why doesn't it
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-02 16:39 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
The FAQ on gcc.gnu.org states in section 2.2 Dynamic linker is unable to find
GCC libraries the following:
snip
However, if you feel you really need such an option to be passed automatically
to the linker, you may add it to the GCC specs file. This file can be found in
the same directory that
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org
|dot org
--- Comment #2 from ro at techfak dot uni-bielefeld dot de 2006-06-02
17:24 ---
Subject: Re: [4.2 Regression] libgomp fails to configure on IRIX 5.3
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00084.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27540
GCC 4.1.0 works, but 4.1.1 does not (dies in libstdc++):
#
# /home/martinol/auto_v4.0/third/build-csips9/gcc-4.1.1/configure
--prefix=/home/martinol/auto_v4.0/devel/mips-sgi-irix6.5 --disable-
shared --enable-static
--with-gmp=/home/martinol/auto_v4.0/devel/mips-sgi-irix6.5
--- Comment #11 from tbm at cyrius dot com 2006-06-02 18:47 ---
Falk's original testcase is baesd on a segfault while compiling qt4-x11. I
just found another application, enigmail, which segfaults on Alpha (with the
same backtrace as in this PR). The interesting observation is that
--- Comment #3 from tbm at cyrius dot com 2006-06-02 18:48 ---
Created an attachment (id=11580)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11580action=view)
test case for 4.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27467
--- Comment #4 from tbm at cyrius dot com 2006-06-02 18:49 ---
(From update of attachment 11580)
wrong bug, sorry
--
tbm at cyrius dot com changed:
What|Removed |Added
--- Comment #12 from tbm at cyrius dot com 2006-06-02 18:50 ---
Created an attachment (id=11581)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11581action=view)
test case for 4.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27082
--- Comment #1 from pcarlini at suse dot de 2006-06-02 19:59 ---
Before confirming this we have to understand why we have got rather good
testresults for 4.1.1 on mips-sgi-irix6.5:
http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg01513.html
Eric, any idea?
--
pcarlini at suse
--- Comment #11 from rsa at us dot ibm dot com 2006-06-02 20:11 ---
I recently ran into this on ppc/ppc64 when building a toolchain with gcc4.1 or
gcc4.2.
When the bootstrap gcc was built with --enable-checking=all (or =fold which we
just tested) the glibc 32bit build stage fails in
--- Comment #5 from patchapp at dberlin dot org 2006-06-02 20:15 ---
Subject: Bug number PR14067
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-06/msg00093.html
--
Static linking is broken on ia64:
$ gcc -static -v hello.c
Using built-in specs.
Target: ia64-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
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-06-02 20:32
---
Eric, any idea?
I presume the message means that the functions are not declared in wchar.h?
I do have both in wchar.h on the IRIX machine:
__SGI_LIBC_USING_FROM_STD(wcstok)
--
schwab at suse dot de changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27880
--- Comment #3 from tbm at cyrius dot com 2006-06-02 20:35 ---
4.1.1 20060511 is also affected, 4.2.0 20060508 works.
--
tbm at cyrius dot com changed:
What|Removed |Added
--- Comment #3 from pcarlini at suse dot de 2006-06-02 20:43 ---
(In reply to comment #2)
Eric, any idea?
I presume the message means that the functions are not declared in wchar.h?
Yes, that for sure ;) but we have got specific configure tests for that and, at
the moment, I have
--- Comment #4 from martinol at nrlssc dot navy dot mil 2006-06-02 20:55
---
Created an attachment (id=11582)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11582action=view)
./mips-sgi-irix6.5/libstdc++-v3/config.log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27878
--- Comment #5 from martinol at nrlssc dot navy dot mil 2006-06-02 21:05
---
An IRIX64 system here has wchar.h with the __SGI_LIBC_USING_FROM_STD(wcstok),
but it failed in the fortran part! :-(
The SGI I am using has a much different looking wchar.h with wsctok here:
#if
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-06-02 21:18
---
An IRIX64 system here has wchar.h with the __SGI_LIBC_USING_FROM_STD(wcstok),
but it failed in the fortran part! :-(
That's it: puar% uname -s
IRIX64
I've not tried to build the Fortran compiler on the
--- Comment #7 from pcarlini at suse dot de 2006-06-02 21:21 ---
(In reply to comment #4)
Created an attachment (id=11582)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11582action=view) [edit]
./mips-sgi-irix6.5/libstdc++-v3/config.log
I do not understand: the configure tests
Please submit a patch against SVN trunk to [EMAIL PROTECTED] with
ChangeLog entries
I regret that I cannot spend more time on this than I already have. If
you don't want to use my diffs, then please just consider it as a bug
report. If you don't want to do that either, then I guess the
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-06-02 22:03
---
Confirmed.
Shorter testcase (fails with C or C++ frontend):
=
static int* foo(int *q, int j) { return q + j; }
int* r;
void bar(int *p)
{
int i;
for (i=0; i2;
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-06-02 22:38
---
Here's an even shorter testcase:
=
struct X {};
struct Y : virtual X {};
struct Z : virtual X {};
struct A : Y, Z {};
struct B : A
{
static const int i =
--- Comment #1 from sje at cup dot hp dot com 2006-06-02 22:40 ---
I believe this is because you are configuring with --with-system-libunwind and
your system unwind does not have _Unwind_GetIPInfo. This routine was added to
the GCC libunwind back in February by Jakub Jelinek to fix PR
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-02 22:49 ---
And I did mention this when that other PR's patch was posted.
--with-system-libunwind is the issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from sje at cup dot hp dot com 2006-06-02 23:10 ---
I should have mentioned that for HP-UX, where the system unwind also does not
have _Unwind_GetIPInfo, I added it to libgcc. See
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01285.html
--
--- Comment #4 from steven at gcc dot gnu dot org 2006-06-02 23:19 ---
Real bug, despite Andrew's usual portion of x86-hate.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-06-02 23:24
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-06-02 23:50 ---
Subject: Bug 27850
Author: amylaar
Date: Fri Jun 2 23:50:11 2006
New Revision: 114332
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114332
Log:
PR other/27850
* Makefile.in (stmp-fixinc):
steven at gcc dot gnu dot org wrote:
--- Comment #4 from steven at gcc dot gnu dot org 2006-06-02 23:19
---
Real bug, despite Andrew's usual portion of x86-hate.
It'd be good to know what exactly is going wrong.
Reassociation only touches floating point because someone asked me
--- Comment #5 from dberlin at gcc dot gnu dot org 2006-06-03 02:11 ---
Subject: Re: reassociation pass produces ~30% slower matrix
multiplication code
steven at gcc dot gnu dot org wrote:
--- Comment #4 from steven at gcc dot gnu dot org 2006-06-02 23:19
---
Real bug,
Compiling the GCC testsuite file alias3.C with -O1 -finline-functions exhausts
memory on checking=all or =yes builds of GCC 4.1.1, on Ubuntu 5.04 with virtual
memory limited to 500M. Roughly similar behavior on Mac OSX 10.4.6 with a
checking=all build of GCC 4.1.0, though ulimit is broken on the
--- Comment #1 from flash at pobox dot com 2006-06-03 02:37 ---
Created an attachment (id=11583)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11583action=view)
Preprocessed Delta-reduced source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27881
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-06-03 02:38 ---
What reassociation is doing is scheduling the instructions further down
before the use but it exands the life time of some variables.
e.g.:
D.1563_59 = rA0_49 * rB0_50;
rC0_0_60 = D.1563_59 + rC0_0_516;
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-06-03 02:49 ---
If you change the code to be integers, this also cause the drop too with
reassociation even without -ffast-math so it is unrelated to the fact
-ffast-math turns on reassociate for floating points for fast math.
So
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-03 03:42 ---
Here is a testcase without inline functions:
void bar(int *p, int t1)
{
int i;
static int *tt;
for (i=0; i2; ++i)
if (i)
{
int t = i - 1;
tt = p+t;
}
}
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-03 03:46 ---
The code to do:
2098 /* If we just created an invalid range with the minimum
2099 greater than the maximum, take the maximum all the
2100 way to +INF. */
95 matches
Mail list logo
