Unreviewed patch

Unreviewed patch

[Rainer Orth]

The following patch has remained unrevied for a month:

	[build] Support init priority on Solaris
        https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00716.html

It needs build and ia64 maintainers and someone familiar with the init
priority support to review.

Thanks.
	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Unreviewed patch

[Jeff Law]

On 11/06/2015 06:29 AM, Rainer Orth wrote:
> The following patch has remained unrevied for a month:
>
> 	[build] Support init priority on Solaris
>          https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00716.html
>
> It needs build and ia64 maintainers and someone familiar with the init
> priority support to review.
This is OK.  Thanks for pinging -- I didn't have it in my queue of 
things to look at, so it'd definitely fallen through the cracks.
jeff

Re: Unreviewed patch

[Rainer Orth]

Jeff Law <law@redhat.com> writes:

> On 11/06/2015 06:29 AM, Rainer Orth wrote:
>> The following patch has remained unrevied for a month:
>>
>> 	[build] Support init priority on Solaris
>>          https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00716.html
>>
>> It needs build and ia64 maintainers and someone familiar with the init
>> priority support to review.
> This is OK.  Thanks for pinging -- I didn't have it in my queue of things
> to look at, so it'd definitely fallen through the cracks.

Thanks, and no worries: I'd been away for 3 weeks, so I didn't ping
before.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Unreviewed patch

[Richard Biener]

On Fri, May 25, 2018 at 12:57 AM Rainer Orth <ro@cebitec.uni-bielefeld.de>
wrote:

> The following patch has remained unreviewed for two weeks:

>          [build] Support SHF_EXCLUDE on non-x86 and with Solaris as
>          https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00465.html

> Most of it falls under my Solaris maintainership, I believe, but running
> the SHF_EXCLUDE configure test on all targets and the varasm.c change
don't.

OK.

Thanks,
Richard.

>          Rainer

> --

-----------------------------------------------------------------------------
> Rainer Orth, Center for Biotechnology, Bielefeld University

Unreviewed patch

[Rainer Orth]

The following patch has remained unreviewed for two weeks:

	[build] Support SHF_EXCLUDE on non-x86 and with Solaris as
        https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00465.html	

Most of it falls under my Solaris maintainership, I believe, but running
the SHF_EXCLUDE configure test on all targets and the varasm.c change don't.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Unreviewed patch

[Jakub Jelinek]

On Mon, Dec 12, 2016 at 01:54:41PM +0100, FX wrote:
> > The following patch has remained unreviewed for a week:
> > 
> > 	[build] Disable hwcaps on libgfortran
> >        https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00336.html
> > 
> > It is required to unbreak bootstrap on Solaris/x86 and, though touching
> > both libgfortran and libitm, probably needs primarily a build
> > maintainer or global reviewer.
> 
> The Fortran part is OK, but I can’t approve the libitm part.

The libitm change is ok too.

	Jakub

Re: Unreviewed patch

[FX]

> The following patch has remained unreviewed for a week:
> 
> 	[build] Disable hwcaps on libgfortran
>        https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00336.html
> 
> It is required to unbreak bootstrap on Solaris/x86 and, though touching
> both libgfortran and libitm, probably needs primarily a build
> maintainer or global reviewer.

The Fortran part is OK, but I can’t approve the libitm part.

FX

Unreviewed patch

[Rainer Orth]

The following patch has remained unreviewed for a week:

	[build] Disable hwcaps on libgfortran
        https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00336.html

It is required to unbreak bootstrap on Solaris/x86 and, though touching
both libgfortran and libitm, probably needs primarily a build
maintainer or global reviewer.

Besides, it's a prerequisite to fix a similar breakage in libgo:

        https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00726.html

Thanks.
        Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Unreviewed patch

[Jeff Law]

On 04/06/2016 04:58 AM, Rainer Orth wrote:
> The following patch has remainded unreviewed for a week:
>
> 	[testsuite, sparcv9] Fix gcc.dg/ifcvt-4.c on 64-bit SPARC (PR rtl-optimization/68749)
> 	https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01631.html
>
> Although it's testsuite-only, I'm quite reluctant to make potential
> semantic changes to a testcase without approval from the subject-matter
> expert.
It's OK for the trunk.

jeff

Unreviewed patch

[Rainer Orth]

The following patch has remainded unreviewed for a week:

	[testsuite, sparcv9] Fix gcc.dg/ifcvt-4.c on 64-bit SPARC (PR rtl-optimization/68749)
	https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01631.html

Although it's testsuite-only, I'm quite reluctant to make potential
semantic changes to a testcase without approval from the subject-matter
expert.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Unreviewed Patch

[Jeff Law]

On 02/22/14 16:07, rbmj wrote:
> Hi all,
>
> Just a ping, I haven't gotten anything back on this patch:
> http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00621.html
The patch needs to be tested by bootstrapping on another platform and 
performing a regression test.    Most folks use an x86_64 linux system 
for that step.

While the odds that this patch breaks things is small, the regression 
test and bootstrap has proven quite valuable through the years in 
catching issues.

jeff

Re: Unreviewed Patch

[rbmj]

On 25-Feb-14 01:21, Jeff Law wrote:
> I think this should be queued until after 4.9 branches.  It's adding a
> new capability (posix threading on vxworks), not fixing a bug and
> certainly not fixing a regression AFAICT.

Fair enough.  It just seems somewhat trivial to me, as it doesn't add 
any functional code, just some #defines and a stub.

Bug could be "compilation of pthread-based gthreads disallowed on 
platform (vxworks) supporting pthreads", but that's a stretch, so if you 
want I can resubmit it after 4.9 branches.  I just think that users 
should be able to compile targeting pthreads if they know that their 
target will support it, especially if it enables additional capabilities 
(e.g. C++11 std::thread).

Re: Unreviewed Patch

[Jeff Law]

On 02/22/14 16:07, rbmj wrote:
> Hi all,
>
> Just a ping, I haven't gotten anything back on this patch:
> http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00621.html
I think this should be queued until after 4.9 branches.  It's adding a 
new capability (posix threading on vxworks), not fixing a bug and 
certainly not fixing a regression AFAICT.

jeff

Unreviewed Patch

[rbmj]

Hi all,

Just a ping, I haven't gotten anything back on this patch:
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00621.html

Thanks!

Re: Unreviewed patch

[Andreas Toler]

On 15.11.10 21:09, Rainer Orth wrote:
> The following patch has remained unreviewed for a week:
>
> 	[libffi, testsuite] Rename libffi-dg.exp to libffi.exp
> 	http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00746.html
>
> It's probably close to obvious.  For lack of a testsuite maintainer,
> either a libffi maintainer (Anthony) or a Global Reviewer needs to
> approve this.

This is ok.

And sorry for not seeing it earlier.

Thanks,
Andreas

Unreviewed patch

[Rainer Orth]

The following patch has remained unreviewed for a week:

	[libffi, testsuite] Rename libffi-dg.exp to libffi.exp
	http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00746.html

It's probably close to obvious.  For lack of a testsuite maintainer,
either a libffi maintainer (Anthony) or a Global Reviewer needs to
approve this.

Thanks.
	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Unreviewed patch

[Rainer Orth]

Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:

> This:
>
> --- a/libstdc++-v3/testsuite/Makefile.am        Mon Jan 25 10:22:04 2010 +0000
> +++ b/libstdc++-v3/testsuite/Makefile.am        Wed Feb 03 19:26:03 2010 +0100
> @@ -103,6 +103,8 @@
>  
>  # Run the testsuite in normal mode.
>  check-DEJAGNU $(check_DEJAGNU_normal_targets): check-DEJAGNU%: site.exp
> +       AR=$(AR); export AR; \
> +       RANLIB=$(RANLIB); export RANLIB; \
>
> would probably be safer if the $(AR) and $(RANLIB) were enclosed in
> quotes, in case some user uses RANLIB="ranlib -t" or so.

Thanks for pointing this out.  I've made the change and commited, based
on Paolo's approval.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Unreviewed patch

[Ralf Wildenhues]

Hello Rainer,

* Rainer Orth wrote on Wed, Feb 24, 2010 at 02:01:59PM CET:
> The following patch has remained unreviewed for about a month:
> 
> 	PATCH: Fix libstdc++ testsuite on systems without ranlib (PR libstdc++/32499)
>         http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00139.html
> 
> It probably needs both a build and a libstdc++ maintainer for review.

This:

--- a/libstdc++-v3/testsuite/Makefile.am        Mon Jan 25 10:22:04 2010 +0000
+++ b/libstdc++-v3/testsuite/Makefile.am        Wed Feb 03 19:26:03 2010 +0100
@@ -103,6 +103,8 @@
 
 # Run the testsuite in normal mode.
 check-DEJAGNU $(check_DEJAGNU_normal_targets): check-DEJAGNU%: site.exp
+       AR=$(AR); export AR; \
+       RANLIB=$(RANLIB); export RANLIB; \

would probably be safer if the $(AR) and $(RANLIB) were enclosed in
quotes, in case some user uses RANLIB="ranlib -t" or so.

Other than that, I cannot really judge the patch.

Cheers,
Ralf

Re: Unreviewed patch

[Rainer Orth]

Paolo Carlini <paolo.carlini@oracle.com> writes:

> On 02/24/2010 02:01 PM, Rainer Orth wrote:
>> The following patch has remained unreviewed for about a month:
>>
>> 	PATCH: Fix libstdc++ testsuite on systems without ranlib (PR libstdc++/32499)
>>         http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00139.html
>>   
> Did you reply to Paolo (Bonzini)?
>
>     http://gcc.gnu.org/ml/libstdc++/2010-02/msg00025.html

I haven't ever seen that mail, though I'm subscribed to gcc-patches.
Very strange.  I'll investigate.

Thanks.
	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Unreviewed patch

[Paolo Carlini]

On 02/24/2010 02:01 PM, Rainer Orth wrote:
> The following patch has remained unreviewed for about a month:
>
> 	PATCH: Fix libstdc++ testsuite on systems without ranlib (PR libstdc++/32499)
>         http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00139.html
>   
Did you reply to Paolo (Bonzini)?

    http://gcc.gnu.org/ml/libstdc++/2010-02/msg00025.html

Paolo

Unreviewed patch

[Rainer Orth]

The following patch has remained unreviewed for about a month:

	PATCH: Fix libstdc++ testsuite on systems without ranlib (PR libstdc++/32499)
        http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00139.html

It probably needs both a build and a libstdc++ maintainer for review.

Thanks.
        Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Unreviewed patch

[Adam Nemet]

Roger Sayle writes:
> >   New target-hook: mode_rep_extended.  The MIPS part was already
> >   approved by Richard Sandiford.
> This is OK for mainline.  Thanks.

Thanks very much, Roger.  I rebootstrapped and retested the patch and
checked it in.

Adam

Re: Unreviewed patch

[Roger Sayle]

On Sat, 15 Apr 2006, Adam Nemet wrote:
> http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01366.html
>
>   New target-hook: mode_rep_extended.  The MIPS part was already
>   approved by Richard Sandiford.

This is OK for mainline.  Thanks.

Roger
--

Unreviewed patch

[Adam Nemet]

Can someone please review this patch.  It was submitted before Stage 3.

http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01366.html

  New target-hook: mode_rep_extended.  The MIPS part was already
  approved by Richard Sandiford.

Thanks,
Adam

Unreviewed patch

[Caroline Tice]

The following patch still needs to be reviewed.

Proper hot/cold partitioning fixes
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01999.html


-- Caroline Tice
ctice@apple.com

Unreviewed Patch

[Andreas Krebbel]

Hi,

unreviewed patch:

- local alloc patch fixing a performance degradation on big endian machines
regarding multiword registers:

http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00659.html

Bye,

-Andreas-

Unreviewed patch

[Jakub Jelinek]

Stdarg optimization:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02897.html

	Jakub

Re: Unreviewed patch

[Roger Sayle]

