[Bug c/80677] New: LIMITS_H_TEST is wrong

[helmut at subdivi dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80677

            Bug ID: 80677
           Summary: LIMITS_H_TEST is wrong
           Product: gcc
           Version: 7.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: helmut at subdivi dot de
  Target Milestone: ---

LIMITS_H_TEST is a Makefile variable defined in gcc/Makefile.in, that
determines how to generate its own limits.h, in particular whether to use
limitx.h and limity.h. The test simply tests whether
$(BUILD_SYSTEM_HEADER_DIR)/limits.h exists and for most practical purposes this
tests whether /usr/include/limits.h exists.

When the build and target architectures equal, this is fine. When they don't
bad things happen.

False positives: When building on a typical GNU/Linux system for a baremetal
target, the test indicates wrongly indicates success.

False negatives: Debian is about to further multiarch. That involves moving
libc headers from /usr/include to /usr/include/$(DEB_HOST_MULTIARCH) as libc
headers can differ for different libc implementations (glibc/musl/uclibc). Thus
the test will wrongly fail even for libcs that provide a limits.h.

It seems that the false positive is present since ages and nobody ever noticed.
Thus it probably is harmless.

The false negative generates a limits.h that disagrees on MB_LEN_MAX with glibc
and breaks builds. (# error "Assumed value of MB_LEN_MAX wrong" when including
<stdlib.h> after <limits.h>)

Thus I propose setting "LIMITS_H_TEST = :" (i.e. always assuming limits.h
presence) as an improved heuristic. I also tried invoking $(GCC_FOR_TARGET) -E
to check for limits.h presence, but since configure.ac overwrites the
GCC_FOR_TARGET defined in gcc/Makefile.in, the required -isystem flags are
missing and it has no chance of finding the header.