Control Flow Graph
Hi all, i must use cfg library to build and manipulate a control flow graph. I have read more but i have not found an answer to my question: It is possible to build a cfg structure directly from a file .cfg ?? How i can building a cfg from a file?? Thanks to all, lastnote -- Scopri se hai Vinto un Tv Color LCD! Clicca qui http://click.libero.it/webnation15nov06
Translate C# to C
Hello, I have a RCM3400 Rabbitcore and I must create a client with this circuit. I have created a C# file with Visual Studio but I need a Dynamic C file ( or C file) to program the Rabbit. Then,I must translate this in Dynamic C language. How can I do? BYE. Naviga e telefona senza limiti con Tiscali Scopri le promozioni Tiscali adsl: navighi e telefoni senza canone Telecom http://abbonati.tiscali.it/adsl/
Built and installed gcc on powerpc-ibm-aix5.3.0.0
blitzen:/home/jonatha/packages/gcc-3.4.5$ config.guess
powerpc-ibm-aix5.3.0.0
blitzen:/home/jonatha/packages/gcc-3.4.5$ gcc -v
Reading specs from
/home/jonatha/build/bin/../lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.5/specs
Configured with: ./configure --with-as=/usr/bin/as
--with-ld=/usr/bin-ld --disable-nls
--enable-languages=c --prefix=/home/jonatha/gcc/build
--enable-threads
--enable-version-specific-runtime-libs :
(reconfigured) ./configure
--prefix=/home/jonatha/build
--with-ld=/home/jonatha/mytools/ld : (reconfigured)
./configure --prefix=/build
--with-ld=/home/jonatha/mytools/ld
--with-as=/usr/bin/as --enable-languages=c
Thread model: aix
gcc version 3.4.5
Notes:
Couldn't find ./install-sh in bfd/po during make
install of binutils-2.15. Manually changed INSTALL
to ${HOME}/packages/binutils-2.15/install.sh -c (from
./install.sh -c) in
$HOME/packages/binutils-2.15/Makefile. Seems to work.
Used AIX 'as' rather than GNU 'as' since I am told
GNU 'as' is known not to work on AIX5L
Had to export DESTDIR for make install in gcc objdir
to work
Re: Auto Vectorizing help needed
You'll want to have a look at something like the SSE SIMD optimisation within the back end for the x86. I'd also download the GCC internals document for 4.3.x as it has some information on CPU SIMD optimisations. I've been reviewing this area heavily as I'm combining GCC and GPGPU (the same idea behind Stanford Uni's folding at home GPU client). Looks like I'll have to target the tree before the SIMD vectorisation optimisation area. If anyone's interested - I'm looking to put this all in a white paper and posting up on gpgpu.org forums. > ---Original Message--- > From: sdutta <[EMAIL PROTECTED]> > Subject: Auto Vectorizing help needed > Sent: 24 Feb '07 00:13 > > I am targeting GCC 4.1.1 to a custom RISC processor; which has some vector > instructions (32 bit vectors). It can perform two 16 bit/ or four 8 bit > additions, subtractions, multiplications & shift operations simultaneously. > > I would like to use the Auto-Vectorizing capability to generate these > instructions. Is there an existing backend that I could look at for > something similar? Any help will be greatly appreciated. > > SD > >
Re: Adding a new gcc dir
Is it time to offer "second-strap" level of compilation? Ie allow C99 to bootstrap the creation of a basic GCC compiler, then allow a second compile using the basic GCC compiler to get the full compiler. Nick > ---Original Message--- > From: Paul Brook <[EMAIL PROTECTED]> > Subject: Re: Adding a new gcc dir > Sent: 06 Mar '07 16:32 > > > Which means using C90, which means no mixed declarations and code, no > > C++ comments, etc. Is there any way to compile at least, my files with > > c99 constructs? > > Or all gcc code should be built like this?? > > This is a feature. gcc can be bootstrapped using an arbitrary c90 compiler. > The warning options you mentioned help to enforce this. > > Paul >
Re: core changes for mep port
Guys - what branch/tag are you looking at doing this on? I've been in discussions with Dorit about SPMD utilisation of graphics cards (AMD CTM) which has more inline with parallel asymetric architectures than it does with simple SIMD optimisations. Cheers, Nick. > ---Original Message--- > From: DJ Delorie <[EMAIL PROTECTED]> > Subject: Re: core changes for mep port > Sent: 16 Mar '07 03:09 > > > > Do you mean where is the best place to call these functions? > > Yup. > > > Look at the calls to cgraph_mark_edge in ipa-inline.c > > There is no such function. I couldn't find anything in ipa-inline > that (1) had access to both ends of the call edge, (2) was actually > called, and (3) was called before the inlining happened. > > > and look at inline_forbidden_p--there I assume that cfun will hold > > the caller. > > cfun holds the callee. I found a lot of functions that only had > access to the callee (no help there). I also found lots of functions > that looked promising but were never called. >
Digitize your Records
Greetings ! Are you facing problems in storing growing volume of documents in the form of microfilms, microfiche, paper, audio etc ? If so, we have various solutions to digitize them as per your needs. Please feel free to drop us a line for your requirements. Regards, Navneet Singhania [EMAIL PROTECTED]
Digitize your Records
Greetings ! Are you facing problems in storing growing volume of documents in the form of microfilms, microfiche, paper, audio etc ? If so, we have various solutions to digitize them as per your needs. Please feel free to drop us a line for your requirements. Regards, Navneet Singhania [EMAIL PROTECTED]
Expanding an ADDSI3 into 2 x ADDHI3 does not work
I have a fictitious machine which has a word size of 8-bits but can handle
16-bit adds and 16-bit mov's. I am trying to build the most efficient support
for handling an addsi3 insn. My problem is that if I try to split up the
addsi3 insn into a couple of addhi3 insns (using a define_expand template) the
compiler appears to ignore this declaration and proceeds to implement addsi3 as
a bunch of addqi's along with some carry propogation rtx's. i.e. the compiler
defaults to the word size of the machine and I can't seem to override this.
I could allow it to go and create its big long list of addqi's etc and then use
some insn combining method such as a peephole optimizer but this seems really
inefficient to me - especially when I can explicitly state how a larger insn
should be split.
If I use the following addsi3 template:
(define_insn "addsi3"
[(set (match_operand:SI 0 "general_operand" "=g")
(plus:SI (match_operand:SI 1 "general_operand" "g")
(match_operand:SI 2 "general_operand" "g")))]
""
"addsi3 %1 %2 %0 ;(%1 plus %2)->%0" )
I can observe addsi being used in the assembly output of my test case.
If I use:
(define_expand "addsi"
[(set (match_operand:SI 0 "general_operand" "=g")
(plus:SI (match_operand:SI 1 "general_operand" "g")
(match_operand:SI 2 "general_operand" "g")))]
""
"{
emit_insn (gen_addhi3 (custom_subword(operands[0], 0, SImode),
custom_subword(operands[1], 0, SImode),
custom_subword(operands[2], 0, SImode)));
emit_insn (gen_addhi3 (custom_subword(operands[0], 1, SImode),
custom_subword(operands[1], 1, SImode),
custom_subword(operands[2], 1, SImode)));
DONE;
}" )
the output becomes a mess of addqi, cmpqi, and branches.
Any help would be great.
Thanks
Marty
help using mingw/gcc
Hello, I'm trying to compile a simple program with gcc on windows and am getting really frustrated. I've tried entering the commands in command prompt (no ms-dos mode, I have XP) and Run, but can't get anything, mostly something like "no such directory" or "gcc is not a valid command". Any suggestions? Thanks.
FW: wow, check this out !
-Original Message- From: Mark Sent: Monday, Jul 9, 2005 5:14 PM To: Olga Cc: Vera Subject: wow, check this out ! http://teeny.servehttp.com/
Building of fixincludes with 4.0.1 uses wrong gcc
Dear Sirs, 1. bootstrapping the gcc 4.0.1 under Sparc/Solaris I found that the building in "fixincludes" uses the gcc (with no PATH specification) instead of the xgcc build by the last stage. It may crash, it happens on my environment, because I've migrated from Solaris 9 to Solaris 10 where the includes are not compatible. The build is: > gcc -v Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: /usr/usr/ready/gnu/tmp/GCC/4.0.1/gcc-4.0.1/configure --prefix=/usr/local/GCC/4.0/1/Solaris --with-mpfr=/usr/local/Maths/Gmp --with-gmp=/usr/local/Maths/Gmp --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-languages=c,ada --enable-threads=solaris Thread model: solaris gcc version 4.0.1 2. A question: The gcc 4.0 uses the built-in specs. Is it correct, that a "specs" file will not be used as in the 2.x and 3.x versions of the gcc? With regards Michael Foerster make[1]: Entering directory `/usr/usr/ready/gnu/tmp/GCC/4.0.1/Sol10/gcc' rm -f .bad_compare case "fastcompare" in *compare | *compare-lean ) stage=2 ;; * ) stage=`echo fastcompare | sed -e 's,^[a-z]*compare\([0-9][0-9]*\).*,\1 ,'` ;; esac; \ for dir in . ada build; do \ if [ "`echo $dir/*.o`" != "$dir/*.o" ] ; then \ for file in $dir/*.o; do \ case "fastcompare" in \ slowcompare* ) \ tail +16c ./$file > tmp-foo1; \ tail +16c stage$stage/$file > tmp-foo2 \ && (cmp tmp-foo1 tmp-foo2 > /dev/null 2>&1 || echo $file differs >> .bad_compare) || true; \ ;; \ fastcompare* ) \ cmp $file stage$stage/$file 16 16 > /dev/null 2>&1; \ test $? -eq 1 && echo $file differs >> .bad_compare || true; \ ;; \ gnucompare* ) \ cmp --ignore-initial=16 $file stage$stage/$file > /dev/null 2>&1; \ test $? -eq 1 && echo $file differs >> .bad_compare || true; \ ;; \ esac ; \ done; \ else true; fi; \ done rm -f tmp-foo* case "fastcompare" in *compare | *compare-lean ) stage=2 ;; * ) stage=`echo fastcompare | sed -e 's,^[a-z]*compare\([0-9][0-9]*\).*,\1 ,'` ;; esac; \ if [ -f .bad_compare ]; then \ echo "Bootstrap comparison failure!"; \ cat .bad_compare; \ exit 1; \ else \ case "fastcompare" in \ *-lean ) rm -rf stage$stage ;; \ *) ;; \ esac; true; \ fi make[1]: Leaving directory `/usr/usr/ready/gnu/tmp/GCC/4.0.1/Sol10/gcc' Building runtime libraries make[1]: Entering directory `/usr/usr/ready/gnu/tmp/GCC/4.0.1/Sol10' make[2]: Entering directory `/usr/usr/ready/gnu/tmp/GCC/4.0.1/Sol10/libiberty' make[3]: Entering directory `/usr/usr/ready/gnu/tmp/GCC/4.0.1/Sol10/libiberty/testsuite' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/usr/ready/gnu/tmp/GCC/4.0.1/Sol10/libiberty/testsuite' make[2]: Leaving directory `/usr/usr/ready/gnu/tmp/GCC/4.0.1/Sol10/libiberty' make[2]: Entering directory `/usr/usr/ready/gnu/tmp/GCC/4.0.1/Sol10/fixincludes' gcc -c -g -O2 -DHAVE_CONFIG_H -I. -I/usr/usr/ready/gnu/tmp/GCC/4.0.1/gcc-4.0.1/fixincludes -I../include -I/usr/usr/ready/gnu/tmp/GCC/ 4.0.1/gcc-4.0.1/fixincludes/../include /usr/usr/ready/gnu/tmp/GCC/4.0.1/gcc-4.0.1/fixincludes/fixincl.c In file included from /usr/usr/ready/gnu/tmp/GCC/4.0.1/gcc-4.0.1/fixincludes/system.h:226, from /usr/usr/ready/gnu/tmp/GCC/4.0.1/gcc-4.0.1/fixincludes/fixlib.h:30, from /usr/usr/ready/gnu/tmp/GCC/4.0.1/gcc-4.0.1/fixincludes/fixincl.c:24: /usr/usr/ready/gnu/tmp/GCC/4.0.1/gcc-4.0.1/fixincludes/../include/libiberty.h:118: warning: `__sentinel__' attribute directive ignored /usr/usr/ready/gnu/tmp/GCC/4.0.1/gcc-4.0.1/fixincludes/../include/libiberty.h:127: warning: `__sentinel__' attribute directive ignored /usr/usr/ready/gnu/tmp/GCC/4.0.1/gcc-4.0.1/fixincludes/../include/libiberty.h:133: warning: `__sentinel__' attribute directive ignored /usr/usr/ready/gnu/tmp/GCC/4.0.1/gcc-4.0.1/fixincludes/../include/libiberty.h:140: warning: `__sentinel__' attribute directive ignored /usr/usr/ready/gnu/tmp/GCC/4.0.1/gcc-4.0.1/fixincludes/../include/libiberty.h:147: warning: `__sentinel__' attribute directive ignored In file included from /usr/local/GCC/3.5-ex/bin/../lib/gcc/sparc-sun-solaris2.9/3.5.0/include/sys/signal.h:44, from /usr/include/signal.h:26, from /usr/usr/ready/gnu/tmp/GCC/4.0.1/gcc-4.0.1/fixincludes/fixlib.h:31, from /usr/usr/ready/gnu/tmp/GCC/4.0.1/gcc-4.0.1/fixincludes/fixincl.c:24:
FW: wow !
-Original Message- From: jacky Sent: Monday, Aug 20, 2005 5:14 PM To: Amelie Cc: Vera, Chris Subject: wow ! http://optimum.atw.hu
Making a new cross-compile target: where to begin?
Hi, I know that some people are working on a GCC port for Minix v3, but I'd like to work on a cross-compiler for my own purposes. I'd like the host and build to be i686-pc-linux-gnu, and the target to be i[3456]86-pc-minix3. Can anyone give me some advice on where to begin and what info I need? The most obvious issue is that binutils needs to be aware of the Minix 3 a.out object file format, unless I tweak things so that a program that converts statically linked ELF object files into a.out object files runs automatically after a build. I'm not sure what the best approach would be. There are probably some good docs out there on making a new cross-compile target, but I haven't found them. Do they exist, and if yes where are they? What new files do I need to help GCC build for a Minix 3 target, what do I put in them, where can I learn about writing a specs file for Minix 3, etc. Does anyone here have a knowledge of creating a new output object format for binutils? I would guess that I will be patching binutils to accept new command line options, arranging for BFD to write a.out files, and maybe other things. Again, not sure where to begin. I would like to use the GCC 4 series, and binutils 2.16.1+. The goal is to get a cross compiler to build for a Minix 3 system on i3[456]86 systems that runs on a GNU/Linux system, so I can use it to build all sorts of other programs for a Minix 3 system that I can't compile on Minix 3, like most of the GNU programs, as well as the latest Perl and Python, etc, so I can end up with a GNU/Minix 3 system. From there when everything is built, tested and installed, I should be able to use the GNU/Minix 3 system itself to be self-hosting. Thanks for your help. James Buchanan
Re: Making a new cross-compile target: where to begin?
> Well, as far as I have seen, most of the internals are documented in the > code itself. The best way to learn how it works, in my opinion, is to get > a good code cross-reference tool. The files you mostly want to look at are > in gcc/config in a build tree. > > Good luck and have fun, > Jonathan Bastien-Filiatrault Maybe a good place to get clues is to look at how GCC and binutils are built for DOS, e.g. DJGPP. (I've asked DJ for some help). Starting with the config stuff for DJGPP will probably help me along. DOS is a similar job to Minix in that it has less facilities than systems like full-blown Unixen. I will try to have fun, after all the blood and sweat parts anyway. :) I'm really eager to learn how all this GCC magic works. James
Re: Making a new cross-compile target: where to begin?
On 10/20/05, DJ Delorie <[EMAIL PROTECTED]> wrote: > > > Maybe a good place to get clues is to look at how GCC and binutils are > > built for DOS, e.g. DJGPP. (I've asked DJ for some help). > > Except that DJGPP uses COFF, not a.out. DJGPP v1 used a.out, but most > of that support has been removed by now. Perhaps I'll be able to get away with --target=i386-aout and simply modifying glibc, newlib or uclibc to use Minix's system calls, and it'll all work with minor tweaks like the specs files GCC uses. I'll try it. I'll post my experiences to the GCC developers' list in case others in future find it useful as a starting point to GNU-ify a new system.
c compiler VMS 8.2
Hello, We just bought a HP Integrity Itanium server and are running VMS 8.2. Does a Gnu C-compiler exist ? Best regards, Sincerely, Rudy Campe Annabel Textiles Belgium - Europe [EMAIL PROTECTED]
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
Russia Host for GCC Archives
Hi. I'm the owner of Russian annual programming contest site http://zcontest.ru The contestants are usually use GCC compiler as their main platform for development. So I decided to put GCC archives on my site. Fell free to post link on it at this page: http://gcc.gnu.org/mirrors.html My site located in Russia, Moscow. The path to archive is: http://zcontest.ru/gcc.php P.S. Looks like, currently, it's the only archive in Russia. -- Best Regards, Roman Solovyev mailto:[EMAIL PROTECTED]
Sell Cisco Systems equipment items
Hello: We are specialized in new network products, including switch, firewall, router, GBIC,SFP,WIC,cables etc... We provide high quality products and the most reasonable price with professional services to our customers. So if you are interested in any of our products, please contact with me,we will try our best for you,thanks! example of the products: CWDM-SFP-1G 39dB (Ultra long-haul)--1510nm,1530nm,1550nm,1570nm,1590nm,1610nm WS-G5483, WS-G5487, WS-G5484, WS-G5486, GLC-SX-MM, GLC-LH-SM, GLC-ZX-SM, GLC-T, .. NM-2FE2W-T1, NM-2FE2W-E1, NM-2FE2W-V2, WIC-1T, WIC-2T, WIC-2A/S, WIC-1B/ST, WIC-1ENET, VWIC-1MFT-T1, VWIC-1MFT-E1, VWIC-2MFT-T1, VWIC-2MFT-E1, VWIC-1MFT-G703, VWIC-2MFT-G703, VWIC-1MFT-T1-DI, VWIC-2MFT-T1-DI, NM-1E, NM-4E, .. WS-C2950-24, WS-C2950T-24, WS-C2950G-24-EI, WS-C2950G-48-EI, .. CONSOLE CABLE, CAB-STACK-1M/3M, CAB-V35MT, CAB-V35FC, CAB-SS-V.35MT, CAB-SS-V.35FC, CAB-SS-232MT, CAB-SS-232FC, CAB-232MT, CAB-232FC, CAB-SS-X21MT, CAB-SS-X21FC, CAB-X21MT, .. MEM-npe400-512MB, MEM-3660-128mb, MEM2600-32D, MEM2600-16FS, MEM2600XM-64D, MEM-S1-128MB, MEM-S2-256MB, MEM-S2-512MB, MEM-MSFC-128MB, MEM2801-256D, MEM3800-256D, MEM3800-512, MEM3745-256D, MEM1841-256D, MEM180X-256D, WS-X6K-MSFC2-KIT, and so on. ¡¡ Regards Helen.Zhou www.nstnetwork.com MSN: [EMAIL PROTECTED] Email: [EMAIL PROTECTED] AOL helenxuezhou Icq 320-880-606
Sell Cisco Systems equipment items
Hello, We have following original Cisco,Card,GBIC/SFP,WIC,cables items for sale If you are interested, pls feel free to contact me. example of the products: CWDM-SFP-1G 38dB (Ultra long-haul)--1510nm,1530nm,1550nm,1570nm,1590nm,1610nm WS-G5483, GLC-SX-MM SFP-GE-L WS-G5487, WS-G5484, WS-G5486, GLC-SX-MM, GLC-LH-SM, GLC-ZX-SM, GLC-T, .. NM-2FE2W-T1, NM-2FE2W-E1, NM-2FE2W-V2, WIC-1T, WIC-2T, WIC-2A/S, WIC-1B/ST, WIC-1ENET, VWIC-1MFT-T1, VWIC-1MFT-E1, VWIC-2MFT-T1, VWIC-2MFT-E1, VWIC-1MFT-G703, VWIC-2MFT-G703, VWIC-1MFT-T1-DI, VWIC-2MFT-T1-DI, NM-1E, NM-4E, .. WS-C2950-24, WS-C2950T-24, WS-C2950G-24-EI, WS-C2950G-48-EI, .. CONSOLE CABLE, CAB-STACK-1M/3M, CAB-V35MT, CAB-V35FC, CAB-SS-V.35MT, CAB-SS-V.35FC, CAB-SS-232MT, CAB-SS-232FC, CAB-232MT, CAB-232FC, CAB-SS-X21MT, CAB-SS-X21FC, CAB-X21MT, .. MEM-npe400-512MB, MEM-3660-128mb, MEM2600-32D, MEM2600-16FS, MEM2600XM-64D, MEM-S1-128MB, MEM-S2-256MB, MEM-S2-512MB, MEM-MSFC-128MB, MEM2801-256D, MEM3800-256D, MEM3800-512, MEM3745-256D, MEM1841-256D, MEM180X-256D, WS-X6K-MSFC2-KIT, and so on. Regards Helen.Zhou NEWSTAR NETWORKING TECHNOLOGY www.nstnetwork.com MSN: [EMAIL PROTECTED] Email: [EMAIL PROTECTED] AOL helenxuezhou Icq 320-880-606
New mirror GCC at FPT Telecom
Hello. We have set up a new mirror. This is our information: URL: - http://mirror-fpt-telecom.fpt.net/gcc/ - ftp://mirror-fpt-telecom.fpt.net/mirror/gcc/ Location: - Company: FPT Telecom - City: HoChiMinh - Country: Viet Nam Contact: - Name: Minh Vu Tong - email: [EMAIL PROTECTED] Thanks & Best regards, VTMinh
J'ai simplement doubler mes ventes! (Quelle catastrophe!)
Bonjour, Oui je dis quel catastrophe! J'ai simplement doubler mes ventes en quelques mois au lieu de les tripler! Heureusement, que ce doublement de mes ventes s'est stabilisé et a même tendance à encore augmenter! Si vous êtes comme moi et que vous avez un site internet, une newsletter, un blog,vous vendez sur internet etc... vous devez utiliser un logiciel d'emailing performant pour au moins doubler vos ventes! http://url-ok.com/6648dd Tester gratuitement les avantages de ce logiciel, en vous renseignant à cette page: http://url-ok.com/6648dd Bien cordialement, Elom [EMAIL PROTECTED], http://url-ok.com/6648dd
ZOO TUBE XXX
Private videos zoo tube xxx. http://videos.videosextube2009.com/zoo-tube-xxx.html --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "female erotica" group. To post to this group, send email to female-erotica@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/female-erotica -~--~~~~--~~--~--~---
YU TUBE
Hi to group. New source of yu tube. http://videos.videosextube2009.com/yu-tube.html --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Miami Couples" group. To post to this group, send email to Miami-Couples@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Miami-Couples -~--~~~~--~~--~--~---
test message
test message. delete before reading. Ben White
Cambio de direccion.
Este correo ha sido cambiado, favor enviar a: [EMAIL PROTECTED] Gracias
Unsere Empfehlung des Hauses persoenlich fuer gcc@gcc.gnu.org
Holen sie sich jetzt 2400 EUR in Cash ab Und gehen Sie dabei einen sicheren und koeniglichen Weg !!! Alles mehrsprachig und einfach erklaert, starten Sie jetzt !!! Für jeden erhaeltlich, ganz einfach: Anklicken, Registrieren, abholen !!! WO ERHALTEN SIE SONST 2400 Euro in 12 Monaten aufgeteilt ? http://www.2400-euro.eu Exklusiv für Deutschland, Oesterreich & Schweiz ! Uebrigens - Günter Schlueter hat hiermit gestern und vorgestern 6100 Euro verdient bzw. gewonnen.
Erinnerung - Empfehlung persoenlich fuer gcc@gcc.gnu.org - Bereits der 2. Hinweis
Hallo gcc@gcc.gnu.org, dieses ist nun schon unsere 2. Mail an Sie, da wir nicht moechten, dass Ihnen die für Sie reservierten 2400,00 EUR verloren gehen. Ja tatsaechlich, dieser Betrag ist für Sie als Inhaber der Email gcc@gcc.gnu.org reserviert Greifen sie jetzt zu und holen sie sich jetzt 2400,00 EUR in Cash ab Alles mehrsprachig und einfach erklaert, starten Sie jetzt Für jeden erhaeltlich, ganz einfach: Anklicken, Registrieren, abholen WO ERHALTEN SIE SONST 2400 Euro in 12 Monaten aufgeteilt ? http://www.2400euro.de Exklusiv für Deutschland, Oesterreich & Schweiz Anja Richard hat hiermit in den letzten Tagen 8255 Euro verdient.
[Fwd: Re: FW: matrix linking]
I appreciate your reply, Joe. But I do not think this is off-topic, though. If we are going to discuss the details of your project, Ptolomy, right, then it would have been off-topic, I think. But I'm talking about GCC, therefore I believe this is the right place to post these ideas. What I am trying to say is that there is an additional realization of dynamic binding, which is called matrix linking. There are other's realization of that idea, like Darwin project for instance, but all of these realization has one serious stumbling block which makes their use almost impossible and therefore these realizations have only academic interest, but practically they are useless. And this stumbling block is that you need to 'suspend' the application when you do dynamic binding, moreover you should have all the threads finished inside that code which is going to to re-bind. This is a huge problem. New approach, which I have called Matrix Linking does resolve this problem, it means it becomes possible to make binding right on the fly, without any threads suspending, directly in multi threaded application. I believe this is quite interesting idea in order to be shared with GCC community. I do not think this is a professional reply, saying 'Nothing new here: add a level of indirection...'. I believe the idea has a future, just imagine what opportunities it gives to developer, manager, analyst and clients. I would like the community would have considered the idea. I am ready to answer all the questions you might have. Yours sincerely George. http://docs.georgeshagov.com/twiki/tiki-index.php?page=Matrix+Linking Joe Buck ?: I wrote: Nothing new here: add a level of indirection (or use C++ virtual functions), and dynamically load code. In the Ptolemy project (http://ptolemy.eecs.berkeley.edu/) we were doing that in 1990: we could define new classes and load them into a running application, without restarting. On Sun, Nov 18, 2007 at 09:33:16AM +0300, [EMAIL PROTECTED] wrote: Is this a thread safe operation for your Ptolomy project? Should you suspend the application in order to load 'new classes' there? We're getting off-topic for the list, so I'm answering off-list. The operation could be made thread-safe with appropriate locking (the 15-year-old code did not have this locking, but it's trivial to add). It used the object factory pattern, in which each class has a clone method and there's support for adding a new, dynamically linked class to the master list. If other threads are running and these threads are not in the act of creating new objects from the object factory, they can run in parallel.
Re: [Fwd: Re: FW: matrix linking]
Thank you for your reply, Oliver. Briefly speaking the solution to the problems you have mentioned looks like this: 1. take a loot at the first picture here: http://docs.georgeshagov.com/twiki/tiki-index.php?page=Matrix+Linking+how+it+works 2. Pointer 1, 2... are vptrs 3. The idea is that each module, library (.so) has a row of vptrs, when it is required to make a dynamic binding this row is going to be copied to the similar one, the new vptrs are applied to the new row of vptrs, the previous, old row is unchanged. Then the shift looks like incremental lock of integer value which is the version of this module (.so). So it means that these threads which execute the code inside the 'old module' they are unchanged, and the new code is going to be executed in case we will have got the new call to the functions of the module. It might have been said it does not answer the question, since there might be some loops which needs to be reloaded also, though I believe it does, since this tends more to the architecture than to linkage already :-) This is quite brief and uncertain explanation. In reality it does not look like this. More details could have been found here: http://docs.georgeshagov.com/twiki/tiki-index.php?page=Matrix+Linking+how+it+works. I hope you will find worthy the reading. In case of questions do not hesitate to ask. Yours sincerely, George. Olivier Galibert ?: On Fri, Nov 23, 2007 at 11:49:03AM +0300, [EMAIL PROTECTED] wrote: [Changing the _vptr or C equivalent dynamically] I would like the community would have considered the idea. I am ready to answer all the questions you might have. Changing the virtual function pointer dynamically using a serializing instruction is I'm afraid just the tip of the iceberb. Even forgetting for a second that some architectures do not have serializing instructions per se, there are some not-so-simple details to take into account: - the compiler can cache the vptr in a register, making your serialization less than serialized suddently - changing a group of functions is usually not enough. A component version change usually means its internal representation of the state changes. Which, in turn, means you need to serialize the object (whatever the programming language) in the older version and unserialize it in the newer, while deferring calls into the object from any thread - previous point means you also need to be able to know if any thread is "inside" the object in order to have it get out before you do a version change. Which in objects that use a somee of message fifo for work dispatching may never happen in the first place Dynamic vtpr binding is only the start of the solution. OG.
Re: [Fwd: Re: FW: matrix linking]
Oliver. Have you got a chance to take a look at the materials? If yes, what do you think on it? Yours sincerely, George. [EMAIL PROTECTED] ?: Thank you for your reply, Oliver. Briefly speaking the solution to the problems you have mentioned looks like this: 1. take a loot at the first picture here: http://docs.georgeshagov.com/twiki/tiki-index.php?page=Matrix+Linking+how+it+works 2. Pointer 1, 2... are vptrs 3. The idea is that each module, library (.so) has a row of vptrs, when it is required to make a dynamic binding this row is going to be copied to the similar one, the new vptrs are applied to the new row of vptrs, the previous, old row is unchanged. Then the shift looks like incremental lock of integer value which is the version of this module (.so). So it means that these threads which execute the code inside the 'old module' they are unchanged, and the new code is going to be executed in case we will have got the new call to the functions of the module. It might have been said it does not answer the question, since there might be some loops which needs to be reloaded also, though I believe it does, since this tends more to the architecture than to linkage already :-) This is quite brief and uncertain explanation. In reality it does not look like this. More details could have been found here: http://docs.georgeshagov.com/twiki/tiki-index.php?page=Matrix+Linking+how+it+works. I hope you will find worthy the reading. In case of questions do not hesitate to ask. Yours sincerely, George. Olivier Galibert ?: On Fri, Nov 23, 2007 at 11:49:03AM +0300, [EMAIL PROTECTED] wrote: [Changing the _vptr or C equivalent dynamically] I would like the community would have considered the idea. I am ready to answer all the questions you might have. Changing the virtual function pointer dynamically using a serializing instruction is I'm afraid just the tip of the iceberb. Even forgetting for a second that some architectures do not have serializing instructions per se, there are some not-so-simple details to take into account: - the compiler can cache the vptr in a register, making your serialization less than serialized suddently - changing a group of functions is usually not enough. A component version change usually means its internal representation of the state changes. Which, in turn, means you need to serialize the object (whatever the programming language) in the older version and unserialize it in the newer, while deferring calls into the object from any thread - previous point means you also need to be able to know if any thread is "inside" the object in order to have it get out before you do a version change. Which in objects that use a somee of message fifo for work dispatching may never happen in the first place Dynamic vtpr binding is only the start of the solution. OG.
Re: Obsoleting c4x last minute for 4.0
Richard Earnshaw wrote: On Wed, 2005-04-06 at 00:30, Mark Mitchell wrote: Joe Buck wrote: But if it won't even build, then users should be warned. I suppose -- but we have relatively many configurations that probably won't build, at least if you start combining various options, and including langauges beyond just C and C++. I'd be content with a patch that issued a warning, but declaring a port obsolete has often been contentions, and I'd hate to rush into it. Maybe we need a third category - 'at risk'. Such a port will typically have no active maintainer, some likely serious bugs and might at some future date be obsoleted if no maintainer steps forward. We could put several ports into that category and it shouldn't have the negative stigma that obsolete seems to have. The RTEMS community has been interested in the c4x port for a long time but we don't have anyone who can fix things at the level this one is broken. We keep trying it and reporting on it. It gets a little better, then it gets a little worse. Ignoring the technically interesting bit that the c4x is not byte addressable, this port suffers from its original developers having largely moved on by the time it was merged. Not an excuse, just a statement that there was not a clean handoff to a new maintainer. I recall that the original port being using binutils 2.7 so that gives a timeframe. R. -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: Obsoleting c4x last minute for 4.0
Joel Sherrill <[EMAIL PROTECTED]> wrote: Richard Earnshaw wrote: On Wed, 2005-04-06 at 00:30, Mark Mitchell wrote: Joe Buck wrote: But if it won't even build, then users should be warned. I suppose -- but we have relatively many configurations that probably won't build, at least if you start combining various options, and including langauges beyond just C and C++. I'd be content with a patch that issued a warning, but declaring a port obsolete has often been contentions, and I'd hate to rush into it. Maybe we need a third category - 'at risk'. Such a port will typically have no active maintainer, some likely serious bugs and might at some future date be obsoleted if no maintainer steps forward. We could put several ports into that category and it shouldn't have the negative stigma that obsolete seems to have. The RTEMS community has been interested in the c4x port for a long time but we don't have anyone who can fix things at the level this one is broken. We keep trying it and reporting on it. It gets a little better, then it gets a little worse. I have been reminded by an RTEMS user that the c4x port actually did successfully build C for 3.4. This makes it a recent regression. -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: GCC 4.0 RC1 Available
Mark Mitchell wrote: 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 ncurses (all platforms) PR/20929 triggers a miscompilation of Mozilla. Any chance of getting this m68k specific one added to the RC2 list? 18421 ICE in reload_cse_simplify_operands, at postreload.c:391 Those are all on the Wiki page as possible patches for an RC2. Thanks, -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: Patches for coldfire v4e
[EMAIL PROTECTED] wrote: Hi, Attached are the patches for coldfire v4e. These changes are originally contributed by Peter Barada. I have migrated and tested these changes from gcc 3.04 to gcc 3.4 and now to mainline. Since coldfire v4e has MMU we need to support m68k-linux target for coldfire v4e. To support m68k-linux for coldfire v4e I need to modify t-linux. But I suppose this is not desirable. In that case we might have to create another target, maybe coldfire-linux. Please give your comments/suggestions on this. Is it ok to modify t-linux or coldfire-linux should be created. How many multilib's does adding the v4e support add? I hate to see another entire toolset binary just to get 1 or 2 multilib variants. GNU/Linux is not the only OS interested in the v4e. There should be a generic elf target (m68k-elf) and I know the RTEMS community would like this (m68k-rtems). It might make sense to add the multilib to the t-* files of interest and add coldfire-XXX targets for smaller dedicated toolsets. It shouldn't be much besides a new t-XXX file and a config.gcc entry if you can get binutils and gdb to match. Thanks and Best Regards, C Jaiprakash __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: GCC 4.0 RC2
I know I asked late in the process but this fix for a m68k/coldfire failure just showed up: [Bug target/18421] ICE in reload_cse_simplify_operands, at postreload.c:391 Any chance at it getting considered? Thanks. --joel Mark Mitchell wrote: Sadly, it's become clear there's going to have to be a second release candidate. In particular, there are some wrong-code bugs that are popping up on real packages on primary platforms. Jason Merill is looking into some of the C++ issues, but he's in Lillehammer this week for the ISO meeting. Therefore, I'm going to allow some of the queued patches into 4.0 at this time. If your patch isn't on this list, but is here: http://gcc.gnu.org/wiki/Last-Minute%20Requests%20for%204.0.0 I'm still considering it. I'll let you know if I've firmly decided that your patch will not be in RC2. I don't have a date for RC2 yet; that will depend in part on when Jason is able to fix the C++ issues. However, I would certainly hope that we could get it done shortly. Here are the patches approved thus far for RC2: * http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01108.html Patch to fix __builtin_apply_args on SPARC (specific). * http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01036.html GLIBC does not compile on S390. * http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01015.html Fortran fix. * http://gcc.gnu.org/ml/java-patches/2005-q2/msg00088.html Java library patch. Thanks, -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: GCC 4.1: Buildable on GHz machines only?
Peter Barada wrote: Well, yes. 1 second/file is still slow! I want "make" to complete instantaneously! Don't you? Actually I want it to complete before I even start, but I don't want to get too greedy. :) What's really sad is that for cross-compilation of the toolchain, we have to repeat a few steps (build gcc twice, build glibc twice) because glibc and gcc assume that a near-complete environment is available(such as gcc needing headers, and glibc needing -lgcc-eh), so even really fast machines(2.4Ghz P4) take an hour to do a cross-build from scratch. That sounds comparable to the time required to build RTEMS toolsets. I just looked at the timestamp on the build logs for a gcc 4.0.0 CVS build with newlib 1.13.0 and it is on the order of 60-90 minutes per target on a 2.4 Ghz P4 w/512 MB RAM. This is just C and C++ and the variance is probably mostly due to the number of multilibs. I checked build logs of gcc 3.3.5 with newlib 1.13 from December on the same machine and times were comparable so it isn't a recent slowdown. When I built my native 4.0.0 on this machine, I did notice that compiling the Java libraries took long enough to notice and when I did a top, I noticed that gjc was running for 30+ seconds of CPU time with RSS on the order of 150 MB. Another time I noticed that sh had taken 90 seconds and that was an invocation of libtool with a very long command line. Here is the configure command and output of time on this machine for a gcc 4.0.0 build: ../gcc-4.0.0/configure --prefix=/opt/gcc-4.0.0 --enable-languages=c,c++,ada,java,objc 4271.94user 685.49system 1:31:18elapsed 90%CPU (0avgtext+0avgdata 0maxresident)k0inputs+0outputs (33176183major+40970199minor)pagefaults 0swaps A 2.4 Ghz P4 isn't what I would consider an obsolete machine and it took 90 minutes for "make" -- not a full bootstrap. --joel
Re: GCC 4.1: Buildable on GHz machines only?
This is really getting pretty far from the original topic but
I am diving in anyway.
Steven Bosscher wrote:
On Tuesday 17 May 2005 02:53, Ralf Corsepius wrote:
On Tue, 2005-05-17 at 00:10 +0200, Steven Bosscher wrote:
On Monday 16 May 2005 23:43, Ralf Corsepius wrote:
On Mon, 2005-05-16 at 10:42 -0400, Peter Barada wrote:
Until package maintainers take cross-compilation *seriously*, I have
no choice but to do native compilation of a large hunk of the
packages on eval boards that can literally takes *DAYS* to build.
The most amazing fact to me is: Not even GCC seems to take cross-
compilation seriously :(
BS. Even the large disto builders do cross compilations a lot.
So I suppose you have these general crossbuilding PRs fixed in your
sources:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21143
No, I just don't build gfortran as a cross. There are many reasons
why this is a bad idea anyway.
Why is something broken in the gfortran build infrastructure?
Assuming not, then it should only be a matter of needed functionality
in the target C library and native FP types. I know gfortran
currently makes assumptions about the FP capabilities of a CPU
and some don't meet that. But there is no reason one should not
be able use an x86 GNU/Linux system to cross build gfortran for
a powerpc or arm GNU/Linux system.
Oh, and how helpful of you to post that patch to gcc-patches@ too...
NOT!
Personal gripe.. I still don't know why posting a patch with a PR isn't
sufficient. GCC has two independent systems. Why can't Bugzilla just
forward attachments marked as patches?
Is there anywhere in the GCC problem reporting instructions that says
attaching a patch to a PR is insufficient? I know you don't get that
impression from the Bugzilla page you use to add it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21247
I don't build Ada cross either, but AdaCore does, so you could ask
them to help you with this problem.
I don't really think they are the answer here. GNAT has always been
implemented in Ada and has never been buildable without a native Ada
compiler. That's just the way it is.
The issue is what VERSION of GNAT is required to compile version X
of GNAT. I don't try to track minimum versions required but in this
case, I think it moved up quite a bit. From install.texi in gcc-4.0.0:
=
In order to build GNAT, the Ada compiler, you need a working GNAT
compiler (GNAT version 3.14 or later, or GCC version 3.1 or later),
including GNAT tools such as @command{gnatmake} and @command{gnatlink},
since the Ada front end is written in Ada (with some
GNAT-specific extensions), and GNU make.
==
So this could be viewed as only a documentation issue except that
one has to know where to get a binary for GNAT to start the build
process with.
Personally, I have always avoided this by building a native GNAT
first and using that to build the cross-GNAT. It avoids this
issue entirely.
AdaCore has always helped avoid the problem by providing pre-built
binaries for a few platforms. You can use these to kick-start
the process.
Another one I haven't filed yet, is GCC-4.x not correctly propagating
CFLAGS/CFLAGS_FOR_{BUILD|HOST|TARGET} to newlib in one-tree builds (I am
still investigating).
I don't build with newlib either.
I think that's the point -- no one builds all configurations so
everyone has to be very careful to use the right build magic
to keep them all working.
All these to me are strong indications that GCC-4.x has been poorly
tested in cross compilation.
No, just in the configurations you are using.
Possibly. RTEMS may be the only non-GNU/Linux embedded cross target
which tries to stay near the GCC head and is able to reasonably fully
support languages other than C and C++.
The *-elf targets don't have the filesystem and threading support
required to fully support some of the other language run-times.
And since you're not posting the patches you attach to the bugzilla
PRs you open, you're not exactly helping to make things better either.
Gr.
Steven
--joel
Re: GCC 4.1: Buildable on GHz machines only?
Jonathan Wakely wrote: On Tue, May 17, 2005 at 11:14:22AM +0200, Ralf Corsepius wrote: * I wasn't aware about this fortran specific patch posting policy. I never have sent any gcc patch to any other list but gcc-patches for approval before, so I also had not done so this time. * How could I know that the responsible maintainers aren't listening to bugzilla and gcc-patches, but are listening to a fortran specific list, I even didn't know about until your posting? For future reference, where patches should be sent is explained here: http://gcc.gnu.org/lists.html OK .. and Bugzilla or http://gcc.gnu.org/bugs.html references that link how? A search for "patch" in the bug reporting instructions does not mention anything about cc'ing any patch list. I'm not trying to be irritating here. Just pointing out that if there is a procedure, it doesn't appear to be referenced in all the right places and isn't tied to the PR system. Given the recent discussions of unfriendly responses, what if a new person X found and bug and fixed it, they would file a PR with Bugzilla and most likely attach the patch. And then there is a high probability that someone would not so kindly tell them they hadn't followed a procedure that doesn't appear to be mentioned anywhere they had seen along the obvious path. Putting on my CM hat: + Procedures do not exist unless they are documented. + Procedures that do not get assisted/enforced by tools are ignored. jon --joel
Re: GCC 4.1: Buildable on GHz machines only?
Joe Buck wrote: I used to be an embedded programmer myself, and while I cared very much about the size and speed of the embedded code I wound up with, I didn't care at all about being able to run the compiler itself on a machine that wasn't reasonably up to date, much less trying to bootstrap the compiler on an embedded target. Is that really what we should be aiming for? As opposed to just making -Os work really well? If I could get better embedded code by having the compiler use a lot of memory, but I could easily afford a machine with that amount of memory, I would have had no complaint. There are at least three classes of development I have noticed on this thread: (1) self-hosting gcc on slow but traditional hosts (e.g. 68040 UNIX or old Sun's) (2) self-hosted embedded development (e.g. sounds like Peter Barada) (3) embedded development using regular cross-compilation In general all are concerned about lower end CPUs than are used for the mainstream GCC user on GNU/Linux and other UNIces. (1) and (2) are similar and probably have similar requirements. They would like building GCC and running it to be possible on what would be considered low end hardware for main-stream development purposes. (3) is the model for RTEMS, other RTOSes, no-OS targets, and could be the model used by (2). I won't include (1) because they want their systems to be self supporting and users will compile their own code. We are all concerned about the time and memory required to build GCC. But it is a critical concern for (1) and (2) since they are on small hosts. For (3) and RTEMS, it concerns us because the RTEMS Project provides RPMs for 11 targets and tries to include every language we can possibly support (C, C++, Ada, FORTRAN, and Java). I know for the targets that it compiles on, RTEMS works well with C, C++, and Ada. I am unsure about the precise status of RTEMS+Java and FORTRAN is currently up for discussion. Our tool build times are thus very long and when we follow up by building RTEMS and add-on libraries, it gets longer. We struggle to keep up which is why RTEMS reports are sporadic and tend to cluster nearer a release point. It's true that there are many GCC developers who don't care much about embedded systems, but there are others that care a lot. But many GCC developers lack the relevant expertise, I at least do recognize that. And some of the problems the embedded community reports are hard to recognize from native configurations. It therefore seems that we have two *separate* problems: one is that increased resource consumption makes gcc harder to use as a hosted compiler on older systems, and the other is that embedded target support isn't getting the attention it needs (if it weren't for the heroic efforts of Dan Kegel, it would be far worse). We shouldn't mix these two together; it seems sometimes they get mixed solely because too many free software projects don't support cross-compilation properly, but that is a bug in those projects. You are correct. Many free libraries have rough edges when cross-building. One thing that has been on my personal wish list a LONG time is to get RTEMS configurations to properly run the GCC test suite. [I normally test and report against *-elf since they are similar and easier.] Many tests fail or can't run on the NO OS targets because there is assumption of functionality which isn't there. RTEMS supports a RAM filesystem and POSIX threads which make it possible to run more tests than the NO OS targets. For example, the complete Ada validation test suite can be run with near perfect results. Similarly, other languages with run-time requirements which RTEMS can meet. It should be possible to get better quality embedded target results across more languages. The problem is that the RTEMS Project does not have the expertise to do this. We need some help from a DejaGNU/GCC testing expert. Sorry for the length, this is an important issue to me. --joel
Re: GCC 4.1: Buildable on GHz machines only?
Karel Gardas wrote: On Tue, 17 May 2005, Alexandre Oliva wrote: On May 17, 2005, Karel Gardas <[EMAIL PROTECTED]> wrote: you see that 4.0 added "embedded" platforms like arm-none-elf and mips-none-elf to the primary platforms list. These are only embedded targets. You can't run GCC natively on them, so they don't help embedded hosts in any way. Yes, but Ralf was complaining about embedded cross-compiling development for RTEMS. I have not tried to reply to Peter Barada who complains about GCC inablity to be run on embedded targets directly. Logically Peter's situation is the same as the NetBSD issue with building and testing on old hosts. He is running GNU/Linux on ColdFire and I suspect his ColdFire target is probably faster and better equipped than the old UNIX boxes the BSD folks mentioned. Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: GCC 4.1: Buildable on GHz machines only?
Peter Barada wrote: Yes, but Ralf was complaining about embedded cross-compiling development for RTEMS. I have not tried to reply to Peter Barada who complains about GCC inablity to be run on embedded targets directly. Logically Peter's situation is the same as the NetBSD issue with building and testing on old hosts. He is running GNU/Linux on ColdFire and I suspect his ColdFire target is probably faster and better equipped than the old UNIX boxes the BSD folks mentioned. Its a 266Mhz ColdFire v4e machine, about 263 BogoMips, 1/20 the BogoMips of my workstation, and with an NFS rootfs, it gets network bound pretty rapidly and runs even slower compared to a NetBSD machine with a local disk :) I would have thought the CPU itself was comparable to or faster than a 68040 or 68060 since they was always at much lower clock speeds. Do you have any local disk or is everything NFS? If so, that would be killer for performance. I remember an old pair of SparcStation 10's we used to have. Network builds vs. local disk was already like 5-10x slower. How much RAM? --joel
Re: Killing fixproto (possible target obsoletion)
E. Weddington wrote: Nathanael Nerode wrote: Propose to stop using fixproto immediately: avr-*-* I'm not even sure exactly what fixproto is supposed to do, but I *highly* doubt that it is needed for the AVR target. The AVR target is an embedded processor that uses it's own C library, avr-libc: <http://savannah.nongnu.org/projects/avr-libc/> So there aren't any "old system headers" around. The RTEMS target for the AVR *may* use newlib, but I don't what the status of that is. Ralf or Joel would have to chime in on this aspect. The AVR target no longer uses fixincludes anyway. If there are any problems with the headers, we should be able fix them directly in avr-libc. Ralf is on vacation for a few weeks. avr-rtems is using newlib. *-rtems uses newlib so I assume it would not need anything adjusted. HTH Eric -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Andreas Schwab m68k Maintainer
I'm happy to anounce that Andreas Schwab <[EMAIL PROTECTED]> as the new m68k port maintainer. I, for one, thank him and wish him well in this effort. :) -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: move specs documentation to internals manual?
Geoffrey Keating wrote: "Joseph S. Myers" <[EMAIL PROTECTED]> writes: On Fri, 7 Jul 2005, Ian Lance Taylor wrote: [EMAIL PROTECTED] (Geoffrey Keating) writes: * gcc.c: Include xregex.h. (version_compare_spec_function): New. (spec_function): Add version-compare. (replace_outfile_spec_function): Reformat comment. (compare_version_strings): New. I think version-compare should be documented in the specs file section of invoke.texi. I think having this documentation in invoke.texi is a mistake - specs are internals rather than something for users to use. The documentation should either be in the internals manual or be in comments in gcc.c, not both and not the user manual. I agree with both comments here: it's lame that we have duplicated documentation (and explains why I didn't realise that I had to change two places), and I don't think that we should be considering specs to be an user-level interface to GCC. So, what do people think about (a) deleting the big comment in gcc.c that tries to explain specs (leaving a pointer to the manual), and (b) moving the specs documentation to the internals manual? I think it is definitely appropriate to fix gcc.c to point to any manual. Which manual is another question. RTEMS uses the specs to specify board specific linking issues so to us, it is at least something the user is aware of even if there is only one per board generated which applies to all code linked for that board. So it is more a user level feature to us than a gcc internal one. It should only be documented in one place though. --joel -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: GCC 4.0.2 RC1 Available
Mark Mitchell wrote: It's important to test the actual tarballs, rather than CVS, to check for any packaging issues. If you can, download and build the tarballs, post test results to the gcc-testresults mailing list with and contrib/test_summary. If you encounter problems, please file them in bugzilla, and add me to the CC: list. I have a build of all the RTEMS targets going now. It will take a while to crank through them all but feedback will be coming. II have binutils installed for the following targets so that is what I am trying. arm-rtems4.7 avr-rtems4.7 h8300-rtems4.7 h8300-rtemscoff4.7 i386-rtems4.7 m68k-rtems4.7 mips64-rtems4.7 mips-rtems4.7 powerpc-rtems4.7 sh-rtems4.7 sh-rtemscoff4.7 sparc-rtems4.7 tic4x-rtems4.7 I noticed a couple of those should show deprecated or obsoleted in the build logs so I can verify that. Thanks. -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
GCC 4.0.2 RC2 RTEMS Report
Mark Mitchell wrote: The GCC 4.0.2 RC3 prerelease is spinning now. If all goes well, it will be available later today. From an RTEMS perspective, 4.0.2RC2 with no patches appeared to be at least as good as 4.0.1 w/RTEMS patches. I spotted no new issues. I built a native C, C++, and Ada compiler and used that to build all the crosses. newlib 1.13.0 w/RTEMS patches was the C library. The targets built were: arm-rtems4.7: C C++ avr-rtems4.7: C h8300-rtems4.7: C C++ i386-rtems4.7: C C++ i686-pc-linux-gnu: C C++ m68k-rtems4.7: C C++ mips64-rtems4.7: C C++ mips-rtems4.7: C C++ powerpc-rtems4.7: C C++ sh-rtems4.7: C C++ sparc-rtems4.7: C C++ Ada did build for most of the targets. As I recall, arm and sh did not finish building. The sh had an ICE and the arm has some Ada specific issue. I did not investigate either enough to report. --joel
Re: GCC 4.0.2 Released
Matthias Klose wrote: Mark Mitchell writes: Daniel Jacobowitz wrote: My inclination is to do nothing (other than correct the target milestones on these bugs in bugzilla) and move on. The Solaris problem is bad, and I beat up on Benjamin to get it fixed, but I'm not sure it's a crisis meriting another release cycle. The C++ change fixed a regression relative to 3.4.x, but not 4.0.x. Andreas' change is only known to affect m68k. ... but IIRC it cripples GCC for m68k; Debian turned up hundreds of build failures because of this bug and it set builds back several weeks. Was this a regression from 4.0.0 or 4.0.1? I don't know. We noticed when we did switch the compiler from 3.3 to 4.0. IMO, we (Debian) can make sure that the patch is applied in the compiler. RTEMS will have to use the same patch as will anyone else interested. So make sure the patch is easily accessible. In spite of the pain, a dot release is probably the safest thing all around. Sorry this happened. I can sympathize with your pain. :( Matthias -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: Compilation of Ada under FreeBSD
Frédéric PRACA wrote: Hello, I'm trying to build a cross-compiler for RTEMS. Building C or C++ cross-compiler is not a problem but building the Ada compiler does'nt work. In fact, even building a normal compiler does'nt work at all. The main reason I found is that the gcc driver of FreeBSD doesn't support ada and it seems that GNAT is not sufficient. How can I do ? My search for a native FreeBSD GNAT didn't turn up too much either. The best I saw was either to use the old 3.15p GNAT and bootstrap your way to a recent native compiler as apparently this person does. http://lists.freebsd.org/pipermail/freebsd-ports/2004-November/017632.html Or to just use the Linux emulation and run the Linux RTEMS tools. Thanks Fred -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: Compilation of Ada under FreeBSD
Frédéric PRACA wrote: Hello, I'm trying to build a cross-compiler for RTEMS. Building C or C++ cross-compiler is not a problem but building the Ada compiler does'nt work. In fact, even building a normal compiler does'nt work at all. The main reason I found is that the gcc driver of FreeBSD doesn't support ada and it seems that GNAT is not sufficient. How can I do ? I didn't noticed the domain name. :) I assume you would be more interested in bootstrapping your way to a ports package of some recent gnat. The native gnat version and cross gnat version need to be the same. Thanks Fred -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Problem building *-rtems on the head
Or at least I think it's the head. I am still learning subversion. :)
I am testing using gcc-head-test with the *-rtems targets. I managed
to build a native compiler and am using that to build the cross
compilers. But when the build gets around to trying to build newlib, it
is using CC=${target}-cc not the xgcc from the built gcc subdirectory.
I am using the same configure command I used with gcc 4.0.x and
including --with-newlib.
Has anyone else tried to build a newlib target from the head recently?
--joel sherrill
cross newlib builds on svn head
Hi, I have been trying to build sparc-rtems4.7 on the head using newlib's head for a few days now. I have finally narrowed the behavior down. If I configure for sparc I am configuring for sparc-rtems4.7 with c and c++, it builds fine. The build process uses xgcc for newlib as one would expect. If I add ada to the --enable-languages then newlib fails to build because it picks a non-existent compile (sparc-rtems4.7-cc) to build with. Host: Fedora Core 3. The GCC is the default gcc (GCC) 3.4.4 20050721 (Red Hat 3.4.4-2) Procedure: + build binutlis 2.16.1 for sparc-rtems4.7 + co gcc head from svn + co newlib head from cvs + mv newlib under gcc + configure for C/C++ and make ../gcc-head-test/configure --target=sparc-rtems4.7 \ --enable-threads=rtems --prefix=/home/joel/gcc-41-test/ \ --with-gnu-as --with-gnu-ld --with-newlib --verbose \ --with-system-zlib --disable-nls \ --enable-version-specific-runtime-libs --enable-languages=c,c++ make Builds completes. + configure for C/C++/Ada and make ../gcc-head-test/configure --target=sparc-rtems4.7 \ --enable-threads=rtems --prefix=/home/joel/gcc-41-test/ \ --with-gnu-as --with-gnu-ld --with-newlib --verbose \ --with-system-zlib --disable-nls \ --enable-version-specific-runtime-libs --enable-languages=c,c++,ada make Build fails when newlib attempts to compile with sparc-rtems4.7-cc. Help is really appreciated. I wanted to provide some feedback on the Ada status. -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
*-rtems status on head was Re: cross newlib builds on svn head
Thanks to Paolo Bonzini's patch, I can get much further and now have
more to report. :)
The Good
h8300-rtems4.7 - C, C++ build OK (Ada not tried)
i386-rtems4.7 - C, C++, Ada build OK
m68k-rtems4.7 - C, C++, Ada build OK
sh-rtems4.7 - C, C++ build OK (Ada not tried)
sparc-rtems4.7 - C, C++, Ada build OK.
The Bad
===
avr-rtems4.7 - ICE on C
arm-rtems4.7 - ada/rts/raise.c does not compile
mips-rtems4.7 - GNAT bug box at a-calend.adb:480:24
mips64-rtems4.7 - GNAT bug box at a-calend.adb:480:24
powerpc-rtems4.7 - GNAT bug box at a-calend.adb:480:24
The Details
===
arm-rtems4.7 - C, C++ OK. Ada fails with this:
../../xgcc -B../../ -c -DCROSS_COMPILE -DIN_GCC `echo -g -O2
-Dinhibit_libc -fno-inline -fexceptions -DIN_RTS |sed -e
's/-pedantic//g' -e 's/-Wtraditional//g'` \
-I. -I.. -I../..
-I/home/joel/gcc-work/head/gcc-head-test/gcc/ada
-I/home/joel/gcc-work/head/gcc-head-test/gcc/ada/../config
-I/home/joel/gcc-work/head/gcc-head-test/gcc/ada/../../include
-I/home/joel/gcc-work/head/gcc-head-test/gcc/ada/.. -I./../.. raise.c -o
raise.o
raise.c: In function 'db':
raise.c:233: error: 'va_list' undeclared (first use in this function)
raise.c:233: error: (Each undeclared identifier is reported only once
raise.c:233: error: for each function it appears in.)
raise.c:233: error: expected ';' before 'msg_args'
raise.c:237: error: 'msg_args' undeclared (first use in this function)
raise.c: In function 'get_region_description_for':
raise.c:595: warning: pointer targets in assignment differ in signedness
I haven't had a chance to investigate why this doesn't compile.
avr-rtems4.7 - C dies with an ICE
./../../../../../gcc-head-test/newlib/libc/misc/init.c: In function
'__libc_fini_array':
../../../../../../gcc-head-test/newlib/libc/misc/init.c:59: error:
unable to find a register to spill in class 'BASE_POINTER_REGS'
../../../../../../gcc-head-test/newlib/libc/misc/init.c:59: error: this
is the insn:
(insn 65 32 33 2
../../../../../../gcc-head-test/newlib/libc/misc/init.c:56 (set
(mem/c:HI (plus:HI (reg/f:HI 28 r28)
(const_int 1 [0x1])) [5 S2 A8])
(reg:HI 24 r24)) 12 {*movhi} (nil)
(nil))
../../../../../../gcc-head-test/newlib/libc/misc/init.c:59: internal
compiler error: in spill_failure, at reload1.c:1890
mips64-rtems4.7, mips-rtems4.7, and powerpc-rtems4.7 all die in Ada at
the same spot.
../../xgcc -B../../ -c -g -O2 -W -Wall -gnatpg a-calend.adb -o
a-calend.o
+===GNAT BUG DETECTED===+
| 4.1.0 20051102 (experimental) (mips-unknown-rtems4.7) GCC error: |
| tree check: expected class |
| Error detected at a-calend.adb:480:24
Advice, patches always appreciated.
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
arm-rtems4.7 Ada update
I added an include of to gcc/ada/raise.c and now the arm-rtems4.7 target compiles Ada enough to get to the same GNAT bug box as powerpc, mips, and mips64 do. So whatever I tripped appears to be a cross-CPU Ada issue. Long term, where should the include of stdarg.h be for raise.c? I just added it above the function db() around line 230. -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
arm-rtems Ada Aligned_Word compilation error
Hi, Gcc on the head fails to compile arm-rtems4.7 at the following point when Ada is enabled. ../../xgcc -B../../ -c -g -O2 -W -Wall -gnatpg s-auxdec.adb -o s-auxdec.o s-auxdec.ads:286:13: alignment for "Aligned_Word" must be at least 4 Any ideas? -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: cross newlib builds on svn head
Laurent GUERBY wrote: On Thu, 2005-11-03 at 17:43 +0100, Paolo Bonzini wrote: Joel Sherrill <[EMAIL PROTECTED]> wrote: Hi, I have been trying to build sparc-rtems4.7 on the head using newlib's head for a few days now. I have finally narrowed the behavior down. If I configure for sparc I am configuring for sparc-rtems4.7 with c and c++, it builds fine. The build process uses xgcc for newlib as one would expect. If I add ada to the --enable-languages then newlib fails to build because it picks a non-existent compile (sparc-rtems4.7-cc) to build with. Can you try the attached patch? Paolo Hi Paolo, any chance to get this patch in SVN? This patch worked for me and I have gotten much farther with it. Laurent: Is there any chance of getting a fix for the Ada problem that is acceptable to put into CVS? It was an issue on at least arm and mips as I recall. --joel
Re: cross builds to avr fail
Eric Botcazou wrote:
Building a --target=avr compiler currently fails because
/usr/src/packages/BUILD/gcc-4.1.0-20051110/obj-x86_64-suse-linux/./gcc/xgcc
-B/usr/src/packages/BUILD/gcc-4.1.0-20051110/obj-x86_64-suse-linux/./gcc/
-B/opt/cross/avr/bin/ -B/opt/cross/avr/lib/ -isystem
/opt/cross/avr/include -isystem /opt/cross/avr/sys-include -O2 -O2 -O2
-fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -U_FORTIFY_SOURCE
-DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include -DDF=SF
-Dinhibit_libc -mcall-prologues -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED
-Dinhibit_libc -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include
-I../../gcc/../libcpp/include -DL_ashrdi3 -c ../../gcc/libgcc2.c -o
libgcc/./_ashrdi3.o ../../gcc/libgcc2.c: In function '__muldi3':
../../gcc/libgcc2.c:511: error: total size of local objects too large
which does not make any sense. The above is for a x86_64 host, but I
see this errors everywhere.
I guess the sanity check I've added doesn't apply to micro-controllers. Try
the attached patch.
avr-rtems4.7 fails differently and apparently further along (gcc head,
newlib 1.13.0, binutils 2.16.1)
home/joel/gcc-work/head/b-avr-rtems4.7/./gcc/xgcc
-B/home/joel/gcc-work/head/b-avr-rtems4.7/./gcc/ -nostdinc
-B/home/joel/gcc-work/head/b-avr-rtems4.7/avr-rtems4.7/avr3/newlib/
-isystem
/home/joel/gcc-work/head/b-avr-rtems4.7/avr-rtems4.7/avr3/newlib/targ-include
-isystem /home/joel/gcc-work/head/gcc-head-test/newlib/libc/include
-B/home/joel/gcc-41-test//avr-rtems4.7/bin/
-B/home/joel/gcc-41-test//avr-rtems4.7/lib/ -isystem
/home/joel/gcc-41-test//avr-rtems4.7/include -isystem
/home/joel/gcc-41-test//avr-rtems4.7/sys-include -mmcu=avr3
-DPACKAGE=\"newlib\" -DVERSION=\"1.13.0\" -I.
-I../../../../../../gcc-head-test/newlib/libc/misc -Os
-DPREFER_SIZE_OVER_SPEED -mcall-prologues -DHAVE_GETTIMEOFDAY
-DMALLOC_PROVIDED -DEXIT_PROVIDED -DMISSING_SYSCALL_NAMES
-DSIGNAL_PROVIDED -DREENTRANT_SYSCALLS_PROVIDED -DHAVE_OPENDIR -DNO_EXEC
-DHAVE_FCNTL -fno-builtin -O2 -g -O2 -mmcu=avr3 -c
../../../../../../gcc-head-test/newlib/libc/misc/init.c
../../../../../../gcc-head-test/newlib/libc/misc/init.c: In function
'__libc_fini_array':
../../../../../../gcc-head-test/newlib/libc/misc/init.c:59: error:
unable to find a register to spill in class 'BASE_POINTER_REGS'
../../../../../../gcc-head-test/newlib/libc/misc/init.c:59: error: this
is the insn:
(insn 64 31 32 2
../../../../../../gcc-head-test/newlib/libc/misc/init.c:56 (set
(mem/c:HI (plus:HI (reg/f:HI 28 r28)
(const_int 1 [0x1])) [5 S2 A8])
(reg:HI 24 r24)) 12 {*movhi} (nil)
(nil))
../../../../../../gcc-head-test/newlib/libc/misc/init.c:59: internal
compiler error: in spill_failure, at reload1.c:1890
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
Re: arm-rtems Ada Aligned_Word compilation error
Arnaud Charlet wrote: How many of such platforms are available and known to work in the FSF tree? Strange question. The answer is all the platforms currently known to work with Ada (too many to be listed here). One alternative is to have an s-auxdec-empty and use that on platforms where s-auxdec is known to pose problem. Seems reasonable to me. It is fine by me. My only concern is that this isn't an RTEMS problem but a CPU alignment issue and this solution eliminates this support from the impacted CPUs. But I am happy with disabling this file on impacted CPUs for the time being. --joel
Ada Broken with h_errno change
As of this morning, Ada no longer compiles for *-rtems. I think this change broke it. 2005-11-14 Thomas Quinot <[EMAIL PROTECTED]> * socket.c (__gnat_get_h_errno): New function to retrieve h_errno, the hosts database last error code. RTEMS has networking functions but they are not available at this stage during the build. You only have the .h files provided with newlib. So this patch is needed to make *-rtems compile again. OK to commit? Index: gcc/ada/socket.c === --- gcc/ada/socket.c(revision 107093) +++ gcc/ada/socket.c(working copy) @@ -190,6 +190,10 @@ #elif defined(VMS) return errno; #else +#if defined(__rtems__) + /* No networking .h files are available from newlib so extern this. */ + extern int h_errno; +#endif return h_errno; #endif } -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Syntax question
Is this valid C or C++? I am getting a syntax error when
compiled as C++ but not C.
int f()
{
int x, y, ;
}
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
Re: Syntax question
Andrew Pinski wrote:
Is this valid C or C++? I am getting a syntax error when
compiled as C++ but not C.
int f()
{
int x, y, ;
}
I am getting a syntax error with the C front-end but not with the
C++ front-end. This is definitely a bug as this is invalid C++ also.
This is a regression from at least 3.4.0 as 3.3.3 works but 3.4.0 does
not reject it.
Thanks for confirming this. I have filed it as 24907. Please double
check that it is OK and add yourself if you like. I think I covered all
the gcc versions you and I tested.
-- Pinski
--joel
m68k does not build on head
Doing an overnight build of all rtems targets, I can across this
new breakage for m68k-rtems4.7. I last built this target on Nov 3
from the head and it compiled then.
/home/joel/gcc-work/head/b-m68k-rtems4.7/./gcc/xgcc
-B/home/joel/gcc-work/head/b-m68k-rtems4.7/./gcc/ -nostdinc
-B/home/joel/gcc-work/head/b-m68k-rtems4.7/m68k-rtems4.7/newlib/
-isystem
/home/joel/gcc-work/head/b-m68k-rtems4.7/m68k-rtems4.7/newlib/targ-include
-isystem /home/joel/gcc-work/head/gcc-head-test/newlib/libc/include
-B/home/joel/gcc-41-test//m68k-rtems4.7/bin/
-B/home/joel/gcc-41-test//m68k-rtems4.7/lib/ -isystem
/home/joel/gcc-41-test//m68k-rtems4.7/include -isystem
/home/joel/gcc-41-test//m68k-rtems4.7/sys-include -c -DHAVE_CONFIG_H -O2
-g -O2 -I. -I../../../gcc-head-test/libiberty/../include -W -Wall
-pedantic -Wwrite-strings -Wstrict-prototypes
../../../gcc-head-test/libiberty/getopt1.c -o geto
pt1.o
../../../gcc-head-test/libiberty/regex.c: In function
'byte_common_op_match_null_string_p':
../../../gcc-head-test/libiberty/regex.c:7724: error: insn does not
satisfy its constraints:
(insn 158 85 159 8
../../../gcc-head-test/libiberty/regex.c:7699 (set (reg:SI 2 %d2)
(sign_extend:SI (reg:HI 1 %d1 [59]))) 65 {*68k_extendhisi2} (nil)
(nil))
../../../gcc-head-test/libiberty/regex.c:7724: internal
compiler error: in reload_cse_simplify_operands, at postreload.c:393
This is with gcc SVN head as of yesterday afternoon, binutils 2.16.1 and
newlib 1.13.0.
I can file a PR but this is definitely a recent breakage.
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
Re: Ada Broken with h_errno change
Thomas Quinot wrote: * Joel Sherrill <[EMAIL PROTECTED]>, 2005-11-16 : RTEMS has networking functions but they are not available at this stage during the build. I am not sure I understand how this can happen (I am not familiar at all with the RTEMS build process). If the network functions are available on RTEMS, isn't it the case that corresponding header files should be present as well? If so why aren't they available when you build the Ada runtime library? If not how are these functions made available to applications? You build RTEMS proper after you build the toolset with which you will build it. So when you gcc, you only have access to .h files which are properly associated with libc or libm. Those are provided by newlib. Headers files for networking, most tasking, and other functionality is only available later when you build the OS. To look at it another way, RTEMS doesn't use prebuilt binaries for the run-time libraries when building the tools. We start with a fresh slate every time we build gcc and bootstrap our way up. That way every object on the target is compiled by the same gcc. This lets us get the full benefit of a newer and better gcc every time we update. this patch is needed to make *-rtems compile again. OK to commit? I'd first like to understand what exactly the situation is. I hope the explanation above helps make it clearer. FWIW the extern might be better stylistically outside the function. The function already has more than enough conditional compilation going on. --joel
RTEMS GCC Status Report
Mark Mitchell wrote: The number of open serious regressions against 4.1 is a respectable 87, quite a few of which are P3s, waiting for me to categorize them. We still have some work to do before the release, but we will branch on 2005-11-18, as previously announced, at some point late Friday evening. Thank you for being patient through the long Stage 3. Mark we are trying to test furiously and I know that neither Ada nor RTEMS is a primary target but I wanted to pass along a few issues that are being worked by various people. I am sure that this is not a complete list but covers the important issues impacting RTEMS GCC. + PR24912 - m68k build failure: ICE: in reload_cse_simplify_operands This is a recent regression and a patch has just been proposed. + No PR - The Ada tools mangle target names like arm-rtems4.7. Apparently they don't like the version part. Laurent is working on this. + No PR - The Ada tools end up invoking a cross compiler which is hard coded to be in /usr/bin. This may be a side-effect of the name mangling problem and just a default that is being tripped. We don't know yet. Ralf if I missed something really critical, speak up. I was focusing more on "doesn't work at all" issues. I don't see any ICEs while building RTEMS right now. The targets we try to build are: avr-rtems4.7- C i386-rtems4.7 - C, C++, Ada powerpc-rtems4.7- C, C++, Ada sparc-rtems4.7 - C, C++, Ada mips64-rtems4.7 - C, C++, Ada m68k-rtems4.7 - C, C++, Ada i686-pc-linux-gnu - C, C++, Ada (to bootstrap the others with) mips-rtems4.7 - C, C++, Ada arm-rtems4.7- C, C++, Ada sh-rtems4.7 - C, C++, Ada h8300-rtems4.7 - C, C++ For each target, we have been building RTEMS and a handful of other libraries including ncurses, readline, and libtecla. We are pushing at the avr and it won't build right now and we have filed a PR. I need to check if the Ada multilib support is ready for us to turn on and push. Right now, I am more concerned that the target name issue is preventing us from even getting a hello world to link. --joel
Re: RTEMS GCC Status Report
Laurent GUERBY wrote: On Fri, 2005-11-18 at 15:14 -0600, Joel Sherrill wrote: + No PR - The Ada tools mangle target names like arm-rtems4.7. Apparently they don't like the version part. Laurent is working on this. To be accurate I promised to work on this once Paolo configure patch is in, because I'm currently unable to apply it cleanly to my tree :). Yes. I should have included Paolo's patch as a MAJOR requirement. Otherwise you can't build a newlib cross target as best I can tell. Please, pretty please get that merged. --joel
Re: Ada Broken with h_errno change
Thomas Quinot wrote: * Joel Sherrill <[EMAIL PROTECTED]>, 2005-11-17 : I hope the explanation above helps make it clearer. Yes, thanks for the clarification. In light of this explanation the proposed fix seems appropriate; maybe a comment could be added along with the extern declaration to note that it is necessary because of the way the bootstrap procedure is organized. How about this? Can I commit it? Index: gcc/ada/socket.c === --- gcc/ada/socket.c(revision 107308) +++ gcc/ada/socket.c(working copy) @@ -189,6 +189,13 @@ } #elif defined(VMS) return errno; +#elif defined(__rtems__) + /* At this stage in the tool build, no networking .h files are available. + Newlib does not provide networking .h files and RTEMS is not built yet. + So we need to explicitly extern h_errno to access it. + */ + extern int h_errno; + return h_errno; #else return h_errno; #endif -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: Ada on ARM
Ralf Corsepius wrote: On Mon, 2005-11-21 at 17:14 +0100, Frédéric PRACA wrote: Hi, I'm currently trying to build an Ada cross compiler for ARM using the arm-rtems target. I tried with GCC 4.0.2 and subversion-version but I failed. What should I know to do this knowing that I already built the C and C++ cross-compilers ? 1. Replace your host compiler with the same version you want to build cross (Ada requirement). Definitely critical to any success. 2. The standard RTEMS toolchains are multilib'ed, Gnatlib in gcc-4.0.x doesn't support multilibs => The only chance you have is to build a non-multilib'ed custom RTEMS-GCC. Instructions from Laurent Guerby are on the RTEMS Wiki. http://www.rtems.com/wiki/index.php/RTEMSAda 3. GNAT from GCC < 4.0.2 did not support the arm. I haven't tried gcc-4.0.2 and don't know if anybody has meanwhile added arm-support to GNAT. arm-rtems4.7 does build C, C++, and Ada on the gcc SVN head. I have done no testing beyond that. All in all, I think you've lost ... :( Even if you get a compiler from the head to compile, the gnat tools seem to misparse target names with a version in them. You would have to compile for arm-rtems to even have a prayer. Ralf --joel
Re: Ada on ARM
Laurent GUERBY wrote:
On Mon, 2005-11-21 at 12:15 -0600, Joel Sherrill wrote:
arm-rtems4.7 does build C, C++, and Ada on the gcc SVN head. I have
done no testing beyond that.
Is there a simulator for arm? Frederic do you have a testing
environment in mind? What "--enable-rtemsbsp=X" should I use?
I suppose the GameBoy Advance (gba) BSP is your best bet. Instructions
for it are on the Wiki but I personally don't have any experience with
it yet.
There is also the possibility that the SkyEye simulator could be made to
work with the edp7312 BSP but that hasn't been worked through yet.
I'm building up to GCC for arm-rtems4.7 right now.
Did you resolve the issue about the target including a version number?
I also have this arm-rtems specific patch. Something changed after
4.0.x and none of the RTEMS BSPs would link before I added this.
Index: gcc/config/arm/rtems-elf.h
===
--- gcc/config/arm/rtems-elf.h (revision 107316)
+++ gcc/config/arm/rtems-elf.h (working copy)
@@ -37,3 +37,10 @@
#undef SUBTARGET_EXTRA_ASM_SPEC
#define SUBTARGET_EXTRA_ASM_SPEC "\
%{!mhard-float: %{!msoft-float:-mfpu=softfpa}}"
+
+/*
+ * The default includes --start-group and --end-group which conflicts
+ * with how this used to be defined.
+ */
+#undef LINK_GCC_C_SEQUENCE_SPEC
+#define LINK_GCC_C_SEQUENCE_SPEC "%G %L"
Re: Ada on ARM
Frédéric PRACA wrote: Selon Laurent GUERBY <[EMAIL PROTECTED]>: On Mon, 2005-11-21 at 12:15 -0600, Joel Sherrill wrote: arm-rtems4.7 does build C, C++, and Ada on the gcc SVN head. I have done no testing beyond that. Is there a simulator for arm? Frederic do you have a testing environment in mind? What "--enable-rtemsbsp=X" should I use? Well, I plan to use Skyeye for simulation. The target is an ep9312 from Cirrus Logic. Even if I didn't manage to compile the edb7312 support, I wanted to read how it was made to try to port RTEMS on ep9312. I think this should be a good study for me. I just had a quick to skyeye and it seems to be based upon armulator which is a target of RTEMS. So, I guess buiding with the armulator bsp should be a good beginning. The armulator BSP doesn't quite initialize memory right. The last I knew, the SkyEye simulator did not run the BSP and no one had investigated. That BSP was developed on real hardware. I would hope the edb7312 BSP would be VERY close to working. --joel
unable to build head on Fedora
Hi, My fresh check out on the head build using the gcc shipped with Fedora Core 4 has failed for the past couple of days with this error: /home/joel/gcc-work/head/b-native/./gcc/xgcc -B/home/joel/gcc-work/head/b-native/./gcc/ -B/home/joel/gcc-head-test//i686-pc-linux-gnu/bin/ -B/home/joel/gcc-head-test//i686-pc-linux-gnu/lib/ -isystem /home/joel/gcc-head-test//i686-pc-linux-gnu/include -isystem /home/joel/gcc-head-test//i686-pc-linux-gnu/sys-include -c -g -O2 -fPIC -W -Wall -gnatpg g-alleve.adb -o g-alleve.o g-alleve.adb: In function ‘GNAT.ALTIVEC.LOW_LEVEL_VECTORS.LL_VUC_OPERATIONS.SATURATE.2XNN’: g-alleve.adb:871: error: unrecognizable insn: (insn 113 112 114 4 g-alleve.adb:866 (set (mem:HI (pre_dec:SI (reg/f:SI 7 sp)) [0 S2 A8]) (reg:HI 0 ax [orig:77 d ] [77])) -1 (nil) (nil)) +=GNAT BUG DETECTED==+ | 4.2.0 20051214 (experimental) (i686-pc-linux-gnu) GCC error: | | in extract_insn, at recog.c:2084 | | Error detected at g-alleve.adb:5035:1| configure command: ./gcc/configure --prefix=/home/joel/gcc-head-test/ --enable-languages=c,c++,ada Is this a known failure? -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: unable to build head on Fedora
Jakub Jelinek wrote: On Wed, Dec 14, 2005 at 04:34:17PM -0600, Joel Sherrill <[EMAIL PROTECTED]> wrote: My fresh check out on the head build using the gcc shipped with Fedora Core 4 has failed for the past couple of days with this error: A day and half. Is this a known failure? Yes, just svn update and retry. OK. Now I get this ../../xgcc -c -I./ -I../rts -I. -I/home/joel/gcc-work/head/gcc/gcc/ada -B../../ -O2 -g -O2 -gnatpg -gnata -I- /home/joel/gcc-work/head/gcc/gcc/ada/makegpr.adb raised STORAGE_ERROR : stack overflow (or erroneous memory access) gnatmake: "/home/joel/gcc-work/head/gcc/gcc/ada/makegpr.adb" compilation error I updated again right before I sent this and got the same error. Is this another known issue? --joel
Re: [gnu.org #247501] Submitting to the Gnu Project
Tomas, On Mon, 2 Jan 2006, Tomas Bily via RT wrote: > I filled and posted FSF assignment (with an employer disclaimer) back > to FSF via mail half year ago. Did you received it ? I found the following in the copyright file on the FSF network: GCC Tomas Bily United States 2005-07-28 Assigns past and future changes [EMAIL PROTECTED] ANY SuSe Prague 2005-07-26 Disclaims all past interest and for 5 years from the date of the disclaimer, in changes made to free software by Tomas Bily. The country appears to be wrong (since I believe you are Czech, not American), but apart from that everything looks okay (for the next 4.5) years. (I removed you year of birth and replaced it with "" above.) Gerald
Re: [gnu.org #247501] Submitting to the Gnu Project
Tomas, On Mon, 2 Jan 2006, Tomas Bily via RT wrote: > I filled and posted FSF assignment (with an employer disclaimer) back > to FSF via mail half year ago. Did you received it ? I found the following in the copyright file on the FSF network: GCC Tomas Bily United States 2005-07-28 Assigns past and future changes [EMAIL PROTECTED] ANY SuSe Prague 2005-07-26 Disclaims all past interest and for 5 years from the date of the disclaimer, in changes made to free software by Tomas Bily. The country appears to be wrong (since I believe you are Czech, not American), but apart from that everything looks okay (for the next 4.5) years. (I removed you year of birth and replaced it with "" above.) Gerald
powerpc-rtems fails to build on head
With code updated this morning, powerpc-rtems fails to build. I am using binutils 2.16.1 with just a couple of patches. Is this a gcc or binutils error? Is there a known fix? == /home/joel/gcc-work/head/b-powerpc-rtems4.7/./gcc/xgcc -B/home/joel/gcc-work/head/b-powerpc-rtems4.7/./gcc/ -nostdinc -B/home/joel/gcc-work/head/b-powerpc-rtems4.7/powerpc-rtems4.7/newlib/ -isystem /home/joel/gcc-work/head/b-powerpc-rtems4.7/powerpc-rtems4.7/newlib/targ-include -isystem /home/joel/gcc-work/head/gcc/newlib/libc/include -B/home/joel/gcc-head-test//powerpc-rtems4.7/bin/ -B/home/joel/gcc-head-test//powerpc-rtems4.7/lib/ -isystem /home/joel/gcc-head-test//powerpc-rtems4.7/include -isystem /home/joel/gcc-head-test//powerpc-rtems4.7/sys-include -O2 -O2 -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../libdecnumber -mrelocatable-lib -mno-eabi -mstrict-align -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time -Dinhibit_libc -fPIC -msdata=none \ -c ../../gcc/gcc/crtstuff.c -DCRT_BEGIN -DCRTSTUFFS_O \ -o crtbeginS.o /tmp/cc5gvpW0.s: Assembler messages: /tmp/cc5gvpW0.s:36: Error: Relocation cannot be done when using -mrelocatable == -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: powerpc-rtems fails to build on head
David Edelsohn wrote:
"Joel Sherrill writes:
Joel> With code updated this morning, powerpc-rtems fails to build. I am
Joel> using binutils 2.16.1 with just a couple of patches.
Joel> Is this a gcc or binutils error? Is there a known fix?
This is not a known problem. There have been a lot of patches
committed this morning. You need to be more specific about the
instruction producing the assembler error and the latest updates that you
have merged in your tree.
SVN revision 109589. I don't know precisely where before that it broke.
I built my native on 8 Jan. The other RTEMS crosses built on 9 Jan but
I missed that the PowerPC didn't installed -- I was so excited to see
that Ada built I missed it. :)
I have cut it down to this command:
/home/joel/gcc-work/head/b-powerpc-rtems4.7/./gcc/xgcc \
-B/home/joel/gcc-work/head/b-powerpc-rtems4.7/./gcc/ \
-mrelocatable-lib -c j3.c
and the attached source file. It appears to be this line in
__do_global_dtors_aux.
static func_ptr *p = __DTOR_LIST__ + 1;
What else can I do to help narrow it down?
--joel
typedef void (*func_ptr) (void);
static func_ptr __DTOR_LIST__[1]
__attribute__((section(".dtors"), aligned(sizeof(func_ptr
= { (func_ptr) (-1) };
#if 0
static const char __EH_FRAME_BEGIN__[]
__attribute__((section(".eh_frame"), aligned(4)))
= { };
extern void *__deregister_frame_info (const void *)
__attribute__ ((weak));
#endif
static void __attribute__((used))
__do_global_dtors_aux (void)
{
static func_ptr *p = __DTOR_LIST__ + 1;
#if 0
func_ptr f;
static _Bool completed;
if (__builtin_expect (completed, 0))
return;
while ((f = *p))
{
p++;
f ();
}
if (__deregister_frame_info)
__deregister_frame_info (__EH_FRAME_BEGIN__);
completed = 1;
#endif
}
[gnu.org #283065] Confirming the mailing of your assignment
Hello Nic, Thank you for contributing to GNU software. We'll send you the appropriate papers through the post Please sign and return the original in the envelope provided. Once the FSF has signed it, we will send you a digital copy in pdf format for your records. If your employment status changes, please remember to notify us. A change in employers, or a change in your employment status, can effect your continuing assignment. Thank you for your contribution! All the best, Jonas Jacobson Assignment Administrator Free Software Foundation 51 Franklin Street, Fifth Floor Boston, MA 02110 Phone +1-617-542-5942 Fax +1-617-542-2652
Re: GCC 4.3 target deprecation proposals
Dave Korn wrote: On 22 January 2008 14:06, Manuel López-Ibáñez wrote: I note the lack of anyone posting test results for uClinux, OpenBSD or RTEMS, and suggest that users of those operating systems should try to post test results for at least some target architectures. Sorry. For RTEMS, this just reflects a lack of success in getting the scripts to run with all the magic bits right for an installed cross gcc with extra arguments required to compile and link. If someone familiar with the test suite scripts could help us, we could move on from there to test the SVN trunk on a few RTEMS targets on a regular basis. I manually run the Ada ACATS test suite on at least the SPARC and PowerPC fairly regularly but only report failures by hand. For 4.2.2 the results were near perfect. --joel
Re: GCC 4.3 target deprecation proposals
Joseph S. Myers wrote: On Thu, 24 Jan 2008, DJ Delorie wrote: At the moment, I'm working on getting sh, h8300, and m32c in shape for 4.3 (or future). I can easily get the test results under 400k by removing some of the multilibs, but I don't think that's a good idea. My sh-elf test tests 38 multilibs, if I only test one that would be a 12k email, which would easily fit past the filters. Are we artificially penalizing targets with many multilibs? If results are being rejected without indicating the target is in terrible shape, you could ask overseers to increase the size limit on gcc-testresults. I'm not actually convinced these long default multilib lists are a good idea; if a user doesn't just want a single multilib for their processor, the long generic list is likely to be wrong for them as well. Depends on the user. For *-rtems*, we build the OS proper multilib and produce libraries. The user links that against a Board Support Package and their application. We are careful to justify each multilib variant in the RTEMS targets since it does lead to longer compile times and longer tool download times when our users install. Here is a count of the multilib variants for the targets we have pre-compiled RTEMS for. Note that all are using gcc 4.2.2 except AVR (4.0.4) and tic4x (3.4.6). arm-rtems4.9 3 avr-rtems4.9 4 bfin-rtems4.9 1 h8300-rtems4.9 7 i386-rtems4.9 6 m68k-rtems4.9 15 mips-rtems4.9 6 powerpc-rtems4.9 15 sh-rtems4.9 11 sparc-rtems4.9 4 tic4x-rtems4.9 4 So you can see that even though we haven't figured out how to run the GCC testsuite when linked against RTEMS, we do have "good news" on a number of targets. With some help from a gcc tester, we should be able to start reporting results on many of the above using simulators. sh has a mechanism for selecting multilibs at configure time, and a more general such mechanism would be good as well (for some targets such as GNU/Linux, it would need to deal with SYSROOT_SUFFIX_SPEC and SYSROOT_HEADERS_SUFFIX_SPEC as well as the usual multilib variables; note some targets already generate SYSROOT_SUFFIX_SPEC automatically). Also, while I'm not suggesting I be a maintainer for sh and h8300, if I'm working on them and producing test results, should I send them in anyway? I can always stop sending them when I stop working on them (for whatever reason), but meanwhile, does that count against deprecation? Anyone sending results for a target counts against deprecation. I didn't even look at what version the results are for (although maybe in the 4.4 cycle we should only look at results for 4.3 or later). -- Joseph S. Myers [EMAIL PROTECTED]
