Re: Inconsistent next_bb info when EXIT is a successor
On 3/2/07, Andrey Belevantsev <[EMAIL PROTECTED]> wrote: Steven Bosscher wrote: > No. The condition you're checking is simply not true in cfglayout > mode. The whole point of cfglayout mode is to get rid of the > requirement that basic blocks are serial. That means a fallthru edge > in cfglayout mode doesn't have to go to next_bb. It can go to *any* > bb. Yes, but I'm not in cfglayout mode, because I'm either in sched1 or sched2. In that case, should this condition be preserved or not? The condition should always be preserved when you are not in cfglayout mode, but... You wrote: > > During my work on the selective scheduler I have triggered an assert in > > our code saying that a fall-through edge should have e->src->next_bb == > > e->dest. This was for a bb with EXIT_BLOCK as its fall-through > > successor, but its next_bb pointing to another block. I don't understand this. You're saying there is a fallthrough edge from your e->src to EXIT_BLOCK. This case is explicitly allowed by the checking code. It is an exception from the rule: For a fallthrough edge to EXIT, e->src->next_bb != e->dest is OK. It is hard to tell without more context what your problem is. That assert, is it an assert in your own code? Maybe it is too strict? Gr. Steven Gr. Steven
[RFC]possible improvements to --with-sysroot
The following suggestion is based on my understanding of --with-sysroot, if there were any error, please correct me. To my understanding, currently if cross-compile tool chain (including gcc) is configured with --with-sysroot when installing them, then when cross compiling, ld will look for libraries in $SYSROOT/usr/lib and $SYSROOT/usr/local/lib. Wouldn't it be great that we go one step further that we let ld look for libraries in the dir listed in $SYSROOT/etc/ld.so.conf, if this file ever exits? Of course for each entry in $SYSROOT/etc/ld.so.conf, we prefix $SYSROOT to it. Comments are welcomed. Thanks! -- Zhang Le, Robert http://zhllg.blogspot.com http://zh.gentoo-wiki.com http://savannah.nongnu.org/projects/pgubook http://groups.google.com/group/gentoo-china http://groups.google.com/group/szlug
Re: Inconsistent next_bb info when EXIT is a successor
Steven Bosscher wrote: > I don't understand this. You're saying there is a fallthrough edge > from your e->src to EXIT_BLOCK. This case is explicitly allowed by > the checking code. It is an exception from the rule: For a fallthrough > edge to EXIT, e->src->next_bb != e->dest is OK. Thanks! It's the answer I was looking for -- this case is a known exception, so I shouldn't worry. Given that ... > It is hard to tell without more context what your problem is. That > assert, is it an assert in your own code? Maybe it is too strict? ... yes, the assert was too strict. I've fixed that so we don't rely on next_bb in these cases. Andrey
About the unnamed insn defined in the machine.md
Hello, recently I am porting the GCC backend to a DSP. The GCC Internals document says that the unnamed insns are used to translate RTL insns to the assembler insns, but I find that the unnamed insn patterns can be used in combine phase to combine insns by reading the "*arith_shiftsi" insn pattern in arm.md file..This "*arith_shiftsi" insn pattern is used to combine the "plus insn" and "shift insn" into "add rd,Rn,rm,shift immediate_operand".Is my understanding correct?
Re: Massive SPEC failures on trunk
Grigory Zagorodnev wrote on 03/03/07 02:27: > There are three checkins, candidates for the root of regression: > http://gcc.gnu.org/viewcvs?view=rev&revision=122487 > http://gcc.gnu.org/viewcvs?view=rev&revision=122484 > http://gcc.gnu.org/viewcvs?view=rev&revision=122479 > SPEC2k works as usual[1] for me on x86_64 as of revision 122484. The only new compile failure I see is building 300.twolf with: mt.c: In function 'MTEnd': mt.c:46: warning: incompatible implicit declaration of built-in function 'free' mt.c:46: error: too many arguments to function 'free' specmake: *** [mt.o] Error 1 Ian, looks like your VRP patch may be involved. [1] 176.gcc and 253.perlbmk usually miscompare for me. Not sure why.
Re: Massive SPEC failures on trunk
> Grigory Zagorodnev wrote on 03/03/07 02:27: > > > There are three checkins, candidates for the root of regression: > > http://gcc.gnu.org/viewcvs?view=rev&revision=122487 > > http://gcc.gnu.org/viewcvs?view=rev&revision=122484 > > http://gcc.gnu.org/viewcvs?view=rev&revision=122479 > > > SPEC2k works as usual[1] for me on x86_64 as of revision 122484. The only new > compile failure I see is building 300.twolf with: > > mt.c: In function 'MTEnd': > mt.c:46: warning: incompatible implicit declaration of built-in function > 'free' > mt.c:46: error: too many arguments to function 'free' Diego, this is actually bug in twolf calling free with two arguments (block and size). We used to tolerate it but since free is now a builtin, we no longer do. SPEC has alternate source tree without this bug. Honza > specmake: *** [mt.o] Error 1 > > Ian, looks like your VRP patch may be involved. > > > [1] 176.gcc and 253.perlbmk usually miscompare for me. Not sure why.
Re: About the unnamed insn defined in the machine.md
"redriver jiang" <[EMAIL PROTECTED]> writes: > Hello, recently I am porting the GCC backend to a DSP. The GCC > Internals document says that the unnamed insns are used to translate > RTL insns to the assembler insns, but I find that the unnamed insn > patterns can be used in combine phase to combine insns by reading the > "*arith_shiftsi" insn pattern in arm.md file..This "*arith_shiftsi" > insn pattern is used to combine the "plus insn" and "shift insn" into > "add rd,Rn,rm,shift immediate_operand".Is my understanding correct? Yes. Ian
Re: Massive SPEC failures on trunk
Grigory Zagorodnev <[EMAIL PROTECTED]> writes: > Trunk GCC shows massive (2 compile-time and 6 run-time) failures on > SPEC CPU2000 and CPU2006 at i386 and x86_64 on -O2 optimization > level. Regression introduced somewhere between revision 122487 and > 122478. > > There are three checkins, candidates for the root of regression: > http://gcc.gnu.org/viewcvs?view=rev&revision=122487 > http://gcc.gnu.org/viewcvs?view=rev&revision=122484 > http://gcc.gnu.org/viewcvs?view=rev&revision=122479 Can you boil one of these problems down into a test case which you can share? Thanks. Ian
Re: Massive SPEC failures on trunk
On 03 Mar 2007 11:00:11 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: Grigory Zagorodnev <[EMAIL PROTECTED]> writes: > Trunk GCC shows massive (2 compile-time and 6 run-time) failures on > SPEC CPU2000 and CPU2006 at i386 and x86_64 on -O2 optimization > level. Regression introduced somewhere between revision 122487 and > 122478. > > There are three checkins, candidates for the root of regression: > http://gcc.gnu.org/viewcvs?view=rev&revision=122487 > http://gcc.gnu.org/viewcvs?view=rev&revision=122484 > http://gcc.gnu.org/viewcvs?view=rev&revision=122479 Can you boil one of these problems down into a test case which you can share? There are segfaults on Polyhedron rnflow, linpk and test_fpu as well. Richard.
Hi all, just an onfo about huw to use gcc tree
Hi all, I'd like to develop a tool able to do the following things: 1) to load all the .h and .c/.cpp files; 2) to analyze allo the data struct / unions and classes; 3) to give me for each data member of a struct or union and for each data member of a class, the offset in bytes related to the base addess of a generic istance of the struct/union and class. In this way I could easily calculate the real address of each data member of each global declared struct / union and classes, and I clould easily read usign a simple communication protocol the content of a memory location of an embedded system only knowing the map file and the offset of each member of each global variable. I suppose to do this could be usefully used the tree structure of gcc. Is it? If yes where could I find a tutorial to use the internals of gcc? Thanks a lot -- Fabio Giovagnini Aurion s.r.l. via degli orti 11, 40050 Funo di Argelato (BO) Tel. +39.335.8350919 Fax +39.051.8659009 www.aurion-tech.com account telefono VoIP skype (www.skype.com): aurion.giovagnini
RE: Hi all, just an onfo about huw to use gcc tree
On 03 March 2007 20:15, Fabio Giovagnini wrote: > Hi all, > I'd like to develop a tool able to do the following things: > 1) to load all the .h and .c/.cpp files; > 2) to analyze allo the data struct / unions and classes; > 3) to give me for each data member of a struct or union and for each data > member of a class, the offset in bytes related to the base addess of a > generic istance of the struct/union and class. > > In this way I could easily calculate the real address of each data member of > each global declared struct / union and classes, and I clould easily read > usign a simple communication protocol the content of a memory location of an > embedded system only knowing the map file and the offset of each member of > each global variable. Sounds like what you really want is a debugger... GDB does things like that. The information you want is all emitted by the compiler as debug info in your object files when you use the -g flag. You haven't given details about the task you're trying to achieve but scripting gdb is probably going to be the way to go. cheers, DaveK -- Can't think of a witty .sigline today
Re: Hi all, just an onfo about huw to use gcc tree
Thanks for the answer. I go deeper in my thought so that maybe you can give me more infos about how I have to investagte about gcc/gdb We are developers of embedded software on board designed and build by us; Generally we use 16 bit cisc and 32 bits risc cpu (Renesas h8/h8s; sh 2 / 3 ). We write applications for automotive enviroment mainly. We write the code using c/c++ and we compile using gcc. Because of we do not have much memory (ram and flash) we develop in the following way: each software we write has the same communication protocol running on RS232 or over TCP/IP and we have a simple monitoring progarm able to show the contents of the memory addresses in some format (char, int, long, signed unsigned, strings, ecc). Generally we declare a global variable, we write a debug value into it and during the run time we read at the right moment the content of such a variable. Good. For avoiding to read by hand .map file produced by ld, I developed a flex / bison simple analizer able to extract from .map file the address of a symbol. So into my tool I load the .map file and I write the name of the variable and I can read the content of it. This way of working becomes very hard if I use struct and union in c and classes in c++; I should know the offeset of each field of the struct so addind it to the base address known from the .map file, for each istance of such a struct I coud write "mysrtuct.myfield" into my tool, and, calculating the rigth address, my protocol could ask the target to read/write the content at that address. I prefer to avoid -g option because of my memory is never enough; but a good compromise cound be if I could compile the debug infos into sections I could remove after used by gdb for giving me the informations about the offset of each field. Is it possible? Where can I read more about to use gdb for embedded development with very poor uControllers? Thanks Alle 21:28, sabato 3 marzo 2007, Dave Korn ha scritto: > On 03 March 2007 20:15, Fabio Giovagnini wrote: > > Hi all, > > I'd like to develop a tool able to do the following things: > > 1) to load all the .h and .c/.cpp files; > > 2) to analyze allo the data struct / unions and classes; > > 3) to give me for each data member of a struct or union and for each data > > member of a class, the offset in bytes related to the base addess of a > > generic istance of the struct/union and class. > > > > In this way I could easily calculate the real address of each data member > > of each global declared struct / union and classes, and I clould easily > > read usign a simple communication protocol the content of a memory > > location of an embedded system only knowing the map file and the offset > > of each member of each global variable. > > Sounds like what you really want is a debugger... GDB does things like > that. The information you want is all emitted by the compiler as debug info > in your object files when you use the -g flag. You haven't given details > about the task you're trying to achieve but scripting gdb is probably going > to be the way to go. > > cheers, > DaveK -- Fabio Giovagnini Aurion s.r.l. via degli orti 11, 40050 Funo di Argelato (BO) Tel. +39.335.8350919 Fax +39.051.8659009 www.aurion-tech.com account telefono VoIP skype (www.skype.com): aurion.giovagnini
Re: Hi all, just an onfo about huw to use gcc tree
On 3/3/07, Fabio Giovagnini <[EMAIL PROTECTED]> wrote: Thanks for the answer. I go deeper in my thought so that maybe you can give me more infos about how I have to investagte about gcc/gdb We are developers of embedded software on board designed and build by us; Generally we use 16 bit cisc and 32 bits risc cpu (Renesas h8/h8s; sh 2 / 3 ). We write applications for automotive enviroment mainly. We write the code using c/c++ and we compile using gcc. Because of we do not have much memory (ram and flash) we develop in the following way: each software we write has the same communication protocol running on RS232 or over TCP/IP and we have a simple monitoring progarm able to show the contents of the memory addresses in some format (char, int, long, signed unsigned, strings, ecc). Generally we declare a global variable, we write a debug value into it and during the run time we read at the right moment the content of such a variable. Good. For avoiding to read by hand .map file produced by ld, I developed a flex / bison simple analizer able to extract from .map file the address of a symbol. So into my tool I load the .map file and I write the name of the variable and I can read the content of it. This way of working becomes very hard if I use struct and union in c and classes in c++; I should know the offeset of each field of the struct so addind it to the base address known from the .map file, for each istance of such a struct I coud write "mysrtuct.myfield" into my tool, and, calculating the rigth address, my protocol could ask the target to read/write the content at that address. I prefer to avoid -g option because of my memory is never enough; but a good compromise cound be if I could compile the debug infos into sections I could remove after used by gdb for giving me the informations about the offset of each field. Is it possible? Just use the dwarf info produced by the compiler with -g and strip the binary. Of course I would debug embedded stuff using a simulator... Richard.
Valid gimple for MEM_REF
I noticed that gcc.dg/tree-ssa/loop-19.c was failing on both powerpc-linux-gnu and powerpc64-linux-gnu: FAIL: gcc.dg/tree-ssa/loop-19.c scan-tree-dump-times MEM.(base: &|symbol: )a, 2 FAIL: gcc.dg/tree-ssa/loop-19.c scan-tree-dump-times MEM.(base: &|symbol: )c, 2 The reason why they are failing is because we produce: MEM[base: (double *) &c, index: ivtmp.34] = MEM[base: (double *) &a, index: ivtmp.34]; Which does not match the regex as there is a cast there. Now the real question comes down to, is the following valid gimple that IV-OPTS produces: MEM[base: (double *) &a, index: ivtmp.34_12]; base is now a non gimple invariant but instead is a full expression. If we decide to do any other optimizations with MEM_REF, we might run into more of these issues? So what are the constraints on MEM_REF's base argument, is it a simple expression (SSA_name or invariant) or can it be a complex expression? Thanks, Andrew Pinski
Re: Massive SPEC failures on trunk
On Sat, Mar 03, 2007 at 11:01:40AM -0500, Diego Novillo wrote: > Grigory Zagorodnev wrote on 03/03/07 02:27: > > > There are three checkins, candidates for the root of regression: > > http://gcc.gnu.org/viewcvs?view=rev&revision=122487 > > http://gcc.gnu.org/viewcvs?view=rev&revision=122484 > > http://gcc.gnu.org/viewcvs?view=rev&revision=122479 > > > SPEC2k works as usual[1] for me on x86_64 as of revision 122484. The only new > compile failure I see is building 300.twolf with: > > mt.c: In function 'MTEnd': > mt.c:46: warning: incompatible implicit declaration of built-in function > 'free' > mt.c:46: error: too many arguments to function 'free' > specmake: *** [mt.o] Error 1 > > Ian, looks like your VRP patch may be involved. > > > [1] 176.gcc and 253.perlbmk usually miscompare for me. Not sure why. I don't have any problems with SPEC CPU 2K on FC6/Intel64 using -O2. I use the following on gcc 4.3: # portability & libraries default=default=default=default: PORTABILITY = -DSPEC_CPU2000_LP64 176.gcc=default=default=default: CPORTABILITY = -Dalloca=_alloca EXTRA_LDFLAGS = srcalt=64bitgcc40 178.galgel=default=default=default: EXTRA_FFLAGS = -ffixed-form -ffixed-line-length-132 EXTRA_LDFLAGS = 186.crafty=default=default=default: CPORTABILITY = -DLINUX_i386 252.eon=default=default=default: CXXPORTABILITY = -DHAS_ERRLIST srcalt=fmax_errno 253.perlbmk=default=default=default: CPORTABILITY = -DSPEC_CPU2000_LINUX_I386 -DSPEC_CPU2000_NEED_BOOL -DSPEC_CPU2000_GLIBC22 254.gap=default=default=default: CPORTABILITY = -DSYS_IS_USG -DSYS_HAS_IOCTL_PROTO -DSYS_HAS_TIME_PROTO -DSYS_HAS_SIGNAL_PROTO -DSYS_HAS_CALLOC_PROTO -DSYS_HAS_READ_PROTO 255.vortex=default=default=default: EXTRA_CFLAGS=-fno-strict-aliasing srcalt=closed_files 300.twolf=default=default=default: srcalt=stdfree H.J.
Re: Massive SPEC failures on trunk
On 3/3/07, H. J. Lu <[EMAIL PROTECTED]> wrote: > [1] 176.gcc and 253.perlbmk usually miscompare for me. Not sure why. 176.gcc=default=default=default: CPORTABILITY = -Dalloca=_alloca EXTRA_LDFLAGS = srcalt=64bitgcc40 For one, the 176.gcc in SPEC 2k has an aliasing violation in it so that failing is known. You might want to try adding -fno-strict-aliasing. I have been asking someone who has the power to submit an alt to SPEC for that failure for 3 years now and now it is too late really. Thanks, Andrew Pinski
Re: Valid gimple for MEM_REF
Hello, > I noticed that gcc.dg/tree-ssa/loop-19.c was failing on both > powerpc-linux-gnu and powerpc64-linux-gnu: > FAIL: gcc.dg/tree-ssa/loop-19.c scan-tree-dump-times MEM.(base: &|symbol: > )a, 2 > FAIL: gcc.dg/tree-ssa/loop-19.c scan-tree-dump-times MEM.(base: &|symbol: > )c, 2 > > The reason why they are failing is because we produce: > MEM[base: (double *) &c, index: ivtmp.34] = MEM[base: (double *) &a, > index: ivtmp.34]; > Which does not match the regex as there is a cast there. > Now the real question comes down to, is the following valid gimple > that IV-OPTS produces: > MEM[base: (double *) &a, index: ivtmp.34_12]; > > base is now a non gimple invariant but instead is a full expression. > If we decide to do any other optimizations with MEM_REF, we might run > into more of these issues? > > So what are the constraints on MEM_REF's base argument, is it a simple > expression (SSA_name or invariant) or can it be a complex expression? only gimple_vals (name or invariant). However, the expressions are matched in final_cleanup dump (after out-of-ssa and ter), so this no longer is the case. I think just the regular expressions need to be updated. Zdenek
Re: Massive SPEC failures on trunk
On Sat, Mar 03, 2007 at 02:00:30PM -0800, Andrew Pinski wrote: > On 3/3/07, H. J. Lu <[EMAIL PROTECTED]> wrote: > >> [1] 176.gcc and 253.perlbmk usually miscompare for me. Not sure why. > > >176.gcc=default=default=default: > >CPORTABILITY = -Dalloca=_alloca > >EXTRA_LDFLAGS = > >srcalt=64bitgcc40 > > For one, the 176.gcc in SPEC 2k has an aliasing violation in it so > that failing is known. You might want to try adding > -fno-strict-aliasing. > > I have been asking someone who has the power to submit an alt to SPEC > for that failure for 3 years now and now it is too late really. While we are on SPEC CPU, has anyone tried gcc on SPEC CPU 2006? I need a patch to fix 465.tonto and a patch to fix 400.perlbench which is Linux/ia64 specific. Has anyone else reported those problems to SPEC? H.J.
Re: Valid gimple for MEM_REF
On 3/3/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote: Hello, only gimple_vals (name or invariant). However, the expressions are matched in final_cleanup dump (after out-of-ssa and ter), so this no longer is the case. I think just the regular expressions need to be updated. Then IV-OPTs has an issue too but IV-OPTs dump gives: D.1604_5 = MEM[base: (double *) &a, index: ivtmp.34_12]; MEM[base: (double *) &c, index: ivtmp.34_12] = D.1604_5; the expression matching in final_cleanup was just a symptom of the issue. Thanks, Andrew Pinski
Re: Hi all, just an onfo about huw to use gcc tree
Fabio Giovagnini wrote: Thanks for the answer. I go deeper in my thought so that maybe you can give me more infos about how I have to investagte about gcc/gdb We are developers of embedded software on board designed and build by us; Generally we use 16 bit cisc and 32 bits risc cpu (Renesas h8/h8s; sh 2 / 3 ). We write applications for automotive enviroment mainly. We write the code using c/c++ and we compile using gcc. Because of we do not have much memory (ram and flash) we develop in the following way: each software we write has the same communication protocol running on RS232 or over TCP/IP and we have a simple monitoring progarm able to show the contents of the memory addresses in some format (char, int, long, signed unsigned, strings, ecc). It sounds like you are recreating the functionality in the gdb remote. Generally we declare a global variable, we write a debug value into it and during the run time we read at the right moment the content of such a variable. Good. For avoiding to read by hand .map file produced by ld, I developed a flex / bison simple analizer able to extract from .map file the address of a symbol. So into my tool I load the .map file and I write the name of the variable and I can read the content of it. This way of working becomes very hard if I use struct and union in c and classes in c++; I should know the offeset of each field of the struct so addind it to the base address known from the .map file, for each istance of such a struct I coud write "mysrtuct.myfield" into my tool, and, calculating the rigth address, my protocol could ask the target to read/write the content at that address. Yes, developing a debugger it quite time-consuming and difficult. That is essentially what you appear to be doing. I prefer to avoid -g option because of my memory is never enough; but a good compromise cound be if I could compile the debug infos into sections I could remove after used by gdb for giving me the informations about the offset of each field. Is it possible? Why is the size of your target memory an issue? Are you trying to run the debugger on the target? In most cross-development environments, the debugger (gdb) runs on a host system and only a small portion of code (gdb remote) runs on the target. The size of your target's memory doesn't affect the host. Where can I read more about to use gdb for embedded development with very poor uControllers? Try "info gdb" as a start. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
