On Sun, Sep 09, 2007 at 11:42:55AM -0700, Mark Mitchell wrote:
Other than that, the patch looks pretty good to me. However, I'd like a
middle-end maintainer to review the patch. Ian, Diego, Roger, would one
of you please take a look?
Well... ping?
to use the --param mechanism. Our policy
Mark,
Kai Tietz wrote:
Kai, why is your change making OUTGOING_REG_PARM_STACK_SPACE accept a
FUNCTION_DECL, rather than a FUNCTION_TYPE? I'd think that all
calling-convention predicates ought to be looking at the type to
support
calling through function pointers?
This macro is
Kai Tietz wrote:
I'm sorry -- that doesn't really answer the question I was trying to
ask. To be clear, if we're calling through a function pointer, we still
need to be able to do the right thing, and in that case we don't have a
FUNCTION_DECL. So, I don't understand how you can have a
Joseph S. Myers wrote on 14.09.2007 00:09:49:
On Thu, 13 Sep 2007, Michael Meissner wrote:
In the first patch, I am somewhat uncomfortable with changing
RETURN_IN_MEMORY
and OUTGOING_REG_PARM_STACK_SPACE, by adding an additional
parameter, and then
changing all of the targets. It
Mark Mitchell wrote on 13.09.2007 20:42:25:
Jan Hubicka wrote:
Kai Tietz wrote:
See
http://www.nabble.com/-PING%5E2-PATCH-%3A-Preparations-for-SYSV-
MS-ABI-attributes-in-backend-tf4414541.html
http://www.nabble.com/-PATCH-%3A-Implementation-for-SYSV-MS-ABI-
Kai Tietz wrote:
Kai, why is your change making OUTGOING_REG_PARM_STACK_SPACE accept a
FUNCTION_DECL, rather than a FUNCTION_TYPE? I'd think that all
calling-convention predicates ought to be looking at the type to support
calling through function pointers?
This macro is used also in
Kai Tietz wrote:
See
http://www.nabble.com/-PING%5E2-PATCH-%3A-Preparations-for-SYSV-MS-ABI-attributes-in-backend-tf4414541.html
http://www.nabble.com/-PATCH-%3A-Implementation-for-SYSV-MS-ABI-attributes-in-i386-may-before-stage--3-tf4428449.html
Thanks for letting me know. I'm going to
Kai Tietz wrote:
See
http://www.nabble.com/-PING%5E2-PATCH-%3A-Preparations-for-SYSV-MS-ABI-attributes-in-backend-tf4414541.html
http://www.nabble.com/-PATCH-%3A-Implementation-for-SYSV-MS-ABI-attributes-in-i386-may-before-stage--3-tf4428449.html
Thanks for letting me know. I'm going
Michael Meissner wrote:
One patch that got dropped on the floor was my patch to remove the dependency
in the back ends of the way arguments are encoded, so that eventually for LTO
we can swtich to using a vector instead of linked list.
I think that could still goto 4.3, since it's already
Ramana Radhakrishnan wrote:
I have a couple of patches that I submitted / intend to submit . One
of them was submitted today regarding a small improvement to the
auto-increment pass. I am not sure if this is suitable for stage3 if
it is approved.
Jan Hubicka wrote:
Kai Tietz wrote:
See
http://www.nabble.com/-PING%5E2-PATCH-%3A-Preparations-for-SYSV-MS-ABI-attributes-in-backend-tf4414541.html
http://www.nabble.com/-PATCH-%3A-Implementation-for-SYSV-MS-ABI-attributes-in-i386-may-before-stage--3-tf4428449.html
Thanks for letting me
On Thu, Sep 13, 2007 at 10:45:56AM +0200, Jan Hubicka wrote:
Kai Tietz wrote:
See
http://www.nabble.com/-PING%5E2-PATCH-%3A-Preparations-for-SYSV-MS-ABI-attributes-in-backend-tf4414541.html
-Original Message-
From: Mark Mitchell [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 13, 2007 2:37 PM
To: Meissner, Michael; Mark Mitchell; GCC
Subject: Re: GCC 4.3.0 Status Report (2007-09-04)
Michael Meissner wrote:
One patch that got dropped on the floor was my patch
Meissner, Michael wrote:
I didn't hear back from you, so I checked in the machine independent and
i386 parts in my SSE5 patch. Now, on to making the various ports still
work with the change.
All right; sounds good.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
On Thu, 13 Sep 2007, Michael Meissner wrote:
In the first patch, I am somewhat uncomfortable with changing RETURN_IN_MEMORY
and OUTGOING_REG_PARM_STACK_SPACE, by adding an additional parameter, and then
changing all of the targets. It might be better to have new macros
(RETURN_IN_MEMORY_ABI,
I have two patch may be worth to enter into 4.3 at stage 2.
Jan and I tried to ping the first part now about some time and we didn't
got a comment or approval for them.
See
http://www.nabble.com/-PING%5E2-PATCH-%3A-Preparations-for-SYSV-MS-ABI-attributes-in-backend-tf4414541.html
Hi,
I apologize for the late response to your mail but I sort of did these
patches up recently .
I have a couple of patches that I submitted / intend to submit . One
of them was submitted today regarding a small improvement to the
auto-increment pass. I am not sure if this is suitable for stage3
On Tue, Sep 04, 2007 at 07:40:19PM -0700, Mark Mitchell wrote:
We are closing in on Stage 3, previously announced for September 10th.
At this point, I'm not aware of any reason to delay that date. Are
there any Stage 2 patches that people don't think will be submitted by
that point?
Are
Jagasia, Harsha wrote:
I still plan to submit a patch for the x86 target cost model tuning.
Assuming that this isn't too dramatic, I'll leave approval of that
during Stage 3 to the x86 back-end maintainers.
Thanks.
The patch involves some x86 back-end bits, which Honza has already
approved
On Tue, 2007-09-04 at 19:40 -0700, Mark Mitchell wrote:
Are there Stage 1 or Stage 2 patches in need of review? I'll do my best
to either (a) convince someone to review them, or (b) review them myself.
It has only been four days since I posted the patch, but I am
waiting for a review of the
On Tue, Sep 04, 2007 at 07:40:19PM -0700, Mark Mitchell wrote:
Summary
===
We are closing in on Stage 3, previously announced for September 10th.
At this point, I'm not aware of any reason to delay that date. Are
there any Stage 2 patches that people don't think will be submitted by
Hi,
thanks for looking at the patch.
On Sun, Sep 09, 2007 at 11:42:55AM -0700, Mark Mitchell wrote:
Martin Jambor wrote:
Well, there's mine :-) Specifically, its the Switch initializations
conversion: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00215.html
Do you have an FSF copyright
Jakub Jelinek wrote:
I have a bunch of tiny patches, nevertheless all Stage 2 material, as
they add new features:
I'd like a middle-end maintainer to review this one:
redundant zero store elimination optimization (simplistic version,
but nevertheless is able to trigger many times during gcc
Peter Bergner wrote:
On Tue, 2007-09-04 at 19:40 -0700, Mark Mitchell wrote:
Are there Stage 1 or Stage 2 patches in need of review? I'll do my best
to either (a) convince someone to review them, or (b) review them myself.
It has only been four days since I posted the patch, but I am
Martin Jambor wrote:
Well, there's mine :-) Specifically, its the Switch initializations
conversion: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00215.html
Do you have an FSF copyright assignment on file? This patch is big
enough that we would not be able to include it without that.
Jakub
Rask Ingemann Lambertsen wrote:
On Tue, Sep 04, 2007 at 07:40:19PM -0700, Mark Mitchell wrote:
Are there Stage 1 or Stage 2 patches in need of review? I'll do my best
to either (a) convince someone to review them, or (b) review them myself.
Richard Guenther wrote:
There is
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01978.html
for example, which is not suitable for stage3.
This is an optimization pass which leads to dramatically better code on
at least one SPEC benchmark. Ian, Roger, Diego, would one of you care
to review
Jan Hubicka wrote:
I am still planning to do some retuning of inliner (our inline limits
wasn't revisited for inclusion of SSA optimizers).
Assuming that the tuning is essentially twiddling constants, I'm not
overly worried. If you're planning to adjust the algorithms
substantially, then I'd
Jagasia, Harsha wrote:
I still plan to submit a patch for the x86 target cost model tuning.
Assuming that this isn't too dramatic, I'll leave approval of that
during Stage 3 to the x86 back-end maintainers.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
This is an optimization pass which leads to dramatically better code on
at least one SPEC benchmark. Ian, Roger, Diego, would one of you care
to review this?
My concern is that as formulated, conditional store elimination is not
always a win.
Transforming
if (cond)
*p = x;
On 9/9/07, Roger Sayle [EMAIL PROTECTED] wrote:
This is an optimization pass which leads to dramatically better code on
at least one SPEC benchmark. Ian, Roger, Diego, would one of you care
to review this?
Btw, diego already approved the patch.
My concern is that as formulated,
Richard Guenther wrote:
On 9/9/07, Roger Sayle [EMAIL PROTECTED] wrote:
This is an optimization pass which leads to dramatically better code on
at least one SPEC benchmark. Ian, Roger, Diego, would one of you care
to review this?
Btw, diego already approved the patch.
I apologize for
Jan Hubicka wrote:
I am still planning to do some retuning of inliner (our inline limits
wasn't revisited for inclusion of SSA optimizers).
Assuming that the tuning is essentially twiddling constants, I'm not
overly worried. If you're planning to adjust the algorithms
substantially,
On Tue, Sep 04, 2007 at 07:40:19PM -0700, Mark Mitchell wrote:
Are there Stage 1 or Stage 2 patches in need of review? I'll do my best
to either (a) convince someone to review them, or (b) review them myself.
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02217.html
It's blocking work on the
Hi,
On Tue, Sep 04, 2007 at 07:40:19PM -0700, Mark Mitchell wrote:
Summary
===
We are closing in on Stage 3, previously announced for September 10th.
At this point, I'm not aware of any reason to delay that date. Are
there any Stage 2 patches that people don't think will be submitted
On 9/5/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Summary
===
We are closing in on Stage 3, previously announced for September 10th.
At this point, I'm not aware of any reason to delay that date. Are
there any Stage 2 patches that people don't think will be submitted by
that point?
There is
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01978.html
for example, which is not suitable for stage3.
As much as I like the idea, wasn't get_non_trapping considered unsafe?
Paolo
On 9/6/07, Paolo Bonzini [EMAIL PROTECTED] wrote:
There is
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01978.html
for example, which is not suitable for stage3.
As much as I like the idea, wasn't get_non_trapping considered unsafe?
Only if you tried to preserve this information
On 05/09/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Summary
===
We are closing in on Stage 3, previously announced for September 10th.
At this point, I'm not aware of any reason to delay that date. Are
there any Stage 2 patches that people don't think will be submitted by
that point?
Summary
===
We are closing in on Stage 3, previously announced for September 10th.
At this point, I'm not aware of any reason to delay that date. Are
there any Stage 2 patches that people don't think will be submitted by
that point?
I am still planning to do some retuning of inliner
On 9/4/07, Mark Mitchell [EMAIL PROTECTED] wrote:
We are closing in on Stage 3, previously announced for September 10th.
At this point, I'm not aware of any reason to delay that date. Are
there any Stage 2 patches that people don't think will be submitted by
that point?
I still plan to
Manuel López-Ibáñez wrote:
On 05/09/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Summary
===
We are closing in on Stage 3, previously announced for
September 10th.
At this point, I'm not aware of any reason to delay that date. Are
there any Stage 2 patches that people don't
On 9/4/07, Mark Mitchell [EMAIL PROTECTED] wrote:
We are closing in on Stage 3, previously announced for September
10th.
At this point, I'm not aware of any reason to delay that date. Are
there any Stage 2 patches that people don't think will be submitted
by
that point?
I still plan to
DJ Delorie wrote:
Also, we never decided if undo was worth the extra overhead. The
code is in the patch, but ifdef'd out.
URL, please?
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01317.html
It looks to me like this probably isn't quite ready for prime-time; I do
think we'd want to make
It looks to me like this probably isn't quite ready for prime-time;
I do think we'd want to make the push/pop stuff fully reliable,
including warnings emitted from the middle-end.
push-pop around functions won't be reliable until we have the file
location thing, so we can map a file:line to a
Summary
===
We are closing in on Stage 3, previously announced for September 10th.
At this point, I'm not aware of any reason to delay that date. Are
there any Stage 2 patches that people don't think will be submitted by
that point?
Are there Stage 1 or Stage 2 patches in need of review?
Mark Mitchell [EMAIL PROTECTED] writes:
Are there Stage 1 or Stage 2 patches in need of review?
Do you want the diagnostic pragma push/pop patch in?
DJ Delorie wrote:
Mark Mitchell [EMAIL PROTECTED] writes:
Are there Stage 1 or Stage 2 patches in need of review?
Do you want the diagnostic pragma push/pop patch in?
In, if it works. :-) URL, please?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
In, if it works. :-)
Well, it does what it's supposed to do. Whether that's a works in
the grand scheme of things is still debatable :-)
I'd still need to write testcases and a changelog, as I was posing it
as a what-if-example so far.
Also, we still don't guarantee proper operation in all
49 matches
Mail list logo
