Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Message-ID: <02d801c15c35$c5822f70$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <cygwin-developers AT cygwin DOT com>
References: <02a201c15b5b$7910a4d0$0200a8c0 AT lifelesswks> <20011022204740 DOT B18754 AT redhat DOT com> <20011023005236 DOT 7136 DOT qmail AT lizard DOT curl DOT com> <20011022205828 DOT C18754 AT redhat DOT com> <02ea01c15b5f$7e673bc0$0200a8c0 AT lifelesswks> <20011022212759 DOT A19493 AT redhat DOT com> <035a01c15b6b$e7788c70$0200a8c0 AT lifelesswks> <039401c15b74$3555bd70$0200a8c0 AT lifelesswks> <03d201c15b83$0e480990$0200a8c0 AT lifelesswks> <03d801c15b83$663928f0$0200a8c0 AT lifelesswks> <20011023131115 DOT E18754 AT redhat DOT com>
Subject: Re: 1.3.4 status?
Date: Wed, 24 Oct 2001 12:44:14 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-OriginalArrivalTime: 24 Oct 2001 02:48:49.0240 (UTC) FILETIME=[68631D80:01C15C36]


----- Original Message -----
From: "Christopher Faylor" <cgf AT redhat DOT com>
To: <cygwin-developers AT cygwin DOT com>
Sent: Wednesday, October 24, 2001 3:11 AM
Subject: Re: 1.3.4 status?


> On Tue, Oct 23, 2001 at 03:27:24PM +1000, Robert Collins wrote:
> >and this patch fixes it.
> >
> >Index: fhandler_console.cc
> >===================================================================
> >RCS file: /cvs/src/src/winsup/cygwin/fhandler_console.cc,v
> >retrieving revision 1.66
> >diff -u -p -r1.66 fhandler_console.cc
> >--- fhandler_console.cc 2001/10/22 18:39:22     1.66
> >+++ fhandler_console.cc 2001/10/23 05:23:17
> >@@ -54,7 +54,7 @@ cp_convert (UINT destcp, char * dest, UI
> >     }
> >   else
> >     {
> >-      WCHAR wbuffer[CONVERT_LIMIT]; /* same size as the maximum
input,
> >s.b. */
> >+      WCHAR *wbuffer = (WCHAR *) alloca (CONVERT_LIMIT); /* same
size
> >as the maximum inpu
> >t, s.b. */
> >       if (!MultiByteToWideChar (srccp, 0, src, size, wbuffer, sizeof
> >(wbuffer)))
> >        return FALSE;
> >       if (!WideCharToMultiByte (destcp, 0, wbuffer, size, dest,
size,
> >
> >Have fun!
>
> Aren't you potentially doing that assignment in a loop?  If this is
inlined,
> I wonder if gcc does the right thing.

Right, well gcc was doing the 'right' thing before, by moving the
allocation out of the for (;;) which was two calls up. Except for that
minor thing with trashing the registers. Hmmm, let me see...

Ok, the presence of the alloca seems to have prevented automatic
inlining of that function. So the code will behave correctly, and won't
overflow the stack.

I can see two good solutions that should allow inlining:
1) have a sub function to do the double conversion that takes a buffer
argumentm, and have the base function pass in the buffer via alloca. We
can then call the function using the extended syntax to give it the
buffer - which we alloc via alloca outside the loop. It's a little
convoluted but AFAICT will work correctly and not be a pain to debug.
2) Fix gcc to save the regparm registers before any inserted optimised
code.

Some related links:
http://gcc.gnu.org/ml/gcc/1998-08/msg00773.html
http://www.call-with-current-continuation.org/NEWS.txt (search for
regparm - gcc bug noted - "Another GCC bug: 'regparm' attribute doesn't
work in conjunction with 'alloca'"

And finally, here is a trivial testcase should anyone want to see if gcc
3 has this fixed and/or take this to the gcc list and ask for a bug fix
for 2.95.3.

/* Show a bad optimisation case on win32 with gcc 2.95.3
   compile with gcc -g -O1
*/

#include <stdio.h>
#include <stdlib.h>

int outerfunction (int foo, int bar) __attribute__ ((regparm(2)));

inline int innerfunction ()
{
  int bigarray[4200],n;
  for (n=0; n<4200; n++)
    bigarray[n] = n;
  return bigarray [1000];
}

int
outerfunction(int foo, int bar)
{
  if (foo==12345)
    printf ("good call\n");
  else
    printf ("bad call\n");
  for (;;)
  {
    if (innerfunction ())
      break;
  }
  printf ("test complete\n");
}

int
main ()
{
  outerfunction (12345, 1);
  return 0;
}