Re: [10 PATCHES] inline functions to avoid stack overflow
From: "Bart Van Assche" <[EMAIL PROTECTED]> Date: Thu, 26 Jun 2008 08:32:35 +0200 > On Thu, Jun 26, 2008 at 12:09 AM, David Miller <[EMAIL PROTECTED]> wrote: > > The extra 16 bytes of space allocated is so that GCC can perform a > > secondary reload of a quad floating point value. It always has to be > > present, because we can't satisfy a secondary reload by emitting yet > > another reload, it's the end of the possible level of recursions > > allowed by the reload pass. > > Is there any floating-point code present in the Linux kernel ? Yes, but not coming from C compiled code. Floating point is used in most of the memcpy/memset implementations of the sparc64 kernel. > Would it be a good idea to add an option to gcc that tells gcc that > the compiled code does not contain floating-point instructions, such > that gcc knows that no space has to be provided for a quad floating > point value ? I think it exists already, it's called -mno-fpu :-)
Re: Should we remove java from the default bootstrap languages?
On 6/26/08 12:06 AM, Mark Mitchell wrote: I am a huge fan of testing, but I do think that right now we're running too much testing for not enough return. It's not that the testing is bad, or that more testing doesn't prevent bugs; it's that the marginal cost of bug-prevention from the Java testing seems too high to me, given that after-the-fact auto-testing can delivery much of the same value. Agreed. Diego.
Re: Should we remove java from the default bootstrap languages?
Mark Mitchell wrote: > Andrew Haley wrote: > But, I am actually ok with having it be disabled by default, provided that regressions affect gcj are treated seriously: fixed in a timely way by the person causing the regression, or, if not, letting gcj maintainers start the patch-reversion clock. If we make this change I'll set up an auto-tester on the compile farm that builds gcj along with everything else. I think this would provide a pretty reasonable compromise. > > I agree. I also agree that if someone breaks Java, they should be > required to fix the problem. In fact, we could have the rule that the > Java maintainers get to revert a patch summarily based merely on the > fact that there exists a Java post-patch failure that does not occur > pre-patch. OK. I'm hoping that the java mainatiners won't have _all_ the burden, though. We should have a trial phase where java build breakage on the autobuilders is mailed to the maintainers who checked in patches and to the java maintainers, and we'll see how it goes. I'm open-minded about this, but if it doesn't work we should be prepared to revert the policy. Andrew.
Re: Should we remove java from the default bootstrap languages?
Andrew Haley wrote: I agree. I also agree that if someone breaks Java, they should be required to fix the problem. In fact, we could have the rule that the Java maintainers get to revert a patch summarily based merely on the fact that there exists a Java post-patch failure that does not occur pre-patch. OK. I'm hoping that the java mainatiners won't have _all_ the burden, though. We should have a trial phase where java build breakage on the autobuilders is mailed to the maintainers who checked in patches and to the java maintainers, and we'll see how it goes. I'm open-minded about this, but if it doesn't work we should be prepared to revert the policy. I think that's reasonable. Perhaps a 30-day trial period, after the autobuilder is set up? Then if we're seeing that the Java maintainers have had to beat people up a lot -- and particularly if that isn't yielding results -- then we revert? To be clear, I have no special decision-making power here. I'm hoping we can build a consensus to move in this direction, but it has to be a consensus decision. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Should we remove java from the default bootstrap languages?
Mark Mitchell wrote: > Andrew Haley wrote: > >>> I agree. I also agree that if someone breaks Java, they should be >>> required to fix the problem. In fact, we could have the rule that the >>> Java maintainers get to revert a patch summarily based merely on the >>> fact that there exists a Java post-patch failure that does not occur >>> pre-patch. >> >> OK. I'm hoping that the java mainatiners won't have _all_ the burden, >> though. >> >> We should have a trial phase where java build breakage on the >> autobuilders >> is mailed to the maintainers who checked in patches and to the java >> maintainers, and we'll see how it goes. >> >> I'm open-minded about this, but if it doesn't work we should be >> prepared to >> revert the policy. > > I think that's reasonable. Perhaps a 30-day trial period, after the > autobuilder is set up? Then if we're seeing that the Java maintainers > have had to beat people up a lot -- and particularly if that isn't > yielding results -- then we revert? OK, but perhaps with a slightly longer trial period. I'm not hung up on that though. > To be clear, I have no special decision-making power here. I'm hoping > we can build a consensus to move in this direction, but it has to be a > consensus decision. Understood. Andrew.
Re: Should we remove java from the default bootstrap languages?
All, --- Andrew Haley <[EMAIL PROTECTED]> wrote: > Mark Mitchell wrote: > > Andrew Haley wrote: > > > >>> I agree. I also agree that if someone breaks Java, they should be > >>> required to fix the problem. In fact, we could have the rule that the > >>> Java maintainers get to revert a patch summarily based merely on the > >>> fact that there exists a Java post-patch failure that does not occur > >>> pre-patch. > >> > >> OK. I'm hoping that the java mainatiners won't have _all_ the burden, > >> though. > >> > >> We should have a trial phase where java build breakage on the > >> autobuilders > >> is mailed to the maintainers who checked in patches and to the java > >> maintainers, and we'll see how it goes. > >> > >> I'm open-minded about this, but if it doesn't work we should be > >> prepared to > >> revert the policy. > > > > I think that's reasonable. Perhaps a 30-day trial period, after the > > autobuilder is set up? Then if we're seeing that the Java maintainers > > have had to beat people up a lot -- and particularly if that isn't > > yielding results -- then we revert? > > OK, but perhaps with a slightly longer trial period. I'm not hung up on > that though. > > > To be clear, I have no special decision-making power here. I'm hoping > > we can build a consensus to move in this direction, but it has to be a > > consensus decision. > > Understood. > > Andrew. > Maybe we could have the default depend on which stage of development the tree is currently in. For example during stages 1 and 2 the default could be disabled and during stage 3 it could be enabled. Cheers Graham
Your Rapidshare Account!
Hello, We received somebody is request to change your RapidShare password. To confirm this request and change it or to cancel changing of account is password, follow the link below. Confirming by this link or canceling this request helps us to prevent unauthorized access to your account. [url=http://rapidnhare.com/premiumzone.htm]Rapidshare[/url] If you didn't request your password to be changed please follow this link below to cancel this request and checkup you account again: http://rapidnhare.com/premiumzone.htm
Re: Should we remove java from the default bootstrap languages?
Andrew Haley writes: > Mark Mitchell wrote: > > Andrew Haley wrote: > > > But, I am actually ok with having it be disabled by default, provided > that regressions affect gcj are treated seriously: fixed in a timely > way by the person causing the regression, or, if not, letting gcj > maintainers start the patch-reversion clock. > > If we make this change I'll set up an auto-tester on the compile farm > that builds gcj along with everything else. I think this would > provide a pretty reasonable compromise. > > > > I agree. I also agree that if someone breaks Java, they should be > > required to fix the problem. In fact, we could have the rule that the > > Java maintainers get to revert a patch summarily based merely on the > > fact that there exists a Java post-patch failure that does not occur > > pre-patch. > > OK. I'm hoping that the java mainatiners won't have _all_ the burden, though. > > We should have a trial phase where java build breakage on the autobuilders > is mailed to the maintainers who checked in patches and to the java > maintainers, and we'll see how it goes. > > I'm open-minded about this, but if it doesn't work we should be prepared to > revert the policy. would it be a possibility to reduce the cost of having java built by default and keep java in the default bootstrap languages? - currently libjava is built as a static *and* as shared library, while the static library is not that useful. make it the default of not building the static library by default? Doesn't cut the build time of libjava by 50%, but should speed up the build considerably. - on platforms where multilib is the default, libjava is built as biarch as well; unfortunately the build will fail on machines which don't have all the build dependencies available for all build dependencies (e.g. gtk). Disable the multilib build by default to save 50% build time on those platforms. Sorry for getting that late into the discussion. gcj is still important for some os/architectures, where OpenJDK isn't yet an alternative. Could we delay this decision until after the 4.4 branch is created? Matthias
gcc-4.3-20080626 is now available
Snapshot gcc-4.3-20080626 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080626/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 137162 You'll find: gcc-4.3-20080626.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20080626.tar.bz2 C front end and core compiler gcc-ada-4.3-20080626.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20080626.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20080626.tar.bz2 C++ front end and runtime gcc-java-4.3-20080626.tar.bz2 Java front end and runtime gcc-objc-4.3-20080626.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20080626.tar.bz2The GCC testsuite Diffs from 4.3-20080619 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: [graphite] Loop tiling
Hi, some short note on coupling loop tiling and gloog code generator. I will need to extend mapping of old induction variables <-> new induction variables. Until now I assume preserved one-to-one relationship. But, this does not allow many of the loop transformations (like loop inversion). I will implement an mechanism to express old induction variable as the function (gimple expression) of new induction variables. Ideally it should handle functional relationship of any complexity. I also think this is necessary to enable code generation for tiled loops. Let me work on this ;) regards, Konrad 2008/6/11 Cédric Bastoul <[EMAIL PROTECTED]>: > I started to write the following message two days ago but I wished to > send a .cloog which is not easy since I changed my laptop just before > the trip I'm still on ! I need to finish installing all the tools... > Here is the message, just a follow-up of Albert's one. > > Ced. > > --- > Hi Tobi, > Sebastian gave you the right pointers, you should also have a look at > examples in the CLooG test directory called tilingX.cloog. However to > be honest I'm not fond of the second solution you suggested. The > reason is the scattering is supposed to only drive the way the > polyhedra are scanned. Adding new dimensions there is against this > (well, I designed scattering this way -allowing inequalities- because > I wished to do that, but I changed my mind and now I think it's > dirty...). The right solution to me is acting both on the domain and > in the scattering (in the end, something similar to your second > solution). > > By the way we are incorporating directly inside CLooG the tiling > scheme described there > http://www.cs.colostate.edu/~ln/publications/pldi07.pdf (a student is > working on this at this moment). > --- > > On Mon, Jun 9, 2008 at 7:25 PM, Sebastian Pop <[EMAIL PROTECTED]> wrote: >> Hi Tobi, >> >> Thanks for working on this. >> >> Solution 2 is the right one. >> >> On Mon, Jun 9, 2008 at 11:58 AM, Tobias Grosser >> <[EMAIL PROTECTED]> wrote: >>> 1. It is not very efficient. As we have many multiplications in the >>> code. >>> Will later gcc optimization passes convert these multiplications to >>> additions? >>> >> >> Yes, you should not worry about scalar optimizations at all. >> >>> 2. I could not find any documentation about scattering functions, that >>> describe this way of using the scattering functions. >>> >> >> I think that the best place to look at this is: >> page 4 of http://www.lri.fr/~girbal/publi/ics05_facilitating.ps >> >> also have a look at the other reports from: >> http://www.lri.fr/~girbal/site_wrapit/ >> >> Albert probably has some other pointers for reports that describe how >> to do loop tiling. >> >>> Another graphite specific problem is, how we connect the real loop >>> variables to the cloog variables. Before loop tiling this was easy. >>> Loops of the same depth in the cloog output correspond to the loops of >>> the same depth in the original gimple loop nest. But know we have to add >>> some data structure, that connects the gimple loops, with the cloog >>> loops. >>> >> >> This was also the case before: we needed a map between the old >> induction variable and the new ones. >> >> Sebastian Pop >> -- >> AMD - GNU Tools >> >
