gcc-4.5-20100729 is now available
Snapshot gcc-4.5-20100729 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100729/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 162696 You'll find: gcc-4.5-20100729.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20100729.tar.bz2 C front end and core compiler gcc-ada-4.5-20100729.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20100729.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20100729.tar.bz2 C++ front end and runtime gcc-java-4.5-20100729.tar.bz2 Java front end and runtime gcc-objc-4.5-20100729.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20100729.tar.bz2The GCC testsuite Diffs from 4.5-20100722 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 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: GFDL/GPL issues
On Thu, Jul 29, 2010 at 01:20:45PM -0700, Brian Makin wrote: > Or to move to a better foundation? It seems to me that gcc has had various > issues for various reasons for quite a while now. RMS is all for tightly > controller yet freely distributable software. > Maybe it's time to throw more effort behind something like LLVM? This is the gcc development list. If you want to contribute to LLVM, that's fine, but if so you're on the wrong list.
Re: GFDL/GPL issues
>On Thu, Jul 29, 2010 at 12:08 AM, Steven Bosscher wrote: >> On Wed, Jul 28, 2010 at 11:17 PM, Mark Mitchell wrote: >>> Steven Bosscher wrote: >>> > Why not just ignore RMS and the license issues and simply do what we > think suits us and the project. Let the FSF deal with the legal >>>consequences, > they put us in this messy situation, they deal with it. It seems to me that escalating the issue is more helpful. GCC is not the only project with this problem. >>> >>> Sadly, at this point, RMS is simply taking the position that this is not >>> a problem worth solving. >> >> Ah, how the "free" in Free Software Foundation takes a whole different >> meaning when it comes to actual freedom... > >Ha! Sounds like time to overturn the (benevolent?) dictator! > >Richard. Or to move to a better foundation? It seems to me that gcc has had various issues for various reasons for quite a while now. RMS is all for tightly controller yet freely distributable software. Maybe it's time to throw more effort behind something like LLVM?
Re: The impact of the IVOPT changes for our code.
Thanks for testing it out. There are probably more tuning opportunities for fortran (e.g. larger solution search space, more aggressive pruning, and more advanced loop invariants and register pressure estimation), which I hope someone can continue working on (or me if I find more time). David On Thu, Jul 29, 2010 at 11:33 AM, Toon Moene wrote: > It buys the HIRLAM code about 100 seconds out of 8 thousands: > > New: > > $ grep 'FORECAST TOOK' HL_Cycle_2010072912.html > FORECAST TOOK 775.5685 SECONDS > FORECAST TOOK 779.8127 SECONDS > FORECAST TOOK 29.8419 SECONDS > FORECAST TOOK 7929.5913 SECONDS > > Compared to (old): > > $ grep 'FORECAST TOOK' HL_Cycle_2010072812.html > FORECAST TOOK 785.2891 SECONDS > FORECAST TOOK 786.7651 SECONDS > FORECAST TOOK 31.5340 SECONDS > FORECAST TOOK 8027.6938 SECONDS > > -- > Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands > At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ > Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran >
The impact of the IVOPT changes for our code.
It buys the HIRLAM code about 100 seconds out of 8 thousands: New: $ grep 'FORECAST TOOK' HL_Cycle_2010072912.html FORECAST TOOK 775.5685 SECONDS FORECAST TOOK 779.8127 SECONDS FORECAST TOOK29.8419 SECONDS FORECAST TOOK 7929.5913 SECONDS Compared to (old): $ grep 'FORECAST TOOK' HL_Cycle_2010072812.html FORECAST TOOK 785.2891 SECONDS FORECAST TOOK 786.7651 SECONDS FORECAST TOOK31.5340 SECONDS FORECAST TOOK 8027.6938 SECONDS -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran
Re: GFDL/GPL issues
Richard Kenner wrote: > Could part of the problem here be that RMS's view on "documentation" is > that it's meant to be a creative process, somewhat akin to writing a book, > and that mechanically creating "documentation" will produce something of > much lower quality than what's done by hand? Back when he and I spoke > regularly, I know that he cared a lot about the "literary" quality of the > documentation and I think that part of this might be due to a "why would > you want to do that anyway?" position on automaticaly-generated stuff. Yes, that is part of his thinking. And, yes, we can split our manuals up into GPL and GFDL pieces, and in some cases that will work fine. But, documentation of constraints (important to users for writing inline assembly), or documentation of command-line options (important to all users), or documentation of built-in functions (important to users to understand the dialect of C we support) are all things that belong in the manual, not in separate GPL documents. FSF policy is making it impossible for us to do something useful to users, that poses no real risk to the FSF's objectives (manuals were under the GPL for ages without the world ending), and which GCC's competitors can do. That's a suboptimal policy. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
> Isn't one of the specific instances of this issue the desire to copy > some of the constraints information from the source, which would need to > go into the user manual rather than internals documentation? > > And in some cases a function index with documentation may be precisely > what the end-user needs -- think runtime libraries. But in both of these cases, there are basically two separate things: a prose description (in these cases of what constraints do and an overview of the library) and a separate list of details. The first would be a well-written document and the latter would be automatically generated. So I can see the argument that having two separate documents here may be valuable from OTHER than a licensing viewpoint. (I'm not sure whether I AGREE with it or not, but that may be partly where RMS is coming from.)
Re: GFDL/GPL issues
On 07/29/10 08:26, Richard Kenner wrote: But even for documentation written by hand, often I find that I'd like to start out with some comment or example from the actual code. The GPL / GFDL dichotomy doesn't allow me to do that, so some documentation just won't get written. Taking an example from actual code would be "fair use" and not a violation of the GPL. I don't see a problem there. Taking large pieces of code in a mechanical way is completely different from the type of manual copying you're talking about. Isn't one of the specific instances of this issue the desire to copy some of the constraints information from the source, which would need to go into the user manual rather than internals documentation? And in some cases a function index with documentation may be precisely what the end-user needs -- think runtime libraries. What's concerning is how much time we've got to spend discussing this kind of issue rather than getting real work done, all due to a license that is insanely controversial. Jeff
Re: GFDL/GPL issues
> But even for documentation written by hand, often I find that I'd like to > start out with some comment or example from the actual code. The GPL / GFDL > dichotomy doesn't allow me to do that, so some documentation just won't get > written. Taking an example from actual code would be "fair use" and not a violation of the GPL. I don't see a problem there. Taking large pieces of code in a mechanical way is completely different from the type of manual copying you're talking about.
Re: GFDL/GPL issues
Quoting Richard Kenner : Could part of the problem here be that RMS's view on "documentation" is that it's meant to be a creative process, somewhat akin to writing a book, and that mechanically creating "documentation" will produce something of much lower quality than what's done by hand? Back when he and I spoke regularly, I know that he cared a lot about the "literary" quality of the documentation and I think that part of this might be due to a "why would you want to do that anyway?" position on automaticaly-generated stuff. But even for documentation written by hand, often I find that I'd like to start out with some comment or example from the actual code. The GPL / GFDL dichotomy doesn't allow me to do that, so some documentation just won't get written.
Re: GFDL/GPL issues
> Wait. Steven's comment was on the snarky side, but coming from a > long-time gcc contributor I don't think it was over the line or even > near it. I think he was expressing a perfectly valid point of view > considering the constraints that the FSF places on gcc developers. For > certain aspects of gcc, generating documentation from code makes all > kinds of sense. The fact that the FSF is preventing us from doing that > is a real problem. It's not a critical problem, but it's one in a line > of real problems. Could part of the problem here be that RMS's view on "documentation" is that it's meant to be a creative process, somewhat akin to writing a book, and that mechanically creating "documentation" will produce something of much lower quality than what's done by hand? Back when he and I spoke regularly, I know that he cared a lot about the "literary" quality of the documentation and I think that part of this might be due to a "why would you want to do that anyway?" position on automaticaly-generated stuff. But we've heard that he indeed has no problem creating something that's in the form of documentation and calling it a "function index" or something similar. And I think we ought to seriously consider going in that direction, where there are two separate things: a MANUAL, written manually, which is meant to be high-quality language and is under the GFDL, and a separate document which is under the GPL and is generated automatically. This may also produce more of a split between the user and internal documentation. The user manual is the one that (I suspect), he's mostly concerned about that that needs to be produced manually to get appropriate quality. Then there's another GFDL'ed document that's an overview of the internals and references the third (GPL'ed) document that's automatically generated.
Re: optimization question: mpl
On 07/28/10 10:26, Richard Guenther wrote:
[snip]
You can use the flatten attribute to tell the compiler to inline all
calls in a given function, like
void __attribute__((flatten)) foo(void)
{
...
decode1();
...
}
and it will inline decode1() (and recursively all its callees).
[snip]
Will this attribute work when the function calls are done
by dereferencing const function pointers in a const array
as done in the dispatch_funvec shown here:
http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/364c0dd5ce512497#
or is there maybe some other attribute needed?
TIA.
-Larry
Re: GFDL/GPL issues
Ian Lance Taylor wrote: "Alfred M. Szmidt" writes: Please move such unconstructive arguments elsewhere. Wait. Steven's comment was on the snarky side, but coming from a long-time gcc contributor I don't think it was over the line or even near it. I think he was expressing a perfectly valid point of view considering the constraints that the FSF places on gcc developers. For certain aspects of gcc, generating documentation from code makes all kinds of sense. The fact that the FSF is preventing us from doing that is a real problem. It's not a critical problem, but it's one in a line of real problems. Especially if he is right about more projects having this problem. He wrote: "GCC is not the only project with this problem." If that is true, and if those projects are also under the umbrella of the FSF, we (those projects together) might take the step to "escalate" this issue to the board of the FSF. Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran
Re: GFDL/GPL issues
Ian Lance Taylor writes: >> Please move such unconstructive arguments elsewhere. > > Wait. Steven's comment was on the snarky side, but coming from a > long-time gcc contributor I don't think it was over the line or even > near it. I think he was expressing a perfectly valid point of view > considering the constraints that the FSF places on gcc developers. For > certain aspects of gcc, generating documentation from code makes all > kinds of sense. The fact that the FSF is preventing us from doing that > is a real problem. It's not a critical problem, but it's one in a line > of real problems. I think it'd be a lot more palatable if there were at least some justification given for ignoring the request -- but at least the way Mark stated it, rms was just dismissive. -Miles -- Do not taunt Happy Fun Ball.
Re: GFDL/GPL issues
"Alfred M. Szmidt" writes: > Please move such unconstructive arguments elsewhere. Wait. Steven's comment was on the snarky side, but coming from a long-time gcc contributor I don't think it was over the line or even near it. I think he was expressing a perfectly valid point of view considering the constraints that the FSF places on gcc developers. For certain aspects of gcc, generating documentation from code makes all kinds of sense. The fact that the FSF is preventing us from doing that is a real problem. It's not a critical problem, but it's one in a line of real problems. Ian
Re: GFDL/GPL issues
Please move such unconstructive arguments elsewhere.
