Re: GCC 4.4.0 Status Report (2009-03-13)
On Mon, Mar 23, 2009 at 2:32 AM, Joe Buck wrote: > one. RMS wanted to have gcc use machines administered by the FSF; we > pushed back. gcc.gnu.org is sourceware.org. We did agree that we A little off-topic, but why *is* gcc on sourceware.org?
Re: GCC 4.4.0 Status Report (2009-03-13)
On Mon, Mar 23, 2009 at 2:38 AM, Joe Buck wrote: > GCC uses are the ones developed in the egcs days. Remember the old > days when the location of the development tree and the snapshots was > a secret, and people were threatened with banning if they let it out? Are you serious? Why would it be handled that way?
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 08:17:42AM -0700, Richard Kenner wrote: > > It was my understanding that it was a compromise, but the > > EGCS community retains all rights to make technical > > decisions without disruptive interferences from FSF > > Your understanding is incorrect. Independence from the FSF was never an > issue. Well, not quite. We talked about that a lot when we were trying to put things back together. We asked for a degree of independence, which really meant that the FSF would trust the GCC developers to do things right, and not to micromanage, and that the GCC developers would follow free software principles. Brad Kuhn said something to the effect that he considered RMS the expert when it came to promoting the idea of free software, but on technical matters RMS is just another developer.
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 08:08:38AM -0700, Gabriel Dos Reis wrote: > It was my understanding that it was a compromise, but the > EGCS community retains all rights to make technical > decisions without disruptive interferences from FSF And that's pretty much the way it's worked. RMS objected to using bugzilla; we use bugzilla. RMS objected to switching to subversion. RMS argued against independent administration of gcc.gnu.org. RMS doesn't hang out on the gcc list trying to micromanage everything. The maintainers are in charge of their areas; Mark and his team are in charge of releases. And the day-to-day development practices GCC uses are the ones developed in the egcs days. Remember the old days when the location of the development tree and the snapshots was a secret, and people were threatened with banning if they let it out? I do think that RMS overstepped the line that we had set up when he told us to hold off on creating a release branch. That was unprecedented interference.
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 05:47:52AM -0700, Daniel Berlin wrote: > Let's see, just in the somewhat recent past: > Writing out the IL > Plugins > Changing over the bug system > Hosting on sourceware.org > Moving to subversion You're mixing a number of things together here, some of which seem to argue against your point. RMS said he didn't want gcc to move to subversion; gcc moved to subversion anyway. He didn't prevail on that one. RMS wanted to have gcc use machines administered by the FSF; we pushed back. gcc.gnu.org is sourceware.org. We did agree that we wouldn't do things that the FSF considers objectionable on gcc.gnu.org, like link to pages that promote proprietary software. But that's no big deal. RMS didn't want us to use bugzilla; we insisted. We use bugzilla. So on purely technical matters, often RMS did not get his way. We did let him get his way on his fears about writing out the IL, and plugins, but we didn't like it, so we worked out a compromise, the runtime exception language (thanks, David Edelsohn for all your work on this). Now that compromise has taken much much longer than we'd like to get right, hence the current holdup.
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 9:00 PM, Dave Korn wrote: > Gabriel Dos Reis wrote: >> On Sun, Mar 22, 2009 at 7:54 PM, Ben Elliston wrote: >>> On Sun, 2009-03-22 at 18:30 -0500, Gabriel Dos Reis wrote: >>> And there certainly are successful projects using a subset of C++ too. Whether you have not seen them is, well, a different matter :-) >>> I could well even be using such software--I'm just not aware of it. :-) >> >> Interesting. >> >>> Can you give some indication of how the subset is enforced? >>> >> >> so, now we must discuss the police as opposed to the >> successful projects. > > I read that as "the development methodology", not "the police". I'm sure a genuine interest in the topic may start with successful projects such as llvm, or mozilla, or mysql, with guidelines and methodologies published online. http://llvm.org/docs/CodingStandards.html https://developer.mozilla.org/En/C___Portability_Guide http://forge.mysql.com/wiki/MySQL_Internals_Coding_Guidelines I don't agree with everything they say, but anybody genuinely interested can find them with just a few keystrokes and one click. http://www.research.att.com/~bs/applications.html -- Gaby
Re: GCC 4.4.0 Status Report (2009-03-13)
Gabriel Dos Reis wrote: > On Sun, Mar 22, 2009 at 7:54 PM, Ben Elliston wrote: >> On Sun, 2009-03-22 at 18:30 -0500, Gabriel Dos Reis wrote: >> >>> And there certainly are successful projects using a subset of C++ too. >>> Whether you have not seen them is, well, a different matter :-) >> I could well even be using such software--I'm just not aware of it. :-) > > Interesting. > >> Can you give some indication of how the subset is enforced? >> > > so, now we must discuss the police as opposed to the > successful projects. I read that as "the development methodology", not "the police". cheers, DaveK
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 7:54 PM, Ben Elliston wrote: > On Sun, 2009-03-22 at 18:30 -0500, Gabriel Dos Reis wrote: > >> And there certainly are successful projects using a subset of C++ too. >> Whether you have not seen them is, well, a different matter :-) > > I could well even be using such software--I'm just not aware of it. :-) Interesting. > > Can you give some indication of how the subset is enforced? > so, now we must discuss the police as opposed to the successful projects. -- Gaby
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, 2009-03-22 at 18:30 -0500, Gabriel Dos Reis wrote: > And there certainly are successful projects using a subset of C++ too. > Whether you have not seen them is, well, a different matter :-) I could well even be using such software--I'm just not aware of it. :-) Can you give some indication of how the subset is enforced? Ben
Re: GCC 4.4.0 Status Report (2009-03-13)
On Mar 22, 2009, at 3:38 PM, Jeff Law wrote: Steven Bosscher wrote: On Sun, Mar 22, 2009 at 4:05 PM, Jeff Law wrote: I think you're wrong. Many of these players are large companies (such as IBM and now, RedHat). Putting them in the position of having to "reject" the official FSF contribution is awkward for them. I'm sorry, but I don't see it that way. Having been on the front lines on this issue in the past, I can say our customers certainly cared about it and therefore we (Cygnus, now Red Hat) care about it. Perhaps it was true more 12 years ago than today. The whole idea of FOSS is probably better understood than 12 years ago. At least, projects like Linux and LLVM attract contributions from large companies without involvement of the FSF. These companies really don't care about FOSS in the same way GCC developers do. I'd be highly confident that this would still be a serious issue for the majority of the companies I've interacted with through the years. Hi Jeff, Can you please explain the differences you see between how GCC developers and other people think about FOSS? I'm curious about your perception here, and what basis it is grounded on. Thanks, -Chris
Re: Playing with gcc-testresult results
On Mon, 2009-03-23 at 10:22 +1100, Ben Elliston wrote: > On Sat, 2009-03-21 at 18:09 +0100, Steven Bosscher wrote: > > > Interestingly, the results show that no compiler has more test results > > posted than GCC 4.4.0, which hasn't even been released yet! It looks > > like there are many results from ia64 and x86_64 automatic testers > > these days. Also interesting is that some of the primary targets have > > almost no posted test results :-( > > Perhaps we need to reassess the list of primary targets, then? The GCC Compile Farm project accepts hardware + OS licences and hosting donations :). Laurent http://gcc.gnu.org/wiki/CompileFarm
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 6:11 PM, Ben Elliston wrote: > On Sun, 2009-03-22 at 17:43 -0500, Gabriel Dos Reis wrote: > >> Well, the request was not about the full gamut of C++, but rather >> a subset. And the time of the discussion, I thought the subset >> was quite conservative. Every programming language can >> be abused -- and I don't think I've made an exception for C++. > > GCC would not be the first project (free, or proprietary) that I have > seen attempt to use a subset of C++. I don't think I've ever seen this > succeed. Inevitably, use of certain features crawl in when there is no > cleaner way to achieve something and then precedent can be used as an > argument for further use. And there certainly are successful projects using a subset of C++ too. Whether you have not seen them is, well, a different matter :-) -- Gaby
Re: Playing with gcc-testresult results
On Sat, 2009-03-21 at 18:09 +0100, Steven Bosscher wrote: > Interestingly, the results show that no compiler has more test results > posted than GCC 4.4.0, which hasn't even been released yet! It looks > like there are many results from ia64 and x86_64 automatic testers > these days. Also interesting is that some of the primary targets have > almost no posted test results :-( Perhaps we need to reassess the list of primary targets, then? Cheers, Ben
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, 2009-03-22 at 17:43 -0500, Gabriel Dos Reis wrote: > Well, the request was not about the full gamut of C++, but rather > a subset. And the time of the discussion, I thought the subset > was quite conservative. Every programming language can > be abused -- and I don't think I've made an exception for C++. GCC would not be the first project (free, or proprietary) that I have seen attempt to use a subset of C++. I don't think I've ever seen this succeed. Inevitably, use of certain features crawl in when there is no cleaner way to achieve something and then precedent can be used as an argument for further use. I'm a bit sceptical. Ben
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 7:01 PM, Daniel Berlin wrote: > On Sun, Mar 22, 2009 at 6:47 PM, Jeff Law wrote: >> Richard Kenner wrote: Of course, just I (and others) don't see why they should do it in this case. Delaying a *branch* is different from, say, using a proprietary version control or bug tracking system. >>> >>> I don't either. Requesting a delay of a *release* on a license issue >>> is completely and perfectly understandable, but what that has to do >>> with making a *branch* makes absolutely no sense to me. >>> >> >> Agreed. I'll note nobody has really argued that delaying a branch to deal >> with a license issue makes any sense. The FSF itself hasn't even stated >> reasons for their stance. That may simply be because the issue is expected >> to be moot after the weekend meetings. >> >> What I find most distressing about this whole discussion is the fact that we >> have developers who don't seem to grasp that the FSF owns the copyright to >> GCC and we are effectively volunteering to work in the FSF's sandbox under >> certain rules and guidelines set forth by the FSF. > > Maybe this is because every piece of documentation on the GCC project > says otherwise? > Also, do you not realize this is precisely because of the massive lack of transparency about how the project is governed? Do you guys realize that governing like this is in fact, destroying our community (how fast is a question people disagree about)?
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 6:47 PM, Jeff Law wrote: > Richard Kenner wrote: >>> >>> Of course, just I (and others) don't see why they should do it in this >>> case. Delaying a *branch* is different from, say, using a proprietary >>> version control or bug tracking system. >>> >> >> I don't either. Requesting a delay of a *release* on a license issue >> is completely and perfectly understandable, but what that has to do >> with making a *branch* makes absolutely no sense to me. >> > > Agreed. I'll note nobody has really argued that delaying a branch to deal > with a license issue makes any sense. The FSF itself hasn't even stated > reasons for their stance. That may simply be because the issue is expected > to be moot after the weekend meetings. > > What I find most distressing about this whole discussion is the fact that we > have developers who don't seem to grasp that the FSF owns the copyright to > GCC and we are effectively volunteering to work in the FSF's sandbox under > certain rules and guidelines set forth by the FSF. Maybe this is because every piece of documentation on the GCC project says otherwise?
Re: GCC 4.4.0 Status Report (2009-03-13)
Gabriel Dos Reis wrote: On Sun, Mar 22, 2009 at 5:37 PM, Jeff Law wrote: So what if the FSF hadn't accepted the reality of the day, and had decided to let egcs *not* be the official GCC? Would you have pulled the plug on egcs and gone back to the cathedral? Personally, I would have continued to put my effort into EGCS. Obviously, I can't speak for other developers specifically, I believe if you compared overall developer participation in the projects, it was clear that EGCS was more viable. yes -- and some of us got into GCC, precisely thanks to the open development of EGCS. That's good to hear. FWIW, I don't think we're anywhere near the same kind of tipping point we faced a dozen years ago. I believe both sides learned lessons along the way and I actually see evidence of that in the simple fact that we've got a license and blessing to go forward with a plugin framework. Jeff
Re: GCC 4.4.0 Status Report (2009-03-13)
Richard Kenner wrote: Of course, just I (and others) don't see why they should do it in this case. Delaying a *branch* is different from, say, using a proprietary version control or bug tracking system. I don't either. Requesting a delay of a *release* on a license issue is completely and perfectly understandable, but what that has to do with making a *branch* makes absolutely no sense to me. Agreed. I'll note nobody has really argued that delaying a branch to deal with a license issue makes any sense. The FSF itself hasn't even stated reasons for their stance. That may simply be because the issue is expected to be moot after the weekend meetings. What I find most distressing about this whole discussion is the fact that we have developers who don't seem to grasp that the FSF owns the copyright to GCC and we are effectively volunteering to work in the FSF's sandbox under certain rules and guidelines set forth by the FSF. Jeff
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 5:37 PM, Jeff Law wrote: >> So what if the FSF hadn't accepted the reality of the day, and had >> decided to let egcs *not* be the official GCC? Would you have pulled >> the plug on egcs and gone back to the cathedral? >> > > Personally, I would have continued to put my effort into EGCS. Obviously, I > can't speak for other developers specifically, I believe if you compared > overall developer participation in the projects, it was clear that EGCS was > more viable. yes -- and some of us got into GCC, precisely thanks to the open development of EGCS. -- Gaby
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 5:34 PM, Jeff Law wrote: > Gabriel Dos Reis wrote: >> >> On Sun, Mar 22, 2009 at 12:44 PM, Richard Kenner >> wrote: >> > > Yes, I would mind, because it's not MY issue, but RMS's! I don't want > to speculate why RMS might not want to use C++ > That is non argument: RMS has not not contributed any executable code for GCC, and even less the C++ front-end, for YEARS now. >>> >>> What does that have to do with expressing philosophical beliefs about how >>> software development should be done? >>> >> >> You asserted >> >> I don't want to speculate why RMS might not want to use C++ >> >> ^^ >> >> But, in this case the users of C++ would be the GCC developers. >> Those are the ones directly suffering the handcuffs. >> > > I wouldn't generalize things that broadly -- not everyone sees C++ in a > positive light. I'm fully aware of that. > Personally I see things in C++ I like, but I also see > things in C++ (and more specifically how it's commonly used) that I think is > horribly bad. Well, the request was not about the full gamut of C++, but rather a subset. And the time of the discussion, I thought the subset was quite conservative. Every programming language can be abused -- and I don't think I've made an exception for C++. -- Gaby
Re: GCC 4.4.0 Status Report (2009-03-13)
Steven Bosscher wrote: On Sun, Mar 22, 2009 at 4:05 PM, Jeff Law wrote: I think you're wrong. Many of these players are large companies (such as IBM and now, RedHat). Putting them in the position of having to "reject" the official FSF contribution is awkward for them. I'm sorry, but I don't see it that way. Having been on the front lines on this issue in the past, I can say our customers certainly cared about it and therefore we (Cygnus, now Red Hat) care about it. Perhaps it was true more 12 years ago than today. The whole idea of FOSS is probably better understood than 12 years ago. At least, projects like Linux and LLVM attract contributions from large companies without involvement of the FSF. These companies really don't care about FOSS in the same way GCC developers do. I'd be highly confident that this would still be a serious issue for the majority of the companies I've interacted with through the years. jeff
Re: GCC 4.4.0 Status Report (2009-03-13)
Steven Bosscher wrote: On Sun, Mar 22, 2009 at 3:50 PM, Joel Sherrill wrote: EGCS was an experiment in development methodologies that was intended to open up gcc. And a lot of good was done: CVS, GNAT, etc. Then egcs folded back into gcc, and we had discussions over SVN and Bugzilla. The restrictions the FSF imposes on GCC (or rather ironically, the lack of freedom) are one of the main reasons why GCC still doesn't have a proper distributed distributed version control system. So much for advancing to newer development methodologies... I strongly believe we would have had the same discussions WRT SVN & bugzilla with or without FSF involvement in the project. I switch in source control and bug tracking systems for a project of this size without due consideration would be dumb. So what if the FSF hadn't accepted the reality of the day, and had decided to let egcs *not* be the official GCC? Would you have pulled the plug on egcs and gone back to the cathedral? Personally, I would have continued to put my effort into EGCS. Obviously, I can't speak for other developers specifically, I believe if you compared overall developer participation in the projects, it was clear that EGCS was more viable. jeff
Re: GCC 4.4.0 Status Report (2009-03-13)
Gabriel Dos Reis wrote: On Sun, Mar 22, 2009 at 12:44 PM, Richard Kenner wrote: Yes, I would mind, because it's not MY issue, but RMS's! I don't want to speculate why RMS might not want to use C++ That is non argument: RMS has not not contributed any executable code for GCC, and even less the C++ front-end, for YEARS now. What does that have to do with expressing philosophical beliefs about how software development should be done? You asserted I don't want to speculate why RMS might not want to use C++ ^^ But, in this case the users of C++ would be the GCC developers. Those are the ones directly suffering the handcuffs. I wouldn't generalize things that broadly -- not everyone sees C++ in a positive light. Personally I see things in C++ I like, but I also see things in C++ (and more specifically how it's commonly used) that I think is horribly bad. Jeff
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 4:08 PM, Steven Bosscher wrote: > On Sun, Mar 22, 2009 at 5:52 PM, Gabriel Dos Reis > wrote: >> On Sun, Mar 22, 2009 at 11:54 AM, Richard Kenner >> wrote: Yes, surely you have heard of stonewalling use of C++ to directly express some of the abstractions we use in the compiler. >>> >>> Those are hardly detailed technical issues, >> >> So, from your perspective, a request >> >> to use (a subset of) C++ for compiling GCC >> >> is hardly detailed technical issue. > > Well... The language to write your software in is not really a detail, > but it's certainly a technical issue. yes, I do think the choice of language is NOT a detail -- and I do not understand that "detailed" means "just a detail". > > But anyway, is the official position of the FSF still "thou shall use > not C++"? That would mean GNU binutils is in violation with gold, no? Well, I hope someone would come and explain why an efficiency factor of more than "5" is something that should be dismissed because the software was originally written in C, but has now been written in C++. -- Gaby
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, 22 Mar 2009, Steven Bosscher wrote: > On Sun, Mar 22, 2009 at 5:52 PM, Gabriel Dos Reis > wrote: > > On Sun, Mar 22, 2009 at 11:54 AM, Richard Kenner > > wrote: > >>> Yes, surely you have heard of stonewalling use of C++ to directly > >>> express some of the abstractions we use in the compiler. > >> > >> Those are hardly detailed technical issues, > > > > So, from your perspective, a request > > > > to use (a subset of) C++ for compiling GCC > > > > is hardly detailed technical issue. > > Well... The language to write your software in is not really a detail, > but it's certainly a technical issue. > > But anyway, is the official position of the FSF still "thou shall use > not C++"? That would mean GNU binutils is in violation with gold, no? The GNU Coding Standards express a strong preference for C, but the GNU Coding Standards are treated as guidelines for GCC, to be followed unless we have good technical reasons to do otherwise. When we do, we do not seek FSF or SC permission in each case, just consensus among the developers. Following the GNU Coding Standards is not part of the Mission Statement so would not be grounds for a veto; the FSF would need to explain why "Supporting the goals of the GNU project, as defined by the FSF." requires using C to veto C++ if a technical consensus arises to use C++ (or some other reason why a veto doesn't violate "Patches will be considered equally based on their technical merits."). -- Joseph S. Myers jos...@codesourcery.com
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, 22 Mar 2009, Steven Bosscher wrote: > On Sun, Mar 22, 2009 at 5:52 PM, Gabriel Dos Reis > wrote: > > On Sun, Mar 22, 2009 at 11:54 AM, Richard Kenner > > wrote: > >>> Yes, surely you have heard of stonewalling use of C++ to directly > >>> express some of the abstractions we use in the compiler. > >> > >> Those are hardly detailed technical issues, > > > > So, from your perspective, a request > > > > to use (a subset of) C++ for compiling GCC > > > > is hardly detailed technical issue. > > Well... The language to write your software in is not really a detail, > but it's certainly a technical issue. > > But anyway, is the official position of the FSF still "thou shall use > not C++"? That would mean GNU binutils is in violation with gold, no? Probably people were clever enough not to ask the FSF about this ;) Richard.
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 5:52 PM, Gabriel Dos Reis wrote: > On Sun, Mar 22, 2009 at 11:54 AM, Richard Kenner > wrote: >>> Yes, surely you have heard of stonewalling use of C++ to directly >>> express some of the abstractions we use in the compiler. >> >> Those are hardly detailed technical issues, > > So, from your perspective, a request > > to use (a subset of) C++ for compiling GCC > > is hardly detailed technical issue. Well... The language to write your software in is not really a detail, but it's certainly a technical issue. But anyway, is the official position of the FSF still "thou shall use not C++"? That would mean GNU binutils is in violation with gold, no? Ciao! Steven
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 4:05 PM, Jeff Law wrote: >>> I think you're wrong. Many of these players are large companies (such >>> as IBM and now, RedHat). Putting them in the position of having to >>> "reject" the official FSF contribution is awkward for them. >>> >> >> I'm sorry, but I don't see it that way. >> > > Having been on the front lines on this issue in the past, I can say our > customers certainly cared about it and therefore we (Cygnus, now Red Hat) > care about it. Perhaps it was true more 12 years ago than today. The whole idea of FOSS is probably better understood than 12 years ago. At least, projects like Linux and LLVM attract contributions from large companies without involvement of the FSF. Ciao! Steven
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 3:50 PM, Joel Sherrill wrote: > EGCS was an experiment in development methodologies > that was intended to open up gcc. And a lot of good was done: CVS, GNAT, etc. Then egcs folded back into gcc, and we had discussions over SVN and Bugzilla. The restrictions the FSF imposes on GCC (or rather ironically, the lack of freedom) are one of the main reasons why GCC still doesn't have a proper distributed distributed version control system. So much for advancing to newer development methodologies... > If successful, > the goal was to move from being a fork to being > the main GCC FSF development. There was never any > intention of becoming a non-FSF fork. So what if the FSF hadn't accepted the reality of the day, and had decided to let egcs *not* be the official GCC? Would you have pulled the plug on egcs and gone back to the cathedral? Ciao! Steven
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 1:14 PM, Richard Kenner wrote: >> Many of the contributors worked (and still work) for organizations >> that compete with each other: if there weren't some nonprofit with >> legal ownership of the code one would have had to be invented. > > I think this is an important point, and one that many developers have > forgotten about: GCC is not just a volunteer effort, but one that involves > a lot of companies, who are often competitors. These companies can only > legally work together on a project under certain conditions, and the > existence of the FSF who owns the code is one of the ways (and the best > way) that can be done. There are many corporate-sponsored projects out there that do just as well, if not better, without the "help" of the FSF. Linux itself is the most prominent example. There, competing companies get along Just Fine without involvement of *any* pre-set conditions or legal frameworks other than a Free license. I think it is members of the GCC community (especially some of the older) ones who like to forget that. > Given the universality of GCC nowadays, the risk of > anti-trust law being invoked on its development should be more than a > theoretical concern. Say what?? Ciao! Steven
Re: GCC 4.4.0 Status Report (2009-03-13)
What's the evidence to the contrary? When else has the FSF made a request that affects *development* as opposed to a release (other than licensing and issues affecting the principle of free software, which everybody agrees they have a right to)? i386-unknown-lignux ; this broke unified tree builds since gcc wouldn't agree with binutils and newlib on the configuration. i386-pc-linux-gnu made it worse from a functionality standpoint because suddenly we went from host/target triplets to host/target quadruplets. i386-pc-linux_gnu would have fit much better in the old scheme. But the main issue back then was really the lack of coordination with other projects and the lack of a staged transition plan.
Re: cmath call builtin sqrtf but many platforms seem miss that(was Re: lrint lrintf problems )
Hallo Gunther Am 22.03.09 schriebst Du > How about using the original C-library of your system together with its > headers? After all the version you are currently using is an "alien" and without changed headers old ompiler and libs do not work, because for C there is no sqrtf and other C99 funcs and many C++ programs get also many errors. i see old libstdc++ contain sqrtf but get many other linker errors. there is also a sqrtf not undef in cmath as many other functions are. When i define sqrtf in math.h then the sqrtf func in libstdc++ is maybe not add and this strange linker error come.but wy it work not correct when i add sqrtf to libc i dont know.only solution below work. only this funcs are undef. // Get rid of those macros defined in in lieu of real functions. #undef abs #undef div #undef acos #undef asin #undef atan #undef atan2 #undef ceil #undef cos #undef cosh #undef exp #undef fabs #undef floor #undef fmod #undef frexp #undef ldexp #undef log #undef log10 #undef modf #undef pow #undef sin #undef sinh #undef sqrt #undef tan #undef tanh > Bernd Roesch wrote: >> I see in my c++config.h file >> >> this stand here >> >> /* Define if the compiler/host combination has __builtin_sqrtf. */ >> /* #undef _GLIBCXX_HAVE___BUILTIN_SQRTF */ >> >> I find now a solution that work without change of cmath >> >> when i add in math.h this line then it work.the function can too stand as >> static inline in the math.h file. >> >> #define __builtin_sqrtf sqrtf > > How about using the original C-library of your system together with its > headers? After all the version you are currently using is an "alien" and > doesn't fit for your system despite the fact that it was based on your > systems C-library and its headers. Carefully merging changes back to the > original version would be the better solution. > > Gunther > >>> On Mon, Mar 9, 2009 at 3:59 PM, Gabriel Dos Reis >>> wrote: On Mon, Mar 9, 2009 at 7:11 AM, Bernd Roesch wrote: > Hello Gabriel [...] > You see there is the _ not in.normaly funcs that not find have a _ > before > > To get all work, it seem i need add the same function add in math.h > and > in > the linker > lib or change cmath file and remove all __builtin_ commands the > architecture > not have. I believe one should convince the middle end to emit libcall for __builtin_xxx when the target has no builtint support. >>> It of course does. >>> >>> Richard. >> Regards > > > > mfg Bernd
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 12:44 PM, Richard Kenner wrote: >> > Yes, I would mind, because it's not MY issue, but RMS's! I don't want >> > to speculate why RMS might not want to use C++ >> >> That is non argument: RMS has not not contributed any executable >> code for GCC, and even less the C++ front-end, for YEARS now. > > What does that have to do with expressing philosophical beliefs about how > software development should be done? You asserted I don't want to speculate why RMS might not want to use C++ ^^ But, in this case the users of C++ would be the GCC developers. Those are the ones directly suffering the handcuffs. > You don't lose the right to stop > doing that about a project you run just because you haven't written any > code for a while! Many managers in software companies haven't written code > for years but routinely make decision on language choices for projects and > expect their subordinates to follow those decisions. and reasonings along those lines are what gets us in the current mess you claim you do not understand. BTW, when did FSF turned into a software company? I thought it was a 501(c)3 donor supported charity, fighting for the essential freedoms for computer users. -- Gaby
Re: GCC 4.4.0 Status Report (2009-03-13)
> > Yes, I would mind, because it's not MY issue, but RMS's! I don't want > > to speculate why RMS might not want to use C++ > > That is non argument: RMS has not not contributed any executable > code for GCC, and even less the C++ front-end, for YEARS now. What does that have to do with expressing philosophical beliefs about how software development should be done? You don't lose the right to stop doing that about a project you run just because you haven't written any code for a while! Many managers in software companies haven't written code for years but routinely make decision on language choices for projects and expect their subordinates to follow those decisions. > and it's acceptable for Ada, but for not for C++. I think RMS's position might well have been different if the question were restricted to the C++ front end instead of the core compiler.
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 12:25 PM, Richard Kenner wrote: >> would you mind elaborating on the philosophical issue here? > > Yes, I would mind, because it's not MY issue, but RMS's! I don't want > to speculate why RMS might not want to use C++ That is non argument: RMS has not not contributed any executable code for GCC, and even less the C++ front-end, for YEARS now. > >> > Similarly, which of two possible algorithms to use *can* be a >> > *detailed* technical issue, but stops being one if one of those two >> > choices has a patent issue. >> >> By your analogy, which part of C++ do you consider >> has patent issue compared to Ada? > > I don't follow. My analogy was just to show two areas where what might be > considered "technical" decisions might touch on something larger, in one > case philosophy and in another patents. > > If you're asking why RMS didn't object to the Ada front end being written > in Ada, the answer is that he would have preferred C, but it's always > acceptable to write all or part of a compiler in its own language. E.g., and it's acceptable for Ada, but for not for C++. > COBOL would be an odd choice of a language to write a compiler in, but > quite reasonable if the language you're compiling is COBOL (and there is > such). Also, there's a difference between starting from scratch with some > non-C language and converting a C program into one in a different language > (note RMS's "at least for programs that are presently written in C"). > > -- Gaby
Re: GCC 4.4.0 Status Report (2009-03-13)
> would you mind elaborating on the philosophical issue here? Yes, I would mind, because it's not MY issue, but RMS's! I don't want to speculate why RMS might not want to use C++ > > Similarly, which of two possible algorithms to use *can* be a > > *detailed* technical issue, but stops being one if one of those two > > choices has a patent issue. > > By your analogy, which part of C++ do you consider > has patent issue compared to Ada? I don't follow. My analogy was just to show two areas where what might be considered "technical" decisions might touch on something larger, in one case philosophy and in another patents. If you're asking why RMS didn't object to the Ada front end being written in Ada, the answer is that he would have preferred C, but it's always acceptable to write all or part of a compiler in its own language. E.g., COBOL would be an odd choice of a language to write a compiler in, but quite reasonable if the language you're compiling is COBOL (and there is such). Also, there's a difference between starting from scratch with some non-C language and converting a C program into one in a different language (note RMS's "at least for programs that are presently written in C").
"Host/Target specific installation notes for GCC": broken link
Hi! The page on "Host/Target specific installation notes for GCC" (http://gcc.gnu.org/install/specific.html) has a broken link. In the table of contents it links to "http://gcc.gnu.org/install/specific.html#x-x-mingw";, while "http://gcc.gnu.org/install/specific.html#x-x-mingw32"; would be correct. Regards, Dennis Schridde signature.asc Description: This is a digitally signed message part.
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 12:03 PM, Richard Kenner wrote: >> So, from your perspective, a request >> >> to use (a subset of) C++ for compiling GCC >> >> is hardly detailed technical issue. > > Actually, I don't consider an issue of what programming language to use as > a "detailed" issue, but rather a pretty fundamental one. It can be a > purely *technical* issue (though not a "detail") if it doesn't touch on a > philosophical issue, but it *isn't* if it does, as in this case. would you mind elaborating on the philosophical issue here? > > Similarly, which of two possible algorithms to use *can* be a > *detailed* technical issue, but stops being one if one of those two > choices has a patent issue. By your analogy, which part of C++ do you consider has patent issue compared to Ada? -- Gaby >
Re: GCC 4.4.0 Status Report (2009-03-13)
> So, from your perspective, a request > > to use (a subset of) C++ for compiling GCC > > is hardly detailed technical issue. Actually, I don't consider an issue of what programming language to use as a "detailed" issue, but rather a pretty fundamental one. It can be a purely *technical* issue (though not a "detail") if it doesn't touch on a philosophical issue, but it *isn't* if it does, as in this case. Similarly, which of two possible algorithms to use *can* be a *detailed* technical issue, but stops being one if one of those two choices has a patent issue.
Re: GCC 4.4.0 Status Report (2009-03-13)
> Btw, I cannot find anything related to this discussion (about whether > and what power the FSF has to force their maintainers to do anything) > in the official FSF documentation (http://www.gnu.org/prep/maintain/). Well, as the copyright owner and the appointer of maintainers it is pretty obvious that the FSF *can* do whatever they want. Obviously, since they are intelligent people they will usually just ask you to follow the GNU project guidelines (including the strong suggestions about using C). Paolo
Re: GCC 4.4.0 Status Report (2009-03-13)
> Btw, I cannot find anything related to this discussion (about whether > and what power the FSF has to force their maintainers to do anything) > in the official FSF documentation (http://www.gnu.org/prep/maintain/). I can: it's the very first sentence: This file contains guidelines and advice for someone who is the maintainer of a GNU program on behalf of the GNU Project. This clearly says that the maintainer is acting "on behalf" of the GNU Project. That means they act as the AGENT of the GNU project. When you act as somebody's agent, your authority derives from that person.
Re: cmath call builtin sqrtf but many platforms seem miss that(was Re: lrint lrintf problems )
Bernd Roesch wrote: I see in my c++config.h file this stand here /* Define if the compiler/host combination has __builtin_sqrtf. */ /* #undef _GLIBCXX_HAVE___BUILTIN_SQRTF */ I find now a solution that work without change of cmath when i add in math.h this line then it work.the function can too stand as static inline in the math.h file. #define __builtin_sqrtf sqrtf How about using the original C-library of your system together with its headers? After all the version you are currently using is an "alien" and doesn't fit for your system despite the fact that it was based on your systems C-library and its headers. Carefully merging changes back to the original version would be the better solution. Gunther On Mon, Mar 9, 2009 at 3:59 PM, Gabriel Dos Reis wrote: On Mon, Mar 9, 2009 at 7:11 AM, Bernd Roesch wrote: Hello Gabriel [...] You see there is the _ not in.normaly funcs that not find have a _ before To get all work, it seem i need add the same function add in math.h and in the linker lib or change cmath file and remove all __builtin_ commands the architecture not have. I believe one should convince the middle end to emit libcall for __builtin_xxx when the target has no builtint support. It of course does. Richard. Regards
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 11:54 AM, Richard Kenner wrote: >> Yes, surely you have heard of stonewalling use of C++ to directly >> express some of the abstractions we use in the compiler. > > Those are hardly detailed technical issues, So, from your perspective, a request to use (a subset of) C++ for compiling GCC is hardly detailed technical issue. I rest my case. -- Gaby
Re: GCC 4.4.0 Status Report (2009-03-13)
> Yes, surely you have heard of stonewalling use of C++ to directly > express some of the abstractions we use in the compiler. Those are hardly detailed technical issues, but relate directly to the funamental development philosphy of the GNU project, which is something that the FSF clearly has the prerogative to do.
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, 22 Mar 2009, Richard Kenner wrote: > > In the past, RMS had asserted that use some specific programming > > language with an international standard developed by ISO > > was unacceptable for the GNU project (and GCC in particular). > > That had had the practical effect of delaying for years, > > developments of projects both in GCC and directly related to GCC. > > I'm not sure I understand your reference, but those are clearly generic > issues relating to management of FSF projects overall and to philosophical > issues related to Free Software. That's very clearly the prerogative of > the FSF. What I heard claimed was that there was interference in the > *technical* issues, such as when to take branches or similar specific > technical choices. I've heard of no such examples before this one. Btw, I cannot find anything related to this discussion (about whether and what power the FSF has to force their maintainers to do anything) in the official FSF documentation (http://www.gnu.org/prep/maintain/). Richard.
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 11:33 AM, Joseph S. Myers wrote: > On Sun, 22 Mar 2009, Gabriel Dos Reis wrote: > >> >> So, are you now suggesting that technical decisions where not the >> >> sole domain of GCC developers? That contradicts the conventional >> >> understanding we have taken on the issue in the past. >> > >> > Then you had the wrong understanding. >> >> Well, maybe you have the wrong understanding. In the past, >> on many occasions, we have acted on the premise that >> FSF does not have to interfere with technical decisions made >> GCC developers. And you certainly never came hard asserting >> the opposite. > > My view is inbetween. I don't believe that the FSF must never interfere > with technical decisions, but neither do I believe it is completely free > to do so. I believe that the GCC Development Mission Statement binds both > the developers and the FSF equally, as part of the basis for the GCC/EGCS > reunification, so the FSF can only interfere with technical decisions > where doing so is in accordance with the Mission Statement. It could, for > example, rule that a particular change cannot be accepted because of a > risk of patent infringement (legal issues being reserved to the FSF), or Yes, clearly patent infringement cannot be construed as a purely technical matter. It is a legal matter. > resolve a technical dispute in a way consistent with the principle that > "Patches will be considered equally based on their technical merits." and > the other "Open Development Environment" principles (and if the SC acts as > agent of the FSF this is effectively what happens if a technical dispute > is referred to the SC). I acknowledge your position, and it appears to me that in the past you've taken the view that technical issues are left to GCC developers -- unless, as you note they result in non-consensus. http://gcc.gnu.org/ml/gcc/2004-07/msg00697.html -- Gaby
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 11:35 AM, Richard Kenner wrote: >> In the past, RMS had asserted that use some specific programming >> language with an international standard developed by ISO >> was unacceptable for the GNU project (and GCC in particular). >> That had had the practical effect of delaying for years, >> developments of projects both in GCC and directly related to GCC. > > I'm not sure I understand your reference, but those are clearly generic http://gcc.gnu.org/ml/gcc/2004-07/msg00588.html > issues relating to management of FSF projects overall and to philosophical > issues related to Free Software. That's very clearly the prerogative of > the FSF. What I heard claimed was that there was interference in the > *technical* issues, such as when to take branches or similar specific > technical choices. I've heard of no such examples before this one. Yes, surely you have heard of stonewalling use of C++ to directly express some of the abstractions we use in the compiler. -- Gaby
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, 22 Mar 2009, Gabriel Dos Reis wrote: > >> So, are you now suggesting that technical decisions where not the > >> sole domain of GCC developers? That contradicts the conventional > >> understanding we have taken on the issue in the past. > > > > Then you had the wrong understanding. > > Well, maybe you have the wrong understanding. In the past, > on many occasions, we have acted on the premise that > FSF does not have to interfere with technical decisions made > GCC developers. And you certainly never came hard asserting > the opposite. My view is inbetween. I don't believe that the FSF must never interfere with technical decisions, but neither do I believe it is completely free to do so. I believe that the GCC Development Mission Statement binds both the developers and the FSF equally, as part of the basis for the GCC/EGCS reunification, so the FSF can only interfere with technical decisions where doing so is in accordance with the Mission Statement. It could, for example, rule that a particular change cannot be accepted because of a risk of patent infringement (legal issues being reserved to the FSF), or resolve a technical dispute in a way consistent with the principle that "Patches will be considered equally based on their technical merits." and the other "Open Development Environment" principles (and if the SC acts as agent of the FSF this is effectively what happens if a technical dispute is referred to the SC). -- Joseph S. Myers jos...@codesourcery.com
Re: GCC 4.4.0 Status Report (2009-03-13)
> In the past, RMS had asserted that use some specific programming > language with an international standard developed by ISO > was unacceptable for the GNU project (and GCC in particular). > That had had the practical effect of delaying for years, > developments of projects both in GCC and directly related to GCC. I'm not sure I understand your reference, but those are clearly generic issues relating to management of FSF projects overall and to philosophical issues related to Free Software. That's very clearly the prerogative of the FSF. What I heard claimed was that there was interference in the *technical* issues, such as when to take branches or similar specific technical choices. I've heard of no such examples before this one.
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 11:08 AM, Richard Kenner wrote: >> Drawing one conclusion is not drawing 'too many conclusions'. And, >> there is no evidence that this is a "once in a lifetime" issue. Quite >> the contrary. > > What's the evidence to the contrary? When else has the FSF made a > request that affects *development* as opposed to a release (other than > licensing and issues affecting the principle of free software, which > everybody agrees they have a right to)? I'm pretty sure you are well aware of those, and you are just looking for distractions :-/ In the past, RMS had asserted that use some specific programming language with an international standard developed by ISO was unacceptable for the GNU project (and GCC in particular). That had had the practical effect of delaying for years, developments of projects both in GCC and directly related to GCC. Anyway, you know all of this. -- Gaby
Re: GCC 4.4.0 Status Report (2009-03-13)
> Drawing one conclusion is not drawing 'too many conclusions'. And, > there is no evidence that this is a "once in a lifetime" issue. Quite > the contrary. What's the evidence to the contrary? When else has the FSF made a request that affects *development* as opposed to a release (other than licensing and issues affecting the principle of free software, which everybody agrees they have a right to)? > Well, maybe you have the wrong understanding. In the past, on many > occasions, we have acted on the premise that FSF does not have to > interfere with technical decisions made GCC developers. And you > certainly never came hard asserting the opposite. I don't think you meant what you wrote. Nobody said that the FSF *has to* interfere with technical decisions, nor that they, as a matter of usual course, *do* interfere with them. The issue is whether they, as the owner of the project, *can* interfere with them if they so choose. And it's always been clear to me (and, from his response, to Mark) that they can.
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 11:04 AM, Richard Kenner wrote: >> Of course, just I (and others) don't see why they should do it in this >> case. Delaying a *branch* is different from, say, using a proprietary >> version control or bug tracking system. > > I don't either. Requesting a delay of a *release* on a license issue > is completely and perfectly understandable, but what that has to do > with making a *branch* makes absolutely no sense to me. Indeed. That the SC seems to declare that it can't do anything about it is even more puzzling. -- Gaby
Re: GCC 4.4.0 Status Report (2009-03-13)
> Of course, just I (and others) don't see why they should do it in this > case. Delaying a *branch* is different from, say, using a proprietary > version control or bug tracking system. I don't either. Requesting a delay of a *release* on a license issue is completely and perfectly understandable, but what that has to do with making a *branch* makes absolutely no sense to me.
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 10:37 AM, Richard Kenner wrote: >> It appears we are currently not using that model. During EGCS lifetine, >> I do not remember we got to this situation where FSF had to disruptively >> interfere with development (whether on branch or not.) > > This is obviously a rare occurrence. Nobody can recall any previous such > issue with the SC and I can't recall any such issue when I was the GCC > maintainer. Drawing too many conclusions about "once in a lifetime" events > aren't a good idea. Drawing one conclusion is not drawing 'too many conclusions'. And, there is no evidence that this is a "once in a lifetime" issue. Quite the contrary. > >> So, are you now suggesting that technical decisions where not the >> sole domain of GCC developers? That contradicts the conventional >> understanding we have taken on the issue in the past. > > Then you had the wrong understanding. Well, maybe you have the wrong understanding. In the past, on many occasions, we have acted on the premise that FSF does not have to interfere with technical decisions made GCC developers. And you certainly never came hard asserting the opposite. -- Gaby
Re: GCC 4.4.0 Status Report (2009-03-13)
> Then you had the wrong understanding. The FSF has ALWAYS had the right to > overrule technical decisions on ANY of their projects. The point is that > this is a right they very rarely exercise. Of course, just I (and others) don't see why they should do it in this case. Delaying a *branch* is different from, say, using a proprietary version control or bug tracking system. Paolo
Re: GCC 4.4.0 Status Report (2009-03-13)
> It appears we are currently not using that model. During EGCS lifetine, > I do not remember we got to this situation where FSF had to disruptively > interfere with development (whether on branch or not.) This is obviously a rare occurrence. Nobody can recall any previous such issue with the SC and I can't recall any such issue when I was the GCC maintainer. Drawing too many conclusions about "once in a lifetime" events aren't a good idea. > So, are you now suggesting that technical decisions where not the > sole domain of GCC developers? That contradicts the conventional > understanding we have taken on the issue in the past. Then you had the wrong understanding. The FSF has ALWAYS had the right to overrule technical decisions on ANY of their projects. The point is that this is a right they very rarely exercise.
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 10:17 AM, Richard Kenner wrote: >> but FSF still owned the copyright of the codes of EGCS; so it wasn't >> reuniting with FSF interfering with technical decisions. > > I don't follow. There's a difference between working on code whose > copyright is held by the FSF and working as part of an FSF-endorsed > project. > >> At the time, nobody explained that the SC concluded the EGCS >> experience was a failure and therefore the EGCS community >> should surrender and abandon the very reasons it emerged. > > No, indeed the opposite occured: it was concluded that the EGCS experience > was a SUCCESS and that the FSF should use that model for its future > development of GCC. It appears we are currently not using that model. During EGCS lifetine, I do not remember we got to this situation where FSF had to disruptively interfere with development (whether on branch or not.) > >> It was my understanding that it was a compromise, but the >> EGCS community retains all rights to make technical >> decisions without disruptive interferences from FSF > > Your understanding is incorrect. Independence from the FSF was never an > issue. So, are you now suggesting that technical decisions where not the sole domain of GCC developers? That contradicts the conventional understanding we have taken on the issue in the past. -- Gaby
Re: GCC 4.4.0 Status Report (2009-03-13)
Sorry guys for a naive question, but I did not find any answer in this thread. Could someone at FSF, directly or through the SC, be kind enough to explain in plain English for non-native speakers why it was so urgent to disrupt the release process for a licence exception. Indeed I am not expecting names of entities for which the exception is being taylored. TIA Dominique
Re: GCC 4.4.0 Status Report (2009-03-13)
> but FSF still owned the copyright of the codes of EGCS; so it wasn't > reuniting with FSF interfering with technical decisions. I don't follow. There's a difference between working on code whose copyright is held by the FSF and working as part of an FSF-endorsed project. > At the time, nobody explained that the SC concluded the EGCS > experience was a failure and therefore the EGCS community > should surrender and abandon the very reasons it emerged. No, indeed the opposite occured: it was concluded that the EGCS experience was a SUCCESS and that the FSF should use that model for its future development of GCC. > It was my understanding that it was a compromise, but the > EGCS community retains all rights to make technical > decisions without disruptive interferences from FSF Your understanding is incorrect. Independence from the FSF was never an issue.
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 9:50 AM, Joel Sherrill wrote: > Richard Kenner wrote: >>> >>> I must admit that this interpretation is quite new to me. >>> It certainly wasn't when EGCS reunited with gcc. >>> >> >> I disagree. "reuniting with GCC" means "reuniting with the FSF". >> > > Richard's memory is correct here. We did not want > any perception of any company having undue influence. > > EGCS was an experiment in development methodologies > that was intended to open up gcc. If successful, > the goal was to move from being a fork to being > the main GCC FSF development. There was never any > intention of becoming a non-FSF fork. I never suggested EGCS was to become non-FSF. The source code of EGCS was still owned by FSF. Rather, it is question of letting developers make technical decisions without disruptive interference from FSF. > > gcc 2.95 was where it reunited. The egcs fork > only existed from 1997 until April 1999 when 2.95 > was released. Yes. Nobody is disputing that. What disturbs me is the new interpretation of the SC mission statement. -- Gaby
Re: GCC 4.4.0 Status Report (2009-03-13)
Steven Bosscher wrote: On Sun, Mar 22, 2009 at 1:44 AM, Richard Kenner wrote: I think the community of GCC consumers also doesn't care which sandbox the developers play in, as long as they're all playing in the same sandbox. But maybe I'm wrong, and maybe that's why I've never been able to understand why EGCS merged back into the FSF GCC in the first place... I think you're wrong. Many of these players are large companies (such as IBM and now, RedHat). Putting them in the position of having to "reject" the official FSF contribution is awkward for them. I'm sorry, but I don't see it that way. Having been on the front lines on this issue in the past, I can say our customers certainly cared about it and therefore we (Cygnus, now Red Hat) care about it. Jeff
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 9:41 AM, Richard Kenner wrote: >> I must admit that this interpretation is quite new to me. >> It certainly wasn't when EGCS reunited with gcc. > > I disagree. "reuniting with GCC" means "reuniting with the FSF". > but FSF still owned the copyright of the codes of EGCS; so it wasn't reuniting with FSF interfering with technical decisions. At the time, nobody explained that the SC concluded the EGCS experience was a failure and therefore the EGCS community should surrender and abandon the very reasons it emerged. It was my understanding that it was a compromise, but the EGCS community retains all rights to make technical decisions without disruptive interferences from FSF -- Gaby
Re: GCC 4.4.0 Status Report (2009-03-13)
> If the SC now has a different mission/etc than they used to, they > should, you know, tell the rest of us and put it on the page, since > clearly nobody understands exactly what the GCC's project governance > is like? I don't believe that the SC's mission or interest has changed. The term "GCC project" has, from its inception, meant "the FSF's GCC project". That was the case prior to ecgs, was the case when egcs was merged back into the GCC project, and is still the case today. The SC has always acted as the FSF's representative for the GCC project. Mark's analogy with a Cabinet department is exactly correct: The Treasury Secretary has authority delegated to him by the President to run the departments under him in a way that he sees fit PROVIDED they're run consistently with the President's expressed wishes, if any. Likewise for the SC (or the official maintainer of ANY FSF project): they have been delegated the responsibily by the FSF to maintain their project in a way that's consistent with the FSF's wishes. In both cases, for the vast majority of things, the President doesn't get involved in a Cabinet member's detailed decisions and the FSF doesn't get involved in the maintenance of one of their projects. But they always can and when they do and can't be convinced they're wrong, the project maintainer (in our case the SC) has exactly two choice: go along or resign. When I was the GCC maintainer, it was because that position was delegated to me by the FSF. Any authority I had was because I was speaking in the name of the FSF on that project. But I had to respect the wishes of the FSF. However, as a practical matter, the FSF very rarely made any requests of me in this regard and they make few of the SC, from what I understand. When egcs merged back into GCC, my position was the GCC maintainer was replaced by the SC. There was a desire that, on a project of this size, no single person or entity would have the role of being the GCC maintainer and that the role would be undertaken collectively by the SC, who in turn, made the same promise. But the change of who was the GCC maintainer (from me to the SC) didn't change the ROLE of the GCC maintainer, which was to act as a representative of the FSF in maintaining a software development project OF THE FSF. The FSF always had and will always have absolute control over their projects, of which GCC is one.
Re: GCC 4.4.0 Status Report (2009-03-13)
Richard Kenner wrote: I must admit that this interpretation is quite new to me. It certainly wasn't when EGCS reunited with gcc. I disagree. "reuniting with GCC" means "reuniting with the FSF". Richard's memory is correct here. We did not want any perception of any company having undue influence. EGCS was an experiment in development methodologies that was intended to open up gcc. If successful, the goal was to move from being a fork to being the main GCC FSF development. There was never any intention of becoming a non-FSF fork. gcc 2.95 was where it reunited. The egcs fork only existed from 1997 until April 1999 when 2.95 was released. --joel sherrill
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 10:47 AM, Paolo Bonzini wrote: > On Sun, Mar 22, 2009 at 15:41, Richard Kenner > wrote: >>> I must admit that this interpretation is quite new to me. >>> It certainly wasn't when EGCS reunited with gcc. >> >> I disagree. "reuniting with GCC" means "reuniting with the FSF". > > ... but not "raising a white flag". If the SC now has a different mission/etc than they used to, they should, you know, tell the rest of us and put it on the page, since clearly nobody understands exactly what the GCC's project governance is like?
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 15:41, Richard Kenner wrote: >> I must admit that this interpretation is quite new to me. >> It certainly wasn't when EGCS reunited with gcc. > > I disagree. "reuniting with GCC" means "reuniting with the FSF". ... but not "raising a white flag". Paolo
Re: GCC 4.4.0 Status Report (2009-03-13)
> I must admit that this interpretation is quite new to me. > It certainly wasn't when EGCS reunited with gcc. I disagree. "reuniting with GCC" means "reuniting with the FSF".
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 7:58 AM, Richard Kenner wrote: >> It also sounds a lot like you are saying the Steering Commitee does >> not care much if the FSF has control over the project, which I know to >> be false :) > > I don't understand your point. GCC is an FSF project. The SC is acting > here as an agent of the FSF. What the statement you quote means is that > the SC will manage the project on behalf of the FSF in such a way that no > single organization will have undo influence on it and the FSF: there's no > way to read this as saying that the FSF, who's project it is in the first > place, can't have undo influence ON ITSELF! I must admit that this interpretation is quite new to me. It certainly wasn't when EGCS reunited with gcc. -- Gaby
Re: [gcc-in-cxx] bootstrap fails
On Sun, Mar 22, 2009 at 12:29 AM, Jerry Quinn wrote: > Ian Lance Taylor wrote: >> >> Jerry Quinn writes: >> >> >>> >>> 2009-03-21 Jerry Quinn >>> >>> * config/i386/i386.c (ix86_function_specific_save): Don't check >>> range of enum values. >>> >> >> I still don't know why I don't see this, but this is OK for the >> gcc-in-cxx branch. >> >> > > Do I need to take any actions before I can commit into gcc's svn repository? Do you have a gcc.gnu.org account? If yes, there are no special actions you need to take before committing. If not, there is a form to fill out, you can list me as the sponsor.
Re: GCC 4.4.0 Status Report (2009-03-13)
> It also sounds a lot like you are saying the Steering Commitee does > not care much if the FSF has control over the project, which I know to > be false :) I don't understand your point. GCC is an FSF project. The SC is acting here as an agent of the FSF. What the statement you quote means is that the SC will manage the project on behalf of the FSF in such a way that no single organization will have undo influence on it and the FSF: there's no way to read this as saying that the FSF, who's project it is in the first place, can't have undo influence ON ITSELF! > >> 1. The FSF, as an organization, clearly now has control over the project. It always has: GCC is an FSF project and always has been.
Re: GCC 4.4.0 Status Report (2009-03-13)
On Sun, Mar 22, 2009 at 1:00 AM, Joe Buck wrote: > On Sat, Mar 21, 2009 at 07:37:10PM -0700, Daniel Berlin wrote: >> "The steering committee was founded in 1998 with the intent of >> preventing any particular individual, group or organization from >> getting control over the project. Its primary purpose is to make major >> decisions in the best interests of the GCC project and to ensure that >> the project adheres to its fundamental principles found in the >> project's mission statement. [see the original announcement below]." > > The purpose of that statement (which dates from egcs days), was to address > concerns that egcs represented a Cygnus takeover of GCC. egcs started > before the Red Hat acquisition of Cygnus, and it started with the Cygnus > "devo tree" with a Cygnus employee as RM, and some Cygnus marketing people > at the time were actually telling customers that it *did* represent a > Cygnus takeover, so they had to have a Cygnus support contract if they > wanted any influence over egcs! Fortunately those people were quickly > slapped down. And after the Cygnus/Red Hat merger, the rest of the > community was worried about the 800 pound gorilla. All of this is a great statement of history if those are no longer the goals, you need to update the statement, so *the rest of us* know exactly what it is the steering committee sees itself doing these days. If the steering committee is no longer following this mission or abiding by these guidelines, you really should update the page. It also sounds a lot like you are saying the Steering Commitee does not care much if the FSF has control over the project, which I know to be false :) > >> 1. The FSF, as an organization, clearly now has control over the project. >> You even liken them to the administration of which you are just a >> subordinate. >> You also believe you must act in accordance with their policy or >> resign from the group supposed to be making the major decisions in the >> best interests of the GCC project. > > Even in the egcs days, every contributor signed over their copyright to > their contributions to the FSF, so even then the FSF played a special > role. Many of the contributors worked (and still work) for organizations > that compete with each other: if there weren't some nonprofit with legal > ownership of the code one would have had to be invented. None of this is a refutation of the above, and in fact, seems to support it. Again, if it is no longer true that the Steering Commitee has a goal/purpose of keeping organizations from taking over GCC, change the page and tell us what the SC's current goals are. > > There are checks on FSF control in the sense that the project can be > forked and developers can leave. This is not a meaningful check on control. The same way that in the US "revolution" is not really a check on control of the government, it is a "method of replacement" when checks and controls are not respected. (This is why in the US we have a whole full constitution of checks and controls) Me, i'd rather see us have meaningful checks and controls. > But in this particular case, I'm hopeful > that this holdup is going to be resolved soon; there's new language and > meetings this weekend which I hope will resolve matters, and the new > language is designed to fix problems raised on this list by GCC > developers. Most of the time, the FSF hasn't interfered with GCC except > on a couple of matters that they care about; licensing is one such matter. I *heavily* disagree with this statement. Let's see, just in the somewhat recent past: Writing out the IL Plugins Changing over the bug system Hosting on sourceware.org Moving to subversion Claiming this as "a couple matters they care about" seems a bit much. All of these were certainly resolved, but *they never should have been issue that the FSF had any control over in the first place*.
Re: GCC 4.4.0 Status Report (2009-03-13)
> Many of the contributors worked (and still work) for organizations > that compete with each other: if there weren't some nonprofit with > legal ownership of the code one would have had to be invented. I think this is an important point, and one that many developers have forgotten about: GCC is not just a volunteer effort, but one that involves a lot of companies, who are often competitors. These companies can only legally work together on a project under certain conditions, and the existence of the FSF who owns the code is one of the ways (and the best way) that can be done. Given the universality of GCC nowadays, the risk of anti-trust law being invoked on its development should be more than a theoretical concern.
Re: Is there any flags to disable warning and/or errors given by GCC 4.3.3?
Hi. This question is not really suitable for the GCC mailing list; this is a list for discussing GCC development. The right place to send such questions is gcc-h...@gcc.gnu.org. Thanks. >I am not able compile my project with GCC 4.3.3 C++. My project > was compiled by GCC 4.1.x. It's a common situation. >Is there any flags to disable warning and/or errors given by GCC > 4.3.3? You can do that using -Wno-, but: >I should remove and/or change code to eliminate warning and/or > error? You should fix your code so that it complies with the C++ standard (that GCC 4.3 will be more strictly enforcing). Cheers, Ben
Re: correct way of having a function pointer inside a GTY()-ed struct?
Quoting Basile STARYNKEVITCH : My current way of thinking is that MELT is incompatibly with precompiled headers. And I tend to think that any sufficient flexible plugin machinery is incompatible with pch. Intuitively I would believe that pch (in their current form) and plugins are incompatible. I suppose it should still be OK if no plugin becomes active before the pch is saved or used. If your pointers are such that you can ignore them for garbage collection, but they cannot be saved sanely in a precompiled header, you could add a GTY marker that says just that. An attempt to save a pch with such a pointer should then fail. That should probably be an internal error; if we assume that plugin use makes pch unusable, we should set a flag when a plugin becomes active, and refuse to save or load a pch if that flag is set. If you think it could be OK for some plugins if they are used in exactly the same way for pch generation and use, you can have each plugin generate data to be compared for pch, or a failure indication if the plugin is fundamentally incompatible with pch (or if the plugin hasn't implemented the necessary logic).
Re: correct way of having a function pointer inside a GTY()-ed struct?
Joern Rennecke wrote:
Basile STARYNKEVITCH:
> So my point is that I want to put inside the GTY-ed struct
basilysroutine_st
> an ignored (I mean GTY((skip))-ed) field called routaddr which is a
function
> pointer
> (function of type basilysroutfun_t - which is typedef-ed above).
>
> How can I achieve that, in the cleanest way possible?
Richard Guenther:
Just do it and fix whatever causes that not to work?!
This is likely to break if this struct gets saved as part of a
precompiled
header, and for some instance of using this header, the function ends
up in
a different place than during header compilation due to address space
randomization.
My current way of thinking is that MELT is incompatibly with precompiled
headers. And I tend to think that any sufficient flexible plugin
machinery is incompatible with pch. Intuitively I would believe that pch
(in their current form) and plugins are incompatible.
Compare also PR31634.
Possible solutions are:
i) Use an enum instead, and use a switch to call the appropriate
function.
I certainly cannot use an enum, since the number of function pointers is
arbitrary large (since MELT has the ability to generate code & dlopen it
during cc1). I might consider perhaps later to use a vector of function
pointers, and instead of the enum use an index. That would add another
indirection for each MELT function calls.
ii) if the switch is too slow, you might convert a pointer to an enum
before pch-saving, and convert back after reading the pch file.
Of course, if your function pointers can point into dynamically shared
objects (dsos)that are not automatically loaded when the compiler binary
starts, you have to worry about dso persistence first...
The MELT function pointers are always dlsym-ed from dlopen-ed shared
objects. That is the very way MELT works. The sequence of shared objects
which are dlopen-ed is gcc runtime configurable (thru -fbasilys-init
option).
Thanks for your insightful comments.
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
