Re: Our Publication Proposal: Your dissertation in book form
* Sarah Lynch: > LAP LAMBERT Academic Publishing GmbH& Co. KG > > Dudweiler Landstraße 99, > 66123 Saarbrücken, Germany This company appears to be affiliated with "VDM Publishing", a company which became notorious as a republisher of Wikipedia articles.
Re: Original commit history for gfortran
On 06/19/11 10:03 PM, Tobias Schlüter wrote: Hi Christopher, On 2011-06-18 14:39, "C. Bergström" wrote: On 06/18/11 05:16 PM, Toon Moene wrote: On 06/18/2011 12:12 PM, Toon Moene wrote: On 06/18/2011 05:05 AM, Christopher Bergström wrote: Hi We're in the process of considering contributing to gfortran for a special project, but when we started to vet the codebase we hit a bump in lack of commit history. Additional information is here: http://sourceforge.net/projects/gcc-g95 The above gives you the history after the split from the g95 project: http://sourceforge.net/projects/g95 in January 2003. The original commit by Paul Brook of the gcc-g95 repository contents to the GCC repository is here: http://gcc.gnu.org/ml/gcc-cvs/2003-07/msg01087.html So I converted the cvs repo to git so I could actually dig and compare a little better.. Here's an example of what we're trying to understand This file wasn't in g95, but then magically appears in Paul's initial commit. gcc/f95/arith.h # Unless I've messed up somewhere along my path.. # Was this file in gcc the whole time and just an external dep? I think the history of this particular change went like this: Steven Bosscher was concerned about making g95 more modular. Part of that process was splitting the big g95.h file into several parts -- that's where arith.h comes from. Another part of that endeavour was moving the various tree dumpers into dump-parse-tree.c -- which IMO defeated the original purpose of having them in their corresponding source files (namely documentation), but on the other hand made that part more self-contained. As for the history, there was another sourceforge project dedicated to g95 -> gcc integration bsides gcc-g95, its name escapes me right now. IIRC some of the I/O library was developed there. Between the closing of g95's tree and gcc-g95's launch some development happened in private trees as pointed out before, but apart from that and Andy's very initial work which happened without CVS, you should find all the history in public record. Thanks for the information I'm sorry that I'm writing the following paragraph, but I think I should. I heard rumors that Andy was hired by Pathscale, so I'm a bit worried about your intentions. Why speculate or give credence to rumors - just ask if it's important to you You're not trying to vet the code for the parts of the code which are available to relicensing to Pathscale for commerical exploitation, are you? That's something that may under very specific circumstances be allowed by the usual copyright assignment? You will probably understand that Andy's past behavior (including blatant disregard for free-software licenses, Steve already told the story) might make me question the behavior of people associated with him, even though I feel very rude doing so, and even though you alrady expressed good intentions. I'd rather someone be rude and honest than quiet and polite. I can't say I really care about Andy's alleged copyright infringement. (My general point on matters like this is litigate or shut up. We're all here to get work done and licensing (licensing trolls and I don't mean you) is the single biggest detractor from open source progress I know of) Andy started the project and at the time of the fork still was the majority contributor. Cut the guy some slack for having a bit of ego and wanting to maintain control. It's been how many years now and still too much hard feelings. I'm biased but it's based on a positive working relationship. Please put in google open source ekopath or pathscale and see whose name and what news comes up. (In the past 2 years I've directly been responsible for open sourcing more code than a lot of people and moved PathScale to an entirely open development model for x86.) Now with that I'll play devil's advocate.. 1) What's wrong with commercial software? 2) What's wrong if we strip out your contributions (20 patches if I'm not mistaken) from g95 and use it in a closed commercial product? (See more comments below) There's a couple views I can imagine people will have 1) GNU/GPL - Using licensing to try to ensure contributions go back upstream. To me this works a majority of the time, but not always. (I think it varies on the project and circumstances. I have a personal laundry list of companies I'd like to force to give changes in public, but their products are so tightly controlled and I'm not a copyright holder so can't do a damn thing about it. Then again even if the changes were public they aren't likely going to get merged anywhere or be useful. So who has time to care at the end of the day. Would you believe I wanted PathScale to be open source before I ever worked here and was blocked...) 2) BSD - No comment 3) Fortran HPC community as a whole - The majority of Fortran users I know work in or around HPC. (I may be biased) With that I can't sa
Re: Original commit history for gfortran
On Sun, Jun 19, 2011 at 11:04:09PM +0700, "C. Bergstr?m" wrote: > > > I can't say I really care about Andy's alleged copyright infringement. > (My general point on matters like this is litigate or shut up. We're > all here to get work done and licensing (licensing trolls and I don't > mean you) is the single biggest detractor from open source progress I > know of) "Fool me once, shame on you; Fool me twice, shame on me" I think some of us are trying to avoid the latter half of the adage. > Andy started the project and at the time of the fork still was the > majority contributor. Perhaps, you need to read the Copyright notices in the trans-*.[ch] files. It was Paul Brook and Steven Bosscher who initially wrote the majority of the code that hooked Andy's parser up to the GCC middle and backend. cd gcc/fortran head trans-*.[ch] | grep -A1 Contribu | grep -v "\-\-" Contributed by Paul Brook and Steven Bosscher Contributed by Paul Brook Contributed by Canqun Yang Contributed by Paul Brook Contributed by Paul Brook Contributed by Paul Brook Contributed by Paul Brook and Steven Bosscher Contributed by Paul Brook and Steven Bosscher Contributed by Paul Brook Contributed by Jakub Jelinek Contributed by Paul Brook and Steven Bosscher Contributed by Paul Brook Contributed by Paul Brook and Steven Bosscher Contributed by Paul Brook and Steven Bosscher > Cut the guy some slack for having a bit of ego > and wanting to maintain control. It's been how many years now and still > too much hard feelings. I'm biased but it's based on a positive working > relationship. > (deleted rant) > If you have concerns about PathScale email me privately. My intention > is to vet the codebase. Vetting g95 is relatively easy, but there's a > chasm between it and gfortran I'm trying to map. If that's successful > I'd like to figure out if/how PathScale can contribute. if we continue > to get much more negatively this early on (I don't care the reason). > I'll just forget the whole thing. All of the code in gfortran is assigned to the FSF. Have you approached the FSF with a request to dual licenses the code? There are on the order of 100 contributors listed in the gcc/fortran/ChangeLog* files. Are you asking each individual to re-license his/her contribution to gfortran? -- Steve
Re: Original commit history for gfortran
2011/6/19 "C. Bergström" : > In this case I serve the end user/community and not directly open source. > Why? Would it be good for Fortran if a F2K3 front-end was freely available > under a commercially friendly license? (This is a deeper question I'd love > feedback on) From my point of view a freely available F2K compiler is the only hope for something like a "Fortran community" to keep exisiting (or even for the language itself to survive). Of course this does not mean at all that there is no space for high-quality commercial compilers. I even think that the commercial compiler vendors might profit from the existence of a freely available compiler. Note that right now we have barely *any* compiler which can claim to have a complete F2K implementation (though a few are quite close). Among the freely available ones, gfortran is surely the one which is closest. > a. I see people moving away from Fortran and more towards C++. (Sorry no > empirical data to back this, but how do we stop this trend) This is surely true. The only way to stop it is to provide a Fortran implementation of those features that make C++ so attractive (e.g. object orientation, etc). Such an implementation must be freely available and on the same quality level as, say, g++. > d. Would there be any negative impact to gfortran if PGI/Intel took the > front-end? (Or even worse PathScale *gasp*) What exactly do you mean by "taking" the front-end? > Not all commercial companies are bad (Redhat, Canonical.. etc). From my > perspective it's commercial companies that generally pay people to work full > time and get real engineering in open source done. Agreed. Another example being Google, which helped me a lot to contribute to gfortran (via several Summer of Code stipends). > If you have concerns about PathScale email me privately. My intention is to > vet the codebase. Vetting g95 is relatively easy, but there's a chasm > between it and gfortran I'm trying to map. If that's successful I'd like to > figure out if/how PathScale can contribute. if we continue to get much more > negatively this early on (I don't care the reason). I'll just forget the > whole thing. If you want this discussion to take a more positive direction, maybe you should try to explain your intentions a bit more clearly instead of making cloudy allusions. What exactly are you aiming for? Cheers, Janus
Re: Original commit history for gfortran
Hi Christopher, On 2011-06-18 14:39, "C. Bergström" wrote: On 06/18/11 05:16 PM, Toon Moene wrote: On 06/18/2011 12:12 PM, Toon Moene wrote: On 06/18/2011 05:05 AM, Christopher Bergström wrote: Hi We're in the process of considering contributing to gfortran for a special project, but when we started to vet the codebase we hit a bump in lack of commit history. Additional information is here: http://sourceforge.net/projects/gcc-g95 The above gives you the history after the split from the g95 project: http://sourceforge.net/projects/g95 in January 2003. The original commit by Paul Brook of the gcc-g95 repository contents to the GCC repository is here: http://gcc.gnu.org/ml/gcc-cvs/2003-07/msg01087.html So I converted the cvs repo to git so I could actually dig and compare a little better.. Here's an example of what we're trying to understand This file wasn't in g95, but then magically appears in Paul's initial commit. gcc/f95/arith.h # Unless I've messed up somewhere along my path.. # Was this file in gcc the whole time and just an external dep? I think the history of this particular change went like this: Steven Bosscher was concerned about making g95 more modular. Part of that process was splitting the big g95.h file into several parts -- that's where arith.h comes from. Another part of that endeavour was moving the various tree dumpers into dump-parse-tree.c -- which IMO defeated the original purpose of having them in their corresponding source files (namely documentation), but on the other hand made that part more self-contained. As for the history, there was another sourceforge project dedicated to g95 -> gcc integration bsides gcc-g95, its name escapes me right now. IIRC some of the I/O library was developed there. Between the closing of g95's tree and gcc-g95's launch some development happened in private trees as pointed out before, but apart from that and Andy's very initial work which happened without CVS, you should find all the history in public record. I'm sorry that I'm writing the following paragraph, but I think I should. I heard rumors that Andy was hired by Pathscale, so I'm a bit worried about your intentions. You're not trying to vet the code for the parts of the code which are available to relicensing to Pathscale for commerical exploitation, are you? That's something that may under very specific circumstances be allowed by the usual copyright assignment? You will probably understand that Andy's past behavior (including blatant disregard for free-software licenses, Steve already told the story) might make me question the behavior of people associated with him, even though I feel very rude doing so, and even though you alrady expressed good intentions. Cheers, - Tobi
Re: Original commit history for gfortran
Hi all, I'm sorry if I made this turn into a discussion of the benefits of Free Software, just two short points ... On 2011-06-19 18:58, Steve Kargl wrote: On Sun, Jun 19, 2011 at 11:04:09PM +0700, "C. Bergstr?m" wrote: Andy started the project and at the time of the fork still was the majority contributor. Perhaps, you need to read the Copyright notices in the trans-*.[ch] files. It was Paul Brook and Steven Bosscher who initially wrote the majority of the code that hooked Andy's parser up to the GCC middle and backend. Let's not forget GCC itself, which really is the biggest part of g95 (of course, there would probably have been a g95 without gcc, as there would have been another compiler backend, but there wouldn't have been a g95 without Andy). If you have concerns about PathScale email me privately. My intention is to vet the codebase. Vetting g95 is relatively easy, but there's a chasm between it and gfortran I'm trying to map. If that's successful I'd like to figure out if/how PathScale can contribute. if we continue to get much more negatively this early on (I don't care the reason). I'll just forget the whole thing. All of the code in gfortran is assigned to the FSF. Have you approached the FSF with a request to dual licenses the code? There are on the order of 100 contributors listed in the gcc/fortran/ChangeLog* files. Are you asking each individual to re-license his/her contribution to gfortran? Given Christopher's answer to my question, I think he wants to make sure that the code is REALLY assigned to the FSF so that his company doesn't run into troubles down the road. Cheers, - Tobi
Re: Original commit history for gfortran
On Mon, Jun 20, 2011 at 12:02 AM, Janus Weil wrote: > 2011/6/19 "C. Bergström" : >> In this case I serve the end user/community and not directly open source. >> Why? Would it be good for Fortran if a F2K3 front-end was freely available >> under a commercially friendly license? (This is a deeper question I'd love >> feedback on) > > From my point of view a freely available F2K compiler is the only hope > for something like a "Fortran community" to keep exisiting (or even > for the language itself to survive). Of course this does not mean at > all that there is no space for high-quality commercial compilers. I > even think that the commercial compiler vendors might profit from the > existence of a freely available compiler. > > Note that right now we have barely *any* compiler which can claim to > have a complete F2K implementation (though a few are quite close). > Among the freely available ones, gfortran is surely the one which is > closest. > > >> a. I see people moving away from Fortran and more towards C++. (Sorry no >> empirical data to back this, but how do we stop this trend) > > This is surely true. The only way to stop it is to provide a Fortran > implementation of those features that make C++ so attractive (e.g. > object orientation, etc). Such an implementation must be freely > available and on the same quality level as, say, g++. > > >> d. Would there be any negative impact to gfortran if PGI/Intel took the >> front-end? (Or even worse PathScale *gasp*) > > What exactly do you mean by "taking" the front-end? Above I was referring to a fortran front-end (like gfortran) being available under a more permissive license (BSD/MIT. etc) If that was true then it would be possible for a commercial compiler (PGI/Intel) to take the front-end and then just make it emit the IR needed. > > >> Not all commercial companies are bad (Redhat, Canonical.. etc). From my >> perspective it's commercial companies that generally pay people to work full >> time and get real engineering in open source done. > > Agreed. Another example being Google, which helped me a lot to > contribute to gfortran (via several Summer of Code stipends). Certainly not an exhaustive list :) > > >> If you have concerns about PathScale email me privately. My intention is to >> vet the codebase. Vetting g95 is relatively easy, but there's a chasm >> between it and gfortran I'm trying to map. If that's successful I'd like to >> figure out if/how PathScale can contribute. if we continue to get much more >> negatively this early on (I don't care the reason). I'll just forget the >> whole thing. > > If you want this discussion to take a more positive direction, maybe > you should try to explain your intentions a bit more clearly instead > of making cloudy allusions. What exactly are you aiming for? Nothing cloudy 1) Vet the codebase (stated this clearly) 2) Listen to what people say - (What needs to be worked on, are people open to things like dual licensing, what's the future of Fortran, etc..) For whatever reason someone at Apple has decided to work on "flang". I'm not sure if the code is public or even a serious effort at all. Apple certainly has the resources to toss at it, but outside of someone's personal hobby project I can only think of one reason to spend time on it. 1) Our goal (PathScale) is to implement F2K3/8 2) My personal goal is to advocate and push open source # Possibly more important than either of the two points above 3) I'd like to see a larger Fortran community grow out of gfortran. (This of course largely depends on if the contributors are more interested in keeping it locked up to gcc or increasing Fortran adoption.) btw - I appreciate the feedback and information from everyone so far.. Thanks
Re: PIE and FSF gcc
On Fri, Jun 17, 2011 at 07:30:43AM -0700, Ian Lance Taylor wrote: > Jack Howarth writes: > > > What is the current state of supporting hardened operating systems > > that default to -fpie/-fPIE/-pie in gcc trunk? Do those releases still use > > their own patches for gcc or has all of those changes been committed to gcc > > trunk? > > If so, does anyone recall the specific commits? In particular, I am > > interested > > in any fixes to boehm-gc, libffi and pch to support PIE. > > I know there are variants of gcc out there which default to -fPIE when > compiling and -pie when linking. As far as I know there is no support > for that in trunk, unless you count the --with-specs configure option > which may be used to implement these defaults. > > I don't see why -pie should make any difference for boehm-gc or libffi. > Is there some known problem with them? > > For PCH what matters is not whether gcc defaults to generating PIE, but > whether gcc itself is compiled as a PIE. In general I believe that a > PIE gcc will not support PCH--it will work most of the time, but will > occasionally fail. However, I have not actually tested this. If I'm > right about this limitation, it would be quite difficult to fix given > the current PCH implementation. Fortunately, as far as I can see, the > kind of attacks which PIE protects against are unimportant when > attacking gcc, as gcc simply runs under your own user ID on your own > system. Anything the user can somehow suborn gcc into doing, the user > can do anyhow. So I see no reason to build gcc as a PIE. Of course > those considerations would change if somebody is running a compilation > server on the net which invokes gcc; such a setup might get some small > benefit from building gcc as a PIE, but such a setup would be unlikely > to support PCH in any case. > > Ian Ian, I found some interesting information on what Gentoo Hardened Linux is doing with their toolchain here... http://www.gentoo.org/proj/en/hardened/hardened-toolchain.xml It appears that they consider JIT to be a major security risk and disable it by default... http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml#jitflag as well as passing... CFLAGS="-fPIE -fstack-protector-all -D_FORTIFY_SOURCE=2" LDFLAGS="-Wl,-z,now -Wl,-z,relro" automatically on builds. Also, apparently -O3 is considered problematic when SSP is in use. http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml#Othreessp Jack
Re: Original commit history for gfortran
On Sunday 19 June 2011 20:30:17 Christopher Bergström wrote: > Nothing cloudy > > 1) Vet the codebase (stated this clearly) > 2) Listen to what people say - (What needs to be worked on, are people > open to things like dual licensing, what's the future of Fortran, > etc..) > > For whatever reason someone at Apple has decided to work on "flang". > I'm not sure if the code is public or even a serious effort at all. > Apple certainly has the resources to toss at it, but outside of > someone's personal hobby project I can only think of one reason to > spend time on it. > > 1) Our goal (PathScale) is to implement F2K3/8 Why not extend the existing frontend? Is it in such a bad shape that rewriting a new IR generator is preferable? Is it g95 only that you plan to import or some of gfortran as well? I personally see no problem gfortran being reused in pathscale's compiler as long as pathscale's contribution is libre (free). It can even improve code quality to make gfortran backend independant (probably not much as the IR generation is quite separated already, but who knows?), and that would give us an open64 (this one is a "really free" compiler I think) backend at the same time. Not bad. Mikael
gcc-4.3-20110619 is now available
Snapshot gcc-4.3-20110619 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20110619/ 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 175193 You'll find: gcc-4.3-20110619.tar.bz2 Complete GCC MD5=d14aa47459f6755cff96bc4caffed0f6 SHA1=edde4a7bc724aa15177505c1a5672b4684f94e26 Diffs from 4.3-20110612 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: PIE and FSF gcc
Jack Howarth writes: > On Fri, Jun 17, 2011 at 07:30:43AM -0700, Ian Lance Taylor wrote: >> >> For PCH what matters is not whether gcc defaults to generating PIE, but >> whether gcc itself is compiled as a PIE. In general I believe that a >> PIE gcc will not support PCH--it will work most of the time, but will >> occasionally fail. However, I have not actually tested this. If I'm >> right about this limitation, it would be quite difficult to fix given >> the current PCH implementation. Fortunately, as far as I can see, the >> kind of attacks which PIE protects against are unimportant when >> attacking gcc, as gcc simply runs under your own user ID on your own >> system. Anything the user can somehow suborn gcc into doing, the user >> can do anyhow. So I see no reason to build gcc as a PIE. Of course >> those considerations would change if somebody is running a compilation >> server on the net which invokes gcc; such a setup might get some small >> benefit from building gcc as a PIE, but such a setup would be unlikely >> to support PCH in any case. > >I found some interesting information on what Gentoo Hardened Linux > is doing with their toolchain here... > > http://www.gentoo.org/proj/en/hardened/hardened-toolchain.xml > > It appears that they consider JIT to be a major security risk and disable it > by default... > > http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml#jitflag > > as well as passing... > > CFLAGS="-fPIE -fstack-protector-all -D_FORTIFY_SOURCE=2" LDFLAGS="-Wl,-z,now > -Wl,-z,relro" > > automatically on builds. Those web pages are about whether gcc defaults to generating PIE. As I said, for PCH what matters is whether gcc itself is compiled as a PIE. > Also, apparently -O3 is considered problematic when SSP is in use. > > http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml#Othreessp It would be interesting to find out what the problem is here. Ian
[GCC steering committee] I'd like to be maintainer for Linux/x86 platform
Hi GCC steering committee, Apparently, there is no GCC maintainer for Linux/x86 platform. I have been working on GCC, as well as binutils and C libraries, for Linux/x86 over 20 years. I ported GCC, binutils and the C library to Linux/x86. I like to be appointed as maintainer for Linux/x86 platform. Thanks for your time. -- H.J.
Re: PIE and FSF gcc
On 06/19/2011 04:26 PM, Ian Lance Taylor wrote: > Jack Howarth writes: > >> On Fri, Jun 17, 2011 at 07:30:43AM -0700, Ian Lance Taylor wrote: >>> >>> For PCH what matters is not whether gcc defaults to generating PIE, but >>> whether gcc itself is compiled as a PIE. In general I believe that a >>> PIE gcc will not support PCH--it will work most of the time, but will >>> occasionally fail. However, I have not actually tested this. If I'm >>> right about this limitation, it would be quite difficult to fix given >>> the current PCH implementation. Fortunately, as far as I can see, the >>> kind of attacks which PIE protects against are unimportant when >>> attacking gcc, as gcc simply runs under your own user ID on your own >>> system. Anything the user can somehow suborn gcc into doing, the user >>> can do anyhow. So I see no reason to build gcc as a PIE. Of course >>> those considerations would change if somebody is running a compilation >>> server on the net which invokes gcc; such a setup might get some small >>> benefit from building gcc as a PIE, but such a setup would be unlikely >>> to support PCH in any case. >> >>I found some interesting information on what Gentoo Hardened Linux >> is doing with their toolchain here... >> >> http://www.gentoo.org/proj/en/hardened/hardened-toolchain.xml >> >> It appears that they consider JIT to be a major security risk and disable it >> by default... >> >> http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml#jitflag >> >> as well as passing... >> >> CFLAGS="-fPIE -fstack-protector-all -D_FORTIFY_SOURCE=2" LDFLAGS="-Wl,-z,now >> -Wl,-z,relro" >> >> automatically on builds. > > Those web pages are about whether gcc defaults to generating PIE. As I > said, for PCH what matters is whether gcc itself is compiled as a PIE. Our gcc itself is PIE code. 'readelf -h /usr/bin/gcc | grep Type' gives Type: DYN (Shared object file) We have to disable PCH because it is broken as expected. The JIT issue is because of RWX mappings which are killed by our hardened kernel. PaX. > > >> Also, apparently -O3 is considered problematic when SSP is in use. >> >> http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml#Othreessp > > It would be interesting to find out what the problem is here. > > Ian I don't know what the problem is here but I have seen ssp break with -O3. I'd like to know too. -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197
Re: Original commit history for gfortran
"C. Bergström" writes: > 1) What's wrong with commercial software? I don't want to get into licensing fight, and I don't know anything about the history of the Fortran frontend, but I do want to suggest a correction to your wording. I'm not aware of any GCC contributor who thinks there is anything wrong with commercial software. You even mention commercial companies like Red Hat in your e-mail; Red Hat is a significant contributor to GCC, along with several other commercial companies. What many GCC contributors are concerned about is proprietary software, a completely different matter. Code released under the GPL may not be distributed in a proprietary manner. > 2) What's wrong if we strip out your contributions (20 patches if I'm > not mistaken) from g95 and use it in a closed commercial product? > (See more comments below) Nothing, if the g95 license permits it. The only g95 frontend I am aware of (g95.cvs.sourceforge.net) is distributed under the GPL and is copyright FSF, and as such would only permit this if you were able to identify each original author and get their agreement to distribute the code under another license. > There's a couple views I can imagine people will have I can imagine several more, but it's kind of irrelevant with respect to the g95 frontend in particular. That code is under whatever license it is under. > If you have concerns about PathScale email me privately. My intention > is to vet the codebase. Vetting g95 is relatively easy, but there's a > chasm between it and gfortran I'm trying to map. If that's successful > I'd like to figure out if/how PathScale can contribute. if we > continue to get much more negatively this early on (I don't care the > reason). I'll just forget the whole thing. You asked specifically about arith.h. arith.h is not present in the g95 sourceforge repository. It is present in the gcc-g95 repository. The gcc-g95 repository was created January 6, 2003. Looking at the revision of g95.h in the g95 repository immediately prior to that date, revision 1.212 commited January 3, 2003, it is evident that arith.h in the gcc-g95 repository was created by simply moving some lines from g95.h to arith.h. That explains why the copyright date of arith.h is what it is: it reflects the copyright date of g95.h. Since this is a simple copy of information from one file to another, there are no copyright issues here. It would have been cleaner if Paul had started with an exact extract of the g95 repository when he created the g95-gcc repository, but evidently he did not. I skimmed the changes between the g95 repository dated January 1, 2003 and the gcc-g95 repository revision 1.1. There are many whitespace and formatting changes, and a bit of code motion, all to change the code to conform to the GNU coding standards. I saw no substantitive changes which would affect the copyright status; however, I didn't examine the entire diff closely. Perhaps if you identify other specific concerns we can allay or corroborate them. Ian
Backport new -mflat support for SPARC to 4.6 branch
Dear RMs, I'd like to have permission to backport the new -mflat support for SPARC from the mainline to the 4.6 branch. I received the first requests to reinstate the option last year, when Laurent (and some others) started to work on it, but the initial patch was submitted too late in the 4.6 development cycle, due to technical and administrative issues. I nevertheless think that it would be too bad to postpone its availabilty by another full year. The bulk of the changes are to the SPARC back-end, but there are a few minor adjustments to the generic RTL code, namely 3 one-liners to builtins.c, cse.c and postreload-gcse.c. I think that the risk for non-SPARC targets is nearly null (and is acceptable for the SPARC port at this point in the 4.6 cycle). The patch has already been written and tested on the branch (on x86/Linux, SPARC/Solaris and SPARC64/Solaris) so it could be applied immediately. The patches from mainline it is made up of are listed at the end of the message. Can I proceed with the backport? 2011-06-10 Eric Botcazou Laurent Rougé * doc/invoke.texi (SPARC options): Add -mflat. * config/sparc/sparc.opt: Likewise. * config/sparc/sparc-protos.h (sparc_expand_epilogue): Add parameter. (sparc_flat_expand_prologue): Declare. (sparc_flat_expand_epilogue): Likewise. * config/sparc/sparc.h (CPP_CPU_SPEC): Do not handle -msoft-float. (CPP_ENDIAN_SPEC): Replace with... (CPP_OTHER_SPEC): ...this. Also handle -mflat and -msoft-float. (CPP_SPEC): Adjust to above change. (EXTRA_SPECS): Likewise. (SPARC_INCOMING_INT_ARG_FIRST): Add TARGET_FLAT handling. (INCOMING_REGNO): Likewise. (OUTGOING_REGNO): Likewise. (LOCAL_REGNO): Likewise. (SETUP_FRAME_ADDRESSES): Likewise. (FIXED_REGISTERS): Set 0 for %fp. (CALL_USED_REGISTERS): Likewise. (INITIAL_ELIMINATION_OFFSET): Pass current_function_is_leaf. (EXIT_IGNORE_STACK): Define to 1 unconditionally. (RETURN_ADDR_REGNUM): Define. (RETURN_ADDR_RTX): Use it. (INCOMING_RETURN_ADDR_REGNUM): Define. (INCOMING_RETURN_ADDR_RTX): Use it. (DWARF_FRAME_RETURN_COLUMN): Likewise. (EH_RETURN_REGNUM): Define. (EH_RETURN_STACKADJ_RTX): Use it. (EH_RETURN_HANDLER_RTX): Delete. (EPILOGUE_USES): Use them and add TARGET_FLAT handling. * config/sparc/sparc.c (apparent_fsize, actual_fsize, num_gfregs): Delete. (struct machine_function): Add frame_size, apparent_frame_size, frame_base_reg, frame_base_offset, n_global_fp_regs and save_local_in_regs_p fields. (sparc_frame_size, sparc_apparent_frame_size, sparc_frame_base_reg, sparc_frame_base_offset, sparc_n_global_fp_regs, sparc_save_local_in_regs_p): New macros. (sparc_option_override): Error out if -fcall-saved-REG is specified for Out registers. (eligible_for_restore_insn): Fix formatting. (eligible_for_return_delay): Likewise. Add TARGET_FLAT handling. (eligible_for_sibcall_delay): Likewise. (RTX_OK_FOR_OFFSET_P, RTX_OK_FOR_OLO10_P): Add MODE parameter. (sparc_legitimate_address_p): Adjust to above change. (save_global_or_fp_reg_p): New predicate. (return_addr_reg_needed_p): Likewise. (save_local_or_in_reg_p): Likewise. (sparc_compute_frame_size): Use them. Add TARGET_FLAT handling. (SORR_SAVE, SORR_RESTORE): Delete. (sorr_pred_t): New typedef. (sorr_act_t): New enum. (save_or_restore_regs): Rename to... (emit_save_or_restore_regs): ...this. Change type of LOW and HIGH parameters, remove ACTION parameter, add LEAF_FUNCTION_P, SAVE_P, ACTION_TRUE and ACTION_FALSE parameters. Implement more general mechanism. Add CFI information for double-word saves in 32-bit mode. (emit_adjust_base_to_offset): New function extracted from... (emit_save_or_restore_regs): ...this. Rename the rest to... (emit_save_or_restore_regs_global_fp_regs): ...this. (emit_save_or_restore_regs_local_in_regs): New function. (gen_create_flat_frame_[123]): New functions. (sparc_expand_prologue): Use SIZE local variable. Adjust. (sparc_flat_expand_prologue): New function. (sparc_asm_function_prologue): Add TARGET_FLAT handling. (sparc_expand_epilogue): Use SIZE local variable. Adjust. (sparc_flat_expand_epilogue): New function. (sparc_can_use_return_insn_p): Add TARGET_FLAT handling. (output_return): Likewise. (output_sibcall): Likewise. (sparc_output_mi_thunk): Likewise. (sparc_frame_pointer_required): Likewise. (sparc_conditional_register_usage): If TARGET_FLAT, disable the leaf function optimization. * config/sparc/sparc.md (flat): New attribute.
Re: Original commit history for gfortran
On Sun, 19 Jun 2011 21:32:25 +0200, "Mikael Morin" wrote: > I personally see no problem gfortran being reused in pathscale's compiler as > long as pathscale's contribution is libre (free). It can even improve code > quality to make gfortran backend independant (probably not much as the IR > generation is quite separated already, but who knows?), and that would give us > an open64 (this one is a "really free" compiler I think) backend at the same > time. Not bad. Be careful, open64 is not completely "libre". The license is GPLv2 with a funny special remark about intellectual property licenses: "Further, this software is distributed without any warranty that it is free of the rightful claim of any third person regarding infringement or the like. Any license provided herein, whether implied or otherwise, applies only to this software file. Patent licenses, if any, provided herein do not apply to combinations of this program with other software, or any other product whatsoever." Whether this extra clause is a valid addition, I don't know. Not a lawyer, etc. But I'd bet a box of wine of a good vintage that this is incompatible with GPLv3 that is the current license for gfortran. If so, you can't glue a recent gfortran on top of the open64/pathscale/Rice/... back end. Back porting gfortran code into an older, GPLv2 licensed g95 is also not possible without permission from the FSF. On Mon, 20 Jun 2011 01:30:17 +0700, Christopher Bergström wrote: > # Possibly more important than either of the two points above > 3) I'd like to see a larger Fortran community grow out of gfortran. > (This of course largely depends on if the contributors are more > interested in keeping it locked up to gcc or increasing Fortran > adoption.) It is not a question of personal interests and "keeping it locked up". You make it sound as if gfortran contributors are blocking your Bigger Plan for the Fortran community. Reality is that gfortran has helped ensure that this community still exists at all. Gfortran is largely the result of quite altruistic behavior of engineers and scientists with little or no background in computer science to work around "you guys" commercial compiler vendors. So please don't come here insinuating that gfortran contributors put their own interests before that of the Fortran community. Had you put the Cray front end out on a BSD license or donated it to the FSF, instead of locking it up behind a shady modified GPLv2, then there wouldn't even have been a need for a completely new GNU Fortran front end. Contributors to gfortran agree to assign copyright for their contributions to the FSF in exchange for a perpetual license to do as they see fit with their own contributions (including re-licensing to 3rd a party). What you seem to be asking for, is that all gfortran contributors are tracked and that they all agree to re-license their contributions under a license that suits your needs. For what it's worth, I have absolutely no intention to do so. I find the whole idea offensive, especially given the history of Pathscale and of g95. Ciao! Steven
[Take 2] Help with specifying processor pipeline GCC4.5.1
Hello All, I need some help with setting the pipeline hazard recognizer (I am working with gcc v4.5.1 for a private target). A brief pipeline description of my target: We have 2 functional units 1) For multiplication. 2) For All other instructions. a) Multiply instructions are not pipelined. b) It takes 4 cycles to execute a multiply instruction. c) The result of multiply instruction will be available after 4 cycles. So there should be a 4 cycle gap between 2 multiply instructions (independent/dependent) and also its depend instructions (other than multiply). e.g.1: mult R3, R4, R5 -- (A) add R0, R1, R2 mult R7, R8, R9 -- (B) A) & (B) are independent. This is a pipeline error. Need to add 2 NOP's or schedule 2 other independent instructions before (B). e.g.2: mult R3, R4, R5 --(A) add R7, R8, R9 add R5, R1, R2 --(B) (A) & (B) are dependent. Even though there is no pipeline error, the value of "R5" used will not be the updated one as 'mult' takes 4 cycles for the result to be available. Need to add 2 NOP's or schedule 2 other independent instructions before (B). I have done the following, but not sure if this will take care of: A) 4 cycle gap between 2 Independent multiply instructions B) 4 cycle gap beween multiply and any other dependent instruction. (define_automaton "pipeline") (define_cpu_unit "simple" "pipeline") (define_cpu_unit "mult" "pipeline") (define_insn_reservation "any_insn" 1 (eq_attr "type" "!mul") "simple") (define_insn_reservation "mult" 4 (eq_attr "type" "mul") "mult*4") In case other independent instructions are not available to be scheduled for this latency, i will be inserting NOP's from the backend. But i want to make sure the correct info is passed to the scheduler. Any comments/suggestions? Thanks, Rohit
