The PCH largefile test, in gcc/testsuite/gcc.dg/pch/pch.exp, fails using the default mmap implementation on i386-unknown-netbsdelf1.6.1. It also fails using the Solaris implementation on sparc-sun-solaris2.9. It fails on i686-pc-cygwin, although actually most of the PCH tests fail on that platform. A failure in the PCH largefile test for a given platform means that PCH is unstable for that platform. A PCH will work for most source code files but will fail for large source code files. The user can not easily predict when a PCH will work and when it will fail. When a PCH fails, there is no easy way to compile the file without removing the PCH so that gcc does not find it. On i386-unknown-netbsdelf1.6.1, and probably other platforms, a direct consequence is that qt-x11-free-3.3.0 can not be built. Those sources test whether PCH works, and use it if they do. The test passes, but some of the source files are large. Those source files fail to build.
Confirmed.
The Cygwin problems are 11341. I've added the two BSD maintainers to the CC.
Confirmed on i386-unknown-freebsd4.9 with yesterday's tree-ssa build.
*** Bug 16599 has been marked as a duplicate of this bug. ***
Actually this is target independent and only host dependent.
Subject: Re: PCH largefile test fails on various platforms > Actually this is target independent and only host dependent. Do you think we could set or fallback to MAP_FIXED? If we can't, the mmap call can fail on all hosts and the problem is not host dependent. Dave
Subject: Re: PCH largefile test fails on various platforms Some hosts override the default mmap call. See, e.g., config/host-linux.c. So whether this works is indeed host dependent.
I should add that always using MAP_FIXED will cause the new mmap to clobber any existing memory maps, which will lead to silent failure if the GC code (or the library malloc code) happens to have mapped any portion of that memory space. So using MAP_FIXED does not work in general. For an example of how it can be used on some systems, see gcc/config/host-solaris.c, which uses mincore() to explicitly check whether anything else is mapped in that address space. But note that that code does not work on, e.g., GNU/Linux, because mincore() does not work as expected--it does not detect anonymous maps.
Note also that, although the mincore() trick is functional on Solaris, it doesn't solve the problem in general because the largefile test fails on all versions I tested (Solaris 2.5.1, 2.6, 7, 8 and 9).
Subject: Re: PCH largefile test fails on various platforms > ------- Additional Comments From ebotcazou at gcc dot gnu dot org > 2004-07-17 15:43 ------- > Note also that, although the mincore() trick is functional on Solaris, it > doesn't solve the problem in general because the largefile test fails on all > versions I tested (Solaris 2.5.1, 2.6, 7, 8 and 9). Is that because a page is mapped in the PCH memory region, or because the mmap call with MAP_FIXED fails to return the desired address? HP-UX doesn't have mincore. It might be possible to write a routine to probe the region. However, it's not going to fix the problem if extant pages can be mapped in the PCH memory region. Dave
> Is that because a page is mapped in the PCH memory region, or because > the mmap call with MAP_FIXED fails to return the desired address? The former IIRC. > HP-UX doesn't have mincore. It might be possible to write a routine > to probe the region. However, it's not going to fix the problem if > extant pages can be mapped in the PCH memory region. Btw, the test fails on PA/Linux too?
Subject: Re: PCH largefile test fails on various platforms "ebotcazou at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: > Btw, the test fails on PA/Linux too? Add an appropriate definition of TRY_EMPTY_VM_SPACE in gcc/config/host-linux.c. Ian
Subject: Re: PCH largefile test fails on various platforms > Btw, the test fails on PA/Linux too? Yes. I had one libstdc++ testsuite run recently where this problem caused nearly all the tests to fail. It's not just a problem with largefile.c. Dave
The freebsd problem is PR 16646.
*** Bug 17131 has been marked as a duplicate of this bug. ***
Subject: Re: PCH largefile test fails on various platforms I have noted in testing in the past week that changing kernels on hppa-linux can break PCH. Rerunning the libstdc++-v3 testsuite after a kernel change sometimes causes nearly all the tests to fail. Dave
patch for powerpc64-linux-gnu: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01037.html Index: gcc/config/host-linux.c =================================================================== RCS file: /home/jgrimm/gcc-cvs/gcc/gcc/config/host-linux.c,v retrieving revision 1.2 diff -c -3 -p -r1.2 host-linux.c *** gcc/config/host-linux.c 24 Apr 2004 00:33:18 -0000 1.2 --- gcc/config/host-linux.c 12 Oct 2004 21:35:47 -0000 *************** *** 75,80 **** --- 75,82 ---- # define TRY_EMPTY_VM_SPACE 0x8000000000 #elif defined(__s390__) # define TRY_EMPTY_VM_SPACE 0x60000000 + #elif defined(__powerpc__) + # define TRY_EMPTY_VM_SPACE 0x60000000 #else # define TRY_EMPTY_VM_SPACE 0 #endif
+ #elif defined(__sparc__) + # define TRY_EMPTY_VM_SPACE 0x60000000 Also works for sparc-linux and largefile.c on sparc64-linux. Unfortunatly, there are other pch failures on sparc64-linux.
> + #elif defined(__sparc__) > + # define TRY_EMPTY_VM_SPACE 0x60000000 > > Also works for sparc-linux and largefile.c on sparc64-linux. Unfortunatly, > there are other pch failures on sparc64-linux. I'm a bit skeptical about using the same value for the 32-bit and the 64-bit flavors, but I'm not a specialist of Linux on the SPARC at all. I'd suggest to contact David S. Miller (see the MAINTAINERS file).
Subject: Bug 14940 CVSROOT: /cvs/gcc Module name: gcc Changes by: phython@gcc.gnu.org 2004-11-09 12:35:16 Modified files: gcc : ChangeLog gcc/config : host-linux.c Log message: 2004-11-07 James A. Morrison <phython@gcc.gnu.org> PR pch/14940 * config/host-linux.c (TRY_EMPTY_VM_SPACE): Add __sparc__ definitions. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6237&r2=2.6238 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/host-linux.c.diff?cvsroot=gcc&r1=1.3&r2=1.4
Subject: Bug 14940 CVSROOT: /cvs/gcc Module name: gcc Changes by: danglin@gcc.gnu.org 2004-11-23 02:29:40 Modified files: gcc : ChangeLog gcc/config : host-linux.c Log message: PR pch/14940 * config/host-linux.c (TRY_EMPTY_VM_SPACE): Define for __hppa__. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6476&r2=2.6477 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/host-linux.c.diff?cvsroot=gcc&r1=1.4&r2=1.5
Subject: Bug 14940 CVSROOT: /cvs/gcc Module name: gcc Changes by: danglin@gcc.gnu.org 2004-11-27 16:57:06 Modified files: gcc : ChangeLog gcc/config : host-linux.c Log message: PR pch/14940 * config/host-linux.c (TRY_EMPTY_VM_SPACE): Revert 2004-11-22 change. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6586&r2=2.6587 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/host-linux.c.diff?cvsroot=gcc&r1=1.5&r2=1.6
Subject: Bug 14940 CVSROOT: /cvs/gcc Module name: gcc Changes by: danglin@gcc.gnu.org 2004-11-30 03:11:29 Modified files: gcc : ChangeLog config.host Added files: gcc/config/pa : pa-host.c x-hpux x-linux Log message: PR pch/14940 * config/pa/pa-host.c, config/pa/x-hpux, config/pa/x-linux: New files. * config.host (hppa*-*-hpux*, hppa*-*-linux): Define out_host_hook_obj and host_xmake_file using new host configuration files. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6636&r2=2.6637 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config.host.diff?cvsroot=gcc&r1=2.11&r2=2.12 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/pa-host.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/x-hpux.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/x-linux.diff?cvsroot=gcc&r1=NONE&r2=1.1
Also fails on ia64-hpux.
Subject: Re: PCH largefile test fails on various platforms > ------- Additional Comments From jsm28 at gcc dot gnu dot org 2005-02-11 > 01:54 ------- > Also fails on ia64-hpux. This is now "fixed" on the PA. You might look at pa-host.c to if the adopted work around might help other ports. Dave
> This is now "fixed" on the PA. You might look at pa-host.c to if the > adopted work around might help other ports. Alas, that doesn't work on SPARC/Solaris.
Subject: Bug 14940 CVSROOT: /cvs/gcc Module name: gcc Changes by: phython@gcc.gnu.org 2005-02-15 20:52:14 Modified files: gcc : ChangeLog gcc/config : host-linux.c Log message: 2005-02-15 James A. Morrison <phython@gcc.gnu.org> PR pch/14940 PR target/19300 * config/host-linux.c (linux_gt_pch_use_address): Copy from config/pa/pa-host.c:pa_gt_pch_use_address. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7484&r2=2.7485 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/host-linux.c.diff?cvsroot=gcc&r1=1.6&r2=1.7
Subject: Bug 14940 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_4-branch Changes by: ian@gcc.gnu.org 2005-08-02 19:03:46 Modified files: gcc : ChangeLog c-pch.c config.host ggc-common.c hooks.c hooks.h hosthooks-def.h hosthooks.h gcc/config/rs6000: host-darwin.c gcc/doc : hostconfig.texi gcc/testsuite : ChangeLog gcc/testsuite/gcc.dg/pch: pch.exp Added files: gcc/config : host-linux.c host-solaris.c x-linux x-solaris Log message: ./ PR pch/14400 Backport from mainline: 2005-08-01 Ian Lance Taylor <ian@airs.com> * config/host-linux.c (linux_gt_pch_get_address): Add new name randomize_va_space for virtual address randomization control. 2005-02-15 James A. Morrison <phython@gcc.gnu.org> PR pch/14940 PR target/19300 * config/host-linux.c (linux_gt_pch_use_address): Copy from config/pa/pa-host.c:pa_gt_pch_use_address. 2004-11-09 James A. Morrison <phython@gcc.gnu.org> PR pch/14940 * config/host-linux.c (TRY_EMPTY_VM_SPACE): Add __sparc__ definitions. 2004-10-15 Jon Grimm <jgrimm2@us.ibm.com> * config/host-linux.c (TRY_EMPTY_VM_SPACE): Add __powerpc__ definition. 2004-04-24 Ulrich Weigand <uweigand@de.ibm.com> * config/host-linux.c (TRY_EMPTY_VM_SPACE): Define for __s390__ and __s390x__ hosts. 2004-04-08 Ian Lance Taylor <ian@wasabisystems.com> * config/rs6000/host-darwin.c (darwin_rs6000_gt_pch_use_address): Return 1 if file was successfully mapped. 2004-03-15 Ian Lance Taylor <ian@wasabisystems.com> * config/rs6000/host-darwin.c (darwin_rs6000_gt_pch_use_address): Fix the check for abort and only do the mmap if we can. 2004-03-12 Andrew Pinski <apinski@apple.com> * config/rs6000/host-darwin.c (darwin_rs6000_gt_pch_use_address): Use ret instead of result. Use addr instead of base. 2004-03-10 Richard Henderson <rth@redhat.com> * c-pch.c (c_common_no_more_pch): Update for gt_pch_use_address extra arguments. * config.host (*-*-solaris2*, *-*-linux*): Add out_host_hook_obj and host_xmake_file fragments. * ggc-common.c (gt_pch_save): Update for gt_pch_get_address change. (gt_pch_restore): Similarly for gt_pch_use_address. (default_gt_pch_get_address): New. (mmap_gt_pch_get_address): Split out of gt_pch_save. (default_gt_pch_use_address): Split out of gt_pch_restore. (mmap_gt_pch_use_address): Likewise. * hooks.c (hook_voidp_size_t_null): Remove. (hook_bool_voidp_size_t_false): Remove. * hooks.h: Likewise. * hosthooks-def.h (HOST_HOOKS_GT_PCH_GET_ADDRESS): Use one of the default_ or mmap_ definitions. (HOST_HOOKS_GT_PCH_USE_ADDRESS): Likewise. * hosthooks.h (struct host_hooks): Update gt_pch_get_address and gt_pch_use_address. * config/host-linux.c, config/host-solaris.c: New files. * config/x-linux, config/x-solaris: New files. * config/rs6000/host-darwin.c darwin_rs6000_gt_pch_get_address): Update for changed definition. (darwin_rs6000_gt_pch_use_address): Likewise. * doc/hostconfig.texi: Update docs. testsuite/ PR pch/14400 Backport from mainline: 2004-04-07 Ian Lance Taylor <ian@wasabisystems.com> * gcc.dg/pch/pch.exp: Add largefile test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.893&r2=2.2326.2.894 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-pch.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.19.4.1&r2=1.19.4.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config.host.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.7&r2=2.7.12.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ggc-common.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.78&r2=1.78.6.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/hooks.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.22.10.2&r2=1.22.10.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/hooks.h.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.23.10.2&r2=1.23.10.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/hosthooks-def.h.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3&r2=1.3.12.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/hosthooks.h.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.4&r2=1.4.12.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/host-linux.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.11.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/host-solaris.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.3.4.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/x-linux.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.6.48.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/x-solaris.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.2.50.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/host-darwin.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.7&r2=1.7.12.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/hostconfig.texi.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.7&r2=1.7.10.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.416&r2=1.3389.2.417 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pch/pch.exp.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.8&r2=1.8.18.1
Subject: Re: PCH largefile test fails on various platforms > Log message: > ./ > PR pch/14400 > Backport from mainline: With this change largefile.c now fails on hppa2.0w-hp-hpux11.00 on 3.4. So, we now have a 3.4 regression. I guess the 4.0 PA fix needs to be backported. Dave
My patch added the largefile test to the 3.4 branch. I don't think that failing a new test can be called a regression. I expect that the compiler would have failed the test before, too, it's just that nobody knew about it. Failing the largefile test means that pre-compiled headers will fail occasionally and effectively unpredictably. That's why I added the test: so that at least people will know for which targets PCH is unreliable. I would be in favor of backporting to 3.4 any HP/UX fix which fixes the largefile test. But since I don't think it's a regression I don't think it's on my plate to do that. I will probably do it if nobody else does, but not very soon.
Subject: Re: PCH largefile test fails on various platforms > My patch added the largefile test to the 3.4 branch. I don't think that failing > a new test can be called a regression. I expect that the compiler would have > failed the test before, too, it's just that nobody knew about it. Ok. > I would be in favor of backporting to 3.4 any HP/UX fix which fixes the > largefile test. But since I don't think it's a regression I don't think it's on > my plate to do that. I will probably do it if nobody else does, but not very soon. I'll try to find the time to test the change in the next few days. Dave
Subject: Bug 14940 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_4-branch Changes by: danglin@gcc.gnu.org 2005-08-07 02:48:04 Modified files: gcc : ChangeLog config.host Added files: gcc/config/pa : pa-host.c x-hpux x-linux Log message: PR pch/14940 * config.host (hppa*-*-hpux*, hppa*-*-linux): Define out_host_hook_obj and host_xmake_file using new host configuration files. * config/pa/pa-host.c, config/pa/x-hpux, config/pa/x-linux: New files. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.901&r2=2.2326.2.902 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config.host.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.7.12.1&r2=2.7.12.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/pa-host.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.4.8.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/x-hpux.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.42.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/x-linux.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.42.1
I think I'm seeing this same problem on Solaris x86. Executing on host: /var/tmp/gcc_svn/gcc20051214/gcc/xgcc -B/var/tmp/gcc_svn/gcc2 0051214/gcc/ largefile.c -O0 -g -I. -S -o largefile.s (timeout = 300) largefile.c:1: fatal error: had to relocate PCH^M compilation terminated.^M compiler exited with status 1 output is: largefile.c:1: fatal error: had to relocate PCH^M compilation terminated.^M FAIL: largefile.c -O0 -g (test for excess errors) Excess errors: largefile.c:1: fatal error: had to relocate PCH Should the SPARC fix apply for x86 also? Brett Albertson
Just a confirmation that I see this test failing with GCC 4.1 on Solaris as well. As Eric says in Comment #11, the symptoms are that, in host-solaris.c the first call to mmap succeeds (but at the wrong address). Then, mincore reports that the pages we want are already mapped, so we can't try the MAP_FIXED approach.
Ian Taylor suggests: The way to fix this is to add a HOST_HOOKS_GT_PCH_GET_ADDRESS to host-solaris.c. That hook should try to allocate the space in some address area that is normally free on Solaris. See the use of TRY_EMPTY_VM_SPACE in host-linux.c.
Subject: Bug 14940 Author: ro Date: Mon Mar 1 12:44:33 2010 New Revision: 157141 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157141 Log: gcc: PR pch/14940 * config/host-solaris.c (HOST_HOOKS_GT_PCH_GET_ADDRESS): Redefine to sol_gt_pch_get_address. (TRY_EMPTY_VM_SPACE): Define for all combinations of 32 and 64-bit, SPARC and x86. (sol_gt_pch_get_address): New function. gcc/testsuite: PR pch/14940 * gcc.dg/pch/pch.exp: Don't XFAIL largefile.c on i?86-*-solaris2.10. Modified: trunk/gcc/ChangeLog trunk/gcc/config/host-solaris.c trunk/gcc/testsuite/gcc.dg/pch/pch.exp
Subject: Bug 14940 Author: ro Date: Mon Mar 1 14:07:12 2010 New Revision: 157145 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157145 Log: PR pch/14940 * gcc.dg/pch/pch.exp: Don't XFAIL largefile.c on i?86-*-solaris2.10. Modified: trunk/gcc/testsuite/ChangeLog
Fixed for Solaris 2 for 4.5.0: http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00979.html
Subject: Bug 14940 Author: ro Date: Wed Jun 2 17:28:24 2010 New Revision: 160176 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160176 Log: Backport from mainline: 2010-03-01 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> PR pch/14940 * config/host-solaris.c (HOST_HOOKS_GT_PCH_GET_ADDRESS): Redefine to sol_gt_pch_get_address. (TRY_EMPTY_VM_SPACE): Define for all combinations of 32 and 64-bit, SPARC and x86. (sol_gt_pch_get_address): New function. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/host-solaris.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pch/pch.exp
Subject: Bug 14940 Author: ro Date: Mon Jul 12 11:57:16 2010 New Revision: 162074 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162074 Log: PR pch/14940 * config/host-solaris.c (mmap_fixed): New function. (sol_gt_pch_get_address): Use it. (sol_gt_pch_use_address): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/host-solaris.c
Subject: Bug 14940 Author: ro Date: Tue Jul 13 09:06:17 2010 New Revision: 162127 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162127 Log: Backport from mainline: 2010-07-12 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> PR pch/14940 * config/host-solaris.c (mmap_fixed): New function. (sol_gt_pch_get_address): Use it. (sol_gt_pch_use_address): Likewise. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/host-solaris.c
Subject: Bug 14940 Author: ro Date: Tue Jul 13 09:07:18 2010 New Revision: 162128 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162128 Log: Backport from mainline: 2010-07-12 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> PR pch/14940 * config/host-solaris.c (mmap_fixed): New function. (sol_gt_pch_get_address): Use it. (sol_gt_pch_use_address): Likewise. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/host-solaris.c
Author: ro Date: Tue Feb 15 09:49:14 2011 New Revision: 170166 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170166 Log: PR pch/14940 * config/alpha/host-osf.c: New file. * config/alpha/x-osf: New file. * config.host (alpha*-dec-osf*): Use it. Added: trunk/gcc/config/alpha/host-osf.c trunk/gcc/config/alpha/x-osf Modified: trunk/gcc/ChangeLog trunk/gcc/config.host
Author: ro Date: Tue Feb 15 09:51:58 2011 New Revision: 170167 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170167 Log: PR pch/14940 * config/alpha/host-osf.c: New file. * config/alpha/x-osf: New file. * config.host (alpha*-dec-osf*): Use it. Added: branches/gcc-4_5-branch/gcc/config/alpha/host-osf.c branches/gcc-4_5-branch/gcc/config/alpha/x-osf Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config.host
Author: ro Date: Tue Feb 15 09:58:01 2011 New Revision: 170168 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170168 Log: PR pch/14940 * config/alpha/host-osf.c: New file. * config/alpha/x-osf: New file. * config.host (alpha*-dec-osf*): Use it. Added: branches/gcc-4_4-branch/gcc/config/alpha/host-osf.c branches/gcc-4_4-branch/gcc/config/alpha/x-osf Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config.host
It looks like the windows host has the similar issue, see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926
Patch for i386-mingw32: diff --git a/gcc/config/i386/host-mingw32.c b/gcc/config/i386/host-mingw32.c index aa17378..7ee6d0b 100644 --- a/gcc/config/i386/host-mingw32.c +++ b/gcc/config/i386/host-mingw32.c @@ -42,9 +42,6 @@ static size_t mingw32_gt_pch_alloc_granularity (void); static inline void w32_error(const char*, const char*, int, const char*); -/* FIXME: Is this big enough? */ -static const size_t pch_VA_max_size = 128 * 1024 * 1024; - /* Granularity for reserving address space. */ static size_t va_granularity = 0x10000; @@ -86,9 +83,6 @@ static void * mingw32_gt_pch_get_address (size_t size, int) { void* res; - size = (size + va_granularity - 1) & ~(va_granularity - 1); - if (size > pch_VA_max_size) - return NULL; /* FIXME: We let system determine base by setting first arg to NULL. Allocating at top of available address space avoids unnecessary @@ -148,7 +142,7 @@ mingw32_gt_pch_use_address (void *addr, size_t size, int fd, /* Offset must be also be a multiple of allocation granularity for this to work. We can't change the offset. */ - if ((offset & (va_granularity - 1)) != 0 || size > pch_VA_max_size) + if ((offset & (va_granularity - 1)) != 0) return -1;
Hi, Martin Richter, thanks, I have post this patch link in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926.
(In reply to Martin Richter from comment #47) My apologies, that patch is incorrect - `VirtualAlloc` still uses `pch_VA_max_size` instead of `size`. Some discussion about this bug and the reasoning behind the patch can be found here: https://sourceforge.net/p/mingw-w64/bugs/382/ Now the correct patch: diff --git a/gcc/config/i386/host-mingw32.c b/gcc/config/i386/host-mingw32.c index aa17378..631d9c4 100644 --- a/gcc/config/i386/host-mingw32.c +++ b/gcc/config/i386/host-mingw32.c @@ -42,9 +42,6 @@ static size_t mingw32_gt_pch_alloc_granularity (void); static inline void w32_error(const char*, const char*, int, const char*); -/* FIXME: Is this big enough? */ -static const size_t pch_VA_max_size = 128 * 1024 * 1024; - /* Granularity for reserving address space. */ static size_t va_granularity = 0x10000; @@ -86,9 +83,6 @@ static void * mingw32_gt_pch_get_address (size_t size, int) { void* res; - size = (size + va_granularity - 1) & ~(va_granularity - 1); - if (size > pch_VA_max_size) - return NULL; /* FIXME: We let system determine base by setting first arg to NULL. Allocating at top of available address space avoids unnecessary @@ -98,7 +92,7 @@ mingw32_gt_pch_get_address (size_t size, int) If we allocate at bottom we need to reserve the address as early as possible and at the same point in each invocation. */ - res = VirtualAlloc (NULL, pch_VA_max_size, + res = VirtualAlloc (NULL, size, MEM_RESERVE | MEM_TOP_DOWN, PAGE_NOACCESS); if (!res) @@ -148,7 +142,7 @@ mingw32_gt_pch_use_address (void *addr, size_t size, int fd, /* Offset must be also be a multiple of allocation granularity for this to work. We can't change the offset. */ - if ((offset & (va_granularity - 1)) != 0 || size > pch_VA_max_size) + if ((offset & (va_granularity - 1)) != 0) return -1;
The following patch fixes segfault when gt_pch_use_address fails (returns -1). fatal_error now correctly shows an error message and terminates the program. I have basicly only reordered reads, and placed them after the file mapping itself. Global pointers are changed only after gt_pch_use_address succeeds, so in case of failure they still contain valid addresses. This patch is meant for the master branch. However, it should not be hard to modify it for others. diff --git a/gcc/ggc-common.c b/gcc/ggc-common.c index 5096837..f741f2c 100644 --- a/gcc/ggc-common.c +++ b/gcc/ggc-common.c @@ -599,7 +599,9 @@ gt_pch_restore (FILE *f) size_t i; struct mmap_info mmi; int result; - + long pch_tabs_off; + long pch_data_off; + /* Delete any deletable objects. This makes ggc_pch_read much faster, as it can be sure that no GCable objects remain other than the ones just read in. */ @@ -607,20 +609,24 @@ gt_pch_restore (FILE *f) for (rti = *rt; rti->base != NULL; rti++) memset (rti->base, 0, rti->stride); - /* Read in all the scalar variables. */ + /* We need to read tables after mapping, or fatal_error will + segfault when gt_pch_use_address returns -1. Skip them for now. */ + pch_tabs_off = ftell(f); + + /* Skip all the scalar variables. */ for (rt = gt_pch_scalar_rtab; *rt; rt++) for (rti = *rt; rti->base != NULL; rti++) - if (fread (rti->base, rti->stride, 1, f) != 1) - fatal_error (input_location, "can%'t read PCH file: %m"); + if (fseek (f, rti->stride, SEEK_CUR) != 0) + fatal_error (input_location, "can%'t read PCH file: %m"); - /* Read in all the global pointers, in 6 easy loops. */ + /* Skip all the global pointers. */ for (rt = gt_ggc_rtab; *rt; rt++) for (rti = *rt; rti->base != NULL; rti++) for (i = 0; i < rti->nelt; i++) - if (fread ((char *)rti->base + rti->stride * i, - sizeof (void *), 1, f) != 1) - fatal_error (input_location, "can%'t read PCH file: %m"); - + if (fseek (f, sizeof (void *), SEEK_CUR) != 0) + fatal_error (input_location, "can%'t read PCH file: %m"); + + /* mmi still has to be read now. */ if (fread (&mmi, sizeof (mmi), 1, f) != 1) fatal_error (input_location, "can%'t read PCH file: %m"); @@ -631,12 +637,35 @@ gt_pch_restore (FILE *f) if (result == 0) { if (fseek (f, mmi.offset, SEEK_SET) != 0 - || fread (mmi.preferred_base, mmi.size, 1, f) != 1) - fatal_error (input_location, "can%'t read PCH file: %m"); + || fread (mmi.preferred_base, mmi.size, 1, f) != 1) + fatal_error (input_location, "can%'t read PCH file: %m"); } else if (fseek (f, mmi.offset + mmi.size, SEEK_SET) != 0) fatal_error (input_location, "can%'t read PCH file: %m"); + + /* File mapping done, read tables now. */ + pch_data_off = ftell(f); + + if (fseek (f, pch_tabs_off, SEEK_SET) != 0) + fatal_error (input_location, "can%'t read PCH file: %m"); + /* Read in all the scalar variables. */ + for (rt = gt_pch_scalar_rtab; *rt; rt++) + for (rti = *rt; rti->base != NULL; rti++) + if (fread (rti->base, rti->stride, 1, f) != 1) + fatal_error (input_location, "can%'t read PCH file: %m"); + + /* Read in all the global pointers, in 6 easy loops. */ + for (rt = gt_ggc_rtab; *rt; rt++) + for (rti = *rt; rti->base != NULL; rti++) + for (i = 0; i < rti->nelt; i++) + if (fread ((char *)rti->base + rti->stride * i, + sizeof (void *), 1, f) != 1) + fatal_error (input_location, "can%'t read PCH file: %m"); + + if (fseek (f, pch_data_off, SEEK_SET) != 0) + fatal_error (input_location, "can%'t read PCH file: %m"); + ggc_pch_read (f, mmi.preferred_base); gt_pch_restore_stringpool ();
I can confirm Martin's patches in #49 and #50 work on GCC 9.2.0. They solve silent segfaults when using large PCHs (> 128MB).
N.B. patches need to be posted to the gcc-patches mailing list for review, not here. https://gcc.gnu.org/contribute.html
The patch no longer applies to GCC 12.
(In reply to LIU Hao from comment #53) > The patch no longer applies to GCC 12. Right because I think this issue has been fixed by r12-5855-g747380f47da0da .
(In reply to Andrew Pinski from comment #54) > (In reply to LIU Hao from comment #53) > > The patch no longer applies to GCC 12. > > Right because I think this issue has been fixed by r12-5855-g747380f47da0da . No, at least not completely. In 'gcc/config/i386/host-mingw32.cc' there is still the 128MiB hard limit: ``` /* FIXME: Is this big enough? */ static const size_t pch_VA_max_size = 128 * 1024 * 1024; ```
(In reply to LIU Hao from comment #55) > (In reply to Andrew Pinski from comment #54) > > (In reply to LIU Hao from comment #53) > > > The patch no longer applies to GCC 12. > > > > Right because I think this issue has been fixed by r12-5855-g747380f47da0da . > > No, at least not completely. In 'gcc/config/i386/host-mingw32.cc' there is > still the 128MiB hard limit: > > ``` > /* FIXME: Is this big enough? */ > static const size_t pch_VA_max_size = 128 * 1024 * 1024; > ``` Right, some hosts need to be changed. Looks like only darwin and linux was fixed. See r12-5857-g0d5db1dd65b452 for the change done for darwin. Maybe a similar change is needed for Mingw.
(In reply to Andrew Pinski from comment #56) > Right, some hosts need to be changed. > Looks like only darwin and linux was fixed. Yeah, I said that clearly that other ports need to be changed if they want to take advantage of it. I don't have access to those targets, can't test and am not familiar with them, it is up to the maintainers of those targets or anyone that is willing to test it...
The master branch has been updated by Jonathan Yong <jyong@gcc.gnu.org>: https://gcc.gnu.org/g:f769d22ab685671095525d09ef29eeeed0ae3cee commit r13-6392-gf769d22ab685671095525d09ef29eeeed0ae3cee Author: LIU Hao <lh_mouse@126.com> Date: Tue May 10 13:19:07 2022 +0800 gcc: Remove size limit of PCH for *-*-mingw32 hosts PCHs can now be relocated, so the size limit makes no sense any more. This patch was submited to MSYS2 9 months ago for GCC 12. No issue has been reported so far. Reference: https://github.com/msys2/MINGW-packages/blob/717d5a5a09e2370e3bd7e12b393a26dbfbe48921/mingw-w64-gcc/0010-Fix-using-large-PCH.patch Signed-off-by: LIU Hao <lh_mouse@126.com> gcc/ChangeLog: PR pch/14940 * config/i386/host-mingw32.cc (mingw32_gt_pch_get_address): Remove the size limit `pch_VA_max_size` Signed-off-by: Jonathan Yong <10walls@gmail.com>