Bug 14940

Summary: PCH largefile test fails on various platforms
Product: gcc Reporter: Ian Lance Taylor <ian>
Component: pchAssignee: Not yet assigned to anyone <unassigned>
Status: NEW ---    
Severity: normal CC: asmwarrior, brett.albertson, cato, christian.joensson, danglin, egallager, gcc-bugs, ghazi, jakub, jruffin, jsm28, jwakely.gcc, lh_mouse, ljrittle, phython, sjames, thorpej
Priority: P2 Keywords: ice-on-valid-code, testsuite-fail
Version: 4.0.0   
Target Milestone: ---   
Host: i386-*-netbsdelf1.6.1 Target:
Build: Known to work:
Known to fail: Last reconfirmed: 2005-12-12 03:14:55
Bug Depends on: 16646    
Bug Blocks:    

Description Ian Lance Taylor 2004-04-13 13:57:22 UTC
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.
Comment 1 Andrew Pinski 2004-04-13 16:09:15 UTC
Confirmed.
Comment 2 Geoff Keating 2004-04-13 18:56:12 UTC
The Cygwin problems are 11341.

I've added the two BSD maintainers to the CC.
Comment 3 Loren Rittle 2004-04-14 17:52:52 UTC
Confirmed on i386-unknown-freebsd4.9 with yesterday's tree-ssa build.
Comment 4 Andrew Pinski 2004-07-17 04:09:22 UTC
*** Bug 16599 has been marked as a duplicate of this bug. ***
Comment 5 Andrew Pinski 2004-07-17 04:10:43 UTC
Actually this is target independent and only host dependent.
Comment 6 dave 2004-07-17 04:21:41 UTC
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
Comment 7 Ian Lance Taylor 2004-07-17 14:20:54 UTC
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.
Comment 8 Ian Lance Taylor 2004-07-17 14:43:32 UTC
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.
Comment 9 Eric Botcazou 2004-07-17 15:43:03 UTC
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).
Comment 10 dave 2004-07-17 17:10:18 UTC
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
Comment 11 Eric Botcazou 2004-07-18 10:00:41 UTC
> 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?
Comment 12 Ian Lance Taylor 2004-07-18 12:25:52 UTC
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
Comment 13 dave 2004-07-18 16:03:08 UTC
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
Comment 14 Andrew Pinski 2004-07-20 17:49:03 UTC
The freebsd problem is PR 16646.
Comment 15 Andrew Pinski 2004-08-21 17:05:26 UTC
*** Bug 17131 has been marked as a duplicate of this bug. ***
Comment 16 dave 2004-08-31 14:20:12 UTC
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
Comment 17 Jon Grimm 2004-10-12 19:56:22 UTC
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

Comment 18 James A. Morrison 2004-11-04 04:57:39 UTC
+ #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.
Comment 19 Eric Botcazou 2004-11-04 07:09:13 UTC
> + #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).
Comment 20 GCC Commits 2004-11-09 12:35:36 UTC
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

Comment 21 GCC Commits 2004-11-23 02:30:17 UTC
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

Comment 22 GCC Commits 2004-11-27 16:57:17 UTC
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

Comment 23 GCC Commits 2004-11-30 03:11:35 UTC
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

Comment 24 Joseph S. Myers 2005-02-11 01:54:03 UTC
Also fails on ia64-hpux.
Comment 25 dave 2005-02-11 02:07:08 UTC
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
Comment 26 Eric Botcazou 2005-02-13 11:52:46 UTC
> 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.
Comment 27 GCC Commits 2005-02-15 20:52:55 UTC
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

Comment 28 GCC Commits 2005-08-02 19:03:59 UTC
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

Comment 29 dave 2005-08-04 17:41:20 UTC
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
Comment 30 Ian Lance Taylor 2005-08-04 17:54:06 UTC
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.
Comment 31 dave 2005-08-04 18:04:01 UTC
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
Comment 33 Brett Albertson 2005-12-14 19:24:54 UTC
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
Comment 34 Mark Mitchell 2007-03-27 04:31:48 UTC
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.
Comment 35 Mark Mitchell 2007-05-08 22:05:40 UTC
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.
Comment 36 Rainer Orth 2010-03-01 12:44:54 UTC
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

Comment 37 Rainer Orth 2010-03-01 14:07:30 UTC
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

Comment 38 Rainer Orth 2010-03-01 18:17:59 UTC
Fixed for Solaris 2 for 4.5.0:

http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00979.html
Comment 39 Rainer Orth 2010-06-02 17:28:48 UTC
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

Comment 40 Rainer Orth 2010-07-12 11:57:31 UTC
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

Comment 41 Rainer Orth 2010-07-13 09:06:31 UTC
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

Comment 42 Rainer Orth 2010-07-13 09:07:30 UTC
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

Comment 43 Rainer Orth 2011-02-15 09:49:22 UTC
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
Comment 44 Rainer Orth 2011-02-15 09:52:04 UTC
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
Comment 45 Rainer Orth 2011-02-15 09:58:04 UTC
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
Comment 46 asmwarrior 2015-05-31 06:22:19 UTC
It looks like the windows host has the similar issue, see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926
Comment 47 Martin Richter 2015-06-27 18:28:15 UTC
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;
Comment 48 asmwarrior 2015-06-28 08:53:19 UTC
Hi, Martin Richter, thanks, I have post this patch link in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926.
Comment 49 Martin Richter 2015-07-07 10:07:45 UTC
(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;
Comment 50 Martin Richter 2015-07-09 18:47:20 UTC
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 ();
Comment 51 Julien Ruffin 2020-11-11 15:30:53 UTC
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).
Comment 52 Jonathan Wakely 2021-05-19 17:37:01 UTC
N.B. patches need to be posted to the gcc-patches mailing list for review, not here. https://gcc.gnu.org/contribute.html
Comment 53 LIU Hao 2022-05-10 04:52:19 UTC
The patch no longer applies to GCC 12.
Comment 54 Andrew Pinski 2022-05-10 04:59:13 UTC
(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 .
Comment 55 LIU Hao 2022-05-10 05:05:25 UTC
(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;
```
Comment 56 Andrew Pinski 2022-05-10 05:15:09 UTC
(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.
Comment 57 Jakub Jelinek 2022-05-10 08:51:38 UTC
(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...
Comment 58 GCC Commits 2023-03-01 13:47:16 UTC
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>