We severely regressed for Java (22*2 new failures) 3 days ago.
Ugh. Not very surprising, given that a jumbo patch landed by that time:
2005-04-06 Tom Tromey [EMAIL PROTECTED]
* Makefile.in: Rebuilt.
* Makefile.am (lib_gnu_java_awt_peer_gtk_la_SOURCES): Removed
Eric Botcazou writes:
We severely regressed for Java (22*2 new failures) 3 days ago.
Please post the list of failures to [EMAIL PROTECTED]
Andrew.
Mark Mitchell writes:
Your primary objective (get rid of -fno-unit-at-a-time) is one that I
strongly support.
I have a problem with getting rid of -fno-unit-at-a-time. Sometimes
we compile huge Java programs; however, keeping all the method bodies
consumes vast amouts of memory. So, we
On Monday 11 April 2005 12:18, Andrew Haley wrote:
Mark Mitchell writes:
Your primary objective (get rid of -fno-unit-at-a-time) is one that I
strongly support.
I have a problem with getting rid of -fno-unit-at-a-time. Sometimes
we compile huge Java programs; however, keeping all the
Steven Bosscher writes:
On Monday 11 April 2005 12:18, Andrew Haley wrote:
Mark Mitchell writes:
Your primary objective (get rid of -fno-unit-at-a-time) is one that I
strongly support.
I have a problem with getting rid of -fno-unit-at-a-time. Sometimes
we compile huge Java
Andrew Haley wrote:
Might it still be possible for a front end to force all pending code
to be generated, even with -fno-unit-at-a-time gone?
I think this is a bad idea. You're essentially asking for the backend
to retain all the functionality of -fno-unit-at-a-time.
Might I refer you to Mike
Andrew Haley wrote on 11/04/2005 13:31:52:
Steven Bosscher writes:
This is what C++ does now too. Why would this be a problem
for Java but not for C++?
I don't know why it's not a problem for C++; I do know why it's a
problem for Java. Perhaps the files we're compiling are
Nathan Sidwell [EMAIL PROTECTED] writes:
| Andrew Haley wrote:
|
| Might it still be possible for a front end to force all pending code
| to be generated, even with -fno-unit-at-a-time gone?
|
| I think this is a bad idea. You're essentially asking for the backend
| to retain all the
Nathan Sidwell writes:
Andrew Haley wrote:
Might it still be possible for a front end to force all pending code
to be generated, even with -fno-unit-at-a-time gone?
I think this is a bad idea. You're essentially asking for the backend
to retain all the functionality of
Andrew Haley wrote:
Nathan Sidwell writes:
Andrew Haley wrote:
Might it still be possible for a front end to force all pending code
to be generated, even with -fno-unit-at-a-time gone?
I think this is a bad idea. You're essentially asking for the backend
to retain all the
Hello again!
In the freetype-devel list, I got some suggestions:
This bug/problem seems to concentrate on ppc32/64 and s390 architectures.
Basically all Type1 fonts shipped with X11 are suspect to this
problem. I made tests agains UTBI.pfa
The possible (temporary)fix:
If I re-compile freetype
Just as another idea -
Steven Bosscher wrote:
(The proper solution is of course to have an IR that we can stream
to disk, *sigh* ;-)
AFAICT, MSVC solves this by generating some of the code when it reaches some
memory limit. So when GCC is under some memory pressure it could identify
Nathan Sidwell [EMAIL PROTECTED] writes:
| Andrew Haley wrote:
| Nathan Sidwell writes:
|Andrew Haley wrote:
| Might it still be possible for a front end to force all
| pending code
| to be generated, even with -fno-unit-at-a-time gone?
| I think this is a bad idea. You're
Andrew Haley wrote:
Nathan Sidwell writes:
1) The C++ programs are smaller than the java programs
That's my guess. Usually, C++ users compile one source file at a
time, whereas Java users find it convenient to compile a whole
archive.
ok, thanks. This sounds like you're really in an IMA mode
Andrew Haley [EMAIL PROTECTED] writes:
That's my guess. Usually, C++ users compile one source file at a
time,
Unless you use --enable-final in KDE.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint =
Nathan Sidwell writes:
Andrew Haley wrote:
Nathan Sidwell writes:
1) The C++ programs are smaller than the java programs
That's my guess. Usually, C++ users compile one source file at a
time, whereas Java users find it convenient to compile a whole
archive.
ok, thanks.
I guess the best solution is to change the place you modified, but to
use a test that checks for autoinc codes. I'll come up with something.
Try this.
Bernd
* reload.c (find_reloads): Only set INC field if we know we have an
autoinc reload.
* reload.h (struct reload): Update comment to match.
Eric Botcazou writes:
Tom, I presume there was a very good reason for installing such a
potentially
destabilizing patch a few days before the prerelease?
In defence of my fellow maintainer:
There was. We are now, for the first time ever, in a position where
we can run a large
Mark Mitchell wrote:
The first GCC 4.0 candidate is available from:
...
a minor issue with the configure script:
...
checking whether gcc-3.4 accepts -g... yes
checking for gnatbind... gnatbind
--- here ---
checking whether compiler driver understands Ada...
../src/gcc-4.0.0-20050410/configure:
Rupert Wood [EMAIL PROTECTED] wrote:
I have a problem with getting rid of -fno-unit-at-a-time. Sometimes
we compile huge Java programs; however, keeping all the method bodies
consumes vast amouts of memory.
AFAICT, MSVC solves this by generating some of the code when it reaches some
memory
On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote:
BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1
or so... I still lean on that crutch.
A user! Can you explain why?
--
Daniel Jacobowitz
CodeSourcery, LLC
Hi,
How can I use GCC for cross compilation?
I want to build an application for the EPOC platform. It is for a
Psion 5MX device which has an 32-bit RISC-based ARM 710 processor.
The application is in C. Is it possible to build the application using
GCC for that platform?
--
Regards,
Vishal
Mark Mitchell [EMAIL PROTECTED] writes:
If you are willing to help, please download the release candidate, build
it on appropriate platforms, and post testresults by using
contrib/test_summary. Please use the release candidate itself, *not*
the CVS 4.0 release branch, as part of the goal is
--- here ---
checking whether compiler driver understands
Ada... ../src/gcc-4.0.0-20050410/configure: line 2141: break: only
meaningful in a `for', `while', or `until' loop
yes
checking how to compare bootstrapped objects... cmp
--ignore-initial=16 $$f1 $$f2
...
looks like there
Has anyone had success in building gcc-4.0.0 RC1 on a
powerpc-ibm-aix5.2.0.0 (a primary platform)?
After
configure --enable-languages=c
make bootstrap
I get
: [stuff deleted]
: build/genattrtab
/home/kate/gcc-4.0.0-20050410/src/gcc-4.0.0-20050410/gcc/config/rs6000/
rs6000.md
On Apr 4, 2005, Richard Henderson [EMAIL PROTECTED] wrote:
On Mon, Apr 04, 2005 at 07:57:09PM -0300, Alexandre Oliva wrote:
My head hurts about the GGC implications of opaque pointers in such a
hash table, and retaining pointers in the hash table that have already
been otherwise freed.
Please post the list of failures to [EMAIL PROTECTED]
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00671.html
--
Eric Botcazou
On Apr 10, 2005, Andreas Jaeger [EMAIL PROTECTED] wrote:
Laurent GUERBY [EMAIL PROTECTED] writes:
stage1/xgcc -Bstage1/
-B/home/guerby/work/gcc/install/install-20050410T003153/i686-pc-linux-gnu/bin/
-c -O2 -g -fomit-frame-pointer -gnatpg -gnata -I--I. -Iada
On Apr 11, 2005, Alexandre Oliva [EMAIL PROTECTED] wrote:
On Apr 4, 2005, Richard Henderson [EMAIL PROTECTED] wrote:
On Mon, Apr 04, 2005 at 07:57:09PM -0300, Alexandre Oliva wrote:
My head hurts about the GGC implications of opaque pointers in such a
hash table, and retaining pointers in
I can no longer build Kawa using the 4.0 branch. This is with a
'cvs update' late last night. Kawa did built last time I tried
the 4.0 branch. Unfortunately, I don't know how long ago that was,
but it wasn't *that* long ago.
The cause appears to failure to find a class in the CLASSPATH.
That
Per Bothner wrote:
I can no longer build Kawa using the 4.0 branch.
Some more information:
The failing statement is:
Class.forName(kawa.lib.prim_syntax, false,
getClass().getClassLoader());
prim_syntax.class exists in the current directory,
which is ../../kawa/lib. The program is
The system:
===
uname -a
Darwin localhost 7.2.1 Darwin Kernel Version 7.2.1: Wed Jul 14 03:00:02
PDT 2004; root:tmp/xnu-7.2.1-1-root.obj/RELEASE_I386 x86 i386
gcc -v
Reading specs from /usr/libexec/gcc/darwin/i386/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer,
On 2005-04-11, Julian Brown [EMAIL PROTECTED] wrote:
On 2005-04-10, Mark Mitchell [EMAIL PROTECTED] wrote:
* The DejaGNU testsuite has been run, and compared with a run of
the testsuite on the previous release of GCC, and no regressions are
observed.
If you are willing to help,
On Fri, 2005-04-08 at 16:36, Daniel Berlin wrote:
Jim works on a insert details here machine:
Athlon64 3400+, with 1GB main memory, running SuSE 9.1 x86_64-linux.
Build of freshly updated mainline tree fails with:
/home/gdr/build/4.1/./gcc/xgcc -B/home/gdr/build/4.1/./gcc/ -B/home/gdr/i686-pc-
linux-gnu/bin/ -B/home/gdr/i686-pc-linux-gnu/lib/ -isystem /home/gdr/i686-pc-lin
ux-gnu/include -isystem /home/gdr/i686-pc-linux-gnu/sys-include -O2 -DIN_GCC
-W
On Sun, Apr 10, 2005 at 03:05:17PM -0700, Mark Mitchell wrote:
The first GCC 4.0 candidate is available from:
/pub/gcc/prerelease-4.0.0-20050410/
My test results on i686-pc-linux-gnu:
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00812.html
All looks good except for the libmudflap
Clemens Koller wrote:
In the freetype-devel list, I got some suggestions:
This bug/problem seems to concentrate on ppc32/64 and s390 architectures.
Basically all Type1 fonts shipped with X11 are suspect to this
problem. I made tests agains UTBI.pfa
The possible (temporary)fix:
If I
On Mon, Apr 11, 2005 at 10:59:46PM -0500, Gabriel Dos Reis wrote:
-c /home/gdr/redhat/egcs/gcc/crtstuff.c -DCRT_BEGIN \
-o crtbegin.o
make[1]: *** [crtbegin.o] Aborted
make[1]: Leaving directory `/home/gdr/build/4.1/gcc'
make: *** [all-gcc] Error 2
What's your top-of-ChangeLog? Works
Mark Mitchell [EMAIL PROTECTED] writes:
The first GCC 4.0 candidate is available
...
Then, if you are running on a primary or secondary platform, please
send me an email pointing me at the results you've posted, and
highlighting any failures to meet the release criteria.
Hi Mark,
I'm
Marcus Meissner wrote:
Btw,
We still see some critical 4.0 problems, ordered by my view of
importance:
PR/20126 triggers a miscompilation of python (i386 and x86_64 at least).
PR/20917 triggers a miscompilation of glibc (on s390).
PR/20739 triggers a --enable-checking problem triggering in
Diego Novillo [EMAIL PROTECTED] writes:
| On Mon, Apr 11, 2005 at 10:59:46PM -0500, Gabriel Dos Reis wrote:
|
| -c /home/gdr/redhat/egcs/gcc/crtstuff.c -DCRT_BEGIN \
|-o crtbegin.o
| make[1]: *** [crtbegin.o] Aborted
| make[1]: Leaving directory `/home/gdr/build/4.1/gcc'
| make: ***
Hi,
I have been getting bootstrap failures on i686-pc-linux-gnu since
Caroline's patch
http://gcc.gnu.org/ml/gcc-cvs/2005-04/msg00541.html
Errors go like so:
org/xml/sax/helpers/ParserAdapter.java: In class
'org.xml.sax.helpers.ParserAdapter':
org/xml/sax/helpers/ParserAdapter.java: In
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
06:00 ---
Most likely libiberty (the pex* functions) is being miscompiled.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
06:03 ---
I almost want to say this was caused by:
2005-04-05 Andrew MacLeod [EMAIL PROTECTED]
* lambda-code.c (lambda_loopnest_to_gcc_loopnest): Use update_stmt.
Use immediate use iterator.
--
What|Removed |Added
Target Milestone|--- |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19014
--
What|Removed |Added
Target Milestone|--- |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19106
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Last reconfirmed|2005-01-09
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
06:30 ---
Confirmed, looks like someone is forgetting to call fold somewhere:
int4 C.465 = 1 - 1;
int4 C.464 = 2;
--
What|Removed |Added
The option -ggdb3 has stopped working recently. The following example does not
compile any more
[/Users/fca] cat junk.c
#include stdio.h
main () {
float a=0;
printf(%f\n,a);
}
[/Users/fca] /opt/gcc-4_0/bin/gcc -ggdb3 junk.c -o junk.o
junk.c:5: internal compiler error: Bus error
--
What|Removed |Added
Component|c |debug
Keywords||ice-on-valid-code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
06:34 ---
Confirmed, this just started to happen in the last three days too.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
06:38 ---
This was caused by:
2005-04-09 Caroline Tice [EMAIL PROTECTED]
* dwarf2out.c (COLD_TEXT_SECTION_LABEL): New macro.
..
(output_line_info): Get cold section
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
06:40 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From jason at redhat dot com 2005-04-11 07:49
---
Subject: Re: [4.1 Regression] removing a temporary return
value when we cannot
Have you tested the 4.0 branch with the temporary fix I applied?
Jason
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317
--- Additional Comments From federico dot carminati at cern dot ch
2005-04-11 07:49 ---
This fix has not yet been merged to the head. Any news?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20799
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-11
07:51 ---
Patch from: http://gcc.gnu.org/ml/fortran/2005-04/msg00283.html applied to
mainline. Waiting for 4.0 to reopen.
--
What|Removed |Added
--
What|Removed |Added
Summary|BLK ptr's loosing original |BLK ptr's losing original
|ptr's static-constant |ptr's static-constant
(8,'(/2i2)')n,m
write(*,*)n,m
end
$ gfortran -v
Using built-in specs.
Target: i386-linux
Configured with: ../gcc/configure --prefix=/tmp/gfortran-20050411/irun
--enable-languages=c,f95 --host=i386-linux
Thread model: posix
gcc version 4.1.0 20050411 (experimental)
$ gfortran pr17992.f
This case came to light making service provider property files for
GNU JAXP: org.xml.sax.driver etc. These should be created in the
META-INF/services path of the JAR. Reproduce this error by creating a
META-INF/services directory at the root of your compiled class hierarchy and
adding one or
--- Additional Comments From phil at mkdoc dot com 2005-04-11 08:11 ---
Created an attachment (id=8583)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8583action=view)
SAX driver service provider file
Driver class: gnu.xml.aelfred2.SAXDriver
--
Have not seen this reported yet...
Bootstrap of mainline 4.1 compiler failed at ia32/IPF/x86_64 Linux due to jc1
segmentation fault in 'in_unlikely_text_section'.
/bootstrap/bld/./gcc/gcj -B/bootstrap/bld/./gcc/ -B/bootstrap/usr/i586-suse-
linux/bin/ -B/bootstrap/usr/i586-suse-linux/lib/
--- Additional Comments From phil at mkdoc dot com 2005-04-11 08:56 ---
Created an attachment (id=8584)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8584action=view)
Test case for org.xml.sax.driver service provider property
First checks any service provider configuration using
--- Additional Comments From pluto at pld-linux dot org 2005-04-11 08:59
---
(In reply to comment #26)
Subject: Re: [4.1 Regression] removing a temporary return
value when we cannot
Have you tested the 4.0 branch with the temporary fix I applied?
Jason
I applied a temporary
--- Additional Comments From phil at mkdoc dot com 2005-04-11 09:13 ---
Created an attachment (id=8585)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8585action=view)
GNU JAXP pure Java source, no natives
GNU JAXP source classes, compile using the attached script.
--
--- Additional Comments From phil at mkdoc dot com 2005-04-11 09:18 ---
Created an attachment (id=8586)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8586action=view)
GCJ compile script for GNU JAXP
Compiles GNU JAXP source to classes. Requires environment variables $mk_home, a
--- Additional Comments From phil at mkdoc dot com 2005-04-11 09:21 ---
Created an attachment (id=8587)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8587action=view)
Fastjar archive script for GNU JAXP
Creates a JAR of the compiled GNU JAXP classes. Requires environment variables
--- Additional Comments From phil at mkdoc dot com 2005-04-11 09:23 ---
Created an attachment (id=8588)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8588action=view)
Check you have the necessary environment variables
Checks the $mk_home and $mk_build environment variables are set.
The following command line produces a warning even if it behaves correctly
[/Users/fca] cat bug.F
subroutine bug_bug
end
[/Users/fca] /opt/gcc-4_0/bin/gfortran -c bug.F ; nm bug.o
T _bug_bug__
[/Users/fca] /opt/gcc-4_0/bin/gfortran -fno-second-underscore -c bug.F ; nm
--- Additional Comments From phil at mkdoc dot com 2005-04-11 09:47 ---
Lots of attachments, but it's simple really:
1. Set two environment variables: $mk_home, a path in which the source is at
$mk_home/lib-src/jaxp, and $mk_build, which is a temporary build directory
2. Put all the
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-04-11
09:47 ---
Zdenek,
the ICE with the testcase from comment #12 reappeared on mainline.
Could you please have a look?
--
What|Removed |Added
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-04-11
10:32 ---
The new failure (which is a segfault, btw) was caused by
http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg01363.html
--
What|Removed |Added
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-04-11 10:41 ---
Subject: Re: internal compiler error: in spill_failure, at reload1.c:1880
(-fspeculative-prefetching)
Hello,
the ICE with the testcase from comment #12 reappeared on mainline.
When I compile ACE 5.4.2 with the actual snapshot of gcc41 (gcc-4.1-20050410)
I get an ICE:
g++41 -O2 -c -o .shobj/Synch_Invocation.o Synch_Invocation.ii
Conflict s_4 and s_78 across an abnormal edge from BB40-BB43
Synch_Invocation.cpp: In member function 'TAO::Invocation_Status
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-11
11:33 ---
This one is certainly going to annoy lots of people (when 4.0 is released, I
think we will get bug-reports by the ton).
This should be easy to solve for someone who knows the interactions between GCC
--- Additional Comments From micis at gmx dot de 2005-04-11 11:37 ---
Created an attachment (id=8589)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8589action=view)
preprocessd source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20944
--- Additional Comments From tobi at gcc dot gnu dot org 2005-04-11 12:05
---
It is annoying enough that the preprocessor is invoked via cc1. Is there a
reason for this, besides that it is the example given in the specfiles?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18452
On Sun, Apr 10, 2005 at 09:53:00PM -0400, Andrew Pinski wrote:
Could you try the patch in PR 20934 and see if it fixed the
bootstrap problem on i686-linux?
It does. What's the status of that patch? It almost looks
obvious to me.
Diego.
--- Additional Comments From joern dot rennecke at st dot com 2005-04-11
12:36 ---
Subject: Re: TRULY_NOOP_TRUNCATION ignored
echristo at redhat dot com wrote:
--- Additional Comments From echristo at redhat dot com 2005-04-10 19:02
---
I think I'm ok with this, but I'd
--- Additional Comments From rolf dot ebert dot gcc at gmx dot de
2005-04-11 12:37 ---
Created an attachment (id=8590)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8590action=view)
patch to fix PR20822 in 4.0.0-RC1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20822
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
12:44 ---
*** This bug has been marked as a duplicate of 20934 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
12:44 ---
*** Bug 20942 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
12:47 ---
*** This bug has been marked as a duplicate of 18452 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
12:47 ---
*** Bug 20943 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18452
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
12:48 ---
(In reply to comment #5)
It is annoying enough that the preprocessor is invoked via cc1. Is there a
reason for this, besides that it is the example given in the specfiles?
Besides that is the only
--- Additional Comments From giovannibajo at libero dot it 2005-04-11
12:48 ---
I have a very naive question: if LABEL_REFS should always be generated with
Pmode, can't we add an assert if gen_rtx_LABEL_REF is called with a different
mode? Or better, remove the mode argument
--- Additional Comments From jason at redhat dot com 2005-04-11 12:48
---
Subject: Re: [4.1 Regression] removing a temporary return
value when we cannot
On 11 Apr 2005 08:59:58 -, pluto at pld-linux dot org [EMAIL PROTECTED]
wrote:
Have you tested the 4.0 branch with the
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
12:50 ---
I want to say this is a dup of bug 20920 which has a patch referenced, could
you try with that patch
applied?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20944
--
What|Removed |Added
Target Milestone|--- |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20777
--
What|Removed |Added
Component|java|libgcj
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20941
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-04-11
13:01 ---
*** This bug has been marked as a duplicate of 20920 ***
--
What|Removed |Added
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-04-11
13:01 ---
*** Bug 20944 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pluto at pld-linux dot org 2005-04-11 13:08
---
Problem still exists in 4.0.0-20050409 snap.
I've checked the i386.o and caller-save.o from stage2/3.
They have the same size but diff. instructions in several places.
--- stage2-i386.o.txt 2005-04-11
--- Additional Comments From joern dot rennecke at st dot com 2005-04-11
13:16 ---
Subject: Re: VOIDmode LABEL_REFs are generated
giovannibajo at libero dot it wrote:
--- Additional Comments From giovannibajo at libero dot it 2005-04-11
12:48 ---
I have a very naive
fortran 4.0 shows perfomance regression (with -O2 option) in comparison with
g77 from 3.4.2 on IA32 with attached test. This test is obtained from
cpu2000/mgrid test.
It consists of calling of two functions: PSINV and RESID.
Instrumental control (gprof) shows that most part of time spends in
--enable-checking=yes,fold fails on the mainline because when we get a
SSA_NAME, we checksum the
whole use-def chain which is wrong.
--
Summary: --enable-checking=yes,fold fails on the mainline
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
13:20 ---
I am testing a fix right now, this is blocking my patch for PR 20931.
--
What|Removed |Added
--- Additional Comments From denis dot nagorny at intel dot com 2005-04-11
13:20 ---
Created an attachment (id=8591)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8591action=view)
Test for results reproducing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20945
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-04-11
13:21 ---
The patch has been posted here:
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01157.html
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
13:28 ---
I know that gfortran has some issue with inlining.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20945
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
13:30 ---
And TREE_LIST too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20946
1 - 100 of 226 matches
Mail list logo
