Re: svn problems
Mike Stump <[EMAIL PROTECTED]> wrote: >> Also, with svn 1.4 dev (all i have on this machine) > > Cool, fixed in 1.4 dev. Now I'm curious if it is fixed in 1.3.x. I > really want to update, but, the fortunes of a large company with lots > of revenue are predicated on this stuff actually working. :-) Can I > rely, given that, on 1.4 dev if it isn't fixed in 1.3.x? Pay attention: SVN 1.4 performs a silent upgrade of your working copy to a new format the first time it writes to it. This allows to deliver much increased performances with large working copies like GCC (IIRC there will be half of the stat operations for a "svn status", for instance), but makes the working copy totally incompatible with SVN 1.3 and previous versions. And there are no official downgrade script (even if google might come up with some unofficial script I saw around). Giovanni Bajo
Re: Dynamically generated code and DWARF exception handling
Daniel Jacobowitz a écrit : On Tue, May 02, 2006 at 07:21:24PM -0700, Mike Stump wrote: Otherwise, would it be possible to generate the DWARF Tables and add those tables dynamically to the running program? Yes (could require OS changes). Under windows, Microsoft provides an API for JITs that does exactly that. Is there an equivalent API for linux? Don't think so. There isn't really. But I know that other JITs have managed to do this - I just don't know how. They may use a nasty hack somewhere. Maybe there is some references somewhere about this? Which JIT? Is there a source code example or something? Would sljl exceptions work? Please there MUST be some knowledgable people here that can answer questions like this. Thanks in advance
Re: svn problems
Andrew Pinski <[EMAIL PROTECTED]> writes: > On May 2, 2006, at 6:34 PM, Mike Stump wrote: >> >>> Also, with svn 1.4 dev (all i have on this machine) >> >> Cool, fixed in 1.4 dev. Now I'm curious if it is fixed in 1.3.x. I >> really want to update, but, the fortunes of a large company with lots >> of revenue are predicated on this stuff actually working. :-) Can I >> rely, given that, on 1.4 dev if it isn't fixed in 1.3.x? > > > I even tried following your directions and it worked for me without > conflicts. It fails for me the same way as it failed for Mike. > And this was with 1.3.0. Ditto. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Dynamically generated code and DWARF exception handling
Daniel Jacobowitz writes: > On Tue, May 02, 2006 at 07:21:24PM -0700, Mike Stump wrote: > > >Otherwise, would it be possible to generate the DWARF Tables and > > >add those tables dynamically to the running program? > > > > Yes (could require OS changes). > > > > >Under windows, Microsoft provides an API for JITs that does exactly > > >that. Is there an equivalent API for linux? > > > > Don't think so. > > There isn't really. But I know that other JITs have managed to do this > - I just don't know how. They may use a nasty hack somewhere. Adding an entry point to register debug info should not be a big deal. We're going to need it for gcj when we add a JIT. Another interesting possibility would be runtime extensions to MD_FALLBACK_FRAME_STATE_FOR. That would be more flexible because it would allow us to use a JIT's native debug info, not just DWARF. Andrew.
Re: Dynamically generated code and DWARF exception handling
On Wed, May 03, 2006 at 10:14:23AM +0100, Andrew Haley wrote: > Adding an entry point to register debug info should not be a big deal. > We're going to need it for gcj when we add a JIT. > > Another interesting possibility would be runtime extensions to > MD_FALLBACK_FRAME_STATE_FOR. That would be more flexible because it > would allow us to use a JIT's native debug info, not just DWARF. Well, MD_FALLBACK_FRAME_STATE_FOR is used solely in the DWARF2/3 unwinder. Furthermore, exposing the changing internals of the unwinder sounds like very bad idea, just registering generated .eh_frame with the unwinder sounds much better. Alternatively, if the generated code always calls at most a handful controlled entry points, one could write sophisticated unwind info for those entry points that would not only unwind through that entry point routine, but also through the generated code above it and you wouldn't need any unwinder changes at all. Jakub
Re: Dynamically generated code and DWARF exception handling
Jakub Jelinek writes: > On Wed, May 03, 2006 at 10:14:23AM +0100, Andrew Haley wrote: > > Adding an entry point to register debug info should not be a big deal. > > We're going to need it for gcj when we add a JIT. > > > > Another interesting possibility would be runtime extensions to > > MD_FALLBACK_FRAME_STATE_FOR. That would be more flexible because it > > would allow us to use a JIT's native debug info, not just DWARF. > > Well, MD_FALLBACK_FRAME_STATE_FOR is used solely in the DWARF2/3 > unwinder. Furthermore, exposing the changing internals of the > unwinder sounds like very bad idea, just registering generated > .eh_frame with the unwinder sounds much better. Well, I don't know it would be better, exactly. It certainly would fit in more closely with gcc's idea of the way the world works. Whether that is better or worse depends on how gcc-centric your view of the world is. > Alternatively, if the generated code always calls at most a handful > controlled entry points, one could write sophisticated unwind info > for those entry points that would not only unwind through that > entry point routine, but also through the generated code above it > and you wouldn't need any unwinder changes at all. That's true, but rather restrictive. I guess you'd have to call a precompiled lump of code at every entry and exit point to JITted code. Andrew.
4.2 hasn't bootstrapped on powerpc-apple-darwin G5 machine for a very long time
4.2 hasn't bootstrapped on powerpc-apple-darwin G5 machine for a very long time. I'm seeing the same problem as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27121 It would be nice if this were remedied. I do try to test gcc versions before release. Brad
Re: Status of SEE and Autovectorization patches?
Mark, > I'm trying to figure out whether we can get the SEE and > Autovectorization improvements into 4.2. And please do not forget: http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00689.html (fwprop and PR/26821) because, as you yourself wrote: > I don't think I can competently review these patches, but I would like > to see them reviewed. Even though we're in Stage 3, we should try to > clear the decks for things that have been already submitted. Cheers, -- Toon Moene, KNMI, The Netherlands Phone: +31 30 2206443; e-mail: [EMAIL PROTECTED]
#line numbers in insn-recog.c
Does anyone find the use of #line in insn-recog.c actually useful? It seems to make debugging recog() impossible. Bernd
Re: Dynamically generated code and DWARF exception handling
Andrew Haley writes: > Jakub Jelinek writes: > > On Wed, May 03, 2006 at 10:14:23AM +0100, Andrew Haley wrote: > > > Adding an entry point to register debug info should not be a big deal. > > > We're going to need it for gcj when we add a JIT. > > > > > > Another interesting possibility would be runtime extensions to > > > MD_FALLBACK_FRAME_STATE_FOR. That would be more flexible because it > > > would allow us to use a JIT's native debug info, not just DWARF. > > > > Well, MD_FALLBACK_FRAME_STATE_FOR is used solely in the DWARF2/3 > > unwinder. Furthermore, exposing the changing internals of the > > unwinder sounds like very bad idea, just registering generated > > .eh_frame with the unwinder sounds much better. > > Well, I don't know it would be better, exactly. It certainly would > fit in more closely with gcc's idea of the way the world works. > Whether that is better or worse depends on how gcc-centric your view > of the world is. A quote from a well-known paper about JIT compiling explains why registering generated .eh_frame with the unwinder may not be the best idea: "While executing applications that use extensive security checks or exception handling, the HotSpot JVM spends a huge amount of time in stack unwinding code. The stack unwinding mechanism in IRIX HotSpot is implemented using DWARF unwind which needs to figure out the size of each frame before moving to the previous frame. The classic VM on the other hand has a better stack walking scheme as it keeps the frames as a linked list. The performance penalty for the DWARF scheme sometimes seems to dilute the better performance of the HotSpot runtime. In case of Tomcat, the HotSpot JVM spends around 19.4% of in stack unwinding code and related code." [1] This figure of about 20% is about the same for gcj. Andrew. [1] Ghulam Lashari, Suresh Srinivas, "Characterizing Java Application Performance," ipdps, p. 138a, International Parallel and Distributed Processing Symposium (IPDPS'03), 2003.
Re: Dynamically generated code and DWARF exception handling
On May 2, 2006, at 9:21 PM, Mike Stump wrote: On May 2, 2006, at 4:23 AM, jacob navia wrote: To get to the corresponding catch, the runtime should skip through the intermediate frames in assembler generated by the JIT. We would like to know how should be the interface with gcc to do this. The C++ abi spec and dwarf specs are good background reading materials. I looked for those a while back and never found them. Does anyone have pointers to these? Thank you, Perry Smith
Strange ACATS fails in acats.log
I'm experiencing ACATS failures that manifest in splitting /abuild/rguenther/obj4/gcc/testsuite/ada/acats/tests/a/ada101a.ada into: ada101a.adb BUILD FAIL: ada101a BUILD FAIL: c760009 splitting /abuild/rguenther/obj4/gcc/testsuite/ada/acats/tests/cd/cd2a22i.ada into: cd2a22i.adb BUILD FAIL: cd2a22i to appear in the logs, but nothing else. What's this about? Can we make the log a little more verbose here please? Thanks, Richard.
Re: Dynamically generated code and DWARF exception handling
On Wed, May 03, 2006 at 07:12:43AM -0500, Perry Smith wrote: > On May 2, 2006, at 9:21 PM, Mike Stump wrote: > > >On May 2, 2006, at 4:23 AM, jacob navia wrote: > >>To get to the corresponding catch, the runtime should skip through > >>the intermediate frames in assembler generated by the JIT. We > >>would like to know how should be the interface with gcc to do this. > > > >The C++ abi spec and dwarf specs are good background reading > >materials. > > I looked for those a while back and never found them. Does anyone > have pointers to these? I'm not sure how... The first google result for "C++ ABI" is the Itanium C++ ABI working pages, which indeed describe the ABI that GCC 3.0 and later use: www.codesourcery.com/cxx-abi/ The first google result for "DWARF standard" is the home page of the DWARF working group, which includes the version 2 and version 3 standards: dwarf.freestandards.org/ -- Daniel Jacobowitz CodeSourcery
Re: Dynamically generated code and DWARF exception handling
On Wed, May 03, 2006 at 10:36:33AM +0200, jacob navia wrote: > Maybe there is some references somewhere about this? > Which JIT? Is there a source code example or something? I'm only familiar with proprietary JITs. > Would sljl exceptions work? This has already been answered. Basically, no. -- Daniel Jacobowitz CodeSourcery
Re: exposing SH's fpscr support
In http://gcc.gnu.org/ml/gcc/2006-05/msg00047.html, you wrote: Ok, I'll bite. Why are there two of them?! Well, this is the real reason why we need an API and not just a simple builtin. GCC uses that table of values to quickly switch the FPU modes between single and double precision. However, it discards all the other fpscr bits at that time, unless the table is also updated. So, if you want to set a specific bit in fpscr, you have to not only set the actual $fpscr, but also all the entries in that table - however many there may be at the moment. There are currently two. Well, if changing fpscr and fpscr_values at the same time was your only concern, you could just call __set_fpscr. That puts the burden of preserving the SZ / PR bit in fpscr on the caller, though. (i.e. read the current value of fpscr, modify the bits you want changed, place that changed value into r4, and call __set_fpscr).
Re: Status of SEE and Autovectorization patches?
Hi Mark, On Tue, 2 May 2006, Mark Mitchell wrote: > Roger, I know that you reviewed the SEE patches. Is there anything > more than needs to be done to get them committed, in your view? As far as I'm aware, we're still just waiting for the Haifa folks to commit them to mainline. There are a number of harmless code generation changes on some platforms, but as far as we know no known performance regressions. And the Intel folks are keen to submit follow-up patches for x86_64 to extend/enhance this framework once its in the tree. And importantly there's a single command-line option/variable that can enable/disable this pass should there be any adverse events. However, my growing concern at the moment is the response time of the Haifa folks. If it's going to go into the tree in stage 3, I'd feel more comfortable that the patch submitters/contributors looked like they could respond to queries/issues with 24 or 48 hours. The current prolonged silence/inaction doesn't inspire great confidence. Perhaps you could make the executive decision, that if it isn't in the tree by June (or some date of your choosing), that it'll just have to wait for 4.3? My apologies for taking so long to review these changes, and I and the GCC maintainership should take some of the responsibility for the delays and current inconvenience. It looks from the e-mail addresses that possibly the primary developer of SEE, Leehod, is no longer at IBM but has returned to academia, with Mircea pinging the patches. This could explain things, but is pure speculation. Maybe someone could volunteer to update the posted patches for mainline and make the minor style corrections requested in the final review/approval? I've Cc'd Leehod and Mircea on this e-mail, so perhaps they'll be able to better explain the current status themselves. Roger --
Re: Summer of Code project discussion
Daniel Berlin wrote: I wrote a lot of the current zone collector. Before that, Daniel Berlin did a lot of work on it. I really don't think I have time to mentor an SoC project (Daniel, do you, maybe?), I do, in fact, have time to mentor such a project, and would be happy to mentor it if you submit it and it is accepted. My thoughts are along the lines of Daniel's. I originally believed that the better data layout of lifetime and object specific pools would help, but it only helps about 10% in the extreme. GC work is most certainly helpful. Exploring generational collection (even if it turned out to be a complete wash) would be a great project as well if you wanted to attempt that. though trying boehm-gc is a good project too. I recall that the idea of making rtl use obstacks again has come up in the past. It shouldn't hurt as much as it used to since we'd no longer have to switch them around as much, and it could potentially be faster. Maybe that would be a good experiment too? Bernd
Re: Summer of Code project discussion
On Tue, May 02, 2006 at 09:34:38PM -0400, Daniel Berlin wrote: > My thoughts are along the lines of Daniel's. I originally believed that > the better data layout of lifetime and object specific pools would help, > but it only helps about 10% in the extreme. Oh, one of the more interesting results from my testing: it can sometimes help much more than that - in precompiled header layout. Depending on the phase of the moon, I saw PCH performance improvements from 3% to 20%. -- Daniel Jacobowitz CodeSourcery
Re: 4.2 hasn't bootstrapped on powerpc-apple-darwin G5 machine for a very long time
> Bradley Lucier writes: Brad> 4.2 hasn't bootstrapped on powerpc-apple-darwin G5 machine for a very Brad> long time. I'm seeing the same problem as Brad> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27121 Brad> It would be nice if this were remedied. I do try to test gcc Brad> versions before release. For the time-being, you can bootstrap with --disable-multilib. The real solution requires Apple to provide an updated cctools with a working ld64. David
Re: Summer of Code project discussion
Hi, Thanks for your comments. I'm replying to both emails at once, as they are related. 2006/5/3, Daniel Jacobowitz <[EMAIL PROTECTED]>: > - Assuming that Boehm GC turns out to be unusable for the compiler, > finish the zone collector. Again, searching mailing list about what's > unfinished was not very fruitful. What's there works. I don't remember if it is sufficiently portable to e.g. systems without mmap to use as the default; and it needs some performance tuning still, probably, although I did a lot. I've looked into it and I see that it, in fact, is not portable to systems without mmap. What's more, a patch to make it such at http://gcc.gnu.org/ml/gcc/2004-05/msg00349.html was rejected with a hint that GCC really needs a generational collector. 2006/5/3, Daniel Berlin <[EMAIL PROTECTED]>: > I wrote a lot of the current zone collector. Before that, Daniel > Berlin did a lot of work on it. I really don't think I have time to > mentor an SoC project (Daniel, do you, maybe?), I do, in fact, have time to mentor such a project, and would be happy to mentor it if you submit it and it is accepted. Thanks for your support! Based on your feedback and on mailing list archive mining, I've made several conclusions. None of them is supported by hard data, so if they're obviously wrong, correct me. 1) Object lifetimes: in general unpredictable, but there are significant number of short-lived and very-long-lived objects. 2) Heap fragmentation is an issue (that's why copying collector is desirable?) 3) If copying (copying-generational included) collector is to be implemented, GCC sources would require some cleaning up of missed roots (pointers in local variables that are used after ggc_collect() call) Based on this, I have following refinement of my initial plan: 1) Investigate possibility of Boehm GC usage for compiler proper. Issues to be considered: 1.1) Portability. Boehm's GC portability should at least match that one of ggc-zone, if gcc-page is not going away. Obviously, if Boehm GC would replace all ggc-* collectors, then it must be as portable as GCC itself, with possibility of graceful degradation of GC performance, if that's acceptable. 1.2) Performance. Boehm's GC should be consistently faster than existing collectors by a healthy margin. (How much is enough? 10%? 20%?) 2) If Boehm GC turns out to be viable option, integrate it. 3) If not, work on existing collectors. Drop the idea of finishing ggc-zone as it is (because its portability fixes were already rejected, see above) and work on making it copying generational collector. The development of copying generational collector could be splitted to the development of simple copying collector first, then using that as a basis for the generational one. There are some risks here (again, correct me if I'm wrong) associated with copying GC: that a lot of patching all over GCC would be required it to work (those pointers in local variables). If that turns out to be a very big problem, then I remember seeing references to the generational collectors that are not copying, so considering them would be logical. Thanks again and looking forward for more comments, -- Laurynas
Re: Status of SEE and Autovectorization patches?
Roger Sayle wrote: > Hi Mark, > > On Tue, 2 May 2006, Mark Mitchell wrote: >> Roger, I know that you reviewed the SEE patches. Is there anything >> more than needs to be done to get them committed, in your view? > > As far as I'm aware, we're still just waiting for the Haifa folks to > commit them to mainline. Thanks for the update. > However, my growing concern at the moment is the response time of > the Haifa folks. I agree, this is a serious issue. > Perhaps you could make the executive decision, that if it isn't in > the tree by June (or some date of your choosing), that it'll just > have to wait for 4.3? I'm not ready to do that quite yet, but, yes, that day will come. Let's hope we get a quick reply. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Summer of Code project discussion
On Wed, 2006-05-03 at 17:18 +0200, Laurynas Biveinis wrote: > Hi, > > Thanks for your comments. I'm replying to both emails at once, as they > are related. > > 2006/5/3, Daniel Jacobowitz <[EMAIL PROTECTED]>: > > > > > - Assuming that Boehm GC turns out to be unusable for the compiler, > > > finish the zone collector. Again, searching mailing list about what's > > > unfinished was not very fruitful. > > > > What's there works. I don't remember if it is sufficiently portable to > > e.g. systems without mmap to use as the default; and it needs some > > performance tuning still, probably, although I did a lot. > > I've looked into it and I see that it, in fact, is not portable to > systems without mmap. What's more, a patch to make it such at > http://gcc.gnu.org/ml/gcc/2004-05/msg00349.html was rejected with a > hint that GCC really needs a generational collector. The number of *host* systems we support that don't have mmap is approaching 0, if it is not there already :) > > Based on your feedback and on mailing list archive mining, I've made > several conclusions. None of them is supported by hard data, so if > they're obviously wrong, correct me. > > 1) Object lifetimes: in general unpredictable, but there are > significant number of short-lived and very-long-lived objects. True, there are certainly sets of trees, rtl, and other objects whose lifetime we know exactly. > > 2) Heap fragmentation is an issue (that's why copying collector is desirable?) Heap fragmentation is a significant issue, and one of the reasons we don't collect very often, so yes. Mark and compact is of course, another option here :). > > 3) If copying (copying-generational included) collector is to be > implemented, GCC sources would require some cleaning up of missed > roots (pointers in local variables that are used after ggc_collect() > call) This is true. I know a bunch of of such places are from implementing a copying collector :). We could attempt stack walking to alleviate this, but there have been concerns about doing that, too :). Some people have talked about mark and compact before too, but it's hard to find performance numbers for real-world mark and compact collectors. > > Based on this, I have following refinement of my initial plan: > > 1) Investigate possibility of Boehm GC usage for compiler proper. > Issues to be considered: > 1.1) Portability. Boehm's GC portability should at least match that > one of ggc-zone, if gcc-page is not going away. Obviously, if Boehm GC > would replace all ggc-* collectors, then it must be as portable as GCC > itself, with possibility of graceful degradation of GC performance, if > that's acceptable. > 1.2) Performance. Boehm's GC should be consistently faster than > existing collectors by a healthy margin. (How much is enough? 10%? > 20%?) Probably 10%. The real answer is "enough to outweigh the maintenance cost of boehm-gc vs ggc-page/ggc-zone" > > 2) If Boehm GC turns out to be viable option, integrate it. > > 3) If not, work on existing collectors. Drop the idea of finishing > ggc-zone as it is (because its portability fixes were already > rejected, see above) and work on making it copying generational > collector. Again, I'm not sure the portability fixes are a real issue. There is nothing that prevents ggc-zone from being the default on systems with mmap, and ggc-page the default elsewhere. One of the reasons that the portability patches were rejected is that if we want to make ggc-zone copying/generational, any barrier style way of doing so will probably involve mprotect. I've not seen a system that supports mprotect but not mmap. In addition, if it was decided that in order to make ggc-zone the default, it would have to support non-mmap systems, i would accept the portability patches. > > The development of copying generational collector could be splitted to > the development of simple copying collector first, then using that as > a basis for the generational one. There are some risks here (again, > correct me if I'm wrong) associated with copying GC: that a lot of > patching all over GCC would be required it to work (those pointers in > local variables). If that turns out to be a very big problem, then I > remember seeing references to the generational collectors that are not > copying, so considering them would be logical. Agreed. > > Thanks again and looking forward for more comments, > > -- > Laurynas >
Re: Summer of Code project discussion
On Wed, May 03, 2006 at 11:31:00AM -0400, Daniel Berlin wrote: > Again, I'm not sure the portability fixes are a real issue. > There is nothing that prevents ggc-zone from being the default on > systems with mmap, and ggc-page the default elsewhere. > > One of the reasons that the portability patches were rejected is that if > we want to make ggc-zone copying/generational, any barrier style way of > doing so will probably involve mprotect. > > I've not seen a system that supports mprotect but not mmap. > > In addition, if it was decided that in order to make ggc-zone the > default, it would have to support non-mmap systems, i would accept the > portability patches. Yes; I think that the zone collector as it is today (my fixes to it postdate that patch rejection) makes the idea of removing ggc-page more attractive than it was then. I think that with a reasonable amount of testing and tuning on different host systems, it might be reasonable to use it as the default - even if generational collection is disabled by the lack of mmap. -- Daniel Jacobowitz CodeSourcery
Summer of Code proposal: escape analysis
Hi, I have a proposal for the summer of code. It's quite long, so I'll simply include a link: https://www.cs.tcd.ie/~pbiggar/soc/application.txt Any comments, suggestions or criticisms are welcome. Thanks Paul -- Paul Biggar [EMAIL PROTECTED]
Re: exposing SH's fpscr support
> Well, if changing fpscr and fpscr_values at the same time was your > only concern, you could just call __set_fpscr. That puts the burden > of preserving the SZ / PR bit in fpscr on the caller, though. > (i.e. read the current value of fpscr, modify the bits you want changed, > place that changed value into r4, and call __set_fpscr). Perhaps a helper function in libgcc that has the API I originally suggested, which calls __set_fpscr and preserves the right bits?
Re: Dynamically generated code and DWARF exception handling
> "jacob" == jacob navia <[EMAIL PROTECTED]> writes: jacob> This application generates dynamically code and executes it, using a jacob> JIT, a Just In time Compiler. Everything is working OK until the C++ jacob> code generates a throw. Fun! I looked at this a little bit with libgcj. In some ways for libgcj it is simpler than it is for C++, since in the gcj context we know that the only objects thrown will be pointers. So, if we were so inclined, we could give the JIT its own exception handling approach and have little trampoline functions to handle the boundary cases. Unfortunately things are also worse for libgcj, in that we need to be able to generate stack traces as well, and the trampoline function approach won't work there. Still, if you know something about the uses of 'throw' in your program, maybe this would work for you. Longer term, yeah, gcc's unwinder needs a JIT API, and then the various JITs need to be updated to use it. At least LLVM appears to be headed this direction. Tom
Re: Dynamically generated code and DWARF exception handling
> "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes: Andrew> Adding an entry point to register debug info should not be a big deal. Andrew> We're going to need it for gcj when we add a JIT. Or for our already existing JITs :-) (Not that either of those support dwarf-style unwinding yet.) Tom
Re: Dynamically generated code and DWARF exception handling
Tom Tromey a écrit : "jacob" == jacob navia <[EMAIL PROTECTED]> writes: jacob> This application generates dynamically code and executes it, using a jacob> JIT, a Just In time Compiler. Everything is working OK until the C++ jacob> code generates a throw. Fun! I looked at this a little bit with libgcj. In some ways for libgcj it is simpler than it is for C++, since in the gcj context we know that the only objects thrown will be pointers. So, if we were so inclined, we could give the JIT its own exception handling approach and have little trampoline functions to handle the boundary cases. Well, there is no exception handling in the generated machine code, and we want not to have any exception handling but to let the C++ exception handling PASS THROUGH our stack frames to find its eventual catch. This means that we have to give the run time function that implements the throw some way of getting into the higher up frames without crashing. The problem is that any throw that encounters intermediate assembler frames will inevitably CRASH. Unfortunately things are also worse for libgcj, in that we need to be able to generate stack traces as well, and the trampoline function approach won't work there. ? Sorry I do not follow here Still, if you know something about the uses of 'throw' in your program, maybe this would work for you. Longer term, yeah, gcc's unwinder needs a JIT API, and then the various JITs need to be updated to use it. At least LLVM appears to be headed this direction. Very interesting but maybe you could be more specific? I browsed that "llvm" and seems a huge project, as libgcj is. To go through all that code to find how they implement this, will be extremely difficult. If you could give me some hints as to where is the needle in those haystacks I would be really thankful. Tom jacob
Re: Fw: Status of SEE and Autovectorization patches?
> Roger Sayle <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > > 03/05/2006 05:03 PM > > To > > Mark Mitchell <[EMAIL PROTECTED]> > > cc > > Richard Henderson <[EMAIL PROTECTED]>, gcc mailing list , Leehod > Baruch <[EMAIL PROTECTED]>, Mircea Namolaru/Haifa/[EMAIL PROTECTED], > <[EMAIL PROTECTED]> > > Subject > > Re: Status of SEE and Autovectorization patches? > > > Hi Mark, > > On Tue, 2 May 2006, Mark Mitchell wrote: > > Roger, I know that you reviewed the SEE patches. Is there anything > > more than needs to be done to get them committed, in your view? > > As far as I'm aware, we're still just waiting for the Haifa folks to > commit them to mainline. There are a number of harmless code generation > changes on some platforms, but as far as we know no known performance > regressions. And the Intel folks are keen to submit follow-up patches > for x86_64 to extend/enhance this framework once its in the tree. > And importantly there's a single command-line option/variable that > can enable/disable this pass should there be any adverse events. > > However, my growing concern at the moment is the response time of > the Haifa folks. If it's going to go into the tree in stage 3, I'd > feel more comfortable that the patch submitters/contributors looked > like they could respond to queries/issues with 24 or 48 hours. The > current prolonged silence/inaction doesn't inspire great confidence. > > Perhaps you could make the executive decision, that if it isn't in > the tree by June (or some date of your choosing), that it'll just > have to wait for 4.3? My apologies for taking so long to review > these changes, and I and the GCC maintainership should take some of > the responsibility for the delays and current inconvenience. > > > It looks from the e-mail addresses that possibly the primary developer > of SEE, Leehod, is no longer at IBM but has returned to academia, with > Mircea pinging the patches. This could explain things, but is pure > speculation. Maybe someone could volunteer to update the posted patches > for mainline and make the minor style corrections requested in the final > review/approval? > > I've Cc'd Leehod and Mircea on this e-mail, so perhaps they'll be > able to better explain the current status themselves. Until they do (we're having our national Memorial-Independence ceremonies now, ending tomorrow), I can update that a patch has been prepared and tested, and is expected to be committed very shortly. Leehod is indeed the primary developer of SEE and has left IBM to continue his studies (we couldn't hold on to him until the patch was reviewed ;-), but was inspired by and worked very closely on it with Mircea who is taking care of following-up and submitting the patch. My apologies for our prolonged response time, some of which is attributed to preparations for the upcoming gcc summit and other matters that have been resolved by now. Ayal. > > Roger > -- >
Re: #line numbers in insn-recog.c
On Wed, May 03, 2006 at 12:29:17PM +0200, Bernd Schmidt wrote:
> Does anyone find the use of #line in insn-recog.c actually useful? It
> seems to make debugging recog() impossible.
Try this patch. It adds #line directives to insn-recog.c and other generated
files to revert the ones already there. It should improve debugging. A few
notes, though:
1) The line numbers are limited to 32767. I simply haven't found a trivially
easy way of fixing that.
2) The change to genrecog.c was added when I saw your message.
3) No testing on other backends than i386 and my ongoing i8086 one.
4) Lines longer than 80 chars.
5) The paperwork isn't done yet.
Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 112877)
+++ gcc/Makefile.in (working copy)
@@ -2711,7 +2713,9 @@
$(simple_generated_c:insn-%.c=s-%): s-%: build/gen%$(build_exeext) \
$(MD_DEPS) insn-conditions.md
$(RUN_GEN) build/gen$*$(build_exeext) $(md_file) \
- insn-conditions.md > tmp-$*.c
+ insn-conditions.md \
+ | awk '/^LINE$$/ { if (FNR < 32767) print "#line", FNR + 1,
"\"'$(objdir)'/insn-'$*'.c\""; next; } { print; }' \
+ > tmp-$*.c
$(SHELL) $(srcdir)/../move-if-change tmp-$*.c insn-$*.c
$(STAMP) s-$*
@@ -2786,7 +2790,9 @@
tm-constrs.h: s-constrs-h; @true
s-preds: $(MD_DEPS) build/genpreds$(build_exeext)
- $(RUN_GEN) build/genpreds$(build_exeext) $(md_file) > tmp-preds.c
+ $(RUN_GEN) build/genpreds$(build_exeext) $(md_file) \
+ | awk '/^LINE$$/ { if (FNR < 32767) print "#line", FNR + 1,
"\"'$(objdir)'/insn-preds.c\""; next; } { print; }' \
+ > tmp-preds.c
$(SHELL) $(srcdir)/../move-if-change tmp-preds.c insn-preds.c
$(STAMP) s-preds
@@ -2796,7 +2802,9 @@
$(STAMP) s-preds-h
s-constrs-h: $(MD_DEPS) build/genpreds$(build_exeext)
- $(RUN_GEN) build/genpreds$(build_exeext) -c $(md_file) > tmp-constrs.h
+ $(RUN_GEN) build/genpreds$(build_exeext) -c $(md_file) \
+ | awk '/^LINE$$/ { if (FNR < 32767) print "#line", FNR + 1,
"\"'$(objdir)'/tm-constrs.h\""; next; } { print; }' \
+ > tmp-constrs.h
$(SHELL) $(srcdir)/../move-if-change tmp-constrs.h tm-constrs.h
$(STAMP) s-constrs-h
Index: gcc/genattrtab.c
===
--- gcc/genattrtab.c(revision 112877)
+++ gcc/genattrtab.c(working copy)
@@ -3770,7 +3770,7 @@
printf ("%sif ", first_if ? "" : "else ");
first_if = 0;
write_test_expr (testexp, 0);
- printf ("\n");
+ printf ("\nLINE\n");
write_indent (indent + 2);
printf ("{\n");
Index: gcc/genemit.c
===
--- gcc/genemit.c (revision 112877)
+++ gcc/genemit.c (working copy)
@@ -511,6 +511,7 @@
is generated. */
print_rtx_ptr_loc (XSTR (expand, 3));
printf ("%s\n", XSTR (expand, 3));
+ puts ("LINE");
/* Output code to copy the arguments back out of `operands'
(unless we aren't going to use them at all). */
@@ -634,6 +635,7 @@
{
print_rtx_ptr_loc (XSTR (split, 3));
printf ("%s\n", XSTR (split, 3));
+ puts ("LINE");
}
/* Output code to copy the arguments back out of `operands' */
Index: gcc/genoutput.c
===
--- gcc/genoutput.c (revision 112877)
+++ gcc/genoutput.c (working copy)
@@ -674,6 +674,7 @@
puts ("{");
print_rtx_ptr_loc (template);
puts (template + 1);
+ puts ("LINE");
puts ("}");
}
Index: gcc/genpreds.c
===
--- gcc/genpreds.c (revision 112877)
+++ gcc/genpreds.c (working copy)
@@ -188,7 +188,7 @@
fputs (p->c_block, stdout);
else
printf ("{\n %s\n}", p->c_block);
- fputs ("\n\n", stdout);
+ fputs ("\nLINE\n\n", stdout);
}
/* Given a predicate expression EXP, from form NAME, determine whether
@@ -536,7 +536,7 @@
"{\n return ",
p->name);
write_predicate_expr (p->exp);
- fputs (";\n}\n\n", stdout);
+ fputs (";\nLINE\n}\n\n", stdout);
}
/* Constraints fall into two categories: register constraints
@@ -998,7 +998,7 @@
fputs (" return ", stdout);
write_predicate_expr (c->exp);
- fputs (";\n}\n", stdout);
+ fputs (";\nLINE\n}\n", stdout);
}
puts ("#endif /* tm-constrs.h */");
}
@@ -1049,7 +1049,7 @@
{
printf ("case CONSTRAINT_%s:\n return ", c->c_name);
write_predicate_expr (c->exp);
- fputs (";\n\n", stdout);
+ fputs (";\nLINE\n\n", stdout);
}
puts ("default: break;\n"
Index: gcc/genrecog.c
===
--- gcc/genrecog.c (revision 112877)
+++ g
Re: Dynamically generated code and DWARF exception handling
On Tue, May 02, 2006 at 01:23:56PM +0200, jacob navia wrote: > Is there an equivalent API for linux? __register_frame_info_bases / __deregister_frame_info_bases. r~
Re: #line numbers in insn-recog.c
On Wed, May 03, 2006 at 12:29:17PM +0200, Bernd Schmidt wrote: > Does anyone find the use of #line in insn-recog.c actually useful? It > seems to make debugging recog() impossible. Yes, it makes compile errors go to the right place. r~
Re: Summer of Code project discussion
2006/5/3, Daniel Berlin <[EMAIL PROTECTED]>: The number of *host* systems we support that don't have mmap is approaching 0, if it is not there already :) Uhm, at least DJGPP as a GCC host system is alive and does not support mmap. But according to the following discussion, that's non-issue. Mark and compact is of course, another option here :). Yes. Of course, it has the same issue with missed pointers as copying collectors do. We could attempt stack walking to alleviate this, but there have been concerns about doing that, too :). This is certainly possible. There is an issue that unitialized areas in the stack may pose as valid pointers and thus render some of the garbage uncollectable. An experiment with Boehm's GC could provide some insight into how much it would affect a GGC, as it does stack walking. Some people have talked about mark and compact before too, Couldn't find any discussion about mark and compact in GCC context, any pointers? In addition, if it was decided that in order to make ggc-zone the default, it would have to support non-mmap systems, i would accept the portability patches. Makes sense. So, regardless of final collector investigation results, it's a good idea to have an additional side-outcome of the project: make GCC have only one GGC. OK, so based on the next round of comments here is the next iteration of the rough plan: 1) Investigate possibility of Boehm GC usage for compiler proper. 1.1) Issues to be considered: 1.1.1) Portability. Boehm's GC portability should at least match that one of ggc-zone, if gcc-page is not going away. Obviously, if Boehm GC would replace all ggc-* collectors, then it must be as portable as GCC itself, with possibility of graceful degradation of GC performance, if that's acceptable. 1.1.2) Performance. Boehm's GC should be consistently faster than existing collectors by a healthy margin, about 10%. 1.2) The investigation would be done with a quick-and-dirty hacking of build system and throwing together a ggc-boehm.c wrapper. Both of these are supposed to be thrown away later. 2) If Boehm GC turns out to be viable option, integrate it. 2.1) Build system integration. Documentation tells that Boehm GC GNU style build system is incomplete. Practically that means that for any GCC hosts, which don't support Java already, GNU-style build system bits have to be written for Boehm GC. Shouldn't be too many such systems or too complex. 2.2) Developing proper ggc-boehm.c. Implement external interface functions of ggc.h. Exploit things like GC_malloc_atomic for performance tuning. Throw away helper functions in ggc.h and most of the ggc-* stuff. 3) If Boehm GC is not a viable option, work on existing collectors. 3.1) Develop a copying collector 3.1.1) Find a solution for root pointer in local variables. By this time should be clear from Boehm GC investigation results if stack walking is viable for GCC. It would be preferred because no modifications all over GCC would be required. 3.2.2) Have a fallback for a non-mmap, non-mprotect system in the same collector. 3.2) Develop a generational collector. A first design idea is to have three generations. Objects would be promoted from the 1st to 2nd generation after surviving a single collection, from 2nd to 3rd after surviving additional few (more than one) collections. Some of the objects with a known lifetime (medium or very long) could be put straight into 2nd or 3rd zone. 4) Testing. I have access to x86, with some additional effort I could also test on amd-x64 and sparc hosts. I assume that I will have to arrange for tests on a number of additional host architectures, that's where I will probably need some help. What's still unresolved with this plan: 1) How does PCH interact with GC and what will I have to do about it. 2) Copying collector as a milestone concerns me a bit. Would GCC accept a collector that doubles its memory requirements, in the (let's hope, unlikely) case that I don't finish generational GC? Obstack resurrection investigation sounds interesting, but for now I exclude it from the plan. It may reappear there later, depending on how things turn out. Thanks again for your comments and looking forward for more feedback. -- Laurynas
Re: Dynamically generated code and DWARF exception handling
On May 3, 2006, at 8:58 AM, Daniel Jacobowitz wrote: On Wed, May 03, 2006 at 07:12:43AM -0500, Perry Smith wrote: On May 2, 2006, at 9:21 PM, Mike Stump wrote: On May 2, 2006, at 4:23 AM, jacob navia wrote: To get to the corresponding catch, the runtime should skip through the intermediate frames in assembler generated by the JIT. We would like to know how should be the interface with gcc to do this. The C++ abi spec and dwarf specs are good background reading materials. I looked for those a while back and never found them. Does anyone have pointers to these? I'm not sure how... Thanks. I appreciate the help. Can a link be added in the g++ documentation to this page? I did not make the connection that exception handling that GNU g++ did for PowerPC was documented on a CodeSourcery page with "Itanium" in its title. Perry
Re: Dynamically generated code and DWARF exception handling
On May 3, 2006, at 4:03 PM, Perry Smith wrote: Can a link be added in the g++ documentation to this page? You mean as we've done on: http://gcc.gnu.org/readings.html under The V3 multi-vendor standard C++ ABI is used in GCC releases 3.0 and above and DWARF Workgroup ? Yes, we can. Anything else?
Re: 4.2 hasn't bootstrapped on powerpc-apple-darwin G5 machine for a very long time
> > Bradley Lucier writes:
> Brad> 4.2 hasn't bootstrapped on powerpc-apple-darwin G5 machine for a very
> Brad> long time. I'm seeing the same problem as
> Brad> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27121
> Brad> It would be nice if this were remedied. I do try to test gcc
> Brad> versions before release.
>
> For the time-being, you can bootstrap with --disable-multilib.
> The real solution requires Apple to provide an updated cctools with a
> working ld64.
Hi,
FWIW, the 20060415 mainline (4.2) snapshot bootstrapped for me, using
odcctools-20060413 (odcctools-590.36od13). This machine is a dual G5
(ppc970) using OS X 10.3.9, and Apple's gcc-3.3 (build 1640).
However, before building, I patched the following 2 files:
In gcc/config/darwin.h:
at: #define LINK_COMMAND_SPEC :
replace:/usr/bin/libtool
with: /path/to/odcctools/bin/libtool
In libstdc++-v3/scripts/make_exports.pl (for OS X 10.3 only):
replace:nm -P
with: /path/to/odcctools/bin/nm -P
(probably not necessary if this nm is already found first in path)
Configure command (your paths may vary):
../configure --prefix=/Users/fang/local/gcc-4.2 \
--program-suffix=-4.2 \
--disable-nls \
--with-gmp=/sw \
--with-mpfr=/sw \
--infodir='${prefix}/share/info' \
--with-included-gettext \
--host=powerpc-apple-darwin`uname -r|cut -f1 -d.` \
`if test ! -f /usr/lib/libSystemStubs.a ; then echo -n
"--with-as=/Users/fang/lib/odcctools/bin/as
--with-ld=/Users/fang/lib/odcctools/bin/ld" ; fi`
The default languages enabled are c,c++,java,fortran,objc according to
configure.
I also made sure all the odcctools came first in my path, a blunder I
made earlier. GMP 4.1.4 and MPFR are installed in /sw.
It might not hurt to add a few hints to
http://gcc.gnu.org/install/specific.html#powerpc-x-darwin
since I (and several other PR reporters) also had trouble bootstrapping
4.2 a while back.
Many thanks to all who help maintain the powerpc-apple-darwin port.
Fang
Re: Summer of Code project discussion
Laurynas Biveinis wrote: > 2006/5/3, Daniel Berlin <[EMAIL PROTECTED]>: > >> The number of *host* systems we support that don't have mmap is >> approaching 0, if it is not there already :) > > Uhm, at least DJGPP as a GCC host system is alive and does not support > mmap. But according to the following discussion, that's non-issue. In the long run, I don't think we really want to be using garbage collection at all. The reason we started using it was that we had memory pools with ill-defined lifetimes, and stuff ended up in the wrong pool, and therefore got deallocated when it shouldn't. We added garbage collection as part of the transition to function-at-a-time mode in the C++ front end. My opinion is, in the long run, memory pools really are what we want -- just not as many as we used to have. In particular, we want one memory pool for global trees (global types, variables with static storage duration, functions), and one memory pool for the body of each function. References would be allowed from the body of each function to the global pool, but the other direction should be strictly limited to one pointer from each function to its body. (This allows you to read in/write out function bodies more easily.) The RTL for each function is generated when emitting code for the function, and is discarded after the function has been emitted as assembly code. Since we no longer do inlining on RTL, this RTL can be discarded immediately after use. To make this work, we have to be careful not to generate as much garbage as we presently do, as we'll needlessly waste space in these pools. Right now, we're using GC partly to compensate for things like using trees to represent strictly temporary data. All of the above should not in way be read as an argument against using the zone collector -- it's actually an argument in favor of improving the zone collector! It's going to take a while to do the bits above, and having better GC is going to help us until then. The great thing about the zone collector is that it's a step in the memory pool direction; it's zones can be the things I called pools. Whether we use GC on those pools, or turn the zones into obstacks, or whatever, is a separate step. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Suggestion for GCC (C & C++) enhancement - static variable initialisation ordering
| I'd encourage you to work up a solid proposal for ISO/ANSI and | propose it there. Being a newbie, I'd appreciate contact/site details for submissions to the ISO/ANSI standardisation forum (do I email [EMAIL PROTECTED]). I will be happy to draft and submit a proposal, including a hopefully compelling motivation. I would need to know what form a proposal must take. I assume that the draft dated 2 December 1996 is what I should use as a basis.
