Compile time stack checking
Hi all. I have read the gcc-summit 2005 publication from Eric Botcaczou, Cyrille Comar and Oliver Hainque about static stack analysis. This is a quite interresting approach, especially for embedded systems. While reading the article i saw many talking about ada but not for C. Is the patch only for ada? Will there be a C/C++-Version available someday? I downloaded gcc-4.2.-20060204 and the resulting compiler did not understand -fstack-usage and -fcallgraph-info. A grep on the sources didnt contain the string "stack-usage". At least i hoped to find something in the ADA directory, since the gcc online docu regarding GNAT tools already documents that compiler switches. Is there a separate patch to be applied? Kind regards Hauke
Re: Compile time stack checking
> I have read the gcc-summit 2005 publication from Eric Botcaczou, Cyrille > Comar and Oliver Hainque about static stack analysis. > > This is a quite interresting approach, especially for embedded systems. > > While reading the article i saw many talking about ada but not for C. > > Is the patch only for ada? Will there be a C/C++-Version available > someday? The patch was developed for 3.x but, as per the GCC rules, needs to be ported to 4.x and merged in mainline. We are in the process of doing that. -- Eric Botcazou
Re: hang in acats testsuite test cxg2014 on hppa2.0w-hp-hpux11.00
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Geert Bosch schrieb: > > On Feb 15, 2006, at 13:28, John David Anglin wrote: > >> Understood. My question was what should the define for >> WIDEST_HARDWARE_FP_SIZE be when generating code for a target >> with no hardware floating point support (e.g., when >> TARGET_SOFT_FLOAT is true)? > > Practically, I'd say it should be 64, as it's a bit of a > universal assumption that you at least have 32-bit and 64-bit > float types, and possibly an 80 bit one (formatted up to 128 bits). > Of course, the idea with soft float is not to reflect reality, > but rather to have a reasonable match with expectations of the > software you'd want to run. apart from your discussion: The patch proposed by Olivier applied to 4.1 gives 0 failures for the whole acats testsuite, as you can see: LAST_UPDATED: === acats tests === === acats Summary === # of expected passes2316 # of unexpected failures0 Native configuration is hppa2.0w-hp-hpux11.00 === gcc tests === Running target unix/ FAIL: gcc.dg/cpp/_Pragma3.c (test for excess errors) === gcc Summary for unix/ === # of expected passes36348 # of unexpected failures1 # of expected failures 78 # of untested testcases 28 # of unsupported tests 420 Running target unix/-mpa-risc-2-0 FAIL: gcc.c-torture/execute/20010122-1.c execution, -O0 FAIL: gcc.c-torture/execute/20010122-1.c execution, -O1 FAIL: gcc.c-torture/execute/20010122-1.c execution, -O2 FAIL: gcc.c-torture/execute/20010122-1.c execution, -O3 -g FAIL: gcc.c-torture/execute/20010122-1.c execution, -Os FAIL: gcc.dg/cpp/_Pragma3.c (test for excess errors) === gcc Summary for unix/-mpa-risc-2-0 === # of expected passes36343 # of unexpected failures6 # of expected failures 78 # of untested testcases 28 # of unsupported tests 420 === gcc Summary === # of expected passes72691 # of unexpected failures7 # of expected failures 156 # of untested testcases 56 # of unsupported tests 840 /disk1/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.1-test/gcc-4.1-test/gcc/xgcc version 4.1.0 20060214 (prerelease) Compiler version: 4.1.0 20060214 (prerelease) Platform: hppa2.0w-hp-hpux11.00 configure flags: --prefix=/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/install - --with-gnu-as - --with-as=/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/install/bin/as - --with-ld=/usr/ccs/bin/ld --enable-threads=posix --disable-shared - --with-gmp=/appl/shared/gnu/HP-UX/hppa2.0w-hp-hpux11.00 - --with-mpfr=/appl/shared/gnu/HP-UX/hppa2.0w-hp-hpux11.00 --enable-languages=c,ada binutils: binutils-2.16.1 Build system: HP-UX c3600-1 B.11.00 A 9000/785 HP-UX cc for building: gcc gcc (GCC) 3.4.5 Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. as for building: GNU assembler 2.16.1 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of \`hppa2.0w-hp-hpux11.00'. ld for building: 92453-07 linker command s800.sgs ld PA64 B.11.43 REL 050124 /usr/ccs/bin/ld: Usage: /usr/ccs/bin/ld [options] [flags] files /usr/ccs/bin/ld: 92453-07 linker linker ld B.11.43 050125 Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD9E6Z3s6elE6CYeURAs6sAJ0aosPF1+bpjDcI2hnJ9Qp2M3v8LACfWVKH Oto+Xl3bpJ0tjUAPGHsRHrc= =jqcg -END PGP SIGNATURE-
Re: Compile time stack checking
Eric Botcazou wrote: I have read the gcc-summit 2005 publication from Eric Botcaczou, Cyrille Comar and Oliver Hainque about static stack analysis. This is a quite interresting approach, especially for embedded systems. While reading the article i saw many talking about ada but not for C. Is the patch only for ada? Will there be a C/C++-Version available someday? The patch was developed for 3.x but, as per the GCC rules, needs to be ported to 4.x and merged in mainline. We are in the process of doing that. Concerning languages, it is true that in the context of the article we did most of our testing with Ada code but the patch is language independent and thus should benefit to all languages. Cyrille
gfortran and -mlong-double-128
Hi all, I'm sending this mail because I'm a bit confused about the -mlong-double-128 option on (for example) ppc64-linux, and its impact on gfortran/libgfortran. When I simply bootstrap a compiler with "configure --with-cpu=default32", I get a gfortran that does only have kind=4 and kind=8 reals (corresponding to C types float and double) by default. When I use this gfortran with the -mlong-double-128 option, the real(kind=16) floating point type is accepted at compile-time, but the I/O library in libgfortran doesn't know how to deal with it (since, when libgfortran was compiled, it did not detect that real(kind=16) was available), and the code fails at runtime. What should we do about that? I see a few options: 1. refuse -mlong-double-128 for Fortran code; easiest, but not exactly satisfying 2. build multiple instances of the library, as is currently done for the -m32/-m64 options 3. build only one instance of the library, but build it with -mlong-double-128 enabled, since as far as libgfortran is concerned, it only adds a new floating-point type. I may be confused about how all this is supposed to be handled, so any pointer to further reading is welcome, as well as opinion on the problem and options above. Thanks, FX
Error making a cross-compiler
Hi there, I don't know if this is the right place for questions about the gcc build/install process. Let me know the right place otherwise. I'm trying to compile a cross-compiler from gcc-4.0.2 sources. It is configured this way: /usr/src/redhat/BUILD/gcc-4.0.2/configure --prefix=/usr/local/gcc-msdos --with-local-prefix=/usr/local/gcc-msdos --enable-checking=release --disable-threads --disable-libunwind-exceptions --enable-target-optspace --with-system-zlib --enable-__cxa_atexit --enable-languages=c,c++ --host=i386-redhat-linux --target=i686-pc-msdosdjgpp But at a point during the make process I've got this: make ... make[2]: Entering directory `/root/gcc-build/i686-pc-msdosdjgpp/gcc' for d in libgcc; do \ if [ -d $d ]; then true; else /bin/sh /usr/src/redhat/BUILD/gcc-4.0.2/gcc/../mkinstalldirs $d; fi; \ done mkdir -p -- libgcc if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi /root/gcc-build/i686-pc-msdosdjgpp/gcc/xgcc -B/root/gcc-build/i686-pc-msdosdjgpp/gcc/ -B/usr/local/gcc-msdos/i686-pc-msdosdjgpp/bin/ -B/usr/local/gcc-msdos/i686-pc-msdosdjgpp/lib/ -isystem /usr/local/gcc-msdos/i686-pc-msdosdjgpp/include -isystem /usr/local/gcc-msdos/i686-pc-msdosdjgpp/sys-include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I/usr/src/redhat/BUILD/gcc-4.0.2/gcc -I/usr/src/redhat/BUILD/gcc-4.0.2/gcc/. -I/usr/src/redhat/BUILD/gcc-4.0.2/gcc/../include -I/usr/src/redhat/BUILD/gcc-4.0.2/gcc/../libcpp/include -DL_muldi3 -c /usr/src/redhat/BUILD/gcc-4.0.2/gcc/libgcc2.c -o libgcc/./_muldi3.o cc1: error: ../include/sys/version.h: No such file or directory make[2]: *** [libgcc/./_muldi3.o] Error 1 make[2]: Leaving directory `/root/gcc-build/i686-pc-msdosdjgpp/gcc' make[1]: *** [libgcc.a] Error 2 make[1]: Leaving directory `/root/gcc-build/i686-pc-msdosdjgpp/gcc' make: *** [all-gcc] Error 2 As far as I can see, both isystem directories don't exist in my system. What I'm doing wrong?. Where should I get the missing header files?. Thank you in advance. David.
Re: Error making a cross-compiler
> I don't know if this is the right place for questions about > the gcc build/install process. Let me know the right place > otherwise. It would be better to start on the gcc-help mailing list. Also, consider looking into using crosstool to assist with building. Ben
Re: Design a microcontroller for gcc
On Wed, 15 Feb 2006, DJ Delorie wrote: I wrote: > > Anyway, at least keep a way to add reg+reg and reg+integer, load and > > store of memory and load of integer and address without condition > > code effects and your port has a chance to avoid the related bloat. > > At least, move/load/store shouldn't touch flags. I may have listed more operations than necessary, but the important bit is that you need to form arbitrary addresses in the stack frame without touching flags. If for any const_int N, (plus reg N) is a valid address for moves to and from memory that doesn't touch flags, then I suppose you don't *need* an "add" that doesn't touch flags. brgds, H-P
GCC 4.1 Branch Frozen
As previously, announced the GCC 4.1 branch is now frozen. All non-documentation changes now require my explicit approval. I had hoped to generate a release candidate last night, but (a) there are a couple of new PRs I need to review, and (b) I'm onsite with a customer, and didn't hvae as much time as I'd hoped. My expectation is that RC1 will be available over the weekend. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: gfortran and -mlong-double-128
On 2/16/06, François-Xavier Coudert <[EMAIL PROTECTED]> wrote: > Hi all, > > I'm sending this mail because I'm a bit confused about the > -mlong-double-128 option on (for example) ppc64-linux, and its impact > on gfortran/libgfortran. > > When I simply bootstrap a compiler with "configure > --with-cpu=default32", I get a gfortran that does only have kind=4 and > kind=8 reals (corresponding to C types float and double) by default. > When I use this gfortran with the -mlong-double-128 option, the > real(kind=16) floating point type is accepted at compile-time, but the > I/O library in libgfortran doesn't know how to deal with it (since, > when libgfortran was compiled, it did not detect that real(kind=16) > was available), and the code fails at runtime. > > What should we do about that? I see a few options: > 1. refuse -mlong-double-128 for Fortran code; easiest, but not > exactly satisfying > 2. build multiple instances of the library, as is currently done for > the -m32/-m64 options > 3. build only one instance of the library, but build it with > -mlong-double-128 enabled, since as far as libgfortran is concerned, > it only adds a new floating-point type. I guess libgfortran has configury to figure out if kind=16 is available? If so then libgfortran should be built with -mlong-double-128, as this should only add extra symbols that do not conflict with kind=4 and kind=8 ones. Am I correct that for gfortran there is no such thing as long double == double for -mlong-double-64? If so, then this is really the way to go. Richard.
Re: gfortran and -mlong-double-128
> I guess libgfortran has configury to figure out if kind=16 is available? Yes. > If so then libgfortran should be built with -mlong-double-128, as this > should only add extra symbols that do not conflict with kind=4 and kind=8 > ones. Hum, that has to be done early in the configury (before all autodetection). Do you think it's better suited at the beginning of libgfortran/configure.ac (a special test, to see if -mlong-double-128 is available, and if it is add it to CFLAGS), or should it be done in an upper level (and here is the limit of my understanding of the build mechanism)? > Am I correct that for gfortran there is no such thing as long double > == double for -mlong-double-64? This is right. Fortran has a list of available floating-point modes, and they are chosen by a unique numbering scheme (the number is called a "kind"). FX
Re: hang in acats testsuite test cxg2014 on hppa2.0w-hp-hpux11.00
> The patch proposed by Olivier applied to 4.1 gives 0 failures for the whole > acats testsuite, as you can see: > > LAST_UPDATED: > === acats tests === > > === acats Summary === > # of expected passes 2316 > # of unexpected failures 0 While not quite as good as your 4.1.0 results, I had a similar improvement on 4.0.3: http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00815.html Olivier, with the addition of a ChangeLog entry, the patch is ok for all active branches (3.4, 4.0, 4.1 and trunk). Mark, is it ok for Olivier to apply the patch mentioned here on 4.1? http://gcc.gnu.org/ml/gcc/2006-02/msg00251.html It only affects Ada on PA HP-UX. It's obviously correct. Thanks, Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Re: Error making a cross-compiler
> cc1: error: ../include/sys/version.h: No such file or directory > > What I'm doing wrong?. Where should I get the missing header files?. This is a header that comes with DJGPP's library. Like most cross compilers, you have to install part of the runtime package (usually at least the headers) before you can build gcc's runtime library.
Re: gfortran and -mlong-double-128
On Thu, Feb 16, 2006 at 01:57:39PM +0100, Fran?ois-Xavier Coudert wrote:
> > I guess libgfortran has configury to figure out if kind=16 is available?
>
> Yes.
>
> > If so then libgfortran should be built with -mlong-double-128, as this
> > should only add extra symbols that do not conflict with kind=4 and kind=8
> > ones.
>
> Hum, that has to be done early in the configury (before all
> autodetection). Do you think it's better suited at the beginning of
> libgfortran/configure.ac (a special test, to see if -mlong-double-128
> is available, and if it is add it to CFLAGS), or should it be done in
> an upper level (and here is the limit of my understanding of the build
> mechanism)?
That will not work. It is not enough if GCC supports -mlong-double-128
switch, you also need runtime library support for that.
So the check needs to be something like
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01075.html
(still not reviewed :( ). If you configure gcc with --with-long-double-128
(what I'm using e.g. on redhat/gcc-4_1-branch now for
{ppc*,s390*,sparc,alpha}-*-linux*), then libgfortran is automatically built
with -mlong-double-128 and can cope with both -mlong-double-128 and
-mlong-double-64 code. libstdc++.so will only support both
-mlong-double-{64,128} if it is built with -mlong-double-128, so it is in
the same boat as libgfortran.
Not sure if it makes any sense to detect the presence of glibc 2.4+ and
build libstdc++-v3/libgfortran with -mlong-double-128 even if configured
with --without-long-double-128.
Jakub
Ada bootstrap failure for mainline on hppa2.0w-hp-hpux11.00
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Failed to build gnattools: # gnattools2 gmake -C ../gcc/ada/tools -f ../Makefile \ "CC=../../xgcc -B../../" "CFLAGS=-O2 -g -O2 " "ADAFLAGS=-gnatpg -gnata" "INCLUDES=-I. -I.. -I../.. - -I/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/src/gcc/ada - -I/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/src/gcc/ada/../config - -I/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/src/gcc/ada/../../include - -I/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/src/gcc/ada/.." "ADA_INCLUDES=-I../rts -I. - -I/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/src/gcc/ada" "exeext=" "fsrcdir=/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/src/gcc/ada" "srcdir=/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/src/gcc/ada" "GNATMAKE=../../gnatmake" "GNATLINK=../../gnatlink" "GNATBIND=../../gnatbind" "TOOLSCASE=native" \ ../../gnatchop ../../gnat ../../gnatkr ../../gnatls ../../gnatprep ../../gnatxref ../../gnatfind ../../gnatname ../../gnatclean ../../gprmake gmake[3]: Entering directory `/disk1/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.2/gcc-4.2/gcc/ada/tools' ../../gnatmake -c -I../rts -I. - -I/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/src/gcc/ada gnatchop - --GCC="../../xgcc -B../../ -O2 -g -O2 -mdisable-indexing -gnatpg -gnata" ../../xgcc -c -I./ -I../rts -I. - -I/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/src/gcc/ada -B../../ -O2 -g -O2 - -mdisable-indexing -gnatpg -gnata -I- /raid/tecosim/it/devel/projects/develtools/src/gcc-4.2-svn/gcc/ada/gnatchop.adb ../../gnatbind -I../rts -I. - -I/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/src/gcc/ada -static -x gnatchop ../../gnatlink -v gnatchop -o ../../gnatchop --GCC="../../xgcc -B../../ - -static-libgcc -I../rts -I. - -I/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/src/gcc/ada" ../../prefix.o ../../version.o targext.o link.o ../rts/libgnat.a ../../../libiberty/libiberty.a /usr/lib/libcl.a GNATLINK 4.2.0 20060216 (experimental) Copyright 1995-2006, Free Software Foundation, Inc xgcc -c -gnatA -gnatWb -gnatiw -B../../ -static-libgcc -I../rts -I. - -I/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/src/gcc/ada -gnatws b~gnatchop.adb ../../xgcc b~gnatchop.o ../../prefix.o ../../version.o targext.o link.o ../rts/ada.o ../rts/a-charac.o ../rts/a-chlat1.o ../rts/gnat.o ../rts/g-string.o ./interfac.o ./system.o ../rts/s-addope.o ./s-casuti.o ../rts/g-casuti.o ./s-htable.o ../rts/s-parame.o ../rts/s-crtl.o ../rts/i-cstrea.o ./s-purexc.o ../rts/s-restri.o ./s-stoele.o ../rts/s-carun8.o ../rts/s-imgint.o ../rts/a-comlin.o ../rts/s-stache.o ../rts/s-strops.o ../rts/s-sopco3.o ../rts/s-sopco4.o ../rts/s-sopco5.o ../rts/s-traceb.o ../rts/s-traent.o ../rts/s-soflin.o ../rts/a-elchha.o ./s-secsta.o ./s-exctab.o ../rts/a-ioexce.o ../rts/a-string.o ../rts/a-stream.o ../rts/g-os_lib.o ../rts/s-assert.o ../rts/s-finroo.o ../rts/s-memory.o ./s-stalib.o ../rts/s-unstyp.o ../rts/s-bitops.o ../rts/a-strmap.o ../rts/a-stmaco.o ../rts/a-chahan.o ../rts/a-strsea.o ../rts/a-strfix.o ../rts/s-stratt.o ../rts/s-finimp.o ../rts/a-finali.o ../rts/a-filico.o ../rts/g-dirope.o ../rts/g-regexp.o ../rts/g-comlin.o ../rts/s-ficobl.o ../rts/s-fileio.o ../rts/a-textio.o ../rts/s-valuti.o ../rts/s-valuns.o ../rts/s-valint.o ../rts/s-wchcon.o ../rts/s-wchjis.o ../rts/s-wchcnv.o ../rts/s-wchstw.o ../rts/a-tags.o ./a-except.o ./gnatvsn.o ./types.o ./hostparm.o ./gnatchop.o -o ../../gnatchop ../rts/libgnat.a ../../../libiberty/libiberty.a /usr/lib/libcl.a -- -L../rts/ - -L./ -L/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/src/gcc/ada/ - -L/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/install/lib/gcc/hppa2.0w-hp-hpux11.00/4.2.0/adalib/ ../rts/libgnat.a /usr/lib/libcl.a -B../../ -static-libgcc -I../rts -I. - -I/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/src/gcc/ada cc1: error: unrecognized command line option "-f " collect2: gcc returned 1 exit status gnatlink: cannot call ../../xgcc gmake[3]: *** [../../gnatchop] Error 4 Rainer - -- Rainer Emrich TECOSIM GmbH Im Eichsfeld 3 65428 Rüsselsheim Phone: +49(0)6142/8272 12 Mobile: +49(0)163/56 949 20 Fax.: +49(0)6142/8272 49 Web: www.tecosim.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD9JW13s6elE6CYeURAnz5AJ4xtezot8SGi6axm2yyR/VEeL2fsACgolOe pKzU5SEPRjXe3ZYqY/RMzck= =he1M -END PGP SIGNATURE-
Re: gfortran and -mlong-double-128
On Thursday 16 February 2006 11:09, François-Xavier Coudert wrote: > Hi all, > > I'm sending this mail because I'm a bit confused about the > -mlong-double-128 option on (for example) ppc64-linux, and its impact > on gfortran/libgfortran. > > When I simply bootstrap a compiler with "configure > --with-cpu=default32", I get a gfortran that does only have kind=4 and > kind=8 reals (corresponding to C types float and double) by default. > When I use this gfortran with the -mlong-double-128 option, the > real(kind=16) floating point type is accepted at compile-time, but the > I/O library in libgfortran doesn't know how to deal with it (since, > when libgfortran was compiled, it did not detect that real(kind=16) > was available), and the code fails at runtime. > > What should we do about that? I see a few options: > 1. refuse -mlong-double-128 for Fortran code; easiest, but not > exactly satisfying > 2. build multiple instances of the library, as is currently done for > the -m32/-m64 options > 3. build only one instance of the library, but build it with > -mlong-double-128 enabled, since as far as libgfortran is concerned, > it only adds a new floating-point type. IMHO libgfortran shouldn't have to know or care about this option at all. If you want a long-double-128 toolchain, then toplevel configure should be passing that option when configuring target libraries. Having gfortran magically know about certain ABI breaking options, and doing funny things on certain targets seems a very bad precedent to me. Paul
Re: gfortran and -mlong-double-128
> Having gfortran magically know about certain ABI breaking options, and doing > funny things on certain targets seems a very bad precedent to me. Then, I think we should have the front-end refuse the option. It's annoying to have a compiler accept code, and only tell you at runtime (at the end of your simulation!) that it can't work. FX
Re: gfortran and -mlong-double-128
On 2/16/06, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 16, 2006 at 01:57:39PM +0100, Fran?ois-Xavier Coudert wrote:
> > > I guess libgfortran has configury to figure out if kind=16 is available?
> >
> > Yes.
> >
> > > If so then libgfortran should be built with -mlong-double-128, as this
> > > should only add extra symbols that do not conflict with kind=4 and kind=8
> > > ones.
> >
> > Hum, that has to be done early in the configury (before all
> > autodetection). Do you think it's better suited at the beginning of
> > libgfortran/configure.ac (a special test, to see if -mlong-double-128
> > is available, and if it is add it to CFLAGS), or should it be done in
> > an upper level (and here is the limit of my understanding of the build
> > mechanism)?
>
> That will not work. It is not enough if GCC supports -mlong-double-128
> switch, you also need runtime library support for that.
> So the check needs to be something like
> http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01075.html
> (still not reviewed :( ). If you configure gcc with --with-long-double-128
> (what I'm using e.g. on redhat/gcc-4_1-branch now for
> {ppc*,s390*,sparc,alpha}-*-linux*), then libgfortran is automatically built
> with -mlong-double-128 and can cope with both -mlong-double-128 and
> -mlong-double-64 code. libstdc++.so will only support both
> -mlong-double-{64,128} if it is built with -mlong-double-128, so it is in
> the same boat as libgfortran.
> Not sure if it makes any sense to detect the presence of glibc 2.4+ and
> build libstdc++-v3/libgfortran with -mlong-double-128 even if configured
> with --without-long-double-128.
Well, fortran is special here compared to libstdc++-v3, because we do not
change its ABI by -mlong-double-128 but only add kind=16 intrinsics support.
So it makes sense to build libgfortran with support for kind=16 if glibc support
is there, regardless of the default setting for long-double.
Richard.
Re: gfortran and -mlong-double-128
On Thursday 16 February 2006 15:14, François-Xavier Coudert wrote: > > Having gfortran magically know about certain ABI breaking options, and > > doing funny things on certain targets seems a very bad precedent to me. > > Then, I think we should have the front-end refuse the option. It's > annoying to have a compiler accept code, and only tell you at runtime > (at the end of your simulation!) that it can't work. The only thing that can do that is the driver (probably via spec strings). The compiler itself doesn't know what multilibs you have available. Paul
Re: gfortran and -mlong-double-128
On 2/16/06, Paul Brook <[EMAIL PROTECTED]> wrote: > On Thursday 16 February 2006 11:09, François-Xavier Coudert wrote: > > Hi all, > > > > I'm sending this mail because I'm a bit confused about the > > -mlong-double-128 option on (for example) ppc64-linux, and its impact > > on gfortran/libgfortran. > Having gfortran magically know about certain ABI breaking options, and doing > funny things on certain targets seems a very bad precedent to me. The point is that from a gfortran perspective -mlong-double-128 doesn't change the ABI, it merely adds to it (which is sort of a change, but less invasive than changing long double from 8bytes to 16bytes). So we can easily cope with the user request for -mlong-double-128 by always providing the kind=16 intrinsics. Richard.
Re: gfortran and -mlong-double-128
> > On 2/16/06, Paul Brook <[EMAIL PROTECTED]> wrote: > > On Thursday 16 February 2006 11:09, François-Xavier Coudert wrote: > > > Hi all, > > > > > > I'm sending this mail because I'm a bit confused about the > > > -mlong-double-128 option on (for example) ppc64-linux, and its impact > > > on gfortran/libgfortran. > > Having gfortran magically know about certain ABI breaking options, and doing > > funny things on certain targets seems a very bad precedent to me. > > The point is that from a gfortran perspective -mlong-double-128 doesn't change > the ABI, it merely adds to it (which is sort of a change, but less invasive > than > changing long double from 8bytes to 16bytes). So we can easily cope with the > user request for -mlong-double-128 by always providing the kind=16 intrinsics. So what, who cares. This option does change other parts of the ABI that you might not know well. The 16bytes version in libgfortran will be calling the wrong function and not working anyways. But this is not really the issue here anyways. The orginal problem was a failural with targets that default to having 128bits floats like powerpc-darwin and sparc-solaris and a couple other targets. -- Pinski
Re: gfortran and -mlong-double-128
On Thursday 16 February 2006 15:18, Richard Guenther wrote: > On 2/16/06, Paul Brook <[EMAIL PROTECTED]> wrote: > > On Thursday 16 February 2006 11:09, François-Xavier Coudert wrote: > > > Hi all, > > > > > > I'm sending this mail because I'm a bit confused about the > > > -mlong-double-128 option on (for example) ppc64-linux, and its impact > > > on gfortran/libgfortran. > > > > Having gfortran magically know about certain ABI breaking options, and > > doing funny things on certain targets seems a very bad precedent to me. > > The point is that from a gfortran perspective -mlong-double-128 doesn't > change the ABI, it merely adds to it (which is sort of a change, but less > invasive than changing long double from 8bytes to 16bytes). So we can > easily cope with the user request for -mlong-double-128 by always providing > the kind=16 intrinsics. Except it [potentially] also changes the ABI that libgfortran uses to talk to glibc. ie. a -mlong-double-128 libgfortran probably won't work with a -mlong-double-64 glibc. Paul
Re: gfortran and -mlong-double-128
On Thu, Feb 16, 2006 at 03:28:46PM +, Paul Brook wrote:
> > The point is that from a gfortran perspective -mlong-double-128 doesn't
> > change the ABI, it merely adds to it (which is sort of a change, but less
> > invasive than changing long double from 8bytes to 16bytes). So we can
> > easily cope with the user request for -mlong-double-128 by always providing
> > the kind=16 intrinsics.
>
> Except it [potentially] also changes the ABI that libgfortran uses to talk to
> glibc. ie. a -mlong-double-128 libgfortran probably won't work with a
> -mlong-double-64 glibc.
That is not a big deal. On the platforms we talk about (ppc{32,64},
s390{,x}, sparc32, alpha) glibc 2.4 and forward has 128-bit long double
support, glibc 2.3.x and earlier doesn't, this isn't an optional glibc
configure decision, it is part of glibc 2.4+ ABI on those arches.
So, yes, you can't use -mlong-double-128 libgfortran against
-mlong-double-64 glibc (read as, glibc 2.3.x or earlier), but that would
mean you compiled/linked against glibc 2.4+ and are trying to run
against glibc 2.3.x or earlier. That generally doesn't work for any
glibc versions, glibc is only backwards compatible, not forward compatible.
And you get a clear error when trying to load program's shared libraries
(or e.g. various package managers like rpm will not even allow you to
install that unless forced).
Jakub
Re: CAN_ELIMINATE question
Ian Lance Taylor writes: [...] > > > I think that better to call update_eliminables() somewhere after > > setup_save_areas() > > Exactly. We do that. About 15 lines after the lines you quoted > above. > > What am I missing? I'm (exactly AVR port) need in call to update_eliminables() somewhere between setup_save_areas() and calculate_needs_all_insns() (Not "about 15 lines after" ;) because all bad things happened inside calculate_needs_all_insns(). calculate_needs_all_insns() collect wrong reloads because reg_eliminate structure for FP->SP have wrong can_eliminate field. Denis.
gcc 4.1 regression for adjusted function declaration?
The following code gives an error with gcc 4.1: struct tag; extern void f (struct tag a[1]); gcc 3.2.3 compiles this code without complaint. I'm not sure what the c99 standard is actually saying about this code. On the one hand, in 6.7.5.2, it says about array declarators: The element type shall not be an incomplete or function type. On the other hand, in 6.7.5.3, function declarators, it says: "After adjustment, the parameters in a parameter type list in a function declarator that is part of a definition of that function shall not have incomplete type." and "A declaration of a parameter as ``array of type'' shall be adjusted to ``qualified pointer to type'',.." You can't actually have an 'array of type' without having an array declarator first, and I also can't find anything about how you could construct in incomplete array declarator using an incomplete type, but if you can't, what would be the point of specifying that the the test for a part of the definition having incomplete type is to be done after adjustment?
Re: gcc 4.1 regression for adjusted function declaration?
On Feb 16, 2006, at 12:52 PM, Joern RENNECKE wrote: The following code gives an error with gcc 4.1: struct tag; extern void f (struct tag a[1]); gcc 3.2.3 compiles this code without complaint. GCC before 4.0.0 was incorrect at not rejecting this code. See PR 19333. Use -pedantic with 3.2.3 and you will get a warning. Also see: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00948.html Thanks, Andrew Pinski
Re: gcc 4.1 regression for adjusted function declaration?
Andrew Pinski wrote: GCC before 4.0.0 was incorrect at not rejecting this code. See PR 19333. Use -pedantic with 3.2.3 and you will get a warning. Yes, I do, but it is also questionable if this warning is required or even useful. Also see: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00948.html The issue there is completely different. The array has definetly no completed type. In the testcase I have given - which is pruned down from the pthread.h header file on a linux installation - after applying adjustment, you get: extern void f (struct tag *a); which is fine. So this is only about the technicality if the adjustment is actually defined in this case. It appears to me that the intent of the standard was that this should be defined, while the letter of it is not even self-consistet.
Re: gcc 4.1 regression for adjusted function declaration?
On Feb 16, 2006, at 1:18 PM, Joern RENNECKE wrote:
Andrew Pinski wrote:
GCC before 4.0.0 was incorrect at not rejecting this code.
See PR 19333.
Use -pedantic with 3.2.3 and you will get a warning.
Yes, I do, but it is also questionable if this warning is required or
even useful.
Also see:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00948.html
The issue there is completely different. The array has definetly no
completed type.
In the testcase I have given - which is pruned down from the pthread.h
header file on
a linux installation - after applying adjustment, you get:
extern void f (struct tag *a);
which is fine. So this is only about the technicality if the
adjustment is actually
defined in this case. It appears to me that the intent of the
standard was that this
should be defined, while the letter of it is not even self-consistet.
See also:
http://gcc.gnu.org/ml/gcc/2005-02/msg00011.html
Even more important:
http://gcc.gnu.org/ml/gcc/2005-02/msg00026.html
Which is the answer you are looking for:
But the constraint in C99 is on array declarators, "The element type
shall
not be an incomplete or function type.". This applies to the syntax
whenever it describes an array type even that array type then gets
adjusted to a pointer type. In C90, without the constraint, there was
undefined behavior for an array of incomplete type, even in parameter
context: DR#047 example 3 is almost exactly this case
/* 3 */ struct S *g(struct S a[]) {return a; }
and was said to involve undefined behavior. "However, there is nothing
to
suggest that a not-strictly-conforming array type can magically be
transformed into a strictly conforming pointer parameter via this rule."
-- Pinski
Re: gcc 4.1 regression for adjusted function declaration?
On Feb 16, 2006, at 1:18 PM, Joern RENNECKE wrote: The issue there is completely different. The array has definetly no completed type. In the testcase I have given - which is pruned down from the pthread.h header file on a linux installation - after applying adjustment, you get: extern void f (struct tag *a); which is fine. Also pthread.h should have been fixincluded (unless you turned it for some reason). The patch which fixed that is: 2005-03-21 Richard Guenther <[EMAIL PROTECTED]> PR target/20166 * inclhack.def: Add fix for array of incomplete structures in function prototype in pthread.h. * fixincl.x: Regenerate. * tests/base/pthread.h: Adjust. Thanks, Andrew Pinski
Re: gcc 4.1 regression for adjusted function declaration?
On Feb 16, 2006, at 2:32 PM, Andrew Pinski wrote:
Even more important:
http://gcc.gnu.org/ml/gcc/2005-02/msg00026.html
Which is the answer you are looking for:
But the constraint in C99 is on array declarators, "The element type
shall
not be an incomplete or function type.". This applies to the syntax
whenever it describes an array type even that array type then gets
adjusted to a pointer type. In C90, without the constraint, there was
undefined behavior for an array of incomplete type, even in parameter
context: DR#047 example 3 is almost exactly this case
/* 3 */ struct S *g(struct S a[]) {return a; }
and was said to involve undefined behavior. "However, there is
nothing to
suggest that a not-strictly-conforming array type can magically be
transformed into a strictly conforming pointer parameter via this
rule."
And this was a documented change too:
http://gcc.gnu.org/gcc-4.0/changes.html
Arrays of incomplete element type are invalid in C. GCC now issues an
error for such arrays. Declarations such as extern struct s x[]; (where
struct s has not been defined) can be moved after the definition of
struct s. Function parameters declared as arrays of incomplete type can
instead be declared as pointers
-- Pinski
Re: pruning unused debugging types (enums/PR23336)
On Tue, Feb 14, 2006 at 06:08:42PM -0800, Mark Mitchell wrote:
> Aldy Hernandez wrote:
>
> > Do we keep a hash of functions that have been written out somewhere?
>
> Not to my knowledge.
>
> > I'd hate to walk the entire hash table each time we write out a function
> > searching for the types that function uses.
>
> Agreed.
Hi Mark. Hi folks.
I went through a couple prototypes, some more cumbersome to implement than
others. I've opted for a hash table of types in struct function. The
implementation is a lot cleaner. Perhaps we can optimize it later if
you really hate it :(.
This patch fixes the cast problem. A similar solution would be in order
for the enums; the infrastructure here would work for that.
Could you take a peek at this, so we can use this as a starting point, and
perhaps then I can start on the C++ front-end? I've sat on this long enough
:(.
Thanks.
Aldy
* function.h (struct function): Add used_types_hash field.
Include hashtab.h.
* function.c (used_types_insert): New.
* c-parser.c (c_parser_cast_expression): Call used_types_insert.
* dwarf2out.c (struct die_struct): Add die_perennial_p field.
(premark_used_types_helper): New.
(premark_used_types): New.
(gen_subprogram_die): Call premark_used_types.
(prune_unused_types_walk): Do not mark perennial types.
* c-decl.c (store_parm_decls): Initialize used_types_hash.
(used_types_insert): Protoize.
* Makefile.in (FUNCTION_H): Depend on HASHTAB_H.
Index: function.h
===
--- function.h (revision 110692)
+++ function.h (working copy)
@@ -23,6 +23,7 @@ Software Foundation, 51 Franklin Street,
#define GCC_FUNCTION_H
#include "tree.h"
+#include "hashtab.h"
struct var_refs_queue GTY(())
{
@@ -312,6 +313,9 @@ struct function GTY(())
/* Language-specific code can use this to store whatever it likes. */
struct language_function * language;
+ /* Used types hash table. */
+ htab_t GTY ((param_is (union tree_node))) used_types_hash;
+
/* For reorg. */
/* If some insns can be deferred to the delay slots of the epilogue, the
@@ -562,4 +566,6 @@ extern bool pass_by_reference (CUMULATIV
extern bool reference_callee_copied (CUMULATIVE_ARGS *, enum machine_mode,
tree, bool);
+extern void used_types_insert (tree, struct function *);
+
#endif /* GCC_FUNCTION_H */
Index: function.c
===
--- function.c (revision 110692)
+++ function.c (working copy)
@@ -5569,6 +5569,18 @@ rest_of_handle_check_leaf_regs (void)
#endif
}
+/* Insert a type into the used types hash table. */
+void
+used_types_insert (tree t, struct function *cfun)
+{
+ if (t != NULL)
+{
+ void **slot = htab_find_slot (cfun->used_types_hash, t, INSERT);
+ if (*slot == NULL)
+ *slot = t;
+}
+}
+
struct tree_opt_pass pass_leaf_regs =
{
NULL, /* name */
Index: c-parser.c
===
--- c-parser.c (revision 110692)
+++ c-parser.c (working copy)
@@ -4660,6 +4660,10 @@ c_parser_cast_expression (c_parser *pars
ret.original_code = ERROR_MARK;
return ret;
}
+
+ /* Save casted types in the function's used types hash table. */
+ used_types_insert (TREE_TYPE (groktypename (type_name)), cfun);
+
if (c_parser_next_token_is (parser, CPP_OPEN_BRACE))
return c_parser_postfix_expression_after_paren_type (parser,
type_name);
Index: dwarf2out.c
===
--- dwarf2out.c (revision 110692)
+++ dwarf2out.c (working copy)
@@ -3677,6 +3677,8 @@ typedef struct die_struct GTY(())
dw_offset die_offset;
unsigned long die_abbrev;
int die_mark;
+ /* Die is used and must not be pruned as unused. */
+ int die_perennial_p;
unsigned int decl_id;
}
die_node;
@@ -11477,6 +11479,30 @@ dwarf2out_abstract_function (tree decl)
current_function_decl = save_fn;
}
+/* Helper function of premark_used_types() which gets called through
+ htab_traverse_resize().
+
+ Marks the DIE of a given type in *SLOT as perennial, so it never gets
+ marked as unused by prune_unused_types. */
+static int
+premark_used_types_helper (void **slot, void *data ATTRIBUTE_UNUSED)
+{
+ tree type;
+ dw_die_ref die;
+
+ type = *slot;
+ die = lookup_type_die (type);
+ die->die_perennial_p = 1;
+ return 1;
+}
+
+/* Mark all members of used_types_hash as perennial. */
+static
+void premark_used_types ()
+{
+ htab_traverse_noresize (cfun->used_types_hash, premark_used_types_helper,
NULL);
+}
+
/* Generate a DIE to represent a declared function (either file-scope or
block-local). */
@@ -11492,6 +11518,8 @@ gen_subprogram_die (tree decl, d
Re: PATCH: [4.1/4.2 Regression]: Miscompiled FORTRAN program
James E Wilson wrote:
Yes, that is what I was suggesting.
It's corrected and tested on ia64 and x86-64. I've attached new version.
Denis.
Index: reload.c
===
*** reload.c(revision 35)
--- reload.c(working copy)
*** static int find_inc_amount (rtx, rtx);
*** 281,286
--- 281,287
static int refers_to_mem_for_reload_p (rtx);
static int refers_to_regno_for_reload_p (unsigned int, unsigned int,
rtx, rtx *);
+ static int reg_inc_found_and_valid_p (unsigned int, unsigned int, rtx);
/* Determine if any secondary reloads are needed for loading (if IN_P is
nonzero) or storing (if IN_P is zero) X to or from a reload register of
*** find_inc_amount (rtx x, rtx inced)
*** 6941,6949
return 0;
}
/* Return 1 if register REGNO is the subject of a clobber in insn INSN.
!If SETS is nonzero, also consider SETs. REGNO must refer to a hard
!register. */
int
regno_clobbered_p (unsigned int regno, rtx insn, enum machine_mode mode,
--- 6942,6977
return 0;
}
+ /* Return 1 if registers from REGNO to ENDREGNO are the subjects of a
+REG_INC note in insn INSN. REGNO must refer to a hard register. */
+
+ static int
+ reg_inc_found_and_valid_p (unsigned int regno ATTRIBUTE_UNUSED,
+unsigned int endregno ATTRIBUTE_UNUSED,
+rtx insn ATTRIBUTE_UNUSED)
+ {
+ #ifdef AUTO_INC_DEC
+ rtx link;
+
+ gcc_assert (insn);
+
+ if (! INSN_P (insn))
+ return 0;
+
+ for (link = REG_NOTES (insn); link; link = XEXP (link, 1))
+ if (REG_NOTE_KIND (link) == REG_INC)
+ {
+ unsigned int test = (int) REGNO (XEXP (link, 0));
+ if (test >= regno && test < endregno)
+ return 1;
+ }
+ #endif
+ return 0;
+ }
+
/* Return 1 if register REGNO is the subject of a clobber in insn INSN.
!If SETS is 1, also consider SETs. If SETS is 2, enable checking REG_INC.
!REGNO must refer to a hard register. */
int
regno_clobbered_p (unsigned int regno, rtx insn, enum machine_mode mode,
*** regno_clobbered_p (unsigned int regno, r
*** 6958,6964
endregno = regno + nregs;
if ((GET_CODE (PATTERN (insn)) == CLOBBER
!|| (sets && GET_CODE (PATTERN (insn)) == SET))
&& REG_P (XEXP (PATTERN (insn), 0)))
{
unsigned int test = REGNO (XEXP (PATTERN (insn), 0));
--- 6986,6992
endregno = regno + nregs;
if ((GET_CODE (PATTERN (insn)) == CLOBBER
!|| (sets == 1 && GET_CODE (PATTERN (insn)) == SET))
&& REG_P (XEXP (PATTERN (insn), 0)))
{
unsigned int test = REGNO (XEXP (PATTERN (insn), 0));
*** regno_clobbered_p (unsigned int regno, r
*** 6966,6971
--- 6994,7002
return test >= regno && test < endregno;
}
+ if (sets == 2 && reg_inc_found_and_valid_p (regno, endregno, insn))
+ return 1;
+
if (GET_CODE (PATTERN (insn)) == PARALLEL)
{
int i = XVECLEN (PATTERN (insn), 0) - 1;
*** regno_clobbered_p (unsigned int regno, r
*** 6974,6980
{
rtx elt = XVECEXP (PATTERN (insn), 0, i);
if ((GET_CODE (elt) == CLOBBER
! || (sets && GET_CODE (PATTERN (insn)) == SET))
&& REG_P (XEXP (elt, 0)))
{
unsigned int test = REGNO (XEXP (elt, 0));
--- 7005,7011
{
rtx elt = XVECEXP (PATTERN (insn), 0, i);
if ((GET_CODE (elt) == CLOBBER
! || (sets == 1 && GET_CODE (PATTERN (insn)) == SET))
&& REG_P (XEXP (elt, 0)))
{
unsigned int test = REGNO (XEXP (elt, 0));
*** regno_clobbered_p (unsigned int regno, r
*** 6982,6987
--- 7013,7020
if (test >= regno && test < endregno)
return 1;
}
+ if (sets == 2 && reg_inc_found_and_valid_p (regno, endregno, elt))
+ return 1;
}
}
Index: reload1.c
===
*** reload1.c (revision 110905)
--- reload1.c (working copy)
*** choose_reload_regs (struct insn_chain *c
*** 5780,5786
if (equiv != 0)
{
! if (regno_clobbered_p (regno, insn, rld[r].mode, 0))
switch (rld[r].when_needed)
{
case RELOAD_FOR_OTHER_ADDRESS:
--- 5780,5786
if (equiv != 0)
{
! if (regno_clobbered_p (regno, insn, rld[r].mode, 2))
switch (rld[r].when_needed)
{
case RELOAD_FOR_OTHER_ADDRESS:
2006-02-16 Denis Nagorny <[EMAIL PROTECTED]>
PR rtl-optimization/25603
* reload.c (reg_inc_found_and_valid_p): New. C
Re: PATCH: [4.1/4.2 Regression]: Miscompiled FORTRAN program
On Feb 16, 2006, at 2:59 PM, Denis Nagorny wrote:
James E Wilson wrote:
Yes, that is what I was suggesting.
It's corrected and tested on ia64 and x86-64. I've attached new
version.
Denis.
+ /* Return 1 if registers from REGNO to ENDREGNO are the subjects of a
+REG_INC note in insn INSN. REGNO must refer to a hard register.
*/
+
+ static int
+ reg_inc_found_and_valid_p (unsigned int regno ATTRIBUTE_UNUSED,
+unsigned int endregno ATTRIBUTE_UNUSED,
+rtx insn ATTRIBUTE_UNUSED)
+ {
+ #ifdef AUTO_INC_DEC
What about defining the code this way:
#ifdef AUTO_INC_DEC
+ static int
+ reg_inc_found_and_valid_p (unsigned int regno,
+unsigned int endregno,
+rtx insn)
+ {
...
}
#else
#define reg_inc_found_and_valid_p(regno,endregno,insn) 0
#endif
So you can remove ugly ATTRIBUTE_UNUSED.
Thanks,
Andrew Pinski
Re: PATCH: [4.1/4.2 Regression]: Miscompiled FORTRAN program
On Thu, Feb 16, 2006 at 03:03:02PM -0500, Andrew Pinski wrote:
>
> On Feb 16, 2006, at 2:59 PM, Denis Nagorny wrote:
>
> >James E Wilson wrote:
> >>Yes, that is what I was suggesting.
> >
> >It's corrected and tested on ia64 and x86-64. I've attached new
> >version.
> >Denis.
> >+ /* Return 1 if registers from REGNO to ENDREGNO are the subjects of a
> >+REG_INC note in insn INSN. REGNO must refer to a hard register.
> >*/
> >+
> >+ static int
> >+ reg_inc_found_and_valid_p (unsigned int regno ATTRIBUTE_UNUSED,
> >+unsigned int endregno ATTRIBUTE_UNUSED,
> >+rtx insn ATTRIBUTE_UNUSED)
> >+ {
> >+ #ifdef AUTO_INC_DEC
>
>
> What about defining the code this way:
> #ifdef AUTO_INC_DEC
> + static int
> + reg_inc_found_and_valid_p (unsigned int regno,
> +unsigned int endregno,
> +rtx insn)
> + {
>
> ...
> }
> #else
>
> #define reg_inc_found_and_valid_p(regno,endregno,insn) 0
>
> #endif
>
> So you can remove ugly ATTRIBUTE_UNUSED.
Should
+static int reg_inc_found_and_valid_p (unsigned int, unsigned int, rtx);
be removed if we do this way?
H.J.
Re: PATCH: [4.1/4.2 Regression]: Miscompiled FORTRAN program
On Feb 16, 2006, at 3:20 PM, H. J. Lu wrote: Should +static int reg_inc_found_and_valid_p (unsigned int, unsigned int, rtx); be removed if we do this way? Yes, in fact it does not need to be there in the first place as the function is declared before the use. -- Pinski
Re: PATCH: [4.1/4.2 Regression]: Miscompiled FORTRAN program
Andrew Pinski wrote:
What about defining the code this way:
#ifdef AUTO_INC_DEC
+ static int
+ reg_inc_found_and_valid_p (unsigned int regno,
+unsigned int endregno,
+rtx insn)
+ {
...
}
#else
#define reg_inc_found_and_valid_p(regno,endregno,insn) 0
#endif
So you can remove ugly ATTRIBUTE_UNUSED.
Thanks,
Andrew Pinski
Yes. It will be more ellegant and easier for compiler to remove following
conditions, but
what about
+ static int reg_inc_found_and_valid_p (unsigned int, unsigned int, rtx);
In this case I must hide this under preprocessor too. I feared to overburden
code by preprocessor
expressions.
What is you opinion?
Denis.
Re: PATCH: [4.1/4.2 Regression]: Miscompiled FORTRAN program
Andrew Pinski wrote: On Feb 16, 2006, at 3:20 PM, H. J. Lu wrote: Should +static int reg_inc_found_and_valid_p (unsigned int, unsigned int, rtx); be removed if we do this way? Yes, in fact it does not need to be there in the first place as the function is declared before the use. -- Pinski I'll do it. Denis
Re: gcc 4.1 regression for adjusted function declaration?
Andrew Pinski wrote: and was said to involve undefined behavior. "However, there is nothing to suggest that a not-strictly-conforming array type can magically be transformed into a strictly conforming pointer parameter via this rule." Ok, I get it. The 'incomplete type' phrase refers to arrays without a size expression. However, these seem not to be covered by the first paragraph of 6.7.5.2 . I.e. in: struct tag; extern void f (struct tag a[]); the [ and ] don't delimit an expression or * ; the size is not present. Hence 'a' has incomplete type before adjustment, and is a reference type (pointer to struct tag) after adjustment. This, too is rejected by gcc 4.1 . I think the standard says this code is legal.
Re: PATCH: [4.1/4.2 Regression]: Miscompiled FORTRAN program
On Thu, 2006-02-16 at 11:59, Denis Nagorny wrote: > It's corrected and tested on ia64 and x86-64. I've attached new version. > Denis. This look pretty good. There is still one place where the spacing looks funny. > + if (test >= regno && test < endregno) > + return 1; Checking this in emacs, I see that the if statement is preceded by 8 spaces, and the return is preceded by a tab and 8 spaces. It should be only a tab before the if, and a tab and 2 spaces before the return. Do you have tab stops set every 8 characters? It looks like you might have tabs set to 2 characters, otherwise I don't see how you could make this mistake and not notice it. There are also 3 other lines that start with spaces that should start with tabs, though this is only a minor problem. Andrew Pinksi made a good suggestion. The AUTO_INC_DEC ifdefs should be placed around the reg_inc_found_and_valid_p function instead of inside it. This lets you get rid of the ATTRIBUTE_UNUSED stuff, and it also is more efficient, since it saves the cost of a call for !AUTO_INC_DEC targets. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Design a microcontroller for gcc
Hans-Peter Nilsson wrote: > On Wed, 15 Feb 2006, DJ Delorie wrote: > I wrote: > >>>Anyway, at least keep a way to add reg+reg and reg+integer, load and >>>store of memory and load of integer and address without condition >>>code effects and your port has a chance to avoid the related bloat. >> >>At least, move/load/store shouldn't touch flags. > > > I may have listed more operations than necessary, but the > important bit is that you need to form arbitrary addresses in > the stack frame without touching flags. If for any const_int N, > (plus reg N) is a valid address for moves to and from memory > that doesn't touch flags, then I suppose you don't *need* an > "add" that doesn't touch flags. 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. But as you said, I could make the load/store take 3 args, either load rD, rB(rA) or load rD, imm4(rA) with imm4 being between -16 and 15. Another thing for memory. I can't make 8 bits access, the memory is 16 bits wide and I can't change that, so 8 bits access will have to be done in sw. Also, I could make the address given a word address or a byte address (but then I would just drop the LSB since i don't support unaligned access ... and the immediate in load/store would be each even between -32 and 30). DJ Delorie wrote: > You have to think about what kind of constants are going to be common > in your software, and plan accordingly. I can see several types of immediates: 1) Complete arbitrary constants like filter coefficients, stuff like that. 2) Small positive/negative integers: like to increment or walk in a array 3) Single bits or grouped bits anywhere in the word (to set/test bits) 4) Power of N - 1 : To do modulo / masking. For the class 1, not much to do about it ... Those will have to be loaded with several operations ... To handle class 2/3/4 in the operation taking an immediate (and that are not mov), I was thinking of allowing a 4 bits immediate, that could be placed in any nibble, and the nibbles on the left could either be filled with 1 or 0, and the nibbles on the right could also be filled with 1 or 0 (independently). So for ex 0x003f would be possible (3 in second nibble, 0-filled on the left and 1 filled on the right). 0xfff1 also, but not 0x0370 for example ... Now the problem is to well describe to gcc what can be taken as an immediate and what can't ... Anyway, thanks for youe advices ! I may not be able to follow all of them because I also have hw constraint but I do appreciate them. It may get sometime before I actually come to start the work on gcc (first I have to actually do the hw and port binutils ;) Sylvain
huge compile time on head
Hi, I am building m68k-rtems (m68k-elf) right now on the head and seeing a cc1 which has been running 17:37.05 according to top on a fast machine running Fedora Core 3. It is a AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ at 2Ghz. The last thing I see in the build log is this: -c ../../gcc/gcc/crtstuff.c -DCRT_END \ -o crtend.o ../../gcc/gcc/crtstuff.c: In function '__do_global_ctors_aux': ../../gcc/gcc/crtstuff.c:519: internal compiler error: Segmentation fault Is this a known issue? --joel
Re: Ada bootstrap failure for mainline on hppa2.0w-hp-hpux11.00
> cc1: error: unrecognized command line option "-f " I don't see any such option in the last xgcc command. What's your gmake version? I've seen problems using versions earlier than 3.80. The next most likely possibility is that this is another loop invariant bug: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01306.html Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
gcc-4.0-20060216 is now available
Snapshot gcc-4.0-20060216 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060216/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch revision 56 You'll find: gcc-4.0-20060216.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20060216.tar.bz2 C front end and core compiler gcc-ada-4.0-20060216.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20060216.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20060216.tar.bz2 C++ front end and runtime gcc-java-4.0-20060216.tar.bz2 Java front end and runtime gcc-objc-4.0-20060216.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20060216.tar.bz2The GCC testsuite Diffs from 4.0-20060209 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: PATCH: [4.1/4.2 Regression]: Miscompiled FORTRAN program
On Thu, Feb 16, 2006 at 12:34:19PM -0800, James E Wilson wrote:
> On Thu, 2006-02-16 at 11:59, Denis Nagorny wrote:
> > It's corrected and tested on ia64 and x86-64. I've attached new version.
> > Denis.
>
> This look pretty good. There is still one place where the spacing looks
> funny.
>
> > + if (test >= regno && test < endregno)
> > + return 1;
>
> Checking this in emacs, I see that the if statement is preceded by 8
> spaces, and the return is preceded by a tab and 8 spaces. It should be
> only a tab before the if, and a tab and 2 spaces before the return. Do
> you have tab stops set every 8 characters? It looks like you might have
> tabs set to 2 characters, otherwise I don't see how you could make this
> mistake and not notice it.
>
> There are also 3 other lines that start with spaces that should start
> with tabs, though this is only a minor problem.
>
> Andrew Pinksi made a good suggestion. The AUTO_INC_DEC ifdefs should be
> placed around the reg_inc_found_and_valid_p function instead of inside
> it. This lets you get rid of the ATTRIBUTE_UNUSED stuff, and it also is
> more efficient, since it saves the cost of a call for !AUTO_INC_DEC
> targets.
I took the liberty to fix the format issue on behalf of Denis. Is this
OK for mainline?
Thanks.
H.J.
2006-02-16 Denis Nagorny <[EMAIL PROTECTED]>
PR rtl-optimization/25603
* reload.c (reg_inc_found_and_valid_p): New. Check REG_INC note.
(regno_clobbered_p): Use it. Reusing SETS argument for REG_INC case.
* reload1.c (choose_reload_regs): Added call of regno_clobbered_p
with new meaning of SETS.
--- gcc/reload.c.reg_inc2006-02-14 09:37:12.0 -0800
+++ gcc/reload.c2006-02-16 14:40:02.0 -0800
@@ -6941,9 +6941,39 @@ find_inc_amount (rtx x, rtx inced)
return 0;
}
+/* Return 1 if registers from REGNO to ENDREGNO are the subjects of a
+ REG_INC note in insn INSN. REGNO must refer to a hard register. */
+
+#ifdef AUTO_INC_DEC
+static int
+reg_inc_found_and_valid_p (unsigned int regno, unsigned int endregno,
+ rtx insn)
+{
+ rtx link;
+
+ gcc_assert (insn);
+
+ if (! INSN_P (insn))
+return 0;
+
+ for (link = REG_NOTES (insn); link; link = XEXP (link, 1))
+if (REG_NOTE_KIND (link) == REG_INC)
+ {
+ unsigned int test = (int) REGNO (XEXP (link, 0));
+ if (test >= regno && test < endregno)
+ return 1;
+ }
+ return 0;
+}
+#else
+
+#define reg_inc_found_and_valid_p(regno,endregno,insn) 0
+
+#endif
+
/* Return 1 if register REGNO is the subject of a clobber in insn INSN.
- If SETS is nonzero, also consider SETs. REGNO must refer to a hard
- register. */
+ If SETS is 1, also consider SETs. If SETS is 2, enable checking
+ REG_INC. REGNO must refer to a hard register. */
int
regno_clobbered_p (unsigned int regno, rtx insn, enum machine_mode mode,
@@ -6958,7 +6988,7 @@ regno_clobbered_p (unsigned int regno, r
endregno = regno + nregs;
if ((GET_CODE (PATTERN (insn)) == CLOBBER
- || (sets && GET_CODE (PATTERN (insn)) == SET))
+ || (sets == 1 && GET_CODE (PATTERN (insn)) == SET))
&& REG_P (XEXP (PATTERN (insn), 0)))
{
unsigned int test = REGNO (XEXP (PATTERN (insn), 0));
@@ -6966,6 +6996,9 @@ regno_clobbered_p (unsigned int regno, r
return test >= regno && test < endregno;
}
+ if (sets == 2 && reg_inc_found_and_valid_p (regno, endregno, insn))
+return 1;
+
if (GET_CODE (PATTERN (insn)) == PARALLEL)
{
int i = XVECLEN (PATTERN (insn), 0) - 1;
@@ -6974,7 +7007,7 @@ regno_clobbered_p (unsigned int regno, r
{
rtx elt = XVECEXP (PATTERN (insn), 0, i);
if ((GET_CODE (elt) == CLOBBER
- || (sets && GET_CODE (PATTERN (insn)) == SET))
+ || (sets == 1 && GET_CODE (PATTERN (insn)) == SET))
&& REG_P (XEXP (elt, 0)))
{
unsigned int test = REGNO (XEXP (elt, 0));
@@ -6982,6 +7015,9 @@ regno_clobbered_p (unsigned int regno, r
if (test >= regno && test < endregno)
return 1;
}
+ if (sets == 2
+ && reg_inc_found_and_valid_p (regno, endregno, elt))
+ return 1;
}
}
--- gcc/reload1.c.reg_inc 2006-02-16 06:47:16.0 -0800
+++ gcc/reload1.c 2006-02-16 14:35:37.0 -0800
@@ -5780,7 +5780,7 @@ choose_reload_regs (struct insn_chain *c
if (equiv != 0)
{
- if (regno_clobbered_p (regno, insn, rld[r].mode, 0))
+ if (regno_clobbered_p (regno, insn, rld[r].mode, 2))
switch (rld[r].when_needed)
{
case RELOAD_FOR_OTHER_ADDRESS:
Re: PATCH: [4.1/4.2 Regression]: Miscompiled FORTRAN program
On Thu, 2006-02-16 at 14:46, H. J. Lu wrote: > I took the liberty to fix the format issue on behalf of Denis. Is this > OK for mainline? Yes, this looks good to me. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: CAN_ELIMINATE question
Denis Chertykov <[EMAIL PROTECTED]> writes: > > > I think that better to call update_eliminables() somewhere after > > > setup_save_areas() > > > > Exactly. We do that. About 15 lines after the lines you quoted > > above. > > > > What am I missing? > > I'm (exactly AVR port) need in call to update_eliminables() somewhere > between setup_save_areas() and calculate_needs_all_insns() > (Not "about 15 lines after" ;) because all bad things happened inside > calculate_needs_all_insns(). > > calculate_needs_all_insns() collect wrong reloads because > reg_eliminate structure for FP->SP have wrong can_eliminate field. But then we go around the loop again, so everything should get recalculated based on the new assumptions. Doesn't that happen for you? Ian
Re: Design a microcontroller for gcc
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, perhaps moved over with a separate instruction? Perhaps have a "load" variant that doesn't load; a "lea"? Perhaps it only does that when run just after a prefix instruction (that has another meaning before some other instruction)? (Look, there's your separate add and move instruction in one! :-) If it comes to that, I will go as far as suggesting that flags handling is more important than multiword add support. Really. (The latter will happen less frequently and can be performed with a few more instructions.) > But as you said, I could make the load/store take 3 args, either > load rD, rB(rA) > or > load rD, imm4(rA) > > with imm4 being between -16 and 15. That's not enough to cover a full stack frame, unfortunately. I suggest you find out a way to load an arbitrary integer into a register without touching flags (there's no point in having that touch flags) and then a way to add two registers without touching flags. Maybe it's sufficient with the first one, but I'm not willing to bet on it. > Another thing for memory. I can't make 8 bits access, the memory is 16 > bits wide and I can't change that, so 8 bits access will have to be done > in sw. That's ok. 8-bit accesses are desirable, but not a must and not as important as anything else I can think of. > Also, I could make the address given a word address or a byte address > (but then I would just drop the LSB since i don't support unaligned > access ... and the immediate in load/store would be each even between > -32 and 30). Stick with byte addresses. Really, really really. Word addresses used to be somehow supported, but there are many bugs and no other working port does it. Having the imm4 be bits 5..1 and bit 0 constant 0 is certainly the right thing to do for 16-bit-wide accesses. > Now the problem is to well describe to gcc what can be taken as an > immediate and what can't ... That's really not a problem, it's quite simple. brgds, H-P
Re: PATCH: [4.1/4.2 Regression]: Miscompiled FORTRAN program
On Thu, Feb 16, 2006 at 03:46:57PM -0800, James E Wilson wrote:
> On Thu, 2006-02-16 at 14:46, H. J. Lu wrote:
> > I took the liberty to fix the format issue on behalf of Denis. Is this
> > OK for mainline?
>
> Yes, this looks good to me.
I checked it in. Here is the testcase.
H.J.
2006-02-16 H.J. Lu <[EMAIL PROTECTED]>
PR target/25603
* gfortran.dg/pr25603.f: New testcase.
--- gcc/testsuite/gfortran.dg/pr25603.f.25603 2006-02-16 17:42:01.0
-0800
+++ gcc/testsuite/gfortran.dg/pr25603.f 2006-02-16 20:07:54.0 -0800
@@ -0,0 +1,60 @@
+C { dg-do run }
+C
+C PR rtl-optimization/25603
+C Check if reload handles REG_INC notes correctly.
+ PROGRAM BAR
+ IMPLICIT REAL (A-H, O-Z)
+ DIMENSION WORK(250)
+
+ XSTART = 201.0
+
+ CALL BAR1(NX,NY,NZ,NT,NTIME,NWINDX,NWINDY,NSINKS,NFILT,
+ *XSTART,YSTART,ZSTART,TSTART,DELTAX,DELTAY,DELTAZ,DELTAT,PHI,DL,
+ *DX,DY,DZ,WORK,IB,IK,ITY,NCOUNT,NPRINT,NGRAPH,NPSTEP,NGSTEP)
+ STOP
+ END
+
+ SUBROUTINE BAR2(NX,NY,NZ,NT,NTIME,NWINDX,ISH,NSMT,NFILT,
+ * XSTART,YSTART,ZSTART,TSTART,DELTAX,DELTAY,DELTAZ,DELTAT,PHI,DL,
+ * DX,DY,DZ,IB,IK,ITY,NCOUNT,NPRINT,NGRAPH,NPSTEP,NGSTEP,LFINAL,
+ * C,STEPC,POTT,STEPT,UX,STEPU,VY,STEPV,WZ,PRES,STEPP,Q,DKZM,DKZH,
+ * ELEV,ELEVX,ELEVY,Z0,HMIX,STEPH,TAVR,OBUK,USTR,TSTR,VDEP,DEP,
+ * ZET,HVAR,UM,VM,UG,VG,TM,DKM,DCDX,DCDY,AN,BN,CN,HELP,HELPA)
+ IMPLICIT REAL (A-H, O-Z)
+
+ DIMENSION C(*),STEPC(*),POTT(*),STEPT(*),UX(*),STEPU(*),
+ * VY(*),STEPV(*),WZ(*),PRES(*),STEPP(*),Q(*),DKZM(*),DKZH(*),
+ * ELEV(*),ELEVX(*),ELEVY(*),Z0(*),HMIX(*),STEPH(*),TAVR(*),
+ * OBUK(*),USTR(*),TSTR(*),VDEP(*), DEP(*),ZET(*),HVAR(*),
+ * UM(*),VM(*),UG(*),VG(*),TM(*),DKM(*), DCDX(*),DCDY(*),
+ * AN(*),BN(*),CN(*),HELP(*),HELPA(*)
+C
+
+ RETURN
+ END
+
+ SUBROUTINE BAR1(NX,NY,NZ,NT,NTIME,NWINDX,NWINDY,NSINKS,NFILT,
+ *XSTART,YSTART,ZSTART,TSTART,DELTAX,DELTAY,DELTAZ,DELTAT,PHI,DL,
+ *DX,DY,DZ,WORK,IB,IK,ITY,NCOUNT,NPRINT,NGRAPH,NPSTEP,NGSTEP)
+
+ IMPLICIT REAL (A-H, O-Z)
+ DIMENSION WORK(*)
+
+ if (XSTART .NE. 201.0) then
+ call abort
+ endif
+
+ CALL BAR2(NX,NY,NZ,NT,NTIME,NWINDX,NWINDY,NSINKS,NFILT,XSTART,
+ * YSTART,ZSTART,TSTART,DELTAX,DELTAY,DELTAZ,DELTAT,PHI,DL,
+ * DX,DY,DZ,IB,IK,ITY,NCOUNT,NPRINT,NGRAPH,NPSTEP,NGSTEP,LAST,
+ * WORK(LC),WORK(LCSTEP),WORK(LPOT),WORK(LTSTEP),WORK(LUX),
+ * WORK(LUSTEP),WORK(LVY),WORK(LVSTEP),WORK(LWZ),WORK(LPI),
+ * WORK(LPSTEP),WORK(LQ),WORK(LDKZM),WORK(LDKZH),WORK(LELEV),
+ * WORK(LELEVX),WORK(LELEVY),WORK(LZ0),WORK(LHMIX),WORK(LSTEPH),
+ * WORK(LTAVR),WORK(LOBUK),WORK(LUSTR),WORK(LTSTR),WORK(LVDEP),
+ * WORK(LDEP),WORK(LZET),WORK(LHVAR),WORK(LUM),WORK(LVM),WORK(LUG),
+ * WORK(LVG),WORK(LTM),WORK(LKM),WORK(LDCDX),WORK(LDCDY),WORK(LAN),
+ * WORK(LBN),WORK(LCN),WORK(LHELP),WORK(LHELPA))
+
+ RETURN
+ END
Successful install of GCC
Hi, I have successfully installed gcc-3.4.5 on DS10 Alpha server. - Output from config.guess: alphaev6-dec-osf4.0g - Output of gcc -v: Reading specs from /usr/local/lib/gcc/alphaev6-dec-osf4.0g/3.4.5/specs Configured with: /home/yok001/temp/packages/gcc-3.4.5/configure Thread model: posix gcc version 3.4.5 - Languages: Java, C/C++ and Fortran - Had to configure and tune the Kernel as per sys_check recommendation in regards to 'virtual memory and swap'. This is to fix the virtual memory exhuastion problem during the build. Also had to redefine TMPDIR=/home/~me/tmp instead of the default TMPDIR=/tmp since the root filesystem free size was not enough for certain parts of the build to be completed and was causing the whole build to terminate with error '/: filesystem full' -- ~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~ Alen Yokhanis Software Engineer - Machine Vision Team CSIRO - Manufacturing & Infrastructure Technology Email : [EMAIL PROTECTED] URL: N/A Postal : Locked Bag No. 9, Preston, Vic. 3072, Australia. Address: Cnr Raglan and Albert Streets, Preston, Vic. 3072 Phone : +61 3 9662 7858 Fax: +61 3 9662 7853 Visit http://www.cmit.csiro.au for news on World Leading Research and New Technologies ~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~ PLEASE NOTE: To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Alen Yokhanis on 61 3 9662 7858. Thank you.
Re: Error making a cross-compiler
David Fernandez kirjoitti: Hi there, I don't know if this is the right place for questions about the gcc build/install process. Let me know the right place otherwise. I'm trying to compile a cross-compiler from gcc-4.0.2 sources. It is configured this way: /usr/src/redhat/BUILD/gcc-4.0.2/configure --prefix=/usr/local/gcc-msdos --with-local-prefix=/usr/local/gcc-msdos --enable-checking=release --disable-threads --disable-libunwind-exceptions --enable-target-optspace --with-system-zlib --enable-__cxa_atexit --enable-languages=c,c++ --host=i386-redhat-linux --target=i686-pc-msdosdjgpp I have source RPMS of GCC-4.0.2 cross-compiler for DJGPP target togethere with ones of needed tools at http://ap1.pp.fi/djgpp/gcc/cross-compiler/index.html Tested on Fedora Core 4, but all perhaps should be OK also for other versions Andris