On Fri, 1 Apr 2005, Jakub Jelinek wrote:
> Handle different mode size conversions involving vectors in convert_move
> PR rtl-optimization/16104
> http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01598.html

This is OK for mainline.  The approved patch is the change to fold_unary
and not the original patch to "convert_move" mentioned above! :)
This regression fix is also Ok for the 4.0 and 3.4 branches, provided
that its bootstraped and regression tested without problems against the
appropriate branch before committing.

Thanks to both you and RTH for resolving this problem.

Roger
--

Unreviewed patch

[Jakub Jelinek]

Hi!

Handle different mode size conversions involving vectors in convert_move
PR rtl-optimization/16104
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01598.html

	Jakub

Unreviewed patch

[Eric Botcazou]

Hi,

A problem with chrecs (PR tree-optimization/19903)
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01024.html

Thanks in advance.

-- 
Eric Botcazou

Re: unreviewed patch

[Alan Modra]

On Wed, Nov 10, 2004 at 01:05:46PM +1030, Alan Modra wrote:
> 8 months without a review.
> 
> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01144.html
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14010

Sorry, I'd forgotten that this has been fixed on mainline with another
patch.  It remains a 3.4.x failure.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

unreviewed patch

[Alan Modra]

8 months without a review.

http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01144.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14010

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Unreviewed patch

[Ulrich Weigand]

Roger Sayle wrote:
> On Wed, 13 Oct 2004, Ulrich Weigand wrote:
> > OK if testing is successful everywhere?
> 
> Sure.

Thanks!

> I do have one more small request though.  Is it possible to add a new
> test case to the testsuite?  You mentioned in your original e-mail,
> this problem is currently latent and only exposed by a change you're
> planning on making to ths s390 backend.  If it's relatively easy to
> reduce a test (that at least triggers this code), it would be nice
> to add it to the testsuite, perhaps when you commit your backend
> changes.

There is already a test case for basically exactly this situation:
gcc.c-torture/execute/multi-ix.c

And in fact this test case currently fails if I remove the back-end
workaround without having the reload fix in place.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: Unreviewed patch

[Roger Sayle]

On Wed, 13 Oct 2004, Ulrich Weigand wrote:
> > Would it be OK for ask you to bootstrap and regression test this patch
> > on at least one other platform?  May be x86 and/or powerpc?  As you'll
> > appreciate accepting patches to reload is a risky business, even before
> > stage3.
>
> Sure.  I don't have ready access to powerpc, but I'll test the patch
> on x86 and ia64, if that's OK with you.  (Testing will take at least
> until tomorrow, though.)
>
> OK if testing is successful everywhere?

Sure.

I do have one more small request though.  Is it possible to add a new
test case to the testsuite?  You mentioned in your original e-mail,
this problem is currently latent and only exposed by a change you're
planning on making to ths s390 backend.  If it's relatively easy to
reduce a test (that at least triggers this code), it would be nice
to add it to the testsuite, perhaps when you commit your backend
changes.

Roger
--

Re: Unreviewed patch

[Ulrich Weigand]

Roger Sayle wrote:

> Would it be OK for ask you to bootstrap and regression test this patch
> on at least one other platform?  May be x86 and/or powerpc?  As you'll
> appreciate accepting patches to reload is a risky business, even before
> stage3.

Sure.  I don't have ready access to powerpc, but I'll test the patch
on x86 and ia64, if that's OK with you.  (Testing will take at least
until tomorrow, though.)

> With the exception of setting goal_alternative_win, this hunk
> looks like a obvious extension of the non-PLUS case, but I'm not
> confident enough to believe it's totally safe without some additional
> testing.

Setting goal_alternative_win would be wrong: if we have *just* a constant,
and this gets forced to the pool, and the insn directly accepts a memory
operand, we need no reload at all any more, so goal_alternative_win can
be set to true.  In the *new* case, however, even after we forced the
constant, we still have to compute the PLUS, so we still require a reload.

I found another place where simply copying the constant case was wrong:
in the 'just a constant case', it makes sense to force the constant 
even though it would be OK, if we cannot allow input reloads (that's
the || no_input_reload case).  In the PLUS case, we require the reload
in any case, so no_input_reload must not be true anyway, and the test
is redundant and probably misleading, so I've removed it now.

The following patch shows this modified version of the patch, together
with the s390-specific parts that remove the workarounds no longer
required after reload it fixed.  I'm currently in the progress of
bootstrapping and regression testing that patch on s390-ibm-linux,
s390x-ibm-linux, i686-pc-linux, and ia64-unknown-linux.

OK if testing is successful everywhere?

Bye,
Ulrich


Index: gcc/reload.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/reload.c,v
retrieving revision 1.256
diff -c -p -r1.256 reload.c
*** gcc/reload.c	12 Oct 2004 19:28:55 -0000	1.256
--- gcc/reload.c	13 Oct 2004 19:14:27 -0000
*************** find_reloads (rtx insn, int replace, int
*** 3778,3783 ****
--- 3778,3804 ----
  	  goal_alternative_win[i] = 1;
        }
  
+   /* Likewise any invalid constants appearing as operand of a PLUS
+      that is to be reloaded.  */
+   for (i = 0; i < noperands; i++)
+     if (! goal_alternative_win[i]
+ 	&& GET_CODE (recog_data.operand[i]) == PLUS
+ 	&& CONST_POOL_OK_P (XEXP (recog_data.operand[i], 1))
+ 	&& (PREFERRED_RELOAD_CLASS (XEXP (recog_data.operand[i], 1),
+ 				    (enum reg_class) goal_alternative[i])
+ 	     == NO_REGS)
+ 	&& operand_mode[i] != VOIDmode)
+       {
+ 	rtx tem = force_const_mem (operand_mode[i],
+ 				   XEXP (recog_data.operand[i], 1));
+ 	tem = gen_rtx_PLUS (operand_mode[i],
+ 			    XEXP (recog_data.operand[i], 0), tem);
+ 
+ 	substed_operand[i] = recog_data.operand[i]
+ 	  = find_reloads_toplev (tem, i, address_type[i],
+ 				 ind_levels, 0, insn, NULL);
+       }
+ 
    /* Record the values of the earlyclobber operands for the caller.  */
    if (goal_earlyclobber)
      for (i = 0; i < noperands; i++)
Index: gcc/config/s390/s390.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/s390/s390.c,v
retrieving revision 1.193
diff -c -p -r1.193 s390.c
*** gcc/config/s390/s390.c	12 Oct 2004 20:37:15 -0000	1.193
--- gcc/config/s390/s390.c	13 Oct 2004 19:14:28 -0000
*************** s390_secondary_input_reload_class (enum 
*** 2274,2290 ****
  				   enum machine_mode mode, rtx in)
  {
    if (s390_plus_operand (in, mode))
!     {
!       /* ??? Reload sometimes pushes a PLUS reload with a too-large constant.
! 	 Until reload is fixed, we need to force_const_mem while emitting the
! 	 secondary reload insn -- thus we need to make sure here that we do
! 	 have a literal pool for the current function.  */
!       if (CONSTANT_P (XEXP (in, 1))
! 	  && !legitimate_reload_constant_p (XEXP (in, 1)))
! 	current_function_uses_const_pool = true;
! 
!       return ADDR_REGS;
!     }
  
    return NO_REGS;
  }
--- 2274,2280 ----
  				   enum machine_mode mode, rtx in)
  {
    if (s390_plus_operand (in, mode))
!     return ADDR_REGS;
  
    return NO_REGS;
  }
*************** s390_expand_plus_operand (register rtx t
*** 2366,2375 ****
  	}
        if (true_regnum (sum2) < 1 || true_regnum (sum2) > 15)
  	{
- 	  /* ??? See comment in s390_secondary_input_reload_class.  */
- 	  if (CONSTANT_P (sum2) && !legitimate_reload_constant_p (sum2))
- 	    sum2 = force_const_mem (Pmode, sum2);
- 
  	  emit_move_insn (scratch, sum2);
  	  sum2 = scratch;
  	}
--- 2356,2361 ----


-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: Unreviewed patch

[Roger Sayle]

On Tue, 12 Oct 2004, Ulrich Weigand wrote:
> [PATCH] Fix too-large constants pushed as reload
> http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02977.html

Would it be OK for ask you to bootstrap and regression test this patch
on at least one other platform?  May be x86 and/or powerpc?  As you'll
appreciate accepting patches to reload is a risky business, even before
stage3.  With the exception of setting goal_alternative_win, this hunk
looks like a obvious extension of the non-PLUS case, but I'm not
confident enough to believe it's totally safe without some additional
testing.

Many thanks in advance,
[Don't let this request stop you commiting your patch, if another
maintainer is happy to approve it without any additional testing].

Roger
--

Unreviewed patch

[Ulrich Weigand]

[PATCH] Fix too-large constants pushed as reload
http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02977.html

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: unreviewed patch

[Richard Henderson]

On Mon, Aug 16, 2004 at 11:49:37PM +0200, Lars Sonchocky-Helldorf wrote:
> http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00506.html

I guess this is ok, since all functional changes are protected
by TARGET_MACHO.

I really really really hate how Darwin represents things though.

IMO, we should be re-using UNSPEC_GOTOFF for base-label relative
references and UNSPEC_GOT for non-lazy-ptr references.  The only
places we need darwin-specific hooks is then in output_pic_addr_const
when we turn the unspecs into assembly syntax.  The x86 rtl patterns
and predicates don't have to know anything special.



r~

unreviewed patch

[Lars Sonchocky-Helldorf]

There is a still unreviewed patch of Mon, 9 Aug 2004 09:20:21 -0700 
pending:

http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00506.html

I'd very much appreciate if that patch could be reviewed by a person 
with x86 Backend approval authority (and with some knowledge regarding 
PIC). If this patch gets approved it would enable me to build gcc 3.5 
on Darwin x86 again (currently only gcc 3.3 without C++ builds) and 
help me this way to advance the GNUstep port on that platform.

Please have also a look at the follow-ups esp.:

http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00534.html


regards, Lars

Re: Unreviewed patch

[Roger Sayle]

On Mon, 28 Jun 2004, Ulrich Weigand wrote:
> Roger Sayle wrote:
> > This patch looks fine technically and conceptually, but I'd feel much
> > happier if it had been tested on more than just the s390 backend.
> > Ok for mainline provided that bootstrapping and regression testing
> > pass on at least one other architecture, perhaps x86 or powerpc?
>
> I've now bootstrapped and tested (with no new regressions) the patch
> on i686-pc-linux and ia64-unknown-linux.  OK to commit now?

Certainly.  Thanks for this additional testing.

Roger
--

Re: Unreviewed patch

[Ulrich Weigand]

Roger Sayle wrote:
> This patch looks fine technically and conceptually, but I'd feel much
> happier if it had been tested on more than just the s390 backend.
> Ok for mainline provided that bootstrapping and regression testing
> pass on at least one other architecture, perhaps x86 or powerpc?

I've now bootstrapped and tested (with no new regressions) the patch
on i686-pc-linux and ia64-unknown-linux.  OK to commit now?

Bye,
Ulric

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: Unreviewed patch

[Roger Sayle]

On Sun, 27 Jun 2004, Ulrich Weigand wrote:
> [PATCH] Re: Use-and-clobber insns and some ancient combine.c code
> http://gcc.gnu.org/ml/gcc-patches/2004-06/msg01546.html

This patch looks fine technically and conceptually, but I'd feel much
happier if it had been tested on more than just the s390 backend.
Ok for mainline provided that bootstrapping and regression testing
pass on at least one other architecture, perhaps x86 or powerpc?

My paranoia over the statement "If (reg X) is a fixed register, the
pattern shouldn't be recognized if it is not safe" requires that GCC's
backends are all correctly coded.  Ensuring that at least the most
popular GCC targets don't immediately suffer bootstrap failures, will
help support any argument that platforms that do regress, reflects
a problem with their machine descriptions, and not with this patch.

I hope this sounds reasonable.

