This is the mail archive of the gcc-cvs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

r275346 - in /branches/gcc-8-branch/gcc: Change...


Author: iains
Date: Tue Sep  3 18:56:04 2019
New Revision: 275346

URL: https://gcc.gnu.org/viewcvs?rev=275346&root=gcc&view=rev
Log:
[c-family] Backport fix for PCH / PR61250.

When we are parsing a source file, the very first token might
be a PRAGMA_GCC_PCH_PREPROCESS. This indicates that we are going
read in a PCH file (named as the value of the pragma). If we don't
see this pragma, then we know that it's OK to release any resources
that the host might have set aside for the PCH file.

There is a thinko in the current implementation, in that the decision
to release resources is happening unconditionally right after the first
token is extracted but before it's been checked or acted upon.

This leads to the pch bug on Darwin, because we actually do release
resources - which are subsequently (reasonably) assumed to be available
when reading a PCH file. We then get random crashes or hangs depending
on the interaction between unmmap and malloc.

The bug is present everywhere but doesn't show on (say) Linux, since
the release of PCH resources is a NOP there.

This effects all the c-family front ends, because they all use
c_lex_with_flags () to implement this.

The solution is to check for the PRAGMA_GCC_PCH_PREPROCESS and only call
c_common_no_more_pch () when that is not the first token.

A secondary effect of the collection is that the name of the PCH file
can be collected during the ggc_pch_read() reset of state. Therefore
we should issue any diagnostic that might name the file before the
collections are triggered.

gcc/

2019-09-03  Iain Sandoe  <iain@sandoe.co.uk>

	Backport from mainline
	2019-08-23  Iain Sandoe  <iain@sandoe.co.uk>

	PR pch/61250
	* ggc-page.c (ggc_pch_read): Read the ggc_pch_ondisk structure
	and issue any diagnostics needed before collecting the pre-PCH
	state.

gcc/c-family/

2019-09-03  Iain Sandoe  <iain@sandoe.co.uk>

	Backport from mainline
	2019-08-23  Iain Sandoe  <iain@sandoe.co.uk>

	PR pch/61250
	* c-lex.c (c_lex_with_flags):  Don't call
	c_common_no_more_pch () from here.

gcc/c/

2019-09-03  Iain Sandoe  <iain@sandoe.co.uk>

	Backport from mainline.
	2019-08-23  Iain Sandoe  <iain@sandoe.co.uk>

	PR pch/61250
	* c-parser.c (c_parse_file): Call c_common_no_more_pch ()
	after determining that the first token is not
	PRAGMA_GCC_PCH_PREPROCESS.

gcc/cp/

2019-09-03  Iain Sandoe  <iain@sandoe.co.uk>

	Backported from mainline
	2019-08-23  Iain Sandoe  <iain@sandoe.co.uk>

	PR pch/61250
	* parser.c (cp_parser_initial_pragma): Call c_common_no_more_pch ()
	after determining that the first token is not
	PRAGMA_GCC_PCH_PREPROCESS.


Modified:
    branches/gcc-8-branch/gcc/ChangeLog
    branches/gcc-8-branch/gcc/c-family/ChangeLog
    branches/gcc-8-branch/gcc/c-family/c-lex.c
    branches/gcc-8-branch/gcc/c/ChangeLog
    branches/gcc-8-branch/gcc/c/c-parser.c
    branches/gcc-8-branch/gcc/cp/ChangeLog
    branches/gcc-8-branch/gcc/cp/parser.c
    branches/gcc-8-branch/gcc/ggc-page.c


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]