[Bug modula2/92336] cross compiling gcc fails in gm2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92336 --- Comment #3 from Helmut Grohne --- I suppose that your changes have migrated to gcc-12 now. The problem persists in exactly the same way. A current build failure can bee seen at: https://crossqa.debian.net/build/gcc-12_12.2.0-9_s390x_20221110151612.log Could you look into this again?
[Bug bootstrap/80677] LIMITS_H_TEST is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80677 Helmut Grohne changed: What|Removed |Added CC||helmut at subdivi dot de --- Comment #3 from Helmut Grohne --- Created attachment 53832 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53832=edit eliminate the need for LIMITS_H_TEST entirely Rather than fix LIMITS_H_TEST, I now propose deleting it. The check that we try to perform at build time with wrong paths can be deferred to runtime and then operated with correct paths. I'm using this patch since at least gcc-11 and only encountered one regression thus far. It triggers https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80755 on hurd, but this is a plain gcc bug that needs fixing anyway, so this should be good to go.
[Bug preprocessor/80755] __has_include_next: internal compiler error: NULL directory in find_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80755 Helmut Grohne changed: What|Removed |Added CC||helmut at subdivi dot de --- Comment #2 from Helmut Grohne --- Created attachment 53801 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53801=edit proposed fix I confirm the issue on gcc 12.2.0-3 on Debian and have seen it since at least version 11. The symptom is slightly different though. It no longer produces an ICE. Instead the output looks like this: lastincdir/testcase.h:1:24: error: no include path in which to search for doesnotexist.h ... (null):0: confused by earlier errors, bailing out The invocation terminates with status 1. While this no longer is an ICE, the behavior is not correct either. __has_include_next should not error out and return false-ish instead. I believe that looking at the attached patch makes the problem fairly obvious. This problem now affects toolchain bootstrap on Debian for hurd architectures. The stage1 preprocessor happens to run into this very early.
[Bug modula2/92336] New: cross compiling gcc fails in gm2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92336 Bug ID: 92336 Summary: cross compiling gcc fails in gm2 Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: unassigned at gcc dot gnu.org Reporter: helmut at subdivi dot de CC: doko at debian dot org Target Milestone: --- Host: !=$(build) Target: ==$(host) Build: x86_64-linux-gnu The version of gcc packaged for Debian (currently based on 9.2.1) fails to cross build. Cross compiler builds appear to work. This bug is about cross building a native compiler. You can find logs of failed builds at http://crossqa.debian.net/src/gcc-9. They always fail with a configure invocation in gm2 that is given a --target, but no --build nor --host. Thus configure assumes a native build, but a cross CC is passed and configure fails: > cd gm2 ; \ > if echo -DIN_GCC | grep \\-DCROSS_COMPILE; then \ > AR=`echo > /usr/lib/gcc-cross/s390x-linux-gnu/9/../../../../s390x-linux-gnu/bin/ar | sed > -e "s/^ //"` ; \ > export AR ; \ > RANLIB=`echo > /usr/lib/gcc-cross/s390x-linux-gnu/9/../../../../s390x-linux-gnu/bin/ranlib | > sed -e "s/^ //"` ; \ > export RANLIB ; \ > /bin/bash -c '../../../src/gcc/gm2/configure > --srcdir=../../../src/gcc/gm2 --target=s390x-ibm-linux-gnu --program-suffix= > --includedir=`echo /usr/include | sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta`' ; \ > else \ > /bin/bash -c '../../../src/gcc/gm2/configure > --srcdir=../../../src/gcc/gm2 --target=s390x-ibm-linux-gnu --program-suffix=' > ; \ >fi > configure: loading site script /etc/dpkg-cross/cross-config.s390x > checking for s390x-linux-gnu-ar... /usr/bin/s390x-linux-gnu-ar > checking for flex... flex > checking for gcc... s390x-linux-gnu-gcc-9 > checking whether the C compiler works... yes > checking for C compiler default output file name... a.out > checking for suffix of executables... > checking whether we are cross compiling... configure: error: in > `/<>/build/gcc/gm2': > configure: error: cannot run C compiled programs. > If you meant to cross compile, use `--host'. > See `config.log' for more details > make[4]: *** [../../src/gcc/gm2/Make-lang.in:1286: gm2/gm2config.h] Error 1 I suspect that quite simply --host and --build flags are missing here as they are present in most other makefiles. Unfortunately, simply adding --build=$(build_alias) --host=$(host_alias) does not work, because the relevant makefile variables are not initialized in this makefile.
[Bug target/83100] [8 Regression] powerpc: internal compiler error: in get_variable_section, at varasm.c:1150 with -fdata-sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83100 --- Comment #2 from Helmut Grohne --- affects armel https://jenkins.debian.net/job/rebootstrap_armel_gcc8/2/console
[Bug bootstrap/80677] LIMITS_H_TEST is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80677 --- Comment #2 from Helmut Grohne --- (In reply to jos...@codesourcery.com from comment #1) > Well, if headers move then configure (and related) tests that look at them > will need updating. See how gcc/configure.ac looks in $target_header_dir > to identify the glibc version and various other configuration, for > example. As far as I understand it, gcc's build system takes care to consult $(build_tooldir)/sys-include. Debian's packaging of gcc takes care to populate it reasonably. I have performed a fair number of builds of gcc with glibc's headers moved now and cannot confirm the projected behavior. At present, it looks like fixing LIMITS_H_TEST is the remaining piece to the puzzle.
[Bug c/80677] New: LIMITS_H_TEST is wrong
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 after ) 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.
