> Note that merging the branch will be painful (as in, please dissect
> the branch into the individual patches again to make bisecting the
> trunk SVN possible). Also the SC vetoed these kind of 'integration'
> branches in the past (to not encourage starting an effective stage1
> on a branch).
I
Steven Bosscher writes:
> case OPT_mfixed_range_:
> @@ -5245,6 +5247,13 @@ ia64_handle_option (size_t code, const char *arg,
> if (!strcmp (arg, processor_alias_table[i].name))
> {
> ia64_tune = processor_alias_table[i].processor;
> + if (ia64_tune ==
On Fri, Mar 20, 2009 at 10:31 AM, Andi Kleen wrote:
> Steven Bosscher writes:
>
>> case OPT_mfixed_range_:
>> @@ -5245,6 +5247,13 @@ ia64_handle_option (size_t code, const char *arg,
>> if (!strcmp (arg, processor_alias_table[i].name))
>> {
>> ia64_tune = proces
On Fri, 20 Mar 2009, NightStrike wrote:
> Stage 3 is bug fix only, so I'm not sure if you agree with me or
> not I was advocating that we take the time to fix more bugs that
> are new for 4.4 and so aren't regressions. We have several that are
> in the win64 port that we will have to support
On Fri, 20 Mar 2009, Roberto Bagnara wrote:
> Hi Joseph,
>
> thanks for the detailed explanation. I admit we always have postoponed the
> issue of cross-compilation... to the point we almost forgot it. We will
> fix the PPL asap. Can we come back to you in case we are unsure about which
> defa
Joseph S. Myers wrote:
On Fri, 20 Mar 2009, Roberto Bagnara wrote:
Work has already started for producing an official PPL 0.11 release.
This will contain fixes for all the problems we discovered since the release
of PPL 0.10 (mainly portability ones), a new "formatted output" feature
that is nee
NightStrike wrote:
On Mon, Mar 16, 2009 at 6:10 AM, Paolo Bonzini wrote:
NightStrike wrote:
On Fri, Mar 13, 2009 at 1:58 PM, Joseph S. Myers
wrote:
Given the SC request we need to stay in Stage 4 rather than trying to work
around it.
What if GCC went back to stage 3
On Fri, Mar 13, 2009 at 2:28 PM, Joe Buck wrote:
> On Fri, Mar 13, 2009 at 10:25:34AM -0700, Richard Guenther wrote:
>> The topmost sentence should be unambiguous. Yes, the SC asked us not
>> to branch.
>
> The request came from RMS, the SC just passed it on.
>
There are two things here that both
On Fri, Mar 20, 2009 at 4:10 AM, Steven Bosscher wrote:
> On Fri, Mar 20, 2009 at 10:31 AM, Andi Kleen wrote:
>> Steven Bosscher writes:
>>
>>> case OPT_mfixed_range_:
>>> @@ -5245,6 +5247,13 @@ ia64_handle_option (size_t code, const char *arg,
>>> if (!strcmp (arg, processor_alias_
Daniel Berlin wrote:
2. Where is the pushback by the SC onto the FSF?
Why haven't we given them a hard deadline, or even any deadline at all?
It's clear when they have no deadlines, they take forever to get
anything done. After all, if they are allowed to not prioritize it and
have no incentive t
Daniel Berlin writes:
> Why hasn't the SC sent something to the FSF like:
>
> "We are grateful for your concern about the issues this licensing
> change and subsequent discussion has brought up. However, sadly, the
> amount of time it is taking to reach consensus on how/what to change
> has begu
On Fri, Mar 20, 2009 at 10:33, Ian Lance Taylor wrote:
> I'm a strong supporter of the FSF, but I agree with Danny. This has
> gone on far too long. Releasing gcc 4.4.0 with the same licensing as
> gcc 4.3.0 will do no significant harm. The FSF is acting
> inappropriately in restricting us in
On Fri, Mar 20, 2009 at 7:10 AM, Steven Bosscher wrote:
> On Fri, Mar 20, 2009 at 10:31 AM, Andi Kleen wrote:
>> Steven Bosscher writes:
>>
>>> case OPT_mfixed_range_:
>>> @@ -5245,6 +5247,13 @@ ia64_handle_option (size_t code, const char *arg,
>>> if (!strcmp (arg, processor_alias_
On Fri, Mar 20, 2009 at 3:52 PM, NightStrike wrote:
> So because Itanium1 has fallen into disuse, you are dropping support
> for Itanium2? Or have I misread this?
You are *so* wrong it's hardly worht answering, but anyway...
Of course *NOT* remove Itanium2, duh!
But yes, remove Itanum1 schedul
On Fri, Mar 20, 2009 at 9:34 AM, Daniel Berlin wrote:
> On Fri, Mar 13, 2009 at 2:28 PM, Joe Buck wrote:
>> On Fri, Mar 13, 2009 at 10:25:34AM -0700, Richard Guenther wrote:
>>> The topmost sentence should be unambiguous. Yes, the SC asked us not
>>> to branch.
>>
>> The request came from RMS, t
Hello,
I just started hacking around with the gcc internals, so apologize if
this is a noob
question:
How can I interpret the stack frame of the current_function? That
means, how can
I tell what is stored at the location FP+xxx. If that is not (easily)
possible, it would
help if I can somehow det
On Fri, 20 Mar 2009, Roberto Bagnara wrote:
> The point is that we had since long decided to make PPL 0.11, due to the
> many little glitches people has reported and due to the fact that the
> changes would not allow to preserve the ABI. Backporting all the changes
> to PPL 0.10 would be a lot of
Hi,
Sorry for sent a duplicate message.
I and Eduardo are in the same class.
But i don't know who is Diego, Egidio and Rodrigo.
:]
But thanks to everybody.
I'll read the gcc docs in the source code!
See ya!
On 3/20/09, Dave Korn wrote:
> Ben Elliston wrote:
>> Ah, good, a duplicate question t
On Fri, Mar 20, 2009 at 11:17 AM, David Edelsohn wrote:
> On Fri, Mar 20, 2009 at 9:34 AM, Daniel Berlin wrote:
>> On Fri, Mar 13, 2009 at 2:28 PM, Joe Buck wrote:
>>> On Fri, Mar 13, 2009 at 10:25:34AM -0700, Richard Guenther wrote:
The topmost sentence should be unambiguous. Yes, the SC
Peter Leist writes:
> How can I interpret the stack frame of the current_function? That
> means, how can
> I tell what is stored at the location FP+xxx. If that is not (easily)
> possible, it would
> help if I can somehow determine the type of data stored at that
> location (i.g is that
> a refer
On Fri, Mar 20, 2009 at 11:42 AM, Daniel Berlin wrote:
> Okay then, as the leadership body of the GCC community, part of your
> responsibility is keeping your constituents (the rest of us!) informed
> of the status of things troubling them.
> I don't believe saying "we have given the FSF a deadli
Guilherme Puglia wrote:
> But thanks to everybody.
> I'll read the gcc docs in the source code!
The C parser starts in gcc/c-parser.c. There are a bunch of lexing routines
at the top, then you'll see a whole bunch of c_parser_X routines which
handle the individual grammar constructs. Eac
On Sun, 2009-03-15 at 17:16 +0100, Steven Bosscher wrote:
> I can't find any test results in
> gcc-testresults reported with -mtune=itanium1 [1]. Those people who
> still use Itanium1 are probably better off if they stick with the
> older GCC releases (pre-gcc-3.4) because at least back then, Itan
David Edelsohn wrote:
> I am sorry that you did not receive the memo.
Speaking as a bystander: there has been a lack of communication. At the
start of January it was a frantic rush to get last-minute bug fixes in time
for the branch, then the license issue cropped up.
Then it all went quiet
On Fri, Mar 20, 2009 at 12:09 PM, David Edelsohn wrote:
> On Fri, Mar 20, 2009 at 11:42 AM, Daniel Berlin wrote:
>
>> Okay then, as the leadership body of the GCC community, part of your
>> responsibility is keeping your constituents (the rest of us!) informed
>> of the status of things troubling
> I guess we get to trust that it is currently more important to listen
> to the thoughts and beliefs of outsiders (who are apparently
> themselves not in contact with the rest of the community) than it is
> to listen to the people actually doing the work on GCC.
> This seems a bit strange.
To me,
On Fri, Mar 20, 2009 at 12:45 PM, Daniel Berlin wrote:
> On Fri, Mar 20, 2009 at 12:09 PM, David Edelsohn wrote:
>> On Fri, Mar 20, 2009 at 11:42 AM, Daniel Berlin wrote:
>>
>>> Okay then, as the leadership body of the GCC community, part of your
>>> responsibility is keeping your constituents (
On Fri, Mar 20, 2009 at 11:42 AM, Daniel Berlin wrote:
> >> Okay then, as the leadership body of the GCC community, part of your
> >> responsibility is keeping your constituents (the rest of us!) informed
> >> of the status of things troubling them.
> >> I don't believe saying "we have given the
On Fri, Mar 20, 2009 at 5:09 PM, David Edelsohn wrote:
> I am sorry that you did not receive the memo.
If fragmentation of the community is something the SC worries about so
much, then why do you, as a member of this self-appointed Polit-buro
(with no virtually no changes in its composition in th
On Fri, Mar 20, 2009 at 5:58 PM, Joe Buck wrote:
> The problem in this instance is that the SC has little power; it's
> the FSF that's holding things up and I don't know more than you do.
I don't understand this. Why does the SC have little power in this
matter? Surely you could decide to ship G
Steven Bosscher wrote:
On Fri, Mar 20, 2009 at 5:58 PM, Joe Buck wrote:
The problem in this instance is that the SC has little power; it's
the FSF that's holding things up and I don't know more than you do.
I don't understand this. Why does the SC have little power in this
matter? Su
On Fri, Mar 20, 2009 at 5:30 PM, Laurent GUERBY wrote:
> The compile farm machine gcc41 is a Merced based machine:
...
> model name : Merced
...
> Now I don't know if gcc41 falls in your -mtune=itanium1 category
> or not.
I believe it does. You may well have one of the last ones running there ;-)
Steven Bosscher wrote:
On Fri, Mar 20, 2009 at 5:09 PM, David Edelsohn wrote:
I am sorry that you did not receive the memo.
If fragmentation of the community is something the SC worries about so
much, then why do you, as a member of this self-appointed Polit-buro
(with no virtually no
>> I don't understand this. Why does the SC have little power in this
>> matter? Surely you could decide to ship GCC 4.4 with the old license,
>> as the official GCC maintainer? But you *choose* not to use this
>> power (perhaps for good reasons, but I'm unconvinced).
>>
> The GCC maintainers w
Jeff Law wrote:
> egcs was about growing the developer community and moving away from a
> single gating maintainer.
>
> The steering committee was formed to deal with political issues, which
> after the gcc/egcs reintegration includes most of the FSF interaction.
> Ideally the steering committee
On Fri, 2009-03-20 at 19:09 +0100, Steven Bosscher wrote:
> On Fri, Mar 20, 2009 at 5:30 PM, Laurent GUERBY wrote:
> > The compile farm machine gcc41 is a Merced based machine:
> ...
> > model name : Merced
> ...
> > Now I don't know if gcc41 falls in your -mtune=itanium1 category
> > or not.
>
>
2009/3/20, Laurent GUERBY :
> May be debian has some itanium patches.
No, GCC in Debian doesn't have any local ia64 specific patch. :-)
Arthur.
Paolo Bonzini wrote:
> Personally, what I'd like to see is a clear justification of why a
> license change motivated by plugins needs to be on a branch that will
> never have plugins. There has been already a plugin branch or two for a
> while, obviously with the old license, and the FSF said not
On Fri, Mar 20, 2009 at 7:50 PM, Laurent GUERBY wrote:
> I'm building with GCC "Debian 4.3.2-1.1" as bootstrap compiler,
> CC is not defined, configure:
>
> ../trunk/configure --prefix=/n/41/guerby/install-trunk
> --enable-languages=c,ada --enable-__cxa_atexit --disable-nls
> --enable-threads=posi
Snapshot gcc-4.4-20090320 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090320/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
> > The GCC maintainers work on behalf of the FSF and in some matters defer
> > to the FSF. It's that simple.
>
> Yes, but it's not written anywhere that release and especially branching
> policies are one of this matters.
The matters to which we defer to the FSF are any matters that they *ask*
Richard Kenner wrote:
> The matters to which we defer to the FSF are any matters that they *ask*
> us to! They own the code. If RMS, for some reason, decides that he doesn't
> like the phrasing of a comment somewhere, we have to either convince RMS
> he's wrong or change the comment.
Indeed.
I
42 matches
Mail list logo
