Björn Haase <[EMAIL PROTECTED]> writes:
> Concerning 1.) Ian Lance Taylor has made a couple of suggestions on how to
> make the transition easier for the back-end maintainers. So it seems that
> there is already some activity around.
In fact Hans-Peter Nilsson is implementing code to support th
Am Freitag, 3. Juni 2005 10:48 schrieb Mark Mitchell:
> DJ Delorie wrote:
> > Do we have a standard way of telling the testsuite how big target
> > types are, or some standard "this test assumes 32 bit int" dejagnu
> > flag?
>
> I don't think we have any way of doing this at present. I could be
>
./config.guess
i686-pc-linux-gnu
gcc -v
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/specs
Configured with: ../configure --with-cpu=pentium2 --with-march=pentium2
--with-mtune=pentium2 --prefix=/usr --enable-shared --enable-threads
Thread model: posix
gcc version 3.4.4
Slackware 10.1
Snapshot gcc-4.1-20050604 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20050604/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 CVS branch
with the following options: -D2005-06-04 17:43 UTC
You'll
Hi,
Kazu reported on the performance of tree-ssa from rebuild_jump_labels's
view in March last year: http://gcc.gnu.org/ml/gcc/2004-03/msg00659.html.
I decided to redo this little experiment on my collection of cc1-i files.
My results for today's CVS head at -O2 on amd64:
mainline today
--
Am Samstag, 4. Juni 2005 15:04 schrieb Paolo Bonzini:
> > (parallel [
> > (use (operands[0]))
> > (set (operands[0]) (minus:HI (operands[1]) (operands[2]))
> > (note "please delete the entire embracing parallel instruction before
> > register life-time analysis by a new pass: It pretends to use
On Saturday 04 June 2005 15:50, Thomas Koenig wrote:
> I'm getting the following error messages when trying to run
> a diff from mainline:
>
> $ cvs diff Makefile.am libgfortran.h runtime/in_pack_generic.c
> runtime/in_unpack_generic.c m4/in_pack.m4 m4/in_unpack.m4 >
> ~/Krempel/In-pack/in_pack.p
I'm getting the following error messages when trying to run
a diff from mainline:
$ cvs diff Makefile.am libgfortran.h runtime/in_pack_generic.c
runtime/in_unpack_generic.c m4/in_pack.m4 m4/in_unpack.m4 >
~/Krempel/In-pack/in_pack.patch
cvs diff: [13:47:28] waiting for hubicka's lock in /cvs/g
The condition-code re-use issue is the point, where, IMO, the link to the
subreg-lowering 2.) shows up. After, e.g., breaking down a HI mode "sub"
operation into two QI mode "sub" and "sub-with-carry"s at expand, I consider
it to be extremely difficult to make the mid-end smart enough to identif
Hi,
During the last weeks I have experimented a bit with the AVR back-end. IMO
there presently are two areas where it is worth to concentrating efforts on:
1.) cc0 -> CCmode transition
2.) splitting of HI- and SI-mode operations so that the RTL finally gets some
similarity with the actually exis
> Jan Hubicka wrote:
>
> > I've comitted the attached patch. I didn't suceed to reproduce your
> > failures, but Danny reported it fixes his and it bootstrap/regtests
> > i686-pc-gnu-linux.
>
> Thanks; this does fix one crash on s390x, but doesn't fix the
> pass57-frag crashes on s390.
>
> What
> This particular problem is gone now
Right, works fine on Solaris too.
--
Eric Botcazou
Jan Hubicka wrote:
> I've comitted the attached patch. I didn't suceed to reproduce your
> failures, but Danny reported it fixes his and it bootstrap/regtests
> i686-pc-gnu-linux.
Thanks; this does fix one crash on s390x, but doesn't fix the
pass57-frag crashes on s390.
What happens is that aft
This particular problem is gone now
--
Cheers,
/ChJ
S -O -ftrapv on SPARC:
foo:
jmp %o7+8
add%o0, %o1, %o0
.size foo, .-foo
.ident "GCC: (GNU) 4.1.0 20050604 (experimental)"
And I have a slightly more contrived example with the same problem at -O0!
I think we cannot use -ftrapv alone for Ada be
15 matches
Mail list logo
