[Bug pch/61250] Random pch failures with -save-temps on x86_64-apple-darwin1(3-8).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #30 from Dominique d'Humieres --- Fixed on all open branches, closing.
[Bug pch/61250] Random pch failures with -save-temps on x86_64-apple-darwin1(3-8).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250 --- Comment #29 from Iain Sandoe --- Author: iains Date: Thu Sep 5 19:27:31 2019 New Revision: 275431 URL: https://gcc.gnu.org/viewcvs?rev=275431=gcc=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-05 Iain Sandoe Backport from mainline 2019-08-23 Iain Sandoe 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-05 Iain Sandoe Backport from mainline 2019-08-23 Iain Sandoe PR pch/61250 * c-lex.c (c_lex_with_flags): Don't call c_common_no_more_pch () from here. gcc/c 2019-09-05 Iain Sandoe Backport from mainline. 2019-08-23 Iain Sandoe 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-05 Iain Sandoe Backported from mainline 2019-08-23 Iain Sandoe 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-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/c-family/ChangeLog branches/gcc-7-branch/gcc/c-family/c-lex.c branches/gcc-7-branch/gcc/c/ChangeLog branches/gcc-7-branch/gcc/c/c-parser.c branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/parser.c branches/gcc-7-branch/gcc/ggc-page.c
[Bug pch/61250] Random pch failures with -save-temps on x86_64-apple-darwin1(3-8).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250 --- Comment #28 from Iain Sandoe --- Author: iains Date: Tue Sep 3 18:56:04 2019 New Revision: 275346 URL: https://gcc.gnu.org/viewcvs?rev=275346=gcc=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 Backport from mainline 2019-08-23 Iain Sandoe 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 Backport from mainline 2019-08-23 Iain Sandoe 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 Backport from mainline. 2019-08-23 Iain Sandoe 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 Backported from mainline 2019-08-23 Iain Sandoe 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
[Bug pch/61250] Random pch failures with -save-temps on x86_64-apple-darwin1(3-8).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250 --- Comment #27 from Iain Sandoe --- Author: iains Date: Sat Aug 31 19:12:10 2019 New Revision: 275246 URL: https://gcc.gnu.org/viewcvs?rev=275246=gcc=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-08-31 Iain Sandoe Backport from mainline 2019-08-23 Iain Sandoe 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-08-31 Iain Sandoe Backport from mainline 2019-08-23 Iain Sandoe PR pch/61250 * c-lex.c (c_lex_with_flags): Don't call c_common_no_more_pch () from here. gcc/c/ 2019-08-31 Iain Sandoe Backport from mainline. 2019-08-23 Iain Sandoe 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-08-31 Iain Sandoe Backported from mainline 2019-08-23 Iain Sandoe 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-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/c-family/ChangeLog branches/gcc-9-branch/gcc/c-family/c-lex.c branches/gcc-9-branch/gcc/c/ChangeLog branches/gcc-9-branch/gcc/c/c-parser.c branches/gcc-9-branch/gcc/cp/ChangeLog branches/gcc-9-branch/gcc/cp/parser.c branches/gcc-9-branch/gcc/ggc-page.c
[Bug pch/61250] Random pch failures with -save-temps on x86_64-apple-darwin1(3-8).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250 --- Comment #26 from Iain Sandoe --- so, should be fixed on trunk, so far.
[Bug pch/61250] Random pch failures with -save-temps on x86_64-apple-darwin1(3-8).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250 --- Comment #25 from Iain Sandoe --- Author: iains Date: Fri Aug 23 12:41:39 2019 New Revision: 274856 URL: https://gcc.gnu.org/viewcvs?rev=274856=gcc=rev Log: [PATCH, c-family] Fix a PCH thinko (and thus 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. This fixes a thinko in the current implementation, in that the decision to release resources was happening unconditionally right after the first token is extracted but before it's been checked or acted upon. This leads to the pch bug (seen 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/c-family/ 2019-08-23 Iain Sandoe PR pch/61250 * c-lex.c (c_lex_with_flags): Don't call c_common_no_more_pch () from here. gcc/c/ 2019-08-23 Iain Sandoe 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-08-23 Iain Sandoe 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. gcc/ 2019-08-23 Iain Sandoe 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. Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-lex.c trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/ggc-page.c
[Bug pch/61250] Random pch failures with -save-temps on x86_64-apple-darwin1(3-8).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250 Iain Sandoe changed: What|Removed |Added Target Milestone|--- |7.5
[Bug pch/61250] Random pch failures with -save-temps on x86_64-apple-darwin1(3-8).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250 --- Comment #24 from Iain Sandoe --- Created attachment 46743 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46743=edit Make sure we process the PRAGMA_GCC_PCH_PREPROCESS first We need to make sure that we've acted on the PRAGMA_GCC_PCH_PREPROCESS before calling c_common_no_more_pch (), since that's allowed to deallocate resources that are set aside for PCH.
