mysql: About libmysqlclient.a and C++

[Mike Simons]

Monty wrote:
> >>>>> "Mike" == Mike Simons <msimons@saic1.com> writes:
> Mike> - Where do we email patches?
> 
> mysql-support@tcx.se;  Anyone is allowed to email patches here!

  Is this another public mailing list or is that private list?
 
[patch to rename 'typedef char * string;' to 'typedef char * my_string;']
> Mike> - Can this patch be applied to the mysql baseline?
> 
> Yes.

  sent it just now...

> (Even if I think it's stupid of ANSI C++ to take a word as
> 'string' as their own :)

  but it's ___so___ much easier to use.


> Mike>   Also the sql/sql_yacc.cc file when compiled with -O9 on SunOS 5.5,
> Mike> with egcs-1.0.1 causes the compile to dump core.  =)
> Mike>   I tracked it down to the -finline flag that is turned on by -O2 and
> Mike> higher... I have trimmed down the preprocessed file from 23000 to 
> Mike> 3000 lines which still nukes the compiler.  I'm hoping to get it to 
> Mike> a small (< 100 line) example to mail off to the egcs folks so they
> Mike> can track it down.
> 
> That would be great!!!!!!!!!!
> I have thought to do this myself, but it would help a lot if you can
> submit the bug report.
> 
> Can you also ask them to look at their optimizer;  I don't think it
> should take more than 80M virtual memory to compile sql_yacc.cc !
> The cause is probably big integer arrays in sql_yacc.cc; 
> They should probably be able to patch the array optimizer to do this
> in a reasonable manner!

  Okay it appears to me that adding the -finline flag causes most of 
the functions given before the yyparse function in sql_yacc.cc to be 
inlined... many hundreds of times.  the combination of the number of 
instructions between the bottom goto and its the label results in the 
compiler nuking itself. 


  To see ?the? bug compile the following program, run it and redirect
stdout to a file.  Then compile *the output file* with "-O9 -g"...

  With loop = 100 both ggcs and egcs nuke themselves pretty quickly.
  With loop = 75 the both take a _long_ time and finish.
  With loop = 50 the both work quickly.

...compiling with "-O9 -fno-inline -g"... works on all compilers/machines.

====================================================
#include <stdio.h>

int main()
{
  int loop = 100;     /* change this number higher or lower as needed */

  printf ("inline void g(int &i) { i +=\n");

  for (; --loop;)
    printf ("  i+i+i+i+i+i+i+i+i+i+i+i+i+i+i+i+i+i+i+"
            "i+i+i+i+i+i+i+i+i+i+i+i+i+i+i+i+i+i+\n");

  printf ("  i+i+i+i+i+i+i+i+i+i+i+i+i+i+i+i+i+i+i+"
          "i+i+i+i+i+i+i+i+i+i+i+i+i+i+i+i+i+i; }\n"
          "\n"
          "int main()\n"
          "{\n"
          "  int i = 1;\n"
          "\n"
          "label:\n"
          "  g(i); g(i); g(i); g(i); g(i); g(i); "
          "g(i); g(i); g(i); g(i); g(i); g(i);\n"
          "\n"
          "  if (i < 13)\n"
          "    goto label;\n"
          "\n"
          "  return i;\n"
          "}\n");

  return 0;
}
====================================================

  I can understand if it's not possible to goto a instruction beyond
a certain distance away... it's just the compiler shouldn't SIGSEGV
trying to.  Printing a "can not do" message and exiting is much better ;).

  I'm think something in the compiler is wandering off the end of an 
array somewhere... To be honest I'm not _sure_ the failure shown above 
is the exact same thing that kills sql_yacc.cc.  I need to recompile 
the compiler with debugging information <sigh> so that I can get a 
backtrace of the stack to prove it (after sleep).

-- 

    Cheers,
      Mike Simons
      Science Applications International Corporation
      msimons@saic1.com                  703-925-5674


ps:
  The program above blows up on both ggcs-2.8.0 and egcs-1.0.1 on both
Linux and Solaris... I haven't tried compiling mysql on Linux yet.

  you can change the inline g() function to anything that creates _lots_
of assembly instructions.  changing main to be:

  do {
    g(i); g(i); g(i); g(i); g(i); g(i); g(i); g(i); g(i); g(i); g(i); g(i);
  } while (i < 13);

  *ALSO* nukes the compiler with a SIGSEGV... (something tells me this is
a known bug ;)