Roger
--

Unreviewed patch

[Ulrich Weigand]

[PATCH] Re: Use-and-clobber insns and some ancient combine.c code
http://gcc.gnu.org/ml/gcc-patches/2004-06/msg01546.html

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Unreviewed patch

[Rainer Orth]

The following patch

	http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00875.html

has remained unreviewed for some time (except for the fixincludes part).

	Rainer

Unreviewed patch

[Josef Zlomek]

Hello,

please someone look at this patch?

Duplicate computed gotos
http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01670.html

Thanks,

Josef

Re: Unreviewed patch

[Roger Sayle]

On Wed, 26 May 2004, Josef Zlomek wrote:
> Fix PR/14084 - big endian correction for REG_OFFSETs
> http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01221.html

This seems Ok for mainline.  Please use "PR middle-end/14084"
in the ChangeLog entry, and not just "PR/14084".

Thanks.

Roger
--

Unreviewed patch

[Josef Zlomek]

Hello,

Fix PR/14084 - big endian correction for REG_OFFSETs
http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01221.html

Thanks,

Josef

Re: Unreviewed patch

[Roger Sayle]

On Thu, 29 Apr 2004, Josef Zlomek wrote:
> Fix removing notes in GCSE store motion
> http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01167.html

This looks OK for mainline.

Please investigate creating a new gcc.dg regression test for the
testsuite from the testcase in your original posting.

Thanks,

Roger
--

Unreviewed patch

[Josef Zlomek]

Hello,

please could someone review following patch?


Fix removing notes in GCSE store motion
http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01167.html


Thanks.

Josef

Re: Unreviewed patch

[Roger Sayle]

On Thu, 25 Mar 2004, Kaveh R. Ghazi wrote:
> It's been around two weeks since I posted this patch:
> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01033.html

This is Ok for mainline.

Roger
--

Unreviewed patch

[Kaveh R. Ghazi]

It's been around two weeks since I posted this patch:

http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01033.html

Would someone please review it?  It would be much appreciated.

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Unreviewed patch

[Jason Merrill]

No, this is wrong.  We already handle reuse earlier in the function; your
change would cause us to use an unqualified type where what we want is a
qualified type.

Jason

Unreviewed patch

[Devang Patel]

Begin forwarded message:

> From: Devang Patel <dpatel@apple.com>
> Date: February 1, 2004 12:54:06 PM PST
> To: GCC Patches <gcc-patches@gcc.gnu.org>
> Subject: [PATCH] PR/8354
>
>
> While emitting new type die, reuse existing one if available.
>
> Bootstrapped and tested on i686-pc-linux-gnu.
> GCC, libstdc++ and GDB DejaGNU tests do not report any new
> regression.
>
> OK for mainline?
> Thank you,
> --
> Devang
>
> 2004-01-02  Devang Patel  <dpatel@apple.com>
>
>         PR/8354
>         *dwarf2out.c (modified_type_die): Reuse existing type die.
>
> Index: dwarf2out.c
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/dwarf2out.c,v
> retrieving revision 1.483
> diff -c -3 -p -r1.483 dwarf2out.c
> *** dwarf2out.c 29 Jan 2004 18:42:56 -0000      1.483
> --- dwarf2out.c 1 Feb 2004 20:43:06 -0000
> *************** modified_type_die (tree type, int is_con
> *** 7964,7969 ****
> --- 7964,7977 ----
>           /* Else cv-qualified version of named type; fall through.  */
>         }
>
> +       /* Just reuse the type die, if it exists.  */
> +       if (!mod_type_die)
> +       {
> +         mod_type_die = lookup_type_die (type);
> +         if (mod_type_die)
> +           return mod_type_die;
> +       }
> +
>         if (mod_type_die)
>         /* OK.  */
>         ;
>
>
--
Devang

Re: Unreviewed patch

[Jason Merrill]

No, this is wrong.  We already handle reuse earlier in the function; your
change would cause us to use an unqualified type where what we want is a
qualified type.

Jason

Unreviewed patch

[Devang Patel]

Begin forwarded message:

> From: Devang Patel <dpatel@apple.com>
> Date: February 1, 2004 12:54:06 PM PST
> To: GCC Patches <gcc-patches@gcc.gnu.org>
> Subject: [PATCH] PR/8354
>
>
> While emitting new type die, reuse existing one if available.
>
> Bootstrapped and tested on i686-pc-linux-gnu.
> GCC, libstdc++ and GDB DejaGNU tests do not report any new
> regression.
>
> OK for mainline?
> Thank you,
> --
> Devang
>
> 2004-01-02  Devang Patel  <dpatel@apple.com>
>
>         PR/8354
>         *dwarf2out.c (modified_type_die): Reuse existing type die.
>
> Index: dwarf2out.c
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/dwarf2out.c,v
> retrieving revision 1.483
> diff -c -3 -p -r1.483 dwarf2out.c
> *** dwarf2out.c 29 Jan 2004 18:42:56 -0000      1.483
> --- dwarf2out.c 1 Feb 2004 20:43:06 -0000
> *************** modified_type_die (tree type, int is_con
> *** 7964,7969 ****
> --- 7964,7977 ----
>           /* Else cv-qualified version of named type; fall through.  */
>         }
>
> +       /* Just reuse the type die, if it exists.  */
> +       if (!mod_type_die)
> +       {
> +         mod_type_die = lookup_type_die (type);
> +         if (mod_type_die)
> +           return mod_type_die;
> +       }
> +
>         if (mod_type_die)
>         /* OK.  */
>         ;
>
>
--
Devang

Unreviewed patch

[Josef Zlomek]

Hello,

plase could somebody look at
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02220.html

It fixes a bug triggered when inlining function x into y and then y into x.

Thanks.

Joe

Here is the updated patch with comment:

Index: tree-inline.c
===================================================================
RCS file: /cvs/gcc-cvs/gcc/gcc/tree-inline.c,v
retrieving revision 1.34.2.17
diff -c -p -c -3 -p -r1.34.2.17 tree-inline.c
*** tree-inline.c	3 Jan 2004 18:13:44 -0000	1.34.2.17
--- tree-inline.c	26 Jan 2004 20:09:30 -0000
*************** copy_body_r (tp, walk_subtrees, data)
*** 490,497 ****
    /* Local variables and labels need to be replaced by equivalent
       variables.  We don't want to copy static variables; there's only
       one of those, no matter how many times we inline the containing
!      function.  */
!   else if ((*lang_hooks.tree_inlining.auto_var_in_fn_p) (*tp, fn))
      {
        tree new_decl;
  
--- 490,500 ----
    /* Local variables and labels need to be replaced by equivalent
       variables.  We don't want to copy static variables; there's only
       one of those, no matter how many times we inline the containing
!      function.
!      We do not also want to copy the label which we put into
!      GOTO_STMT which replaced RETURN_STMT.  */
!   else if (*tp != id->ret_label
! 	   && (*lang_hooks.tree_inlining.auto_var_in_fn_p) (*tp, fn))
      {
        tree new_decl;
  

Unreviewed patch

[kaz Kojima]

Hi,

This is a patch ping for

[PR optimization/13567]
<URL:http://gcc.gnu.org/ml/gcc-patches/2004-01/msg00559.html>.

Regards,
	kaz

Unreviewed patch

[Devang Patel]

ping!

[PATCH] C++/DWARF : Add 'using' support - take 2
http://gcc.gnu.org/ml/gcc-patches/2003-12/msg01778.html

--
Devang

Re: Unreviewed patch

[Jim Wilson]

Roger Sayle wrote:
> The following patch has received no comment since it was reposted
> over a month ago.
> http://gcc.gnu.org/ml/gcc-patches/2003-10/msg02311.html

I looked at the original discussion you had with Richard Henderson about 
this back in August.  I also looked at the gcc sources.

The middle-end is careful to preserve the semantics of 
SUBREG_PROMOTED_VAR_P.  Note that expand_expr, and calls.c/function.c 
only create them when we are reading from a VAR_DECL or PARM_DECL. 
store_expr has special code for SUBREG_PROMOTED_VAR_P as a destination, 
and makes sure the value is extended properly before the store.  Thus we 
can be sure that the VAR_DECL/PARM_DECL always has a properly extended 
value, and that in the middle end, if we have SUBREG_PROMOTED_VAR_P, it 
is safe to assume that the value is already extended.  Some middle end 
routines already do this, namely convert_move, convert_modes, and 
widen_operand.

What happens when we get to RTL is less clear, but I see that 
nonzero_bits and num_sign_bit_copies in combine are using them for 
optimization.  basic_indunction_var in loop also uses it, but this is 
only to identify that we are setting the same reg that we are reading, 
so this makes no assumption about sign/zero extension.  The use in 
combine.c is fairly convincing that it must be safe even during RTL 
optimization.  Looking at the RTL, I see that this is only used with 
pseudos that hold variables, reg/v.  Every store to these pseudos is 
sign/zero extended, and every read has subreg/s.  As long as we ensure 
that the extending stores are never optimized away, then it is safe to 
assume that the underlying reg of subreg/s is properly extended.  Since 
we only use this for word sized or smaller values, we would need some 
kind of optimization pass that tracked the range of values, and detected 
when the sign extend was unnecessary because all following uses did not 
use the sign extended part.  I think we have such a pass, VRP on the 
rtlopt branch.  If it does anything like this, then it will have to 
handle subreg/s specially, or else stuff breaks.  When it sees subreg/s, 
it must assume that the entire register is used, or else if must change 
the subreg/s to a regular subreg.  Otherwise, I think the only place 
that could potentially eliminate a sign_extend and retain the store 
would be combine itself, by combining an extend with a following subreg 
or subreg/s and then splitting.  This could invalidate the subreg/s 
info.  However, since there is nothing after combine that uses subreg/s, 
and combine is internally consistent, this appears safe.

So, my conclusion is
1) The do_jump part of the patch is safe, because it is a middle-end patch.
2) The simplify_rtx patch can be safe, if
a) any optimization pass that can optimize sign/zero extends such as a 
value range propagation pass, has special treatment for subreg/s, either 
preserving the sign/zero extends, or converting the subreg/s to subreg, and
b) after combine we ensure that either
i) there are no further uses of subreg/s for optimization purposes, or
ii) we change subreg/s to subreg if a sign_extend store got optimized away

2-a does not currently exist, but one is potentially proposed (VRP). 
2-b-i is currently true, but mainly because there has been no real 
attempt to use subreg/s.  Since combine already does subreg/s 
optimizations, the simplify_rtx patch does not appear to create 
additional risk.

The patch is approved, but if you check in the simplify_rtx patch you 
will have to watch for potential problems.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Unreviewed patch

[Ulrich Weigand]

Gabriel Dos Reis wrote:
> "Zack Weinberg" <zack@codesourcery.com> writes:
> | Okay, in that case I approve the patch for mainline, and you should
> | inquire of Gaby whether it's okay for 3.3 branch.
> 
> Assuming proper testing reveals no regression, it is OK.
> 
> Thanks for reviewing.

I've now committed the fix to both head and 3.3 branch.

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: Unreviewed patch

[Gabriel Dos Reis]

"Zack Weinberg" <zack@codesourcery.com> writes:

| Ulrich Weigand <weigand@i1.informatik.uni-erlangen.de> writes:
| ...
| > As to why this is the right fix, if you look at all the other
| > places in unroll.c (or loop.c) where the BIV initial value
| > is used in some computation involving a GIV, it is *always*
| > passed through extend_value_for_giv.  This was initially
| > introduced by rth's patch
| > http://gcc.gnu.org/ml/gcc-patches/2000-09/msg00257.html
| >
| > It looks like this was just forgotten at that one location,
| > and simply unnoticed until now because it's hard to trigger.
| 
| Okay, in that case I approve the patch for mainline, and you should
| inquire of Gaby whether it's okay for 3.3 branch.

Assuming proper testing reveals no regression, it is OK.

Thanks for reviewing.

