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 pol
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
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?
> >
>
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 als
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-
> attribu
"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 targ
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_A
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
> -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 tha
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
> > > http://www.nabble.com/-PATCH-%3A-Implementation-for-SYSV-MS-ABI-attributes-in-i386
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 l
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.
>
> http://gcc.gnu.org/ml/gcc-patches/2007
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
> 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
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 le
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
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
http://www.nabbl
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
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
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 c
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 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 n
>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
appro
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?
>
> A
> 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
> substan
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 apolo
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 formulate
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;
int
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
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
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 rev
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.
>
> http://gcc.gnu.org/ml/gcc-patches/2007-08/ms
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.
> Ja
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 a
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 submi
>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
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
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 t
> 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 in
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
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 in
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/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 po
> 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
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
> 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
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
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?
48 matches
Mail list logo
