libiberty configure fails on svr4/svr5 native

libiberty configure fails on svr4/svr5 native

[Robert Lipe]

Depending upon the compiler used to bootstrap on SVR[45]/x86 hosts, you
might get mysterious linker failures during the gcc/stage2 build.  I'll
spare the exact failure modes unless they're important.

libiberty's configure script generates programs to test memcpy and
memset that optimize down to this:

int main()
{
        memcpy();
        return 0;
}


When the SCO, nee USL/USG/Univel/Novell, tools are handed this, they
emit a cryptic error:

UX:acomp: ERROR: "x.c", line 3: no actual for asm formal: z


This makes configure think that there is no memcpy.  Of course, there is
a memcpy but it actually wants to see arguments.  This makes configure
think there is no memcpy so it tries to provide one.  This makes the
native tools even less happy becuase it now knows we're trying to
override the highly optimized mem* brothers with C versions.  To make
matters worse, it seems to stick something in the .o when this happens
(possibly to trigger magic in the linker?) which will then fail to
resolve when gcc becomes the compiler talking to these sometime during
the the stage2 build.  To further confuse the issues, it only adds this
symbol when compiling this file with -g which, of course, the default
configure process provides.  If you _configure_ (but not necessarily
build) with gcc instead of the native cc, all is fine.

$ /udk/usr/ccs/bin/cc  -g -c  -I /play/egcs/include /play/egcs/libiberty/memc>
UX:acomp: WARNING: "/play/egcs/libiberty/memcpy.c", line 25: Function illegally defined in hosted mode: memcpy
(robertl) rjlhome:/play/tmp/x/libiberty
$ nm memcpy.o | grep abbr
[8]     |         0|       0|NOTY |GLOB |0    |UNDEF  |__abbr_table_1.0
(robertl) rjlhome:/play/tmp/x/libiberty
$ /udk/usr/ccs/bin/cc   -c  -I /play/egcs/include /play/egcs/libiberty/memcpy>
UX:acomp: WARNING: "/play/egcs/libiberty/memcpy.c", line 25: Function illegally defined in hosted mode: memcpy
(robertl) rjlhome:/play/tmp/x/libiberty
$ nm memcpy.o | grep abbr


What we have here is a case of too many pieces of software trying to
outsmart each other and the user loses.

I can think of a couple of ways to correct this.  None of them are
particularly pleasant.

1) Provide CFLAGS='nothing' in config/all_affected_targets. (Too many 
   targets and we don't know exactly what they are.)
2) Make configure pass arguments to these functions before testing.  
   (Requires changes to autoconf.)
3) Special case offending targets in libiberty/configure.in.  (See #1)
4) Document a workaround like hand-editing libiberty/Makefile between the
   configure and the make.  (Yuck.)


What's the best way to handle this?

RJL

Re: libiberty configure fails on svr4/svr5 native

[Joern Rennecke]

> 2) Make configure pass arguments to these functions before testing.  
>    (Requires changes to autoconf.)

I think this is the right direction, because autoconf actually fails - so
this should probably be considered a bug in autoconf.  (Not autoconf proper,
but the AC_CHECK_FUNC definition in acgeneral.m4.)
However, it's not easy to tell what actually to pass to an arbitrary
function.  We might try to pass a number of NULLs (writing them as "0",
of course), starting with one and going up to some arbitrary number.
However, that would lead to a lot of code expansion in the configure
scripts, and also make it much slower to determine that a function
doesn't exist.
Or we could try a little harder to outsmart the host and assign the
function's address to a pointer variable.

Would this test suceed?

#include <assert.h>

int main()
{
  char memcpy();
  char (*f)() = memcpy;
  return 0;
}

Re: libiberty configure fails on svr4/svr5 native

[Robert Lipe]

> > 2) Make configure pass arguments to these functions before testing.  
> >    (Requires changes to autoconf.)
> 
> I think this is the right direction, because autoconf actually fails - so
> this should probably be considered a bug in autoconf.  (Not autoconf proper,
> but the AC_CHECK_FUNC definition in acgeneral.m4.)

I'm inclined to agree, but I suspect this is a pretty weak argument for
a rather hard sell.

> Or we could try a little harder to outsmart the host and assign the
> function's address to a pointer variable.

Everyone outsmarting each other is what got us into this situation. :-)

> Would this test suceed?
> 
> #include <assert.h>
> 
> int main()
> {
>   char memcpy();
>   char (*f)() = memcpy;
>   return 0;
> }

Yes, that does seem to compile without blowing up.

What's your recommendation on how to proceed from here?

RJL

Re: libiberty configure fails on svr4/svr5 native

[Joern Rennecke]

> What's your recommendation on how to proceed from here?

Thu Nov  5 04:21:06 1998  J"orn Rennecke <amylaar@cygnus.co.uk>

	* acgeneral.m4 (AC_CHECK_FUNC): Don't actually call the function.

*** acgeneral.m4	Sun Nov 30 12:10:54 1997
--- acgeneral.m4-new	Thu Nov  5 04:19:00 1998
*************** char $1();
*** 1784,1790 ****
  #if defined (__stub_$1) || defined (__stub___$1)
  choke me
  #else
! $1();
  #endif
  ], eval "ac_cv_func_$1=yes", eval "ac_cv_func_$1=no")])
  if eval "test \"`echo '$ac_cv_func_'$1`\" = yes"; then
--- 1784,1790 ----
  #if defined (__stub_$1) || defined (__stub___$1)
  choke me
  #else