-- Gaby

Re: Unreviewed patch

[Zack Weinberg]

Ulrich Weigand <weigand@i1.informatik.uni-erlangen.de> writes:
...
> As to why this is the right fix, if you look at all the other
> places in unroll.c (or loop.c) where the BIV initial value
> is used in some computation involving a GIV, it is *always*
> passed through extend_value_for_giv.  This was initially
> introduced by rth's patch
> http://gcc.gnu.org/ml/gcc-patches/2000-09/msg00257.html
>
> It looks like this was just forgotten at that one location,
> and simply unnoticed until now because it's hard to trigger.

Okay, in that case I approve the patch for mainline, and you should
inquire of Gaby whether it's okay for 3.3 branch.

zw

Re: Unreviewed patch

[Ulrich Weigand]

Zack Weinberg wrote:

> Could you provide a little more context?  The code that causes the
> ICE, for instance, and an analysis of why this is the right fix.

Unfortunately I don't have a test case that triggers the ICE on
either mainline or 'vanilla' 3.3; we saw it when using a compiler
based on 3.3 with this mainline patch backported:
http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01701.html
(With that compiler, the ICE showed in one of the SPECint apps.)

On vanilla 3.3 the problem doesn't show because in that particular
case the ext_dependant giv isn't recognized (without the patch above),
on CVS head it doesn't show because the old unroller isn't really
used any more.

I just thought it would be best to fix it as the fix appears
to be rather obvious, and the problem can conceivably show up 
(in other cases) even in a vanilla 3.3 or else in CVS head when 
using -fold-unroll-loops.

As to why this is the right fix, if you look at all the other
places in unroll.c (or loop.c) where the BIV initial value
is used in some computation involving a GIV, it is *always*
passed through extend_value_for_giv.  This was initially
introduced by rth's patch
http://gcc.gnu.org/ml/gcc-patches/2000-09/msg00257.html

It looks like this was just forgotten at that one location,
and simply unnoticed until now because it's hard to trigger.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: Unreviewed patch

[Zack Weinberg]

Ulrich Weigand <weigand@i1.informatik.uni-erlangen.de> writes:

> Hello, 
>
> the following patch has been unreviewed for some time:
>
> [PATCH] Fix ICE in old unroller
> http://gcc.gnu.org/ml/gcc-patches/2003-10/msg02221.html

Could you provide a little more context?  The code that causes the
ICE, for instance, and an analysis of why this is the right fix.

zw

Unreviewed patch

[Ulrich Weigand]

Hello, 

the following patch has been unreviewed for some time:

[PATCH] Fix ICE in old unroller
http://gcc.gnu.org/ml/gcc-patches/2003-10/msg02221.html

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Unreviewed patch

[Roger Sayle]

The following patch has received no comment since it was reposted
over a month ago.

http://gcc.gnu.org/ml/gcc-patches/2003-10/msg02311.html

Not only does it fix the failure of gcc.dg/uninit-A.c on alpha
but its an important step towards resolving PR middle-end/13191,
which is an enhancement request for reducing the number of
unneccessary sign and zero extensions performed by GCC.

Many thanks in advance,

Roger
--

Unreviewed patch

[Josef Zlomek]

Fix PR/11640
http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00905.html
  (latest patch)
http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00628.html
  (original message with testcase and more description)

Re: Unreviewed patch

[Eric Christopher]

On Wed, 2003-08-13 at 01:58, Richard Sandiford wrote:
> This one didn't get a review:
> 
>     http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02768.html
> 
> It's the trunk version of:
> 
>     http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02766.html
> 
> OK to install?

OK.

-eric

-- 
Eric Christopher <echristo@redhat.com>

Unreviewed patch

[Richard Sandiford]

This one didn't get a review:

    http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02768.html

It's the trunk version of:

    http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02766.html

OK to install?

One thing I forgot to mention in the covering note was that:

	  /* va_arg is an array access in this case, which causes
	     it to get MEM_IN_STRUCT_P set.  We must set it here
	     so that the insn scheduler won't assume that these
	     stores can't possibly overlap with the va_arg loads.  */
	  if (mips_abi != ABI_EABI && BYTES_BIG_ENDIAN)
	    MEM_SET_IN_STRUCT_P (mem, 1);

