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?
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 h
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
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 usi
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
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
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
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 softw
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 indicati
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 contrib
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 f
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 l
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 interest
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 ex
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
versi
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.
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 hav
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 an
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 e
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++
>
Tha
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,
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.
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 ev
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 i
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 co
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 co
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,
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 i
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 impos
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 poin
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 bui
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 func
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
> > 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 expressi
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
> 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
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 corr
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 ra
> 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* is
> 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 obviou
> 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 advic
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
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
> 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
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
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
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
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.
>
>
> 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 directl
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
> 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
l
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 *relea
> 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 understandab
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 occ
> 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
> 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
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 wor
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 expectin
> 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
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 i
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
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; s
> 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
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 und
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"
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
> 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".
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
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,
> 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 t
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 p
> 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 n
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
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.
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 a
75 matches
Mail list logo