! char (*f)() = $1;
  #endif
  ], eval "ac_cv_func_$1=yes", eval "ac_cv_func_$1=no")])
  if eval "test \"`echo '$ac_cv_func_'$1`\" = yes"; then

Re: libiberty configure fails on svr4/svr5 native

[Ben Elliston]

> > What's your recommendation on how to proceed from here?
> 
> Thu Nov  5 04:21:06 1998  J"orn Rennecke <amylaar@cygnus.co.uk>

> 	* acgeneral.m4 (AC_CHECK_FUNC): Don't actually call the function.

On the first pass, this makes a lot of sense to me.  I'll think it through
and may incorporate it into the next version of autoconf.  Thanks for the
patch, Joern.

Ben

Re: libiberty configure fails on svr4/svr5 native

[Andreas Schwab]

Joern Rennecke <amylaar@cygnus.co.uk> writes:

|> Would this test suceed?
|> 
|> #include <assert.h>
|> 
|> int main()
|> {
|>   char memcpy();
|>   char (*f)() = memcpy;
|>   return 0;
|> }

I think the assignment should use a global variable, otherwise an
optimising compiler could completely omit it.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.cs.uni-dortmund.de                      completely different"
schwab@gnu.org

Boostrap failure 19981101 on powerpc

[Brad Reick]

I have been trying to compile recent snapshots and they all seem to fail
on during the stage1 build, on the same piece of code, regmove.c.  In 
fact I havent had any success since I built egcs 1.0.3 months ago.  Were 
there some major changes to regmove.c that would break the build on the 
ppc or could something else be at work here?  

System info: 
target: powerpc-unknown-linux-gnulibc1  (mklinux)
binutils 2.9.1
egcs 1.0.3


Here are the errors encountered on the most recent build attempt:

stage1/xgcc -Bstage1/ -B/users/local//powerpc-unknown-linux-gnulibc1/bin/ 
-c  -DIN_GCC   -DUSE_GNULIBC_1 -W -Wall -O2 -g -O2  -DHAVE_CONFIG_H 
-DHAIFA    -I. -I. -I./config -I./../include regmove.c
regmove.c: In function `regmove_optimize':
regmove.c:196: warning: array subscript has type `char'
regmove.c:210: warning: array subscript has type `char'
regmove.c:162: warning: unused variable `matching_operand'
regmove.c:161: warning: unused variable `output_operand'
regmove.c:622: warning: suggest parentheses around assignment used as 
truth value
regmove.c:762: warning: array subscript has type `char'
regmove.c:776: warning: array subscript has type `char'
regmove.c:728: warning: unused variable `matching_operand'
regmove.c:727: warning: unused variable `output_operand'
regmove.c:933: warning: suggest parentheses around assignment used as 
truth value
regmove.c:116: warning: unused parameter `nregs'
regmove.c:234: warning: `dst_note' might be used uninitialized in this 
function
regmove.c:238: warning: `insn_const' might be used uninitialized in this 
function
regmove.c:238: warning: `newconst' might be used uninitialized in this 
function
regmove.c:363: warning: `set2' might be used uninitialized in this function
regmove.c:542: warning: `set2' might be used uninitialized in this function
xgcc: Internal compiler error: program cc1 got fatal signal 11
make[2]: *** [regmove.o] Error 1
make[2]: Leaving directory `/users/tools/egcs-19981101/gcc'
make[1]: *** [bootstrap] Error 2


Cheers, 

Bradley Reick
bgreick@gauss.cord.edu

Re: libiberty configure fails on svr4/svr5 native

[Joern Rennecke]

> |> #include <assert.h>
> |> 
> |> int main()
> |> {
> |>   char memcpy();
> |>   char (*f)() = memcpy;
> |>   return 0;
> |> }
> 
> I think the assignment should use a global variable, otherwise an
> optimising compiler could completely omit it.

True.  So make that:

#include <assert.h>

char memcpy();
char (*f)();

int main()
{
  f = memcpy;
  return 0;
}

It would be tempting to make f volatile for good measure, however I've
heard that some early compilers don't support volatile.

Do we have to be wary of interprocedural optimizations in autoconf?

*** acgeneral.m4	Mon Nov  9 21:02:51 1998
--- acgeneral.m4-new	Mon Nov  9 21:16:00 1998
*************** extern "C"
*** 1777,1782 ****
--- 1777,1783 ----
  [/* We use char because int might match the return type of a gcc2
      builtin and then its argument prototype would still apply.  */
  char $1();
+ char (*f)();
  ], [
  /* The GNU C library defines this for functions which it implements
      to always fail with ENOSYS.  Some functions are actually named
*************** char $1();
*** 1784,1790 ****
  #if defined (__stub_$1) || defined (__stub___$1)
  choke me
  #else
! $1();
  #endif
  ], eval "ac_cv_func_$1=yes", eval "ac_cv_func_$1=no")])
  if eval "test \"`echo '$ac_cv_func_'$1`\" = yes"; then
--- 1785,1791 ----
  #if defined (__stub_$1) || defined (__stub___$1)
  choke me
  #else
! f = $1;
  #endif
  ], eval "ac_cv_func_$1=yes", eval "ac_cv_func_$1=no")])
  if eval "test \"`echo '$ac_cv_func_'$1`\" = yes"; then

Re: libiberty configure fails on svr4/svr5 native

[Ben Elliston]

> Thu Nov  5 04:21:06 1998  J"orn Rennecke <amylaar@cygnus.co.uk>
> 
> 	* acgeneral.m4 (AC_CHECK_FUNC): Don't actually call the function.

I've just checked this patch onto the main branch in the autoconf
repository. Thanks, all.

---
Ben Elliston
bje@cygnus.com