(which dates back to '96) seems bogus.  Looking at the rtl dumps, va_arg
loads don't have MEM_IN_STRUCT_P set for any combination that I can see.
Certainly not for -mabi=n32 and -mabi=64 on irix (which is a big endian
target).  Having them only on the stores, not the loads, seems dangerous.

Richard

Re: Unreviewed patch

[Zack Weinberg]

"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:

> This patch has been in the queue for two weeks.
>
> Patch to builtin strcat for constant strings
> http://gcc.gnu.org/ml/gcc-patches/2003-07/msg02561.html

This is OK.

zw

Unreviewed patch

[Kaveh R. Ghazi]

This patch has been in the queue for two weeks.

Patch to builtin strcat for constant strings
http://gcc.gnu.org/ml/gcc-patches/2003-07/msg02561.html

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Unreviewed patch

[Josef Zlomek]

> > http://gcc.gnu.org/ml/gcc-patches/2003-07/msg00800.html
> > (Fix latent bug in cfgcleanup.c)
> 
> Please rewrite this section of code to use tablejump_p.

OK, I'll do so.

Josef

Re: Unreviewed patch

[Richard Henderson]

On Thu, Jul 17, 2003 at 07:18:24PM +0200, Josef Zlomek wrote:
> http://gcc.gnu.org/ml/gcc-patches/2003-07/msg00800.html
> (Fix latent bug in cfgcleanup.c)

Please rewrite this section of code to use tablejump_p.


r~

Re: Unreviewed patch

[Josef Zlomek]

> > Hi,
> > 
> > http://gcc.gnu.org/ml/gcc-patches/2003-07/msg00800.html
> > (Fix latent bug in cfgcleanup.c)
> > 
> > Jump table was not recognized in some situations and thus jump table was
> > not moved together with the previous block.
> 
> Isn't the BARRIER supposed to be *after* the jump table?

There is one after jump table and one before jump talbe (between
previous block and the jump table).

Josef

Re: Unreviewed patch

[Geoff Keating]

Josef Zlomek <zlomj9am@artax.karlin.mff.cuni.cz> writes:

> Hi,
> 
> http://gcc.gnu.org/ml/gcc-patches/2003-07/msg00800.html
> (Fix latent bug in cfgcleanup.c)
> 
> Jump table was not recognized in some situations and thus jump table was
> not moved together with the previous block.

Isn't the BARRIER supposed to be *after* the jump table?

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Unreviewed patch

[Josef Zlomek]

Hi,

http://gcc.gnu.org/ml/gcc-patches/2003-07/msg00800.html
(Fix latent bug in cfgcleanup.c)

Jump table was not recognized in some situations and thus jump table was
not moved together with the previous block.

Re: Unreviewed patch

[Alexandre Oliva]

On Jun 21, 2003, Jason Thorpe <thorpej@wasabisystems.com> wrote:

> http://gcc.gnu.org/ml/gcc-patches/2003-06/msg01433.html

This is ok, thanks.  Please check it in both mainline and 3.3 branch.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Unreviewed patch

[Jason Thorpe]

http://gcc.gnu.org/ml/gcc-patches/2003-06/msg01433.html

         -- Jason R. Thorpe <thorpej@wasabisystems.com>

Unreviewed patch

[Zdenek Dvorak]

Hello,

I know it is waiting only a few days, but could someone please have a
look at this patch?  I have several folowup patches ready and stuck
because of this one.

http://gcc.gnu.org/ml/gcc-patches/2003-06/msg01410.html

Zdenek

Unreviewed patch

[kaz Kojima]

Tom Tromey <tromey@redhat.com> wrote:
> As you've discovered, libffi is a bit under maintained.  I'm not
> really the person to do it -- I'd do little more than rubber stamp
> patches that come in.  I'm happy to do that, though, in the absence of
> a better process.  Hopefully some more qualified person out there will
> speak up (and we'll end up with a libffi entry in MAINTAINERS).
> 
> I believe we've agreed in the past that port maintainers can make
> port-specific libffi changes.  So I think you can check in your fix on
> that basis.

I'd like to check my patch in. Thanks.

I totally agree with your and Anthony's suggestion about the approvement 
for libffi changes, though in this specific case I hesitate over because
sh64-linux is for the SHmedia processor with a new and very different ISA
from the other SH family and I'm rather new to SHmedia.
So I thought and still think that it would be nice if SHmedia experts see
my patch.

BTW, libjava works to some extent with the sjlj configuration using this
libffi port. I'll report it to the java list.

Regards,
	kaz

Re: Unreviewed patch

[Joseph S. Myers]

On Thu, 12 Jun 2003, Anthony Green wrote:

> > I believe we've agreed in the past that port maintainers can make
> > port-specific libffi changes.  So I think you can check in your fix on
> > that basis.
> 
> The situation is a little frustrating because it's not made explicit in
> the MAINTAINERS file.  I once tried to clear this up with the SC through
> one of its members, but got no reply.

cvswrite.html currently says:

          Maintainers of a port maintain the files in config/port/, the
          configure fragments for the port, documentation for the port
          and test cases for features or bugs specific to this port. Port
          maintainers do not have approval rights in other files.

Perhaps this should be expanded to list target-specific files outside the
gcc directory.  In that case, the FIXME in sourcebuild.texi asking for a
list of such places, in the checklist of what's needed in a target port,
could be filled in at the same time.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Unreviewed patch

[Gerald Pfeifer]

On Thu, 12 Jun 2003, Anthony Green wrote:
>> I believe we've agreed in the past that port maintainers can make
>> port-specific libffi changes.  So I think you can check in your fix
>> that basis.
> The situation is a little frustrating because it's not made explicit in
> the MAINTAINERS file.  I once tried to clear this up with the SC through
> one of its members, but got no reply.

That's unfortunate.

> My suggestion is that the following people should be able to approve
> libffi changes:
>
> 0. Global maintainers
> 1. GCC port maintainers, since many times they will be the only ones who
> understand the asm code.
> 2. Tromey, as the maintainer of libgcj, since this is an important part
> of it.
> 3. Me, as the original author.
> BTW - I think we should also add MAINTAINERS entries for zlib, boehm-gc
> and fastjar.

Would you mind suggesting appropriate additions to the MAINTAINERS file?
I'll happily forward them to the SC and make sure to follow it.

On Thu, 12 Jun 2003, Joern Rennecke wrote:
> I'm somewhat unsure about the status of libffi.  On the one
> hand it is a separate project, and as such it appears that only
> Anthony Green can approve patches.
> On the other hand the libffi home page says 'libffi is now largely
> maintained as part of GCC.' , and if it is actually maintained as
> part of GCC, that would mean that global and target port maintainers
> of gcc can approve patches.

The point is, is it largely maintained as part of GCC, or is it now
part of GCC (like, for example, libstdc++ and libgcj which became
fully integrated)?

Gerald
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: Unreviewed patch

[Joern Rennecke]

kaz Kojima wrote:
> 
> libffi sh64-*-linux* support:
> <URL:http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02321.html>

I'm somewhat unsure about the status of libffi.  On the one
hand it is a separate project, and as such it appears that only
Anthony Green can approve patches.
On the other hand the libffi home page says 'libffi is now largely
maintained as part of GCC.' , and if it is actually maintained as
part of GCC, that would mean that global and target port maintainers
of gcc can approve patches.
	
-- 
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658

Re: Unreviewed patch

[Anthony Green]

On Thu, 2003-06-12 at 07:15, Tom Tromey wrote:
>  Hopefully some more qualified person out there will
> speak up (and we'll end up with a libffi entry in MAINTAINERS).
> 
> I believe we've agreed in the past that port maintainers can make
> port-specific libffi changes.  So I think you can check in your fix on
> that basis.

The situation is a little frustrating because it's not made explicit in
the MAINTAINERS file.  I once tried to clear this up with the SC through
one of its members, but got no reply.

My suggestion is that the following people should be able to approve
libffi changes:

0. Global maintainers
1. GCC port maintainers, since many times they will be the only ones who
understand the asm code.
2. Tromey, as the maintainer of libgcj, since this is an important part
of it.
3. Me, as the original author.

BTW - I think we should also add MAINTAINERS entries for zlib, boehm-gc
and fastjar.

AG

-- 
Anthony Green <green@redhat.com>
Red Hat, Inc.

Re: Unreviewed patch

[Tom Tromey]

>>>>> "kaz" == kaz Kojima <kkojima@rr.iij4u.or.jp> writes:

kaz> libffi sh64-*-linux* support:
kaz> <URL:http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02321.html>

As you've discovered, libffi is a bit under maintained.  I'm not
really the person to do it -- I'd do little more than rubber stamp
patches that come in.  I'm happy to do that, though, in the absence of
a better process.  Hopefully some more qualified person out there will
speak up (and we'll end up with a libffi entry in MAINTAINERS).

I believe we've agreed in the past that port maintainers can make
port-specific libffi changes.  So I think you can check in your fix on
that basis.

Tom

Unreviewed patch

[kaz Kojima]

libffi sh64-*-linux* support:
<URL:http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02321.html>

Regards,
	kaz

Unreviewed patch

[Jason Thorpe]

http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02155.html

         -- Jason R. Thorpe <thorpej@wasabisystems.com>

Unreviewed patch

[Josef Zlomek]

Hi,

Improvement of splay trees (possible use of alloc-pool for splay tree
nodes):
http://gcc.gnu.org/ml/gcc-patches/2003-05/msg00958.html

(although the improvement is not used yet, somebody may want to use
alloc-pool for splay tree nodes in future).

Josef

Re: Unreviewed patch

[Alexandre Oliva]

On Mar 25, 2003, Nathanael Nerode <neroden@twcny.rr.com> wrote:

> That could possibly be useful but is *much* better served by looking at 
> CVS history.

This assumes you have access to the CVS history.  Most often you'll be
interested in this information when a port is first contributed, and
then you'll have no CVS history whatsoever.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: Unreviewed patch

[Alexandre Oliva]

On Mar 25, 2003, Eric Christopher <echristo@redhat.com> wrote:

>> The duplicate default definitions and commented out definitions cause
>> trouble when grepping for all ports that define a particular macro.  The
>> duplicate comments just stay out of date, or, worse, diverge; each macro
>> should be documented in the internals manual, and there only; the comments
>> for an individual target should be specific to that target and not
>> duplicate the explanation of the standard meaning of the definition of the
>> macro.

> *shrug* I suppose so. I found it useful, but I'm apparently the only
> one.

The generic comments are a bad idea.  Having defaulted the macros with
a commented-out blank definition, to tell whether at the time a port
was created the macro existed, is useful indeed.  It's easy enough to
grep -v the commented-out definitions.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: Unreviewed patch

[Eric Christopher]

> The duplicate default definitions and commented out definitions cause
> trouble when grepping for all ports that define a particular macro.  The
> duplicate comments just stay out of date, or, worse, diverge; each macro
> should be documented in the internals manual, and there only; the comments
> for an individual target should be specific to that target and not
> duplicate the explanation of the standard meaning of the definition of the
> macro.

*shrug* I suppose so. I found it useful, but I'm apparently the only
one.

-eric

-- 
o/~ got caught stealing fire from the sky o/~

Re: Unreviewed patch

[Joseph S. Myers]

On 25 Mar 2003, Eric Christopher wrote:

> Hrm. I dunno that I agree with this beginner project. I've found the
> information useful in the past when looking at a port as to whether or
> not someone at least _thought_ about a particular macro - or in some
> cases whether or not it existed, when the port was created.

The duplicate default definitions and commented out definitions cause
trouble when grepping for all ports that define a particular macro.  The
duplicate comments just stay out of date, or, worse, diverge; each macro
should be documented in the internals manual, and there only; the comments
for an individual target should be specific to that target and not
duplicate the explanation of the standard meaning of the definition of the
macro.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Unreviewed patch

[Nathanael Nerode]

>Hrm. I dunno that I agree with this beginner project. I've found the
>information useful in the past when looking at a port as to whether or
>not someone at least _thought_ about a particular macro - or in some
Well, notes on the order of "I thought about this macro" or "We 
shouldn't use this macro" should be kept, of course.

I don't think 3000 lines of essentially redundant comments are a good 
idea.

>cases whether or not it existed, when the port was created.
That could possibly be useful but is *much* better served by looking at 
CVS history.

--Nathanael

Re: Unreviewed patch

[Eric Christopher]

On Tue, 2003-03-25 at 08:00, Nathanael Nerode wrote:
> Ping.
> http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01150.html
> 

Hrm. I dunno that I agree with this beginner project. I've found the
information useful in the past when looking at a port as to whether or
not someone at least _thought_ about a particular macro - or in some
cases whether or not it existed, when the port was created.

Anyone else or am I alone here? :)

-eric

-- 
o/~ got caught stealing fire from the sky o/~

Unreviewed patch

[Nathanael Nerode]

Ping.
http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01150.html

(also see http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01372.html
 where I revised the ChangeLog)

Re: Unreviewed patch

[Richard Henderson]

On Tue, Mar 18, 2003 at 12:24:29PM -0500, Jakub Jelinek wrote:
> Ping: http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00823.html

I guess this is ok for 3.2 and 3.3.  For 3.4, I'd like to fix
this properly.  The issue is that after 

Fri May  3 11:12:24 CEST 2002  Jan Hubicka  <jh@suse.cz>

	* cfgcleanup.c (try_optimize_cfg):  Call merge_block only when
	jump is simplejump.

Thu May  2 19:50:04 CEST 2002  Jan Hubicka  <jh@suse.cz>

        * cfgrtl.c (try_redirect_by_replacing_jump): Do not kill computed
        jumps post reload.
        * toplev.c (rest_of_compilation): Revert Richard's patch.

we will *never* simplify tablejumps that were trivialized
by crossjumping.  This is quite irritating.  Re-enabling
this will be too tricky a change for either of the aforementioned
branches.



r~

Unreviewed patch

[Jakub Jelinek]

Hi!

Ping: http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00823.html

	Jakub

Re: Unreviewed patch

[Zack Weinberg]

"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:

> Ping:  http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00885.html

Go for it.

zw

Unreviewed patch

[Kaveh R. Ghazi]

Ping:  http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00885.html

TIA.

--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Unreviewed patch

[Josef Zlomek]

HI,

can somebody familiar with C++ frontend look at this?

http://gcc.gnu.org/ml/gcc-patches/2003-01/msg01156.html

Thank you.

Josef

unreviewed patch

[Svein E. Seldal]

Hi,

This patch has not been reviewed yet. Any news?

http://gcc.gnu.org/ml/gcc-patches/2002-11/msg01502.html


Svein

Unreviewed patch

[Krister Walfridsson]

libf2c configuration patch
http://gcc.gnu.org/ml/gcc-patches/2002-10/msg01122.html

   /Krister

Unreviewed patch

[Krister Walfridsson]

libf2c configuration patch
http://gcc.gnu.org/ml/gcc-patches/2002-10/msg01122.html

   /Krister

Unreviewed patch

[John David Anglin]

See

<http://gcc.gnu.org/ml/gcc-patches/2002-11/msg00105.html>.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Unreviewed patch

[Nathanael Nerode]

I'd kind of like to get this one looked at as soon as possible.

http://gcc.gnu.org/ml/gcc-patches/2002-11/msg00657.html
See also http://gcc.gnu.org/ml/gcc-patches/2002-11/msg00696.html

Re: Unreviewed patch

[Richard Henderson]

On Tue, Aug 20, 2002 at 06:02:55PM +0100, Joern Rennecke wrote:
> http://gcc.gnu.org/ml/gcc-patches/2002-07/msg01488.html

Ok.


r~

Unreviewed patch

[Joern Rennecke]

Thu Jul 25 13:03:18 2002  J"orn Rennecke <joern.rennecke@superh.com>

gcc:
	* loop.c (scan_loop): Don't mark separate insns out of a libcall
	for moving.
	(move_movables): Abort if we see the first insn of a libcall.
gcc/testsuite:
	* gcc.c-torture/execute/loop-14.c: New test.

http://gcc.gnu.org/ml/gcc-patches/2002-07/msg01488.html

--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: Unreviewed Patch

[Richard Henderson]

On Wed, Aug 14, 2002 at 09:22:26PM -0400, Kaveh R. Ghazi wrote:
> In the mean time, can I install the original patch?

Yes.


r~

Re: Unreviewed Patch

[Kaveh R. Ghazi]

 > From: Richard Henderson <rth@redhat.com>
 > 
 > On Wed, Aug 14, 2002 at 05:44:57PM +0200, Michael Matz wrote:
 > > Yes, and I think, that's bad.  There is no reason to have CLASS_MAX_NREGS
 > > or HARD_REGNO_NREGS return signed values.  (LOOP_REGNO_NREGS is defined in
 > > terms of HARD_REGNO_NREGS, so that's just the same)
 > 
 > This is why moving to target hooks is good.  Functions have a
 > better defined interface than macros.
 > r~

Agreed.  I'll have a look at these hooks.

In the mean time, can I install the original patch?

(Note, except for a couple coming from bison output, the patch
addresses all remaining signed/unsigned warnings appearing on irix6
and solaris2.)

		--Kaveh
--
Kaveh R. Ghazi			Director of Systems Architecture
ghazi@caip.rutgers.edu		Qwest Solutions

Re: Unreviewed Patch

[Richard Henderson]

On Wed, Aug 14, 2002 at 05:44:57PM +0200, Michael Matz wrote:
> Yes, and I think, that's bad.  There is no reason to have CLASS_MAX_NREGS
> or HARD_REGNO_NREGS return signed values.  (LOOP_REGNO_NREGS is defined in
> terms of HARD_REGNO_NREGS, so that's just the same)

This is why moving to target hooks is good.  Functions
have a better defined interface than macros.


r~

Re: Unreviewed Patch

[Michael Matz]

Hi,

On Wed, 14 Aug 2002, Kaveh R. Ghazi wrote:

> The problem is that there is no consistency among the various ports.
> Some definitions of these macros resolve to signed values and others
> to unsigned.

Yes, and I think, that's bad.  There is no reason to have CLASS_MAX_NREGS
or HARD_REGNO_NREGS return signed values.  (LOOP_REGNO_NREGS is defined in
terms of HARD_REGNO_NREGS, so that's just the same)

> Were I to follow your suggestion and switch the variable's signedness,
> I would just prick some other configuration and cause warnings there.
> I would still need "ugly" casts, just of the other signedness.  The
> other suggestion whereby I would insert a cast in each port's
> definition of these macro to ensure a particular signedness is much
> more invasive and I cannot possibly regression test all combinations.

That's the downside, as I wrote, yes.  I'm not saying you should do this,
though ;)


Ciao,
Michael.

Re: Unreviewed Patch

[Kaveh R. Ghazi]

 > From: Michael Matz <matz@suse.de>
 > 
 > Hi,
 > 
 > On Wed, 14 Aug 2002, Kaveh R. Ghazi wrote:
 > 
 > > If someone would please review this I would very much appreciate it.
 > 
 > Wouldn't it make more sense to directly use a unsigned variable, instead
 > of those ugly casts?  E.g. in loop.c 'i' is only used in unsigned context,
 > except in one loop in move_movables() (where it's compared with XVECLEN).
 > 
 > Similar the usage of the macros CLASS_MAX_NREGS and HARD_REGNO_NREGS.  I
 > think they should be defined to return unsigned numbers.  I guess such a
 > change would need to be followed by many other changes in the compiler to
 > honor that.  I at least feel, that casts are an ugly way to silence the
 > warnings, and additionally also hide real errors with signed/unsigned
 > mismatches, plus optimization opportunities, when it's known that
 > variables are >=0, but not marked unsigned.

Michael,

The problem is that there is no consistency among the various ports.
Some definitions of these macros resolve to signed values and others
to unsigned.  That's why e.g. most of the warnings only appeared on
either mips or sparc but not both.  Because of that, I cast each use
to the signedness of the variable it was being compared to.  That's
the only mechanism guaranteed to be warning-free everywhere.

Were I to follow your suggestion and switch the variable's signedness,
I would just prick some other configuration and cause warnings there.
I would still need "ugly" casts, just of the other signedness.  The
other suggestion whereby I would insert a cast in each port's
definition of these macro to ensure a particular signedness is much
more invasive and I cannot possibly regression test all combinations.

I prefer to leave the patch as it is.  However I would be willing to
change the signedness of `i' and invert all of the relevant casts.
I'll leave that up to the reviewer to decide.

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			Director of Systems Architecture
ghazi@caip.rutgers.edu		Qwest Solutions

Re: Unreviewed Patch

[Michael Matz]

Hi,

On Wed, 14 Aug 2002, Kaveh R. Ghazi wrote:

> If someone would please review this I would very much appreciate it.

Wouldn't it make more sense to directly use a unsigned variable, instead
of those ugly casts?  E.g. in loop.c 'i' is only used in unsigned context,
except in one loop in move_movables() (where it's compared with XVECLEN).

Similar the usage of the macros CLASS_MAX_NREGS and HARD_REGNO_NREGS.  I
think they should be defined to return unsigned numbers.  I guess such a
change would need to be followed by many other changes in the compiler to
honor that.  I at least feel, that casts are an ugly way to silence the
warnings, and additionally also hide real errors with signed/unsigned
mismatches, plus optimization opportunities, when it's known that
variables are >=0, but not marked unsigned.


Ciao,
Michael.

Unreviewed Patch

[Kaveh R. Ghazi]

If someone would please review this I would very much appreciate it.

Subject: Patch for more signed/unsigned warnings 
http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00145.html

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			Director of Systems Architecture
ghazi@caip.rutgers.edu		Qwest Solutions

Unreviewed patch

[Neil Booth]

My C/ObjC/C++ options patch is unreviewed.  I first posted it a week
ago; the latest incarnation is

http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00286.html

I'd like to get this, and other stuff that depends on it, in before
the Aug 15th cutoff for HEAD.

Thanks,

Neil.

Unreviewed patch

[Kaveh R. Ghazi]

This patch needs a review:
http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00145.html

		Thanks in advance,
		--Kaveh
--
Kaveh R. Ghazi			Director of Systems Architecture
ghazi@caip.rutgers.edu		Qwest Solutions

Re: Unreviewed patch

[Geoff Keating]

Roger Sayle <roger@eyesopen.com> writes:

> The following patch is still awaiting review:
> 
> http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00537.html
> exp and log builtin function infrastructure
> 
> Many thanks in advance,

This is OK.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Unreviewed patch

[Roger Sayle]

The following patch is still awaiting review:

http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00537.html
exp and log builtin function infrastructure

Many thanks in advance,

Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833

Re: Unreviewed patch

[Geoff Keating]

"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:

> Patch to replace explicit xmalloc + strcpy/strcat/memcpy/sprintf calls
> with xstrdup or concat instead:
> 
> http://gcc.gnu.org/ml/gcc-patches/2002-06/msg02000.html
> 
> Neil reviewed the cpp bits, but the rest remains.

This is OK.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Unreviewed patch

[Kaveh R. Ghazi]

Patch to replace explicit xmalloc + strcpy/strcat/memcpy/sprintf calls
with xstrdup or concat instead:

http://gcc.gnu.org/ml/gcc-patches/2002-06/msg02000.html

Neil reviewed the cpp bits, but the rest remains.

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			Director of Systems Architecture
ghazi@caip.rutgers.edu		Qwest Solutions

Unreviewed patch

[Daniel Jacobowitz]

This patch posted last week hasn't been reviewed:

	Typo in configure.in for combined tree (uberbaum-style) builds
	http://gcc.gnu.org/ml/gcc-patches/2002-06/msg00560.html

If you approve it, please commit it; I do not have write access.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Unreviewed patch

[Dan Nicolaescu]

This patch:
http://gcc.gnu.org/ml/gcc-patches/2002-04/msg00148.html

has not been reviewed. 

The patch improves alias analysis when inheritance is involved. 
Comments on it would be appreciated. 

Thanks.
        --dan

Unreviewed patch

[Nathanael Nerode]

Ahem!

I would like someone to please look at the patch in message
http://gcc.gnu.org/ml/gcc-patches/2001-07/msg01120.html

And tell me if there's any reason for this patch not to be applied.

If there is no reason not to apply it,
someone please apply it!

Thank you.

--Nathanael Nerode

Re: Unreviewed patch

[Roger Sayle]

On Sat, 30 Mar 2002, Richard Henderson wrote:
> On Wed, Mar 27, 2002 at 11:37:07PM -0700, Roger Sayle wrote:
> > http://gcc.gnu.org/ml/gcc-patches/2002-01/msg00145.html
> > Avoid emitting stack adjustments of zero bytes.
>
> I've applied a slightly different version of the patch.
> Primarily, don't mess around with pending_delete.

Excellent.  That both simplifies the code and fixes the spurious
zero stack adjustments.  Many thanks.

Roger
--

Re: Unreviewed patch

[Richard Henderson]

On Wed, Mar 27, 2002 at 11:37:07PM -0700, Roger Sayle wrote:
> http://gcc.gnu.org/ml/gcc-patches/2002-01/msg00145.html
> Avoid emitting stack adjustments of zero bytes.

I've applied a slightly different version of the patch.
Primarily, don't mess around with pending_delete.

Tested on i386-linux.


r~


2002-03-30  Roger Sayle <roger@eyesopen.com>
            Richard Henderson  <rth@redhat.com>

        * regmove.c (combine_stack_adjustments_for_block): Avoid
        emitting a stack adjustment of zero bytes.  Let delete_insn
        update bb->head.

Index: regmove.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/regmove.c,v
retrieving revision 1.124
diff -c -p -d -r1.124 regmove.c
*** regmove.c	2002/02/19 11:39:01	1.124
--- regmove.c	2002/03/31 03:25:35
*************** combine_stack_adjustments_for_block (bb)
*** 2331,2349 ****
    HOST_WIDE_INT last_sp_adjust = 0;
    rtx last_sp_set = NULL_RTX;
    struct csa_memlist *memlist = NULL;
!   rtx pending_delete;
!   rtx insn, next;
    struct record_stack_memrefs_data data;
  
!   for (insn = bb->head; ; insn = next)
      {
!       rtx set;
! 
!       pending_delete = NULL_RTX;
        next = NEXT_INSN (insn);
  
        if (! INSN_P (insn))
! 	goto processed;
  
        set = single_set_for_csa (insn);
        if (set)
--- 2331,2347 ----
    HOST_WIDE_INT last_sp_adjust = 0;
    rtx last_sp_set = NULL_RTX;
    struct csa_memlist *memlist = NULL;
!   rtx insn, next, set;
    struct record_stack_memrefs_data data;
+   bool end_of_block = false;
  
!   for (insn = bb->head; !end_of_block ; insn = next)
      {
!       end_of_block = insn == bb->end;
        next = NEXT_INSN (insn);
  
        if (! INSN_P (insn))
! 	continue;
  
        set = single_set_for_csa (insn);
        if (set)
*************** combine_stack_adjustments_for_block (bb)
*** 2365,2371 ****
  		{
  		  last_sp_set = insn;
  		  last_sp_adjust = this_adjust;
! 		  goto processed;
  		}
  
  	      /* If not all recorded memrefs can be adjusted, or the
--- 2363,2369 ----
  		{
  		  last_sp_set = insn;
  		  last_sp_adjust = this_adjust;
! 		  continue;
  		}
  
  	      /* If not all recorded memrefs can be adjusted, or the
*************** combine_stack_adjustments_for_block (bb)
*** 2397,2405 ****
  						  this_adjust))
  		    {
  		      /* It worked!  */
! 		      pending_delete = insn;
  		      last_sp_adjust += this_adjust;
! 		      goto processed;
  		    }
  		}
  
--- 2395,2403 ----
  						  this_adjust))
  		    {
  		      /* It worked!  */
! 		      delete_insn (insn);
  		      last_sp_adjust += this_adjust;
! 		      continue;
  		    }
  		}
  
*************** combine_stack_adjustments_for_block (bb)
*** 2418,2433 ****
  		      last_sp_adjust += this_adjust;
  		      free_csa_memlist (memlist);
  		      memlist = NULL;
! 		      goto processed;
  		    }
  		}
  
! 	      /* Combination failed.  Restart processing from here.  */
  	      free_csa_memlist (memlist);
  	      memlist = NULL;
  	      last_sp_set = insn;
  	      last_sp_adjust = this_adjust;
! 	      goto processed;
  	    }
  
  	  /* Find a predecrement of exactly the previous adjustment and
--- 2416,2435 ----
  		      last_sp_adjust += this_adjust;
  		      free_csa_memlist (memlist);
  		      memlist = NULL;
! 		      continue;
  		    }
  		}
  
! 	      /* Combination failed.  Restart processing from here.  If
! 		 deallocation+allocation conspired to cancel, we can
! 		 delete the old deallocation insn.  */
! 	      if (last_sp_set && last_sp_adjust == 0)
! 		delete_insn (insn);
  	      free_csa_memlist (memlist);
  	      memlist = NULL;
  	      last_sp_set = insn;
  	      last_sp_adjust = this_adjust;
! 	      continue;
  	    }
  
  	  /* Find a predecrement of exactly the previous adjustment and
*************** combine_stack_adjustments_for_block (bb)
*** 2453,2467 ****
  							 stack_pointer_rtx),
  				  0))
  	    {
- 	      if (last_sp_set == bb->head)
- 		bb->head = NEXT_INSN (last_sp_set);
  	      delete_insn (last_sp_set);
- 
  	      free_csa_memlist (memlist);
  	      memlist = NULL;
  	      last_sp_set = NULL_RTX;
  	      last_sp_adjust = 0;
! 	      goto processed;
  	    }
  	}
  
--- 2455,2466 ----
  							 stack_pointer_rtx),
  				  0))
  	    {
  	      delete_insn (last_sp_set);
  	      free_csa_memlist (memlist);
  	      memlist = NULL;
  	      last_sp_set = NULL_RTX;
  	      last_sp_adjust = 0;
! 	      continue;
  	    }
  	}
  
*************** combine_stack_adjustments_for_block (bb)
*** 2471,2477 ****
  	  && !for_each_rtx (&PATTERN (insn), record_stack_memrefs, &data))
  	{
  	   memlist = data.memlist;
! 	   goto processed;
  	}
        memlist = data.memlist;
  
--- 2470,2476 ----
  	  && !for_each_rtx (&PATTERN (insn), record_stack_memrefs, &data))
  	{
  	   memlist = data.memlist;
! 	   continue;
  	}
        memlist = data.memlist;
  
*************** combine_stack_adjustments_for_block (bb)
*** 2481,2500 ****
  	  && (GET_CODE (insn) == CALL_INSN
  	      || reg_mentioned_p (stack_pointer_rtx, PATTERN (insn))))
  	{
  	  free_csa_memlist (memlist);
  	  memlist = NULL;
  	  last_sp_set = NULL_RTX;
  	  last_sp_adjust = 0;
  	}
- 
-     processed:
-       if (insn == bb->end)
- 	break;
- 
-       if (pending_delete)
- 	delete_insn (pending_delete);
      }
  
!   if (pending_delete)
!     delete_insn (pending_delete);
  }
--- 2480,2494 ----
  	  && (GET_CODE (insn) == CALL_INSN
  	      || reg_mentioned_p (stack_pointer_rtx, PATTERN (insn))))
  	{
+ 	  if (last_sp_set && last_sp_adjust == 0)
+ 	    delete_insn (last_sp_set);
  	  free_csa_memlist (memlist);
  	  memlist = NULL;
  	  last_sp_set = NULL_RTX;
  	  last_sp_adjust = 0;
  	}
      }
  
!   if (last_sp_set && last_sp_adjust == 0)
!     delete_insn (last_sp_set);
  }

Unreviewed patch

[Roger Sayle]

I still have one code generation patch awaiting review:

http://gcc.gnu.org/ml/gcc-patches/2002-01/msg00145.html
Avoid emitting stack adjustments of zero bytes.

I discovered the problem whilst investigating item #124 from the
old PROBLEMS file dating back before GCC 2.0 (i.e. over 10 years
old).  If the patch is accepted, we can probably "retire" this
item from the current GCC projects WWW page.

Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833

Re: Unreviewed patch

[Richard Henderson]

On Tue, Feb 19, 2002 at 02:04:25PM -0500, Diego Novillo wrote:
> http://gcc.gnu.org/ml/gcc-patches/2002-02/msg00980.html

Ok.


r~

Unreviewed patch

[Diego Novillo]

http://gcc.gnu.org/ml/gcc-patches/2002-02/msg00980.html

Fixes an ICE on gcc.c-torture/compile/20020109-2.c for 16-bit
targets.


Diego.

Unreviewed patch.

[Gaute B Strokkenes]

This is a resend of:

  <http://gcc.gnu.org/ml/gcc-patches/2002-01/msg00495.html>

which fixes two very simple typos in the internals manual.

-- 
Gaute Strokkenes                        http://www.srcf.ucam.org/~gs234/
FEELINGS are cascading over me!!!
Index: c-tree.texi
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/doc/c-tree.texi,v
retrieving revision 1.28
diff -u -r1.28 c-tree.texi
--- c-tree.texi	16 Jan 2002 00:09:27 -0000	1.28
+++ c-tree.texi	29 Jan 2002 10:44:29 -0000
@@ -761,7 +761,7 @@
 (BINFO_TYPE (y))} is always the same binfo as @code{y}.  The reason is
 that if @code{y} is a binfo representing a base-class @code{B} of a
 derived class @code{D}, then @code{BINFO_TYPE (y)} will be @code{B}, and
-@code{TYPE_INFO (BINFO_TYPE (y))} will be @code{B} as its own
+@code{TYPE_BINFO (BINFO_TYPE (y))} will be @code{B} as its own
 base-class, rather than as a base-class of @code{D}.
 
 The @code{BINFO_BASETYPES} is a @code{TREE_VEC} (@pxref{Containers}).
Index: rtl.texi
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/doc/rtl.texi,v
retrieving revision 1.26
diff -u -r1.26 rtl.texi
--- rtl.texi	23 Jan 2002 17:30:28 -0000	1.26
+++ rtl.texi	29 Jan 2002 10:44:29 -0000
@@ -501,7 +501,7 @@
 In @code{mem} expressions, nonzero for reference to a scalar known not
 to be a member of a structure, union, or array.  Zero for such
 references and for indirections through pointers, even pointers pointing
-to scalar types.  If both this flag and @code{MEM_STRUCT_P} are clear, then we
+to scalar types.  If both this flag and @code{MEM_IN_STRUCT_P} are clear, then we
 don't know whether this @code{mem} is in a structure or not.  Both flags should
 never be simultaneously set.
 Stored in the @code{frame_related} field and printed as @samp{/f}.

Re: Unreviewed patch

[Richard Henderson]

On Wed, Jan 16, 2002 at 05:45:15PM -0800, H . J . Lu wrote:
> http://gcc.gnu.org/ml/gcc/2001-10/msg00969.html

Ok.


r~

Unreviewed patch

[H . J . Lu]

This patch

http://gcc.gnu.org/ml/gcc/2001-10/msg00969.html

hasn't been reviewed. Could someone please take a look? I have been
using it for 3 months.


H.J.

Re: Unreviewed patch

[Michael Meissner]

On Wed, Sep 05, 2001 at 04:35:43PM -0700, Stan Shebs wrote:
> This borders on the obvious IMHO, but it should be doublechecked.
> 
> Remove OP_IDENTIFIER tree node type
>     http://gcc.gnu.org/ml/gcc-patches/2001-06/msg01590.html
> 
> Stan

Ok, the patch looks reasonable.

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Unreviewed patch

[Stan Shebs]

This borders on the obvious IMHO, but it should be doublechecked.

Remove OP_IDENTIFIER tree node type
    http://gcc.gnu.org/ml/gcc-patches/2001-06/msg01590.html

Stan

Unreviewed patch

[Diego Novillo]

This patch fixes -fdump-... for the C front-end.  Could someone
review it?

http://gcc.gnu.org/ml/gcc-patches/2001-08/msg01142.html

Thanks.  Diego.

Re: Unreviewed patch

[Diego Novillo]

On Fri, 17 Aug 2001, Richard Henderson wrote:

> On Fri, Aug 17, 2001 at 04:55:38PM -0400, Diego Novillo wrote:
> > http://gcc.gnu.org/ml/gcc-patches/2001-08/msg00772.html
> 
> Ok I guess.  I'm still not altogether pleased with the 
> notion of bb->aux not being considered volatile across
> different passes though.
> 
Yes, I think that in the tree-ssa code I'm using it with
different semantics than the RTL code.  

Currently, it's used as an annotation mechanism.  It contains
these annotations (We might need to add more in the future):

---------------------------------------------------------------------------
struct basic_block_ann_def
{
  /* Control flow parent.  */
  basic_block parent;

  /* List of variable references made in this block.  */
  varref_list refs;
};
---------------------------------------------------------------------------

Field 'parent' is filled and used mainly by the flowgraph
builder.  However, the SSA builder also uses it for things like
finding the statement that holds a DO_COND expression (which
can't have annotations since it might be shared).  I can also see
other passes trying to access this information.

Field 'refs' is filled in by the variable reference finder and
used by the SSA pass.

I considered putting these fields directly in the basic_block
structure.  This is cleaner than annotations, but these fields
are too specific and only used in the tree code.

We could also create a hierarchy for the basic_block structure
similarly to what we have for trees.

I'm certainly open to other suggestions.


Thanks.  Diego.

Re: Unreviewed patch

[Richard Henderson]

On Fri, Aug 17, 2001 at 04:55:38PM -0400, Diego Novillo wrote:
> http://gcc.gnu.org/ml/gcc-patches/2001-08/msg00772.html

Ok I guess.  I'm still not altogether pleased with the 
notion of bb->aux not being considered volatile across
different passes though.


r~

Unreviewed patch

[Diego Novillo]

Could somebody review this patch?

http://gcc.gnu.org/ml/gcc-patches/2001-08/msg00772.html

The subject is misleading.  I actually need the patch for the
trunk, not the ast branch.

Thanks.  Diego.

Unreviewed patch

[John David Anglin]

This hasn't been reviewed:
< http://gcc.gnu.org/ml/gcc-patches/2001-05/msg00487.html >.
According to Neil Booth, it should fix PR 128.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Unreviewed patch

[Geoff Keating]

I think this patch is not acceptable.

The right thing to do is define STRICT_ARGUMENT_NAMING for the rs6000
port.

I believe that the only reason STRICT_ARGUMENT_NAMING is not the
default is that some old ports might break.  (Of course, one of those
old ports might be the rs6000 port, but in that case it'd be better to
fix the rs6000 port.)

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Unreviewed patch

[dalej]

Nobody has commented on the proposed patch at
http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00358.html
Would somebody familiar with the varargs and/or MEM_ALIAS
mechanisms please check this out?  The patch fixes a problem
on powerPC, but may have effects on other targets, such as
your favorite.

unreviewed patch

[Herman ten Brugge]

Hello,

Some time ago (2000-12-14) I sent in a bug report for emit-rtl.c. Could
some one review this patch. This is the only patch left to get a working
c4x compiler. See:

http://gcc.gnu.org/ml/gcc-patches/2000-12/msg00804.html

Thanks.

        Herman.

Unreviewed patch

[Diego Novillo]

A few days ago I posted a patch to add the SPEC testing scripts
to gcc/contrib. I have gotten some other requests for the scripts
and it would make my life easier if the scripts are in CVS.

     http://gcc.gnu.org/ml/gcc-patches/2001-03/msg00248.html

2001-03-05  Diego Novillo  <dnovillo@redhat.com>

	* spec: New directory with scripts for doing automated SPEC runs. 
	* spec/README: New file.
	* spec/TODO: New file.
	* spec/build: New file.
	* spec/dospec: New file.
	* spec/gcc.cfg.skel: New file.
	* spec/isolate: New file.
	* spec/motd.goaway: New file.
	* spec/nightlyspec: New file.
	* spec/perf.plt.skel: New file.
	* spec/perfrc: New file.
	* spec/report: New file.
	* spec/report.html.skel: New file.
	* spec/update: New file.


Is this OK?

Thanks.

Re: Unreviewed patch

[Jan Hubicka]

> On Mon, Feb 12, 2001 at 02:42:48PM +0100, Jan Hubicka wrote:
> > You've already OKayed this patch. But thanks for another approval anyway :)
> 
> Arg.  That's what I get for not removing messages properly...
Eh...
> 
> > http://gcc.gnu.org/ml/gcc-patches/2001-01/msg00847.html
> 
> I thought I'd already acked some of these?  Which ones are
> still pending?
All of them to my best knowledge.

Honza

Re: Unreviewed patch

[Richard Henderson]

On Mon, Feb 12, 2001 at 02:42:48PM +0100, Jan Hubicka wrote:
> You've already OKayed this patch. But thanks for another approval anyway :)

Arg.  That's what I get for not removing messages properly...

> http://gcc.gnu.org/ml/gcc-patches/2001-01/msg00847.html

I thought I'd already acked some of these?  Which ones are
still pending?


r~

Re: Unreviewed patch

[Jan Hubicka]

> On Sat, Dec 30, 2000 at 10:19:54AM +0100, Jan Hubicka wrote:
> > http://gcc.gnu.org/ml/gcc-patches/2000-12/msg00719.html
> 
> Ok after the branch.
You've already OKayed this patch. But thanks for another approval anyway :)
But concerning the old patches, the:

http://gcc.gnu.org/ml/gcc-patches/2001-01/msg00847.html

contains some I consider important for 3.0 (well also some not applicable
during freeze I would like to see at least after branching).

Honza
> 
> 
> r~

Re: Unreviewed patch

[Laurynas Biveinis]

On Sun, Feb 11, 2001 at 11:39:59AM -0800, Richard Henderson wrote:
> On Wed, Jan 31, 2001 at 02:47:12PM +0200, Laurynas Biveinis wrote:
> > http://gcc.gnu.org/ml/gcc-patches/2001-01/msg00164.html
> 
> Ok.

But I don't have CVS write access, could somebody commit it please? 
Or may I just ask for write after approval rights?

Laurynas

Re: Unreviewed patch

[Alexandre Oliva]

On Feb 11, 2001, "Dave Korn" <davek-ml@ntlworld.com> wrote:

> FWIW, I've made a similar patch in my local source tree; my one allows the
> target header to provide definitions TARGET_OBJECT_SUFFIX and
> TARGET_EXECUTABLE_SUFFIX which override OBJECT_SUFFIX and EXECUTABLE_SUFFIX
> in the part of the driver that generates output files (but not the parts of
> the driver that search for files on the host).

FWIW, I have a patch that does this.  The problem is that it breaks
Canadian crosses because autoconf 2.13 can't cope with it.  I'm
waiting for autoconf 2.50 to re-post my patch.

> However, IMO the most properly correct way to do it would be for
> configure to work out the appropriate extensions to use for host and
> target files.

For host, yes, that would be fine.  But there's just no way for
autoconf to determine information for the target before we create a
compiler for the target, which requires deciding what the target
should look like by ourselves.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Unreviewed patch

[Dave Korn]

----- Original Message -----
From: "Richard Henderson" <rth@redhat.com>
Sent: Sunday, February 11, 2001 6:11 PM


> On Sun, Feb 11, 2001 at 02:44:39PM +0200, Laurynas Biveinis wrote:
> > http://gcc.gnu.org/ml/gcc-patches/2001-01/msg01085.html
> >
> > It's a compiler driver fix for DJGPP, so gcc no longer
> > errorneously appends executable suffix to output file.
>
> I'd rather all the dos-based systems work the same way
> wrt extensions.  And really those are the only systems
> with extensions still.

  There's still a problem with the driver mechanism, because the .exe
extension is attached or not depending on the host machine type, rather than
the target machine type.  This is wrong-but-right-by-accident on a native
compiler, and just plain wrong on a cross compiler (I ran into it on the
vxworks port).

  FWIW, I've made a similar patch in my local source tree; my one allows the
target header to provide definitions TARGET_OBJECT_SUFFIX and
TARGET_EXECUTABLE_SUFFIX which override OBJECT_SUFFIX and EXECUTABLE_SUFFIX
in the part of the driver that generates output files (but not the parts of
the driver that search for files on the host).  However, IMO the most
properly correct way to do it would be for configure to work out the
appropriate extensions to use for host and target files.  I haven't looked
at it any further than that because I don't understand auto* stuff.

   DaveK

Re: Unreviewed patch

[Richard Henderson]

On Wed, Jan 31, 2001 at 02:47:12PM +0200, Laurynas Biveinis wrote:
> http://gcc.gnu.org/ml/gcc-patches/2001-01/msg00164.html

Ok.


r~

Re: Unreviewed patch

[lauras]

> > Automatically adding .exe simply breaks things like autoconf. 
> 
> Why? 

Previously if user said gcc foo.c -o bar, this used
to make _both_ bar and bar.exe. And UNIX-born autoconf
macros were happy. Now only bar.exe gets created, and
almost every older configure script doesn't work anymore.

Laurynas

Re: Unreviewed patch

[Richard Kenner]

    Didn't remember.  Not that anyone has been testing
    vms at all recently...

It's being worked on now.

Re: Unreviewed patch

[Richard Henderson]

On Sun, Feb 11, 2001 at 02:30:38PM -0500, Richard Kenner wrote:
> Doesn't VMS have extensions too?

Didn't remember.  Not that anyone has been testing
vms at all recently...


r~

Re: Unreviewed patch

[Richard Kenner]

    I'd rather all the dos-based systems work the same way
    wrt extensions.  And really those are the only systems
    with extensions still.

Doesn't VMS have extensions too?

Re: Unreviewed patch

[Richard Henderson]

On Sat, Dec 30, 2000 at 10:19:54AM +0100, Jan Hubicka wrote:
> http://gcc.gnu.org/ml/gcc-patches/2000-12/msg00719.html

Ok after the branch.


r~

Re: Unreviewed patch

[Richard Henderson]

On Sun, Feb 11, 2001 at 07:07:56PM +0000, lauras@softhome.net wrote:
> Automatically adding .exe simply breaks things like autoconf. 

Why?  I guess I'll leave this to DJ to look at then.


r~

Re: Unreviewed patch

[lauras]

Richard Henderson writes:
> I'd rather all the dos-based systems work the same way
> wrt extensions.  And really those are the only systems
> with extensions still.

My patch fixes some change introduced after 2.95 which
was done _without_ respect to whole DJGPP toolchain. 
Automatically adding .exe simply breaks things like autoconf. 
If we wanted to leave GCC in its current state, as you wish, we 
would have to patch binutils and our library, introducing 
backwards not compatible changes and so on. Actually, this 
is a long term plan, but we have to keep things working now.

Laurynas

Re: Unreviewed patch

[Richard Henderson]

On Sun, Feb 11, 2001 at 02:44:39PM +0200, Laurynas Biveinis wrote:
> http://gcc.gnu.org/ml/gcc-patches/2001-01/msg01085.html
> 
> It's a compiler driver fix for DJGPP, so gcc no longer
> errorneously appends executable suffix to output file.

I'd rather all the dos-based systems work the same way
wrt extensions.  And really those are the only systems
with extensions still.


r~

Unreviewed patch

[Laurynas Biveinis]

Could anyone review
http://gcc.gnu.org/ml/gcc-patches/2001-01/msg01085.html

It's a compiler driver fix for DJGPP, so gcc no longer
errorneously appends executable suffix to output file.

TIA,
Laurynas

Unreviewed patch

[Laurynas Biveinis]

It moves a test for host ranlib from Makefile to
configure.

The patch is in
http://gcc.gnu.org/ml/gcc-patches/2001-01/msg00164.html

The related discussion starts in
http://gcc.gnu.org/ml/gcc-patches/2001-01/msg00142.html

Please commit if it's OK (or after branch, if it is
not suitable for 3.0).

TIA,
Laurynas

Unreviewed patch

[Laurynas Biveinis]

Hello,

could anyone review
http://gcc.gnu.org/ml/gcc-patches/2000-11/msg01561.html
?

It's a trivial patch to fix compiler crash on code
struct {
  char a[0];
};

when using COFF debugging information.

TIA,
Laurynas

Re: Unreviewed patch

[Daniel Berlin]

On Sun, 31 Dec 2000, Richard Henderson wrote:

> On Sat, Dec 30, 2000 at 08:45:39PM -0800, Daniel Berlin wrote:
> > 2. I can't do what intel suggests, and have both an aligned, and
> > unaligned entry point. Doing the aligned entry point requires emitting a
> > label, which really pisses off the scheduler, and other things.
> 
> Huh?  One of the as-yet unsubmitted Cygnus patches has successfully did
> this.  I assume you were cleaning this up for submission?
Yes. I knew it was on various people's todo lists, and I had a need for
SSE intrinsics in a "spare time" project, so I cleaned up the patches to 
force stack alignment.

In the process, I fixed the C++ front end to handle VECTOR_TYPES
properly, as well as dwarf2out, which was having a small problem (it
couldn't determine if VECTOR_TYPE's were simple or complex types). I also
added the two TImode related changes that Bernd either missed,  or hasn't
gotten to (I assume the second). I also fixed a problem that occurred if
you attempted to use the builtin's in C++, because of how the C++ front
end works (the symptom being it couldn't use the builtins, it thought they
were all variable arguments functions. The problem was that the C++ front
end really wanted a void_list_node, rather than a void_type_node, at theh
end of the function types. Has to do with how it tells the two apart).
whew. Think that's it.

 
Basically, I made it work with C++ well enough to use in my C++ app.
 >I'd like to see what sorts of errors you were encountering. 
I'm doing this from memory, as i'm not near the computer with the working
source tree on it.

1. ARG_POINTER is considered an eliminable register. ESI becomes our arg 
pointer if TARGET_STACK_ALIGN is on (otherwise, we use reg 16, just like
we used to)  We need to push it, to keep the old value around, if it was
used. The push patterns need a non-eliminable register, so you get an
unrecognizable insn.
2. emitting the labels and jumps necessary to build the aligned entry
point was causing all sorts of problems, one with the scheduler (which
ignored them, but then region_insns != scheduled_insns, so we aborted),
etc.
It just plain bombed in a lot of ways if you turned on optimization, all
related to those labels/jumps to them. (claiming we were jumping outside
the basic block, etc).

I tried every way tof saying the same thing I could think of (set the pc
to a label_ref, etc), didn't help.

Commented out the 5 lines to do the aligned entry point, all of these
problems went away. 

--Dan
 > > 
> r~
> 

Re: Unreviewed patch

[Richard Henderson]

On Sat, Dec 30, 2000 at 08:45:39PM -0800, Daniel Berlin wrote:
> 2. I can't do what intel suggests, and have both an aligned, and
> unaligned entry point. Doing the aligned entry point requires emitting a
> label, which really pisses off the scheduler, and other things.

Huh?  One of the as-yet unsubmitted Cygnus patches has successfully did
this.  I assume you were cleaning this up for submission?  I'd like to
see what sorts of errors you were encountering.



r~

Re: Unreviewed patch

[Daniel Berlin]

On Sat, 30 Dec 2000, Jan Hubicka wrote:

> Hi
> For the x86_64 port I need to implement SSE/SSE-2 based floating point
> arithmetics. 

You'll need to fix up the stack alignment stuff i'm about to send to
gcc-patches, if you want to be able to use movaps.

It does the proper 16 byte stack alignment.

Two problems. 
1. It's not quite correct, i'm forgetting to do something, and we crash
without -fomit-frame-pointer.
2. I can't do what intel suggests, and have both an aligned, and
unaligned entry point. Doing the aligned entry point requires emitting a
label, which really pisses off the scheduler, and other things.
I'm guessing we are just doing prologue's/epilogue's too late.
It's quite clear it's trying to schedule a label in the dumps ("{code
label}"). This screws a check to make sure we scheduled everything in a
region. I removed the check, and then we crash in flow.
I gave up, and just removed the extra aligned entry point, and it all went
away.

You also need a small modification of i386.md to allow pushing
"eliminable" registers after reload, since we want to use esi as our new
argpointer, since we need to align the stack, and thus, need to store the
old stack somewhere to access the arguments.


I also cleaned up the xmmintrin.h and mmintrin.h, whcih have never been
seen in public before.

Assuming i'm allowed, i'll submit these too (I think they have been meant
to be submitted, just no one had the time.).


The P4, however, would most benefit from 
A. not doing strength reduction, if we do (IIRC, we don't for x86,  i
could be misremembering). The latencies for shift changed so it's cheaper
to do adds now.
B. Scheduling for the function units, rather than the decoder. There is
only one decoder on the P4.


I already took the existing SSE intrinsics, grouped them logically
(sse_packed, sse_single, sse_logical, etc), then added a function unit for
SSE , with the right latencies/throughput for each, just to get some
semblance of scheduling.

 > I would like to do so on the existing P4 hardware and i386 port
> first and then merge it to the mainline before rest of x86_64 stuff, since it
> will be most likely benefical optimization for P4 too.
> 
> Before branching the tree for this project, I would like to floating point get
> into sync with mainline. There is one other FP patch pending that makes long
> double 128bit. This is required by x86_64 ABI as well as speeds up for
> i386/PPro noticeably.  Even when it's usability on the current i386 backend is
> limited, may be possible to review it soon? This can avoid me from having 3
> independent development branches.  Thank you very much!
> 
> The patch is:
> http://gcc.gnu.org/ml/gcc-patches/2000-12/msg00719.html
> 
> Honza
> 

Unreviewed patch

[Jan Hubicka]

Hi
For the x86_64 port I need to implement SSE/SSE-2 based floating point
arithmetics.  I would like to do so on the existing P4 hardware and i386 port
first and then merge it to the mainline before rest of x86_64 stuff, since it
will be most likely benefical optimization for P4 too.

Before branching the tree for this project, I would like to floating point get
into sync with mainline. There is one other FP patch pending that makes long
double 128bit. This is required by x86_64 ABI as well as speeds up for
i386/PPro noticeably.  Even when it's usability on the current i386 backend is
limited, may be possible to review it soon? This can avoid me from having 3
independent development branches.  Thank you very much!

The patch is:
http://gcc.gnu.org/ml/gcc-patches/2000-12/msg00719.html

Honza

Unreviewed patch

[Laurynas Biveinis]

That patch fixes a crash in
struct x {
  char a[0];
};
with COFF debugging info. The patch is two-liner; could anyone
review it?

http://gcc.gnu.org/ml/gcc-patches/2000-11/msg01561.html

TIA,
Laurynas

Unreviewed patch

[Laurynas Biveinis]

It solves gc performance problems under DJGPP, it was posted a month ago:

http://gcc.gnu.org/ml/gcc-patches/2000-07/msg01156.html

Thanks,
Laurynas