[Bug other/32783] New: gcc-4_3-trunk/libiberty/configure - for ac_func gettimeofday ... gettimeofday - tests twice

["rob1weld at aol dot com" <gcc-bugzilla at gcc dot gnu dot org>]

While linting libibery I found various problems with
"gcc-4_3-build-4/libiberty/configure" - all minor, some you might want to fix
someday:


Around line 5140 in the funtion detection it checks for gettimeofday two times:

for ac_func in asprintf atexit basename bcmp bcopy bsearch bzero calloc clock \
  getcwd getpagesize gettimeofday index insque mkstemps memchr memcmp memcpy \
  memmove mempcpy memset putenv random rename rindex sigsetmask \
  strcasecmp setenv stpcpy stpncpy strchr strdup strncasecmp strndup strrchr
strstr \
  strtod strtol strtoul strverscmp tmpnam vasprintf vfprintf vprintf \
  vsprintf waitpid getrusage on_exit psignal strerror strsignal \
  sysconf times sbrk gettimeofday ffs snprintf vsnprintf \
  pstat_getstatic pstat_getdynamic sysmp getsysinfo table sysctl wait3 wait4 \
  realpath canonicalize_file_name __fsetlocking

If all those sort of lists were in alphabetical order that would be less likely
to occur again.


There are two tests of "for ac_func in _doprnt" that contain a lot of similar
code. This could be pared down a little.


In the section with "configure:4053: checking for ANSI C header files" the 
./configure script first uses "#include <stdlib.h>" (near line 4069) to
declare exit() but later (near line 4166) it does not use "#include <stdlib.h>"
which result in the first warning shown above.

If for some reason there are OS's that do not have "stdlib.h" we can use:

# if HAVE_STDLIB_H
#  include <stdlib.h>
# endif

In the sections:
configure:6613: checking stack direction for C alloca
configure:6833: checking for working fork
configure:8866: checking for working strncmp

the same applys (no #include <stdlib.h>).


In the section with "configure:6833: checking for working fork" GCC misses
providing a warning in the "config.log" about a prototype for fork. This
can be found in "unistd.h" (if the OS has such a file). So lets add that:

#if HAVE_UNISTD_H
# include <unistd.h>
#endif


To test for "sys_errlist" and "sys_nerr" we need to include "stdio.h"

# if HAVE_STDIO_H
#  include <stdio.h>
# endif


To test for "sys_siglist" we need to include "signal.h"

# if HAVE_SIGNAL_H
#  include <signal.h>
# endif

The "sys_siglist" is on the "vars" list, see:
vars="`echo $vars | sed -e 's/sys_siglist//'`"


The "funcs" list provides "sigsetmask" and the "checkfuncs" list
provides "strsignal" but none have "signal" - which is good.


I grepped the source for "HAVE_SIGNAL_H" and eventually found a couple:

gcc-4_3-trunk/libgfortran/intrinsics/signal.c

#ifdef HAVE_SIGNAL_H
#include <signal.h>
#endif


# grep -r HAVE_SIGNAL /root/downloads/gcc-4_3-trunk/ | grep config   
/root/downloads/gcc-4_3-trunk/libgfortran/config.h.in:#undef HAVE_SIGNAL
/root/downloads/gcc-4_3-trunk/libgfortran/config.h.in:#undef HAVE_SIGNAL_H
/root/downloads/gcc-4_3-trunk/libmudflap/config.h.in:#undef HAVE_SIGNAL
/root/downloads/gcc-4_3-trunk/libmudflap/config.h.in:#undef HAVE_SIGNAL_H


It would seem that we could get away with adding "signal.h" to the 
"for ac_header in sys/file.h sys/param.h ..." tests near line 3785.


The "for ac_func in asprintf atexit ..." test lists "getpagesize" but it also
gets a second test in the OS specific section:

    for f in $funcs; do
      case "$f" in
        asprintf | basename | bcmp ...


And a third check here:

"for ac_func in getpagesize"


To the "for ac_header in stdlib.h unistd.h" I'll added "signal.h" to create
"HAVE_$ac_header" and to the "for ac_func in getpagesize" I added signal to
create a "HAVE_$ac_func". This does not seem to interfere with anything and
saves writing yet another two sections to handle signal tests.


-- 
           Summary: gcc-4_3-trunk/libiberty/configure - for ac_func
                    gettimeofday ... gettimeofday - tests twice
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: other
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rob1weld at aol dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32783