ICE in reload1.c && jni.cc mainline

Sun Aug 5 11:44:00 GMT 2001

Gordon Sadler <gbsadler1@lcisp.com> writes:
> linux 2.2.19
> glibc 2.2.3
> AMD Duron 800 CPU
> Bootstrap started with gcc-3.0 -v:
> Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.0.1/specs
> Configured with: /usr/src/cvs/gcc-3.0/configure --verbose --enable-threads=posix --with-system-zlib --with-dwarf2 --enable-shared --disable-nls --enable-debug --enable-languages=c,c++
> Thread model: posix
> gcc version 3.0.1 20010708 (prerelease)
>> This was introduced overnight on CVS Head:
> RCS file: /cvs/gcc/gcc/gcc/reload1.c,v
> Working file: reload1.c
> head: 1.279
> branch:
> locks: strict
> access list:
> keyword substitution: kv
> total revisions: 350; selected revisions: 1
> description:
> ----------------------------
> revision 1.279
> date: 2001年08月04日 12:08:43; author: hubicka; state: Exp; lines: +55 -0
> * loop.c (try_copy_prop); Kill invalidated REG_EQUAL notes.
>> 	* reload1.c (fixup_abnormal_edges): New static function.
> 	(reload): Use it.

[...]
> As of now, 1320 CDT, there has been no change to either jni.cc or reload1.c
> so I am trying to notify the appropriate people of this new failure.

Check the thread at
http://gcc.gnu.org/ml/gcc-patches/2001-08/msg00229.html
Honza's patch fixed the problem for me on i686-linux. So far (it's
weekend) nobody reviewed the patches and therefore no fixes have been
added,
Andreas
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7bZPpOJpWPMJyoSYRAkLgAKCQHeLt5g+cJrb9T4mrSvkXsN8bpACbBPY2
IjZu9F3sz9IyYr+3hBmBmhg=
=AhOM
-----END PGP SIGNATURE-----From momara@iti-idsc.gov.eg Mon Aug 06 04:50:00 2001
From: "Mohammad O'mara" <momara@iti-idsc.gov.eg>
To: <java@gcc.gnu.org>
Subject: exe vesus class ... !
Date: 2001年8月06日 04:50:00 -0000
Message-id: <004701c11e6e060ドルd3810$1e01000a@ellipsisdigital.com>
References: <20010805131918.A12890@debian-home.lcisp.com> <u8zo9emjo8.fsf@gromit.moeb>
X-SW-Source: 2001-08/msg00022.html
Content-length: 2085
According to my knowledge , I know that the ( .exe ) file is much faster
than the CLASS file being interpreted by a virtual machine , for the same
source code ... " Ahead-of-Time Compilation versus Interpretation "
but this wasn't the case when I did that using gcj ! .. I measured the
processing time of some java codes using ( <time> command ) in Linux .. it
gives the Real , User and System time .. for single threaded applications ,
this was always the case ( class is 4 times faster than .exe ) , while when
profiling multi-threaded code ( I wrote the same application once in a
single thread and other time multi-threaded ) , in this case ( .exe was
almost 2 times faster ! than class ) ...
I just want to know , if there is something missing in that .. is it normal
to have such results ? .. I mean , isn't there a rule saying that executable
files are faster than classes for the same application all the for example
.. or even slower .. or it's something application dependant !
and if I'm interested in generating ( exe ) files ,how can I make my ( exe )
faster ?, if I can , given that I used ( -O3 ) switch and it didn't jump me
to the level of 4 times faster ( exe ) file to be competing with JVM results
..
and finally , has the RTL got to do anything with optimizing the code even
more than what ( -O3 ) does ?
thanks for help prior to anything ...
============================================================================
=
 Mohammad Y. Omara
 Microelectronic Circuit Designer
 Ellipsis Digital Systems
 ECEC ( Ellipsis Cairo Engineering Center )
 47 A. Ahmed Tayseer St. Kolleyet Al-Banat
 Heliopolis , Cairo , Egypt
 Phone: +20-2-2602623-134
 Cellular : +20-10-5234368
 email: momara@ellipsisdigital.com
 www : www.ellipsisdigital.com
============================================================================
=