Re: 1.3.4 status?

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

----- Original Message -----
From: "Christopher Faylor" <cgf@redhat.com>
To: <cygwin-developers@cygwin.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;
}