* Re: [PATCH] Try harder to fix recently introduced crashes in ggc_collect @ 2017-05-19 17:25 Dominique d'Humières 2017-05-19 17:31 ` Bernd Edlinger 0 siblings, 1 reply; 17+ messages in thread From: Dominique d'Humières @ 2017-05-19 17:25 UTC (permalink / raw) To: bernd.edlinger; +Cc: gcc-patches Hi Bernd, Your patches are causing troubles when I try to do "incremental updates »: After revision r248290 it fails with ../../work/gcc/cp/init.c:4916:10: fatal error: gt-cp-init.h: No such file or directory #include "gt-cp-init.h » and after r248242 with ../../work/gcc/c-family/c-format.c:4215:10: fatal error: gt-c-family-c-format.h: No such file or directory #include "gt-c-family-c-format.h » Note that after r248242 a full bootstrap succeeded (don’t know yet for r248290). Is there a way to fix that? TIA Dominique ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Try harder to fix recently introduced crashes in ggc_collect 2017-05-19 17:25 [PATCH] Try harder to fix recently introduced crashes in ggc_collect Dominique d'Humières @ 2017-05-19 17:31 ` Bernd Edlinger 2017-05-19 18:14 ` Dominique d'Humières 2017-05-22 16:55 ` Martin Sebor 0 siblings, 2 replies; 17+ messages in thread From: Bernd Edlinger @ 2017-05-19 17:31 UTC (permalink / raw) To: Dominique d'Humières; +Cc: gcc-patches On 05/19/17 19:05, Dominique d'Humières wrote: > Hi Bernd, > > Your patches are causing troubles when I try to do "incremental updates »: > > After revision r248290 it fails with > > ../../work/gcc/cp/init.c:4916:10: fatal error: gt-cp-init.h: No such file or directory > #include "gt-cp-init.h » > > and after r248242 with > > ../../work/gcc/c-family/c-format.c:4215:10: fatal error: gt-c-family-c-format.h: No such file or directory > #include "gt-c-family-c-format.h » > > Note that after r248242 a full bootstrap succeeded (don’t know yet for r248290). > > Is there a way to fix that? > No, unfortunately it looks like incremental does not work in this case. You can try to remove gcc/s-gtyp-input, maybe it un-breaks your build. However, I gave up at that point and did a full bootstrap instead. Bernd. > TIA > > Dominique > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Try harder to fix recently introduced crashes in ggc_collect 2017-05-19 17:31 ` Bernd Edlinger @ 2017-05-19 18:14 ` Dominique d'Humières 2017-05-22 7:36 ` Richard Biener 2017-05-22 16:55 ` Martin Sebor 1 sibling, 1 reply; 17+ messages in thread From: Dominique d'Humières @ 2017-05-19 18:14 UTC (permalink / raw) To: Bernd Edlinger; +Cc: gcc-patches > Le 19 mai 2017 à 19:26, Bernd Edlinger <bernd.edlinger@hotmail.de> a écrit : > > No, unfortunately it looks like incremental does not work in this case. > > You can try to remove gcc/s-gtyp-input, maybe it un-breaks your > build. However, I gave up at that point and did a full bootstrap > instead. > > Bernd. Quite bad!-( bootstrap takes 2+ hours, incremental update for gfortran ~10 minutes. Dominique ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Try harder to fix recently introduced crashes in ggc_collect 2017-05-19 18:14 ` Dominique d'Humières @ 2017-05-22 7:36 ` Richard Biener 0 siblings, 0 replies; 17+ messages in thread From: Richard Biener @ 2017-05-22 7:36 UTC (permalink / raw) To: Dominique d'Humières; +Cc: Bernd Edlinger, gcc-patches On Fri, May 19, 2017 at 7:41 PM, Dominique d'Humières <dominiq@lps.ens.fr> wrote: > >> Le 19 mai 2017 à 19:26, Bernd Edlinger <bernd.edlinger@hotmail.de> a écrit : >> >> No, unfortunately it looks like incremental does not work in this case. >> >> You can try to remove gcc/s-gtyp-input, maybe it un-breaks your >> build. However, I gave up at that point and did a full bootstrap >> instead. >> >> Bernd. > > > Quite bad!-( bootstrap takes 2+ hours, incremental update for gfortran ~10 minutes. in gcc/ do ./config.status --recheck > Dominique > > > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Try harder to fix recently introduced crashes in ggc_collect 2017-05-19 17:31 ` Bernd Edlinger 2017-05-19 18:14 ` Dominique d'Humières @ 2017-05-22 16:55 ` Martin Sebor 2017-05-22 18:32 ` Jason Merrill 1 sibling, 1 reply; 17+ messages in thread From: Martin Sebor @ 2017-05-22 16:55 UTC (permalink / raw) To: Bernd Edlinger, Dominique d'Humières; +Cc: gcc-patches On 05/19/2017 11:26 AM, Bernd Edlinger wrote: > On 05/19/17 19:05, Dominique d'Humières wrote: >> Hi Bernd, >> >> Your patches are causing troubles when I try to do "incremental updates »: >> >> After revision r248290 it fails with >> >> ../../work/gcc/cp/init.c:4916:10: fatal error: gt-cp-init.h: No such file or directory >> #include "gt-cp-init.h » >> >> and after r248242 with >> >> ../../work/gcc/c-family/c-format.c:4215:10: fatal error: gt-c-family-c-format.h: No such file or directory >> #include "gt-c-family-c-format.h » >> >> Note that after r248242 a full bootstrap succeeded (donât know yet for r248290). >> >> Is there a way to fix that? >> > > No, unfortunately it looks like incremental does not work in this case. > > You can try to remove gcc/s-gtyp-input, maybe it un-breaks your > build. However, I gave up at that point and did a full bootstrap > instead. I also keep running into this error. Removing my build directory and starting from scratch usually fixes it, but it seems that almost every time git pull or svn update brings in new changes it comes back. Martin ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Try harder to fix recently introduced crashes in ggc_collect 2017-05-22 16:55 ` Martin Sebor @ 2017-05-22 18:32 ` Jason Merrill 2017-05-22 20:43 ` Jason Merrill 0 siblings, 1 reply; 17+ messages in thread From: Jason Merrill @ 2017-05-22 18:32 UTC (permalink / raw) To: Martin Sebor; +Cc: Bernd Edlinger, Dominique d'Humières, gcc-patches On Mon, May 22, 2017 at 12:28 PM, Martin Sebor <msebor@gmail.com> wrote: > On 05/19/2017 11:26 AM, Bernd Edlinger wrote: >> >> On 05/19/17 19:05, Dominique d'Humières wrote: >>> >>> Hi Bernd, >>> >>> Your patches are causing troubles when I try to do "incremental updates >>> »: >>> >>> After revision r248290 it fails with >>> >>> ../../work/gcc/cp/init.c:4916:10: fatal error: gt-cp-init.h: No such file >>> or directory >>> #include "gt-cp-init.h » >>> >>> and after r248242 with >>> >>> ../../work/gcc/c-family/c-format.c:4215:10: fatal error: >>> gt-c-family-c-format.h: No such file or directory >>> #include "gt-c-family-c-format.h » >>> >>> Note that after r248242 a full bootstrap succeeded (don’t know yet for >>> r248290). >>> >>> Is there a way to fix that? >>> >> >> No, unfortunately it looks like incremental does not work in this case. >> >> You can try to remove gcc/s-gtyp-input, maybe it un-breaks your >> build. However, I gave up at that point and did a full bootstrap >> instead. > > I also keep running into this error. Removing my build directory > and starting from scratch usually fixes it, but it seems that almost > every time git pull or svn update brings in new changes it comes back. I've found that the key is ./config.status --recheck so that the GTFILES variable gets updated from config-lang.in. I'm not sure if plain ./config.status is also needed, and/or removing the gtype stuff from the build directory. Jason ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Try harder to fix recently introduced crashes in ggc_collect 2017-05-22 18:32 ` Jason Merrill @ 2017-05-22 20:43 ` Jason Merrill 0 siblings, 0 replies; 17+ messages in thread From: Jason Merrill @ 2017-05-22 20:43 UTC (permalink / raw) To: Martin Sebor; +Cc: Bernd Edlinger, Dominique d'Humières, gcc-patches On Mon, May 22, 2017 at 2:22 PM, Jason Merrill <jason@redhat.com> wrote: > On Mon, May 22, 2017 at 12:28 PM, Martin Sebor <msebor@gmail.com> wrote: >> On 05/19/2017 11:26 AM, Bernd Edlinger wrote: >>> >>> On 05/19/17 19:05, Dominique d'Humières wrote: >>>> >>>> Hi Bernd, >>>> >>>> Your patches are causing troubles when I try to do "incremental updates >>>> »: >>>> >>>> After revision r248290 it fails with >>>> >>>> ../../work/gcc/cp/init.c:4916:10: fatal error: gt-cp-init.h: No such file >>>> or directory >>>> #include "gt-cp-init.h » >>>> >>>> and after r248242 with >>>> >>>> ../../work/gcc/c-family/c-format.c:4215:10: fatal error: >>>> gt-c-family-c-format.h: No such file or directory >>>> #include "gt-c-family-c-format.h » >>>> >>>> Note that after r248242 a full bootstrap succeeded (don’t know yet for >>>> r248290). >>>> >>>> Is there a way to fix that? >>>> >>> >>> No, unfortunately it looks like incremental does not work in this case. >>> >>> You can try to remove gcc/s-gtyp-input, maybe it un-breaks your >>> build. However, I gave up at that point and did a full bootstrap >>> instead. >> >> I also keep running into this error. Removing my build directory >> and starting from scratch usually fixes it, but it seems that almost >> every time git pull or svn update brings in new changes it comes back. > > I've found that the key is ./config.status --recheck so that the > GTFILES variable gets updated from config-lang.in. I'm not sure if > plain ./config.status is also needed, and/or removing the gtype stuff > from the build directory. Nope, just ./config.status --recheck Jason ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH] Try to fix recently introduced crashes in ggc_collect @ 2017-05-18 15:22 Bernd Edlinger 2017-05-18 15:36 ` Richard Biener 0 siblings, 1 reply; 17+ messages in thread From: Bernd Edlinger @ 2017-05-18 15:22 UTC (permalink / raw) To: gcc-patches; +Cc: Jakub Jelinek, Richard Biener, Jeff Law [-- Attachment #1: Type: text/plain, Size: 2862 bytes --] Hi, this attempts to fix occasional segmentation faults that are present in the current snapshot, while previous snapshot was stable. I observed numerous crashes but all were non-reproducible, like the following example: In file included from /home/ed/gnu/gcc-build-1/x86_64-pc-linux-gnu/libstdc++-v3/include/string:52:0, from /home/ed/gnu/gcc-8-20170514-1/gcc/testsuite/g++.dg/asan/asan_test_config.h:19, from /home/ed/gnu/gcc-8-20170514-1/gcc/testsuite/g++.dg/asan/asan_test_utils.h:17, from /home/ed/gnu/gcc-8-20170514-1/gcc/testsuite/g++.dg/asan/asan_globals_test.cc:12, from /home/ed/gnu/gcc-8-20170514-1/gcc/testsuite/g++.dg/asan/asan_globals_test-wrapper.cc:2: /home/ed/gnu/gcc-build-1/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:6277:22: internal compiler error: Segmentation fault 0xd7e17f crash_signal ../../gcc-8-20170514-1/gcc/toplev.c:337 0x8f23fe ggc_set_mark(void const*) ../../gcc-8-20170514-1/gcc/ggc-page.c:1546 0x7e6a5f gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:133 0x7e8c7a gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:235 0x7e8882 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:365 0x81b26d gt_ggc_mx_cp_binding_level(void*) ./gt-cp-name-lookup.h:72 0x7e6d85 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:648 0x7e8ad2 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:221 0x7e8eeb gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:337 0x7e8a3c gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:441 0x7e7304 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:606 0x81b352 gt_ggc_mx_cxx_binding(void*) ./gt-cp-name-lookup.h:60 0x7e6d85 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:648 0x7e8ef5 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:336 0x7e8a3c gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:441 0xb2edbe void gt_ggc_mx<tree_node*>(vec<tree_node*, va_gc, vl_embed>*) ../../gcc-8-20170514-1/gcc/vec.h:1110 0xb2edbe gt_ggc_mx_vec_tree_va_gc_(void*) /home/ed/gnu/gcc-build-1/gcc/gtype-desc.c:1737 0xac59f5 ggc_mark_root_tab ../../gcc-8-20170514-1/gcc/ggc-common.c:77 0xac5c50 ggc_mark_roots() ../../gcc-8-20170514-1/gcc/ggc-common.c:94 0x8f2de7 ggc_collect() ../../gcc-8-20170514-1/gcc/ggc-page.c:2206 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. The following patch fixes one rather suspicious static tree object that did not have the GTY attribute, and was therefore apparently not in the GC root set. Bootstrapped and reg-tested on x86_64-pc-linux-gnu. Is it OK for trunk? Thanks Bernd. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: patch-ggc-crash.diff --] [-- Type: text/x-patch; name="patch-ggc-crash.diff", Size: 1714 bytes --] gcc/c-family: 2017-05-18 Bernd Edlinger <bernd.edlinger@hotmail.de> * c-format.c (local_tree_type_node): Add GTY attribute. gcc/c: 2017-05-18 Bernd Edlinger <bernd.edlinger@hotmail.de> * config-lang.in (gtfiles): Add c-family/c-format.c. --- gcc/c-family/c-format.c.jj 2017-05-09 04:47:14.000000000 +0200 +++ gcc/c-family/c-format.c 2017-05-18 13:57:15.235153933 +0200 @@ -54,7 +54,7 @@ }; /* Initialized in init_dynamic_diag_info. */ -static tree local_tree_type_node; +static GTY(()) tree local_tree_type_node; static bool decode_format_attr (tree, function_format_info *, int); static int decode_format_type (const char *); @@ -4211,3 +4211,5 @@ } // namespace selftest #endif /* CHECKING_P */ + +#include "gt-c-family-c-format.h" --- gcc/c/config-lang.in.jj 2017-01-01 13:07:43.000000000 +0100 +++ gcc/c/config-lang.in 2017-05-18 14:16:46.469924118 +0200 @@ -29,4 +29,4 @@ target_libs= -gtfiles="\$(srcdir)/c/c-lang.c \$(srcdir)/c/c-tree.h \$(srcdir)/c/c-decl.c \$(srcdir)/c-family/c-common.c \$(srcdir)/c-family/c-common.h \$(srcdir)/c-family/c-objc.h \$(srcdir)/c-family/c-cppbuiltin.c \$(srcdir)/c-family/c-pragma.h \$(srcdir)/c-family/c-pragma.c \$(srcdir)/c/c-objc-common.c \$(srcdir)/c/c-parser.h \$(srcdir)/c/c-parser.c \$(srcdir)/c/c-lang.h" +gtfiles="\$(srcdir)/c/c-lang.c \$(srcdir)/c/c-tree.h \$(srcdir)/c/c-decl.c \$(srcdir)/c-family/c-common.c \$(srcdir)/c-family/c-common.h \$(srcdir)/c-family/c-objc.h \$(srcdir)/c-family/c-cppbuiltin.c \$(srcdir)/c-family/c-pragma.h \$(srcdir)/c-family/c-pragma.c \$(srcdir)/c-family/c-format.c \$(srcdir)/c/c-objc-common.c \$(srcdir)/c/c-parser.h \$(srcdir)/c/c-parser.c \$(srcdir)/c/c-lang.h" ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Try to fix recently introduced crashes in ggc_collect 2017-05-18 15:22 [PATCH] Try " Bernd Edlinger @ 2017-05-18 15:36 ` Richard Biener 2017-05-18 20:51 ` [PATCH] Try harder " Bernd Edlinger 0 siblings, 1 reply; 17+ messages in thread From: Richard Biener @ 2017-05-18 15:36 UTC (permalink / raw) To: Bernd Edlinger, gcc-patches; +Cc: Jakub Jelinek, Jeff Law On May 18, 2017 5:15:43 PM GMT+02:00, Bernd Edlinger <bernd.edlinger@hotmail.de> wrote: >Hi, > > >this attempts to fix occasional segmentation faults that are present in >the current snapshot, while previous snapshot was stable. > >I observed numerous crashes but all were non-reproducible, >like the following example: > >In file included from >/home/ed/gnu/gcc-build-1/x86_64-pc-linux-gnu/libstdc++-v3/include/string:52:0, > from >/home/ed/gnu/gcc-8-20170514-1/gcc/testsuite/g++.dg/asan/asan_test_config.h:19, > from >/home/ed/gnu/gcc-8-20170514-1/gcc/testsuite/g++.dg/asan/asan_test_utils.h:17, > from >/home/ed/gnu/gcc-8-20170514-1/gcc/testsuite/g++.dg/asan/asan_globals_test.cc:12, > from >/home/ed/gnu/gcc-8-20170514-1/gcc/testsuite/g++.dg/asan/asan_globals_test-wrapper.cc:2: >/home/ed/gnu/gcc-build-1/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:6277:22: > >internal compiler error: Segmentation fault >0xd7e17f crash_signal > ../../gcc-8-20170514-1/gcc/toplev.c:337 >0x8f23fe ggc_set_mark(void const*) > ../../gcc-8-20170514-1/gcc/ggc-page.c:1546 >0x7e6a5f gt_ggc_mx_lang_tree_node(void*) > ./gt-cp-tree.h:133 >0x7e8c7a gt_ggc_mx_lang_tree_node(void*) > ./gt-cp-tree.h:235 >0x7e8882 gt_ggc_mx_lang_tree_node(void*) > ./gt-cp-tree.h:365 >0x81b26d gt_ggc_mx_cp_binding_level(void*) > ./gt-cp-name-lookup.h:72 >0x7e6d85 gt_ggc_mx_lang_tree_node(void*) > ./gt-cp-tree.h:648 >0x7e8ad2 gt_ggc_mx_lang_tree_node(void*) > ./gt-cp-tree.h:221 >0x7e8eeb gt_ggc_mx_lang_tree_node(void*) > ./gt-cp-tree.h:337 >0x7e8a3c gt_ggc_mx_lang_tree_node(void*) > ./gt-cp-tree.h:441 >0x7e7304 gt_ggc_mx_lang_tree_node(void*) > ./gt-cp-tree.h:606 >0x81b352 gt_ggc_mx_cxx_binding(void*) > ./gt-cp-name-lookup.h:60 >0x7e6d85 gt_ggc_mx_lang_tree_node(void*) > ./gt-cp-tree.h:648 >0x7e8ef5 gt_ggc_mx_lang_tree_node(void*) > ./gt-cp-tree.h:336 >0x7e8a3c gt_ggc_mx_lang_tree_node(void*) > ./gt-cp-tree.h:441 >0xb2edbe void gt_ggc_mx<tree_node*>(vec<tree_node*, va_gc, vl_embed>*) > ../../gcc-8-20170514-1/gcc/vec.h:1110 >0xb2edbe gt_ggc_mx_vec_tree_va_gc_(void*) > /home/ed/gnu/gcc-build-1/gcc/gtype-desc.c:1737 >0xac59f5 ggc_mark_root_tab > ../../gcc-8-20170514-1/gcc/ggc-common.c:77 >0xac5c50 ggc_mark_roots() > ../../gcc-8-20170514-1/gcc/ggc-common.c:94 >0x8f2de7 ggc_collect() > ../../gcc-8-20170514-1/gcc/ggc-page.c:2206 >Please submit a full bug report, >with preprocessed source if appropriate. >Please include the complete backtrace with any bug report. > > >The following patch fixes one rather suspicious static tree >object that did not have the GTY attribute, and was therefore >apparently not in the GC root set. > > >Bootstrapped and reg-tested on x86_64-pc-linux-gnu. >Is it OK for trunk? OK. Richard. > >Thanks >Bernd. ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH] Try harder to fix recently introduced crashes in ggc_collect 2017-05-18 15:36 ` Richard Biener @ 2017-05-18 20:51 ` Bernd Edlinger 2017-05-19 0:16 ` Nathan Sidwell 2017-05-19 7:58 ` Richard Biener 0 siblings, 2 replies; 17+ messages in thread From: Bernd Edlinger @ 2017-05-18 20:51 UTC (permalink / raw) To: Richard Biener, gcc-patches Cc: Jakub Jelinek, Jeff Law, Nathan Sidwell, Jason Merrill [-- Attachment #1: Type: text/plain, Size: 3606 bytes --] Hi, unfortunately the first patch was still insufficient. I identified many more relatively new places where static tree objects are invisible to GC. Nathan, whatever you are doing, please do it a bit more slowly, thanks. Bootstrap and reg-testing on x86_64-pc-linux-gnu in progress. Is it OK after successful reg-testing? Thanks Bernd. On 05/18/17 17:33, Richard Biener wrote: > On May 18, 2017 5:15:43 PM GMT+02:00, Bernd Edlinger <bernd.edlinger@hotmail.de> wrote: >> Hi, >> >> >> this attempts to fix occasional segmentation faults that are present in >> the current snapshot, while previous snapshot was stable. >> >> I observed numerous crashes but all were non-reproducible, >> like the following example: >> >> In file included from >> /home/ed/gnu/gcc-build-1/x86_64-pc-linux-gnu/libstdc++-v3/include/string:52:0, >> from >> /home/ed/gnu/gcc-8-20170514-1/gcc/testsuite/g++.dg/asan/asan_test_config.h:19, >> from >> /home/ed/gnu/gcc-8-20170514-1/gcc/testsuite/g++.dg/asan/asan_test_utils.h:17, >> from >> /home/ed/gnu/gcc-8-20170514-1/gcc/testsuite/g++.dg/asan/asan_globals_test.cc:12, >> from >> /home/ed/gnu/gcc-8-20170514-1/gcc/testsuite/g++.dg/asan/asan_globals_test-wrapper.cc:2: >> /home/ed/gnu/gcc-build-1/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:6277:22: >> >> internal compiler error: Segmentation fault >> 0xd7e17f crash_signal >> ../../gcc-8-20170514-1/gcc/toplev.c:337 >> 0x8f23fe ggc_set_mark(void const*) >> ../../gcc-8-20170514-1/gcc/ggc-page.c:1546 >> 0x7e6a5f gt_ggc_mx_lang_tree_node(void*) >> ./gt-cp-tree.h:133 >> 0x7e8c7a gt_ggc_mx_lang_tree_node(void*) >> ./gt-cp-tree.h:235 >> 0x7e8882 gt_ggc_mx_lang_tree_node(void*) >> ./gt-cp-tree.h:365 >> 0x81b26d gt_ggc_mx_cp_binding_level(void*) >> ./gt-cp-name-lookup.h:72 >> 0x7e6d85 gt_ggc_mx_lang_tree_node(void*) >> ./gt-cp-tree.h:648 >> 0x7e8ad2 gt_ggc_mx_lang_tree_node(void*) >> ./gt-cp-tree.h:221 >> 0x7e8eeb gt_ggc_mx_lang_tree_node(void*) >> ./gt-cp-tree.h:337 >> 0x7e8a3c gt_ggc_mx_lang_tree_node(void*) >> ./gt-cp-tree.h:441 >> 0x7e7304 gt_ggc_mx_lang_tree_node(void*) >> ./gt-cp-tree.h:606 >> 0x81b352 gt_ggc_mx_cxx_binding(void*) >> ./gt-cp-name-lookup.h:60 >> 0x7e6d85 gt_ggc_mx_lang_tree_node(void*) >> ./gt-cp-tree.h:648 >> 0x7e8ef5 gt_ggc_mx_lang_tree_node(void*) >> ./gt-cp-tree.h:336 >> 0x7e8a3c gt_ggc_mx_lang_tree_node(void*) >> ./gt-cp-tree.h:441 >> 0xb2edbe void gt_ggc_mx<tree_node*>(vec<tree_node*, va_gc, vl_embed>*) >> ../../gcc-8-20170514-1/gcc/vec.h:1110 >> 0xb2edbe gt_ggc_mx_vec_tree_va_gc_(void*) >> /home/ed/gnu/gcc-build-1/gcc/gtype-desc.c:1737 >> 0xac59f5 ggc_mark_root_tab >> ../../gcc-8-20170514-1/gcc/ggc-common.c:77 >> 0xac5c50 ggc_mark_roots() >> ../../gcc-8-20170514-1/gcc/ggc-common.c:94 >> 0x8f2de7 ggc_collect() >> ../../gcc-8-20170514-1/gcc/ggc-page.c:2206 >> Please submit a full bug report, >> with preprocessed source if appropriate. >> Please include the complete backtrace with any bug report. >> >> >> The following patch fixes one rather suspicious static tree >> object that did not have the GTY attribute, and was therefore >> apparently not in the GC root set. >> >> >> Bootstrapped and reg-tested on x86_64-pc-linux-gnu. >> Is it OK for trunk? > > OK. > > Richard. > >> >> Thanks >> Bernd. > [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: patch-ggc-crash-2.diff --] [-- Type: text/x-patch; name="patch-ggc-crash-2.diff", Size: 14940 bytes --] gcc/c-family: 2017-05-18 Bernd Edlinger <bernd.edlinger@hotmail.de> * c-format.c (hwi, locus): Move out of function scope, add GTY attribute. gcc/cp: 2017-05-18 Bernd Edlinger <bernd.edlinger@hotmail.de> * config-lang.in (gtfiles): Add c-family/c-format.c, except.c, init.c, lambda.c and friend.c. * class.c (dvirt_fn): Move out of function scope, add GTY attribute. * except.c (fn1-5, throw_fn, rethrow_fn, spec): Likewise. * init.c (fn): Likewise. * lambda.c (ptr_id, max_id): Likewise. * friend.c (global_friend): Add GTY attribute. Index: gcc/c-family/c-format.c =================================================================== --- gcc/c-family/c-format.c (revision 248242) +++ gcc/c-family/c-format.c (working copy) @@ -55,6 +55,8 @@ struct function_format_info /* Initialized in init_dynamic_diag_info. */ static GTY(()) tree local_tree_type_node; +static GTY(()) tree hwi; +static GTY(()) tree locus; static bool decode_format_attr (tree, function_format_info *, int); static int decode_format_type (const char *); @@ -3675,8 +3677,6 @@ find_length_info_modifier_index (const format_leng static void init_dynamic_asm_fprintf_info (void) { - static tree hwi; - if (!hwi) { format_length_info *new_asm_fprintf_length_specs; @@ -3734,8 +3734,6 @@ init_dynamic_asm_fprintf_info (void) static void init_dynamic_gfc_info (void) { - static tree locus; - if (!locus) { static format_char_info *gfc_fci; @@ -3828,8 +3826,6 @@ init_dynamic_diag_info (void) local_tree_type_node = void_type_node; } - static tree hwi; - if (!hwi) { static format_length_info *diag_ls; Index: gcc/cp/class.c =================================================================== --- gcc/cp/class.c (revision 248242) +++ gcc/cp/class.c (working copy) @@ -9541,6 +9541,7 @@ dfs_accumulate_vtbl_inits (tree binfo, } static GTY(()) tree abort_fndecl_addr; +static GTY(()) tree dvirt_fn; /* Construct the initializer for BINFO's virtual function table. BINFO is part of the hierarchy dominated by T. If we're building a @@ -9714,8 +9715,6 @@ build_vtbl_initializer (tree binfo, /* Likewise for deleted virtuals. */ else if (DECL_DELETED_FN (fn_original)) { - static tree dvirt_fn; - if (!dvirt_fn) { tree name = get_identifier ("__cxa_deleted_virtual"); Index: gcc/cp/config-lang.in =================================================================== --- gcc/cp/config-lang.in (revision 248242) +++ gcc/cp/config-lang.in (working copy) @@ -29,4 +29,4 @@ compilers="cc1plus\$(exeext)" target_libs="target-libstdc++-v3" -gtfiles="\$(srcdir)/cp/rtti.c \$(srcdir)/cp/mangle.c \$(srcdir)/cp/name-lookup.h \$(srcdir)/cp/name-lookup.c \$(srcdir)/cp/cp-tree.h \$(srcdir)/cp/decl.h \$(srcdir)/cp/call.c \$(srcdir)/cp/decl.c \$(srcdir)/cp/decl2.c \$(srcdir)/cp/pt.c \$(srcdir)/cp/repo.c \$(srcdir)/cp/semantics.c \$(srcdir)/cp/tree.c \$(srcdir)/cp/parser.h \$(srcdir)/cp/parser.c \$(srcdir)/cp/method.c \$(srcdir)/cp/typeck2.c \$(srcdir)/c-family/c-common.c \$(srcdir)/c-family/c-common.h \$(srcdir)/c-family/c-objc.h \$(srcdir)/c-family/c-lex.c \$(srcdir)/c-family/c-pragma.h \$(srcdir)/c-family/c-pragma.c \$(srcdir)/cp/class.c \$(srcdir)/cp/cp-objcp-common.c \$(srcdir)/cp/cp-lang.c \$(srcdir)/cp/except.c \$(srcdir)/cp/vtable-class-hierarchy.c \$(srcdir)/cp/constexpr.c \$(srcdir)/cp/cp-gimplify.c" +gtfiles="\$(srcdir)/cp/rtti.c \$(srcdir)/cp/mangle.c \$(srcdir)/cp/name-lookup.h \$(srcdir)/cp/name-lookup.c \$(srcdir)/cp/cp-tree.h \$(srcdir)/cp/decl.h \$(srcdir)/cp/call.c \$(srcdir)/cp/decl.c \$(srcdir)/cp/decl2.c \$(srcdir)/cp/pt.c \$(srcdir)/cp/repo.c \$(srcdir)/cp/semantics.c \$(srcdir)/cp/tree.c \$(srcdir)/cp/parser.h \$(srcdir)/cp/parser.c \$(srcdir)/cp/method.c \$(srcdir)/cp/typeck2.c \$(srcdir)/c-family/c-common.c \$(srcdir)/c-family/c-common.h \$(srcdir)/c-family/c-objc.h \$(srcdir)/c-family/c-lex.c \$(srcdir)/c-family/c-pragma.h \$(srcdir)/c-family/c-pragma.c \$(srcdir)/c-family/c-format.c \$(srcdir)/cp/class.c \$(srcdir)/cp/cp-objcp-common.c \$(srcdir)/cp/cp-lang.c \$(srcdir)/cp/except.c \$(srcdir)/cp/vtable-class-hierarchy.c \$(srcdir)/cp/constexpr.c \$(srcdir)/cp/cp-gimplify.c \$(srcdir)/cp/init.c \$(srcdir)/cp/friend.c \$(srcdir)/cp/lambda.c" Index: gcc/cp/except.c =================================================================== --- gcc/cp/except.c (revision 248242) +++ gcc/cp/except.c (working copy) @@ -42,6 +42,15 @@ static int complete_ptr_ref_or_void_ptr_p (tree, t static bool is_admissible_throw_operand_or_catch_parameter (tree, bool); static int can_convert_eh (tree, tree); +static GTY(()) tree fn1; +static GTY(()) tree fn2; +static GTY(()) tree fn3; +static GTY(()) tree fn4; +static GTY(()) tree fn5; +static GTY(()) tree throw_fn; +static GTY(()) tree rethrow_fn; +static GTY(()) tree spec; + /* Sets up all the global eh stuff that needs to be initialized at the start of compilation. */ @@ -154,20 +163,18 @@ declare_library_fn (tree name, tree return_type, t static tree do_get_exception_ptr (void) { - static tree fn; - - if (!fn) + if (!fn1) { tree name = get_identifier ("__cxa_get_exception_ptr"); - fn = IDENTIFIER_GLOBAL_VALUE (name); - if (!fn) + fn1 = IDENTIFIER_GLOBAL_VALUE (name); + if (!fn1) /* Declare void* __cxa_get_exception_ptr (void *) throw(). */ - fn = declare_library_fn + fn1 = declare_library_fn (name, ptr_type_node, ptr_type_node, ECF_NOTHROW | ECF_PURE | ECF_LEAF | ECF_TM_PURE); } - return cp_build_function_call_nary (fn, tf_warning_or_error, + return cp_build_function_call_nary (fn1, tf_warning_or_error, build_exc_ptr (), NULL_TREE); } @@ -177,16 +184,14 @@ do_get_exception_ptr (void) static tree do_begin_catch (void) { - static tree fn; - - if (!fn) + if (!fn2) { - tree name = fn = get_identifier ("__cxa_begin_catch"); - fn = IDENTIFIER_GLOBAL_VALUE (name); - if (!fn) + tree name = get_identifier ("__cxa_begin_catch"); + fn2 = IDENTIFIER_GLOBAL_VALUE (name); + if (!fn2) { /* Declare void* __cxa_begin_catch (void *) throw(). */ - fn = declare_library_fn + fn2 = declare_library_fn (name, ptr_type_node, ptr_type_node, ECF_NOTHROW); /* Create its transactional-memory equivalent. */ @@ -198,12 +203,12 @@ do_begin_catch (void) itm_fn = declare_library_fn (itm_name, ptr_type_node, ptr_type_node, ECF_NOTHROW | ECF_TM_PURE); - record_tm_replacement (fn, itm_fn); + record_tm_replacement (fn2, itm_fn); } } } - return cp_build_function_call_nary (fn, tf_warning_or_error, + return cp_build_function_call_nary (fn2, tf_warning_or_error, build_exc_ptr (), NULL_TREE); } @@ -231,17 +236,15 @@ dtor_nothrow (tree type) static tree do_end_catch (tree type) { - static tree fn; - - if (!fn) + if (!fn3) { tree name = get_identifier ("__cxa_end_catch"); - fn = IDENTIFIER_GLOBAL_VALUE (name); - if (!fn) + fn3 = IDENTIFIER_GLOBAL_VALUE (name); + if (!fn3) { /* Declare void __cxa_end_catch (). This can throw if the destructor for the exception throws. */ - fn = push_void_library_fn (name, void_list_node, 0); + fn3 = push_void_library_fn (name, void_list_node, 0); /* Create its transactional-memory equivalent. */ if (flag_tm) @@ -251,12 +254,12 @@ do_end_catch (tree type) if (!itm_fn) itm_fn = push_void_library_fn (itm_name, void_list_node, ECF_TM_PURE); - record_tm_replacement (fn, itm_fn); + record_tm_replacement (fn3, itm_fn); } } } - tree cleanup = cp_build_function_call_vec (fn, NULL, tf_warning_or_error); + tree cleanup = cp_build_function_call_vec (fn3, NULL, tf_warning_or_error); TREE_NOTHROW (cleanup) = dtor_nothrow (type); return cleanup; @@ -516,17 +519,15 @@ finish_eh_spec_block (tree raw_raises, tree eh_spe static tree do_allocate_exception (tree type) { - static tree fn; - - if (!fn) + if (!fn4) { tree name = get_identifier ("__cxa_allocate_exception"); - fn = IDENTIFIER_GLOBAL_VALUE (name); - if (!fn) + fn4 = IDENTIFIER_GLOBAL_VALUE (name); + if (!fn4) { /* Declare void *__cxa_allocate_exception(size_t) throw(). */ - fn = declare_library_fn (name, ptr_type_node, size_type_node, - ECF_NOTHROW | ECF_MALLOC); + fn4 = declare_library_fn (name, ptr_type_node, size_type_node, + ECF_NOTHROW | ECF_MALLOC); if (flag_tm) { @@ -536,12 +537,12 @@ do_allocate_exception (tree type) itm_fn = declare_library_fn (itm_name, ptr_type_node, size_type_node, ECF_NOTHROW | ECF_MALLOC | ECF_TM_PURE); - record_tm_replacement (fn, itm_fn); + record_tm_replacement (fn4, itm_fn); } } } - return cp_build_function_call_nary (fn, tf_warning_or_error, + return cp_build_function_call_nary (fn4, tf_warning_or_error, size_in_bytes (type), NULL_TREE); } @@ -551,17 +552,15 @@ do_allocate_exception (tree type) static tree do_free_exception (tree ptr) { - static tree fn; - - if (!fn) + if (!fn5) { tree name = get_identifier ("__cxa_free_exception"); - fn = IDENTIFIER_GLOBAL_VALUE (name); - if (!fn) + fn5 = IDENTIFIER_GLOBAL_VALUE (name); + if (!fn5) { /* Declare void __cxa_free_exception (void *) throw(). */ - fn = declare_library_fn (name, void_type_node, ptr_type_node, - ECF_NOTHROW | ECF_LEAF); + fn5 = declare_library_fn (name, void_type_node, ptr_type_node, + ECF_NOTHROW | ECF_LEAF); if (flag_tm) { @@ -571,12 +570,12 @@ do_free_exception (tree ptr) itm_fn = declare_library_fn (itm_name, void_type_node, ptr_type_node, ECF_NOTHROW | ECF_LEAF | ECF_TM_PURE); - record_tm_replacement (fn, itm_fn); + record_tm_replacement (fn5, itm_fn); } } } - return cp_build_function_call_nary (fn, tf_warning_or_error, ptr, NULL_TREE); + return cp_build_function_call_nary (fn5, tf_warning_or_error, ptr, NULL_TREE); } /* Wrap all cleanups for TARGET_EXPRs in MUST_NOT_THROW_EXPR. @@ -640,7 +639,6 @@ build_throw (tree exp) if (exp) { - static tree throw_fn; tree throw_type; tree temp_type; tree cleanup; @@ -793,8 +791,6 @@ build_throw (tree exp) else { /* Rethrow current exception. */ - static tree rethrow_fn; - if (!rethrow_fn) { tree name = get_identifier ("__cxa_rethrow"); @@ -1261,7 +1257,6 @@ build_noexcept_spec (tree expr, int complain) tree unevaluated_noexcept_spec (void) { - static tree spec; if (spec == NULL_TREE) spec = build_noexcept_spec (make_node (DEFERRED_NOEXCEPT), tf_none); return spec; Index: gcc/cp/friend.c =================================================================== --- gcc/cp/friend.c (revision 248242) +++ gcc/cp/friend.c (working copy) @@ -32,7 +32,7 @@ along with GCC; see the file COPYING3. If not see template overload resolution results when accessibility matters (e.g. tests for an accessible member). */ -static tree global_friend; +static GTY(()) tree global_friend; /* Set the GLOBAL_FRIEND for this compilation session. It might be set multiple times, but always to the same scope. */ @@ -668,3 +668,5 @@ do_friend (tree ctype, tree declarator, tree decl, return decl; } + +#include "gt-cp-friend.h" Index: gcc/cp/init.c =================================================================== --- gcc/cp/init.c (revision 248242) +++ gcc/cp/init.c (working copy) @@ -46,6 +46,8 @@ static tree dfs_initialize_vtbl_ptrs (tree, void * static tree build_field_list (tree, tree, int *); static int diagnose_uninitialized_cst_or_ref_member_1 (tree, tree, bool, bool); +static GTY(()) tree fn; + /* We are about to generate some complex initialization code. Conceptually, it is all a single expression. However, we may want to include conditionals, loops, and other such statement-level @@ -2402,7 +2404,6 @@ diagnose_uninitialized_cst_or_ref_member (tree typ tree throw_bad_array_new_length (void) { - static tree fn; if (!fn) { tree name = get_identifier ("__cxa_throw_bad_array_new_length"); @@ -4911,3 +4912,5 @@ build_vec_delete (tree base, tree maxindex, return rval; } + +#include "gt-cp-init.h" Index: gcc/cp/lambda.c =================================================================== --- gcc/cp/lambda.c (revision 248242) +++ gcc/cp/lambda.c (working copy) @@ -427,6 +427,9 @@ build_capture_proxy (tree member) return var; } +static GTY(()) tree ptr_id; +static GTY(()) tree max_id; + /* Return a struct containing a pointer and a length for lambda capture of an array of runtime length. */ @@ -433,7 +436,6 @@ build_capture_proxy (tree member) static tree vla_capture_type (tree array_type) { - static tree ptr_id, max_id; tree type = xref_tag (record_type, make_anon_name (), ts_current, false); xref_basetypes (type, NULL_TREE); type = begin_class_definition (type); @@ -1248,3 +1250,5 @@ is_lambda_ignored_entity (tree val) return false; } + +#include "gt-cp-lambda.h" Index: gcc/cp/typeck.c =================================================================== --- gcc/cp/typeck.c (revision 248242) +++ gcc/cp/typeck.c (working copy) @@ -4366,6 +4366,29 @@ cp_build_binary_op (location_t location, case FLOOR_DIV_EXPR: case ROUND_DIV_EXPR: case EXACT_DIV_EXPR: + if (TREE_CODE (op0) == SIZEOF_EXPR && TREE_CODE (op1) == SIZEOF_EXPR) + { + tree type0 = TREE_OPERAND (op0, 0); + tree type1 = TREE_OPERAND (op1, 0); + tree first_arg = type0; + if (!TYPE_P (type0)) + type0 = TREE_TYPE (type0); + if (!TYPE_P (type1)) + type1 = TREE_TYPE (type1); + if (POINTER_TYPE_P (type0) && same_type_p (TREE_TYPE (type0), type1) + && !(TREE_CODE (first_arg) == PARM_DECL + && DECL_ARRAY_PARAMETER_P (first_arg) + && warn_sizeof_array_argument) + && (complain & tf_warning)) + if (warning_at (location, OPT_Wsizeof_pointer_div, + "division %<sizeof (%T) / sizeof (%T)%> does " + "not compute the number of array elements", + type0, type1)) + if (DECL_P (first_arg)) + inform (DECL_SOURCE_LOCATION (first_arg), + "first %<sizeof%> operand was declared here"); + } + if ((code0 == INTEGER_TYPE || code0 == REAL_TYPE || code0 == COMPLEX_TYPE || code0 == VECTOR_TYPE) && (code1 == INTEGER_TYPE || code1 == REAL_TYPE ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Try harder to fix recently introduced crashes in ggc_collect 2017-05-18 20:51 ` [PATCH] Try harder " Bernd Edlinger @ 2017-05-19 0:16 ` Nathan Sidwell 2017-05-19 7:58 ` Richard Biener 1 sibling, 0 replies; 17+ messages in thread From: Nathan Sidwell @ 2017-05-19 0:16 UTC (permalink / raw) To: Bernd Edlinger, Richard Biener, gcc-patches Cc: Jakub Jelinek, Jeff Law, Jason Merrill On 05/18/2017 04:40 PM, Bernd Edlinger wrote: > Hi, > > unfortunately the first patch was still insufficient. I identified many > more relatively new places where static tree objects are invisible to > GC. > Hm, I didn't think the fns in except.c etc needed to be GTY'd because they'd still be reachable via the symbol table. Oh, is it PCH dying? Sorry about that. The C++ changes are ok (I'll probably go an turn the separate fns as an array as penance.) nathan -- Nathan Sidwell ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Try harder to fix recently introduced crashes in ggc_collect 2017-05-18 20:51 ` [PATCH] Try harder " Bernd Edlinger 2017-05-19 0:16 ` Nathan Sidwell @ 2017-05-19 7:58 ` Richard Biener 2017-05-19 11:06 ` Nathan Sidwell 2017-05-19 14:10 ` Bernd Edlinger 1 sibling, 2 replies; 17+ messages in thread From: Richard Biener @ 2017-05-19 7:58 UTC (permalink / raw) To: Bernd Edlinger Cc: gcc-patches, Jakub Jelinek, Jeff Law, Nathan Sidwell, Jason Merrill On Thu, 18 May 2017, Bernd Edlinger wrote: > Hi, > > unfortunately the first patch was still insufficient. I identified many > more relatively new places where static tree objects are invisible to > GC. > > Nathan, whatever you are doing, please do it a bit more slowly, thanks. > > Bootstrap and reg-testing on x86_64-pc-linux-gnu in progress. > Is it OK after successful reg-testing? Index: gcc/c-family/c-format.c =================================================================== --- gcc/c-family/c-format.c (revision 248242) +++ gcc/c-family/c-format.c (working copy) @@ -55,6 +55,8 @@ struct function_format_info /* Initialized in init_dynamic_diag_info. */ static GTY(()) tree local_tree_type_node; +static GTY(()) tree hwi; +static GTY(()) tree locus; static bool decode_format_attr (tree, function_format_info *, int); static int decode_format_type (const char *); @@ -3675,8 +3677,6 @@ find_length_info_modifier_index (const format_leng static void init_dynamic_asm_fprintf_info (void) { - static tree hwi; - if (!hwi) { format_length_info *new_asm_fprintf_length_specs; @@ -3734,8 +3734,6 @@ init_dynamic_asm_fprintf_info (void) static void init_dynamic_gfc_info (void) { - static tree locus; - if (!locus) { static format_char_info *gfc_fci; @@ -3828,8 +3826,6 @@ init_dynamic_diag_info (void) local_tree_type_node = void_type_node; } - static tree hwi; - you are commoning 'hwi' here. Also a bad (very short) name for a global (even if static). I'll leave review to Nathan anyway. Richard. > > Thanks > Bernd. > > > On 05/18/17 17:33, Richard Biener wrote: > > On May 18, 2017 5:15:43 PM GMT+02:00, Bernd Edlinger <bernd.edlinger@hotmail.de> wrote: > >> Hi, > >> > >> > >> this attempts to fix occasional segmentation faults that are present in > >> the current snapshot, while previous snapshot was stable. > >> > >> I observed numerous crashes but all were non-reproducible, > >> like the following example: > >> > >> In file included from > >> /home/ed/gnu/gcc-build-1/x86_64-pc-linux-gnu/libstdc++-v3/include/string:52:0, > >> from > >> /home/ed/gnu/gcc-8-20170514-1/gcc/testsuite/g++.dg/asan/asan_test_config.h:19, > >> from > >> /home/ed/gnu/gcc-8-20170514-1/gcc/testsuite/g++.dg/asan/asan_test_utils.h:17, > >> from > >> /home/ed/gnu/gcc-8-20170514-1/gcc/testsuite/g++.dg/asan/asan_globals_test.cc:12, > >> from > >> /home/ed/gnu/gcc-8-20170514-1/gcc/testsuite/g++.dg/asan/asan_globals_test-wrapper.cc:2: > >> /home/ed/gnu/gcc-build-1/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:6277:22: > >> > >> internal compiler error: Segmentation fault > >> 0xd7e17f crash_signal > >> ../../gcc-8-20170514-1/gcc/toplev.c:337 > >> 0x8f23fe ggc_set_mark(void const*) > >> ../../gcc-8-20170514-1/gcc/ggc-page.c:1546 > >> 0x7e6a5f gt_ggc_mx_lang_tree_node(void*) > >> ./gt-cp-tree.h:133 > >> 0x7e8c7a gt_ggc_mx_lang_tree_node(void*) > >> ./gt-cp-tree.h:235 > >> 0x7e8882 gt_ggc_mx_lang_tree_node(void*) > >> ./gt-cp-tree.h:365 > >> 0x81b26d gt_ggc_mx_cp_binding_level(void*) > >> ./gt-cp-name-lookup.h:72 > >> 0x7e6d85 gt_ggc_mx_lang_tree_node(void*) > >> ./gt-cp-tree.h:648 > >> 0x7e8ad2 gt_ggc_mx_lang_tree_node(void*) > >> ./gt-cp-tree.h:221 > >> 0x7e8eeb gt_ggc_mx_lang_tree_node(void*) > >> ./gt-cp-tree.h:337 > >> 0x7e8a3c gt_ggc_mx_lang_tree_node(void*) > >> ./gt-cp-tree.h:441 > >> 0x7e7304 gt_ggc_mx_lang_tree_node(void*) > >> ./gt-cp-tree.h:606 > >> 0x81b352 gt_ggc_mx_cxx_binding(void*) > >> ./gt-cp-name-lookup.h:60 > >> 0x7e6d85 gt_ggc_mx_lang_tree_node(void*) > >> ./gt-cp-tree.h:648 > >> 0x7e8ef5 gt_ggc_mx_lang_tree_node(void*) > >> ./gt-cp-tree.h:336 > >> 0x7e8a3c gt_ggc_mx_lang_tree_node(void*) > >> ./gt-cp-tree.h:441 > >> 0xb2edbe void gt_ggc_mx<tree_node*>(vec<tree_node*, va_gc, vl_embed>*) > >> ../../gcc-8-20170514-1/gcc/vec.h:1110 > >> 0xb2edbe gt_ggc_mx_vec_tree_va_gc_(void*) > >> /home/ed/gnu/gcc-build-1/gcc/gtype-desc.c:1737 > >> 0xac59f5 ggc_mark_root_tab > >> ../../gcc-8-20170514-1/gcc/ggc-common.c:77 > >> 0xac5c50 ggc_mark_roots() > >> ../../gcc-8-20170514-1/gcc/ggc-common.c:94 > >> 0x8f2de7 ggc_collect() > >> ../../gcc-8-20170514-1/gcc/ggc-page.c:2206 > >> Please submit a full bug report, > >> with preprocessed source if appropriate. > >> Please include the complete backtrace with any bug report. > >> > >> > >> The following patch fixes one rather suspicious static tree > >> object that did not have the GTY attribute, and was therefore > >> apparently not in the GC root set. > >> > >> > >> Bootstrapped and reg-tested on x86_64-pc-linux-gnu. > >> Is it OK for trunk? > > > > OK. > > > > Richard. > > > >> > >> Thanks > >> Bernd. > > > -- Richard Biener <rguenther@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Try harder to fix recently introduced crashes in ggc_collect 2017-05-19 7:58 ` Richard Biener @ 2017-05-19 11:06 ` Nathan Sidwell 2017-05-19 14:10 ` Bernd Edlinger 1 sibling, 0 replies; 17+ messages in thread From: Nathan Sidwell @ 2017-05-19 11:06 UTC (permalink / raw) To: Richard Biener, Bernd Edlinger Cc: gcc-patches, Jakub Jelinek, Jeff Law, Jason Merrill On 05/19/2017 03:51 AM, Richard Biener wrote: > you are commoning 'hwi' here. Also a bad (very short) name for a global > (even if static). > > I'll leave review to Nathan anyway. IMHO the C FE changes are obvious, with the fixing of the hwi name I guess. I'll go rename fn1..6 in the C++ FE once this lands. nathan -- Nathan Sidwell ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Try harder to fix recently introduced crashes in ggc_collect 2017-05-19 7:58 ` Richard Biener 2017-05-19 11:06 ` Nathan Sidwell @ 2017-05-19 14:10 ` Bernd Edlinger 2017-05-19 14:15 ` Nathan Sidwell 1 sibling, 1 reply; 17+ messages in thread From: Bernd Edlinger @ 2017-05-19 14:10 UTC (permalink / raw) To: Richard Biener Cc: gcc-patches, Jakub Jelinek, Jeff Law, Nathan Sidwell, Jason Merrill On 05/19/17 09:51, Richard Biener wrote: > On Thu, 18 May 2017, Bernd Edlinger wrote: > >> Hi, >> >> unfortunately the first patch was still insufficient. I identified many >> more relatively new places where static tree objects are invisible to >> GC. >> >> Nathan, whatever you are doing, please do it a bit more slowly, thanks. >> >> Bootstrap and reg-testing on x86_64-pc-linux-gnu in progress. >> Is it OK after successful reg-testing? > > Index: gcc/c-family/c-format.c > =================================================================== > --- gcc/c-family/c-format.c (revision 248242) > +++ gcc/c-family/c-format.c (working copy) > @@ -55,6 +55,8 @@ struct function_format_info > > /* Initialized in init_dynamic_diag_info. */ > static GTY(()) tree local_tree_type_node; > +static GTY(()) tree hwi; > +static GTY(()) tree locus; > > static bool decode_format_attr (tree, function_format_info *, int); > static int decode_format_type (const char *); > @@ -3675,8 +3677,6 @@ find_length_info_modifier_index (const format_leng > static void > init_dynamic_asm_fprintf_info (void) > { > - static tree hwi; > - > if (!hwi) > { > format_length_info *new_asm_fprintf_length_specs; > @@ -3734,8 +3734,6 @@ init_dynamic_asm_fprintf_info (void) > static void > init_dynamic_gfc_info (void) > { > - static tree locus; > - > if (!locus) > { > static format_char_info *gfc_fci; > @@ -3828,8 +3826,6 @@ init_dynamic_diag_info (void) > local_tree_type_node = void_type_node; > } > > - static tree hwi; > - > > you are commoning 'hwi' here. Also a bad (very short) name for a global > (even if static). > > I'll leave review to Nathan anyway. > > Richard. > Hmm, yes, I'll drop the 'hwi' change, thus only move 'locus' because: hwi cannot be the root cause of the problem, because it can only be long_integer_type_node or long_long_integer_type_node, otherwise an error would be triggered. >> >> Thanks >> Bernd. >> >> >> On 05/18/17 17:33, Richard Biener wrote: >>> On May 18, 2017 5:15:43 PM GMT+02:00, Bernd Edlinger <bernd.edlinger@hotmail.de> wrote: >>>> Hi, >>>> >>>> >>>> this attempts to fix occasional segmentation faults that are present in >>>> the current snapshot, while previous snapshot was stable. >>>> >>>> I observed numerous crashes but all were non-reproducible, >>>> like the following example: >>>> >>>> In file included from >>>> /home/ed/gnu/gcc-build-1/x86_64-pc-linux-gnu/libstdc++-v3/include/string:52:0, >>>> from >>>> /home/ed/gnu/gcc-8-20170514-1/gcc/testsuite/g++.dg/asan/asan_test_config.h:19, >>>> from >>>> /home/ed/gnu/gcc-8-20170514-1/gcc/testsuite/g++.dg/asan/asan_test_utils.h:17, >>>> from >>>> /home/ed/gnu/gcc-8-20170514-1/gcc/testsuite/g++.dg/asan/asan_globals_test.cc:12, >>>> from >>>> /home/ed/gnu/gcc-8-20170514-1/gcc/testsuite/g++.dg/asan/asan_globals_test-wrapper.cc:2: >>>> /home/ed/gnu/gcc-build-1/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:6277:22: >>>> >>>> internal compiler error: Segmentation fault >>>> 0xd7e17f crash_signal >>>> ../../gcc-8-20170514-1/gcc/toplev.c:337 >>>> 0x8f23fe ggc_set_mark(void const*) >>>> ../../gcc-8-20170514-1/gcc/ggc-page.c:1546 >>>> 0x7e6a5f gt_ggc_mx_lang_tree_node(void*) >>>> ./gt-cp-tree.h:133 >>>> 0x7e8c7a gt_ggc_mx_lang_tree_node(void*) >>>> ./gt-cp-tree.h:235 >>>> 0x7e8882 gt_ggc_mx_lang_tree_node(void*) >>>> ./gt-cp-tree.h:365 >>>> 0x81b26d gt_ggc_mx_cp_binding_level(void*) >>>> ./gt-cp-name-lookup.h:72 >>>> 0x7e6d85 gt_ggc_mx_lang_tree_node(void*) >>>> ./gt-cp-tree.h:648 >>>> 0x7e8ad2 gt_ggc_mx_lang_tree_node(void*) >>>> ./gt-cp-tree.h:221 >>>> 0x7e8eeb gt_ggc_mx_lang_tree_node(void*) >>>> ./gt-cp-tree.h:337 >>>> 0x7e8a3c gt_ggc_mx_lang_tree_node(void*) >>>> ./gt-cp-tree.h:441 >>>> 0x7e7304 gt_ggc_mx_lang_tree_node(void*) >>>> ./gt-cp-tree.h:606 >>>> 0x81b352 gt_ggc_mx_cxx_binding(void*) >>>> ./gt-cp-name-lookup.h:60 >>>> 0x7e6d85 gt_ggc_mx_lang_tree_node(void*) >>>> ./gt-cp-tree.h:648 >>>> 0x7e8ef5 gt_ggc_mx_lang_tree_node(void*) >>>> ./gt-cp-tree.h:336 >>>> 0x7e8a3c gt_ggc_mx_lang_tree_node(void*) >>>> ./gt-cp-tree.h:441 >>>> 0xb2edbe void gt_ggc_mx<tree_node*>(vec<tree_node*, va_gc, vl_embed>*) >>>> ../../gcc-8-20170514-1/gcc/vec.h:1110 >>>> 0xb2edbe gt_ggc_mx_vec_tree_va_gc_(void*) >>>> /home/ed/gnu/gcc-build-1/gcc/gtype-desc.c:1737 >>>> 0xac59f5 ggc_mark_root_tab >>>> ../../gcc-8-20170514-1/gcc/ggc-common.c:77 >>>> 0xac5c50 ggc_mark_roots() >>>> ../../gcc-8-20170514-1/gcc/ggc-common.c:94 >>>> 0x8f2de7 ggc_collect() >>>> ../../gcc-8-20170514-1/gcc/ggc-page.c:2206 >>>> Please submit a full bug report, >>>> with preprocessed source if appropriate. >>>> Please include the complete backtrace with any bug report. >>>> >>>> >>>> The following patch fixes one rather suspicious static tree >>>> object that did not have the GTY attribute, and was therefore >>>> apparently not in the GC root set. >>>> >>>> >>>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu. >>>> Is it OK for trunk? >>> >>> OK. >>> >>> Richard. >>> >>>> >>>> Thanks >>>> Bernd. >>> >> > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Try harder to fix recently introduced crashes in ggc_collect 2017-05-19 14:10 ` Bernd Edlinger @ 2017-05-19 14:15 ` Nathan Sidwell 2017-05-19 14:34 ` Bernd Edlinger 2017-05-24 11:21 ` Trevor Saunders 0 siblings, 2 replies; 17+ messages in thread From: Nathan Sidwell @ 2017-05-19 14:15 UTC (permalink / raw) To: Bernd Edlinger, Richard Biener Cc: gcc-patches, Jakub Jelinek, Jeff Law, Jason Merrill On 05/19/2017 10:05 AM, Bernd Edlinger wrote: > hwi cannot be the root cause of the problem, > because it can only be long_integer_type_node > or long_long_integer_type_node, otherwise > an error would be triggered. that's the error I made with the static fns. PCH moves things around, so anything that can be streamed via PCH must be GTY marked. Also, I'm not sure if the current GC is a compacting GC (given PCH can compact things?) nathan -- Nathan Sidwell ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Try harder to fix recently introduced crashes in ggc_collect 2017-05-19 14:15 ` Nathan Sidwell @ 2017-05-19 14:34 ` Bernd Edlinger 2017-05-24 11:21 ` Trevor Saunders 1 sibling, 0 replies; 17+ messages in thread From: Bernd Edlinger @ 2017-05-19 14:34 UTC (permalink / raw) To: Nathan Sidwell, Richard Biener Cc: gcc-patches, Jakub Jelinek, Jeff Law, Jason Merrill On 05/19/17 16:10, Nathan Sidwell wrote: > On 05/19/2017 10:05 AM, Bernd Edlinger wrote: > >> hwi cannot be the root cause of the problem, >> because it can only be long_integer_type_node >> or long_long_integer_type_node, otherwise >> an error would be triggered. > > that's the error I made with the static fns. PCH moves things around, > so anything that can be streamed via PCH must be GTY marked. Also, I'm > not sure if the current GC is a compacting GC (given PCH can compact > things?) > > Nathan I did three boot-straps with this patch on the 0515-snapshot, and the results are not yet completely stable: One time stage 3 failed as: lto/lto-lang.o lto/lto.o lto/lto-object.o attribs.o lto/lto-partition.o lto/lto-symtab.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a -L/home/ed/gnu/gcc-build/./isl/.libs -lisl -L/home/ed/gnu/gcc-build/./gmp/.libs -L/home/ed/gnu/gcc-build/./mpfr/src/.libs -L/home/ed/gnu/gcc-build/./mpc/src/.libs -lmpc -lmpfr -lgmp -rdynamic -ldl -L./../zlib -lz libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a tree-tailcall.o:(.debug_info+0x142b0): relocation truncated to fit: R_X86_64_8 against `.debug_str' collect2: Fehler: ld gab 1 als Ende-Status zurück make[3]: *** [lto1] Fehler 1 make[3]: *** Warte auf noch nicht beendete Prozesse... rm fsf-funding.pod gcov.pod gfdl.pod cpp.pod gpl.pod gcc.pod gcov-tool.pod gcov-dump.pod gfortran.pod gccgo.pod make[3]: Verlasse Verzeichnis '/home/ed/gnu/gcc-build/gcc' make[2]: *** [all-stage3-gcc] Fehler 2 make[2]: Verlasse Verzeichnis '/home/ed/gnu/gcc-build' make[1]: *** [stage3-bubble] Fehler 2 make[1]: Verlasse Verzeichnis '/home/ed/gnu/gcc-build' make: *** [all] Fehler 2 No idea if this is caused by gcc or binutils, I use binutils-2.28. Two times boot-strap succeeded, but once in the test suite I saw this: FAIL: gfortran.dg/minloc_3.f90 -O1 (internal compiler error) FAIL: gfortran.dg/minloc_3.f90 -O1 (test for excess errors) Excess errors: /home/ed/gnu/gcc-8-20170514/gcc/testsuite/gfortran.dg/minloc_3.f90:48:0: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in create_tmp_var, at gimple-expr.c:474 0xe90a67 tree_class_check_failed(tree_node const*, tree_code_class, char const*, int, char const*) ../../gcc-8-20170514/gcc/tree.c:9911 0x943bbd tree_class_check(tree_node*, tree_code_class, char const*, int, char const*) ../../gcc-8-20170514/gcc/tree.h:3206 0x943bbd create_tmp_var(tree_node*, char const*) ../../gcc-8-20170514/gcc/gimple-expr.c:474 0x967ccc voidify_wrapper_expr(tree_node*, tree_node*) ../../gcc-8-20170514/gcc/gimplify.c:1073 0x96f841 gimplify_statement_list ../../gcc-8-20170514/gcc/gimplify.c:1712 0x96f841 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc-8-20170514/gcc/gimplify.c:11686 0x973ec8 gimplify_stmt(tree_node**, gimple**) ../../gcc-8-20170514/gcc/gimplify.c:6517 0x97935e gimplify_cond_expr ../../gcc-8-20170514/gcc/gimplify.c:3991 0x96ffe8 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc-8-20170514/gcc/gimplify.c:11215 0x973ec8 gimplify_stmt(tree_node**, gimple**) ../../gcc-8-20170514/gcc/gimplify.c:6517 0x96f87b gimplify_statement_list ../../gcc-8-20170514/gcc/gimplify.c:1718 0x96f87b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc-8-20170514/gcc/gimplify.c:11686 0x973ec8 gimplify_stmt(tree_node**, gimple**) ../../gcc-8-20170514/gcc/gimplify.c:6517 0x97033c gimplify_and_add(tree_node*, gimple**) ../../gcc-8-20170514/gcc/gimplify.c:435 0x97033c gimplify_loop_expr ../../gcc-8-20170514/gcc/gimplify.c:1692 0x97033c gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc-8-20170514/gcc/gimplify.c:11462 0x973ec8 gimplify_stmt(tree_node**, gimple**) ../../gcc-8-20170514/gcc/gimplify.c:6517 0x96f87b gimplify_statement_list ../../gcc-8-20170514/gcc/gimplify.c:1718 0x96f87b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc-8-20170514/gcc/gimplify.c:11686 0x973ec8 gimplify_stmt(tree_node**, gimple**) ../../gcc-8-20170514/gcc/gimplify.c:6517 Anyway, I am going to commit my changes now, as at least the crashes which go thru gt_ggc_mx_cxx_binding have stopped. Bernd. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Try harder to fix recently introduced crashes in ggc_collect 2017-05-19 14:15 ` Nathan Sidwell 2017-05-19 14:34 ` Bernd Edlinger @ 2017-05-24 11:21 ` Trevor Saunders 2017-05-24 19:12 ` Jason Merrill 1 sibling, 1 reply; 17+ messages in thread From: Trevor Saunders @ 2017-05-24 11:21 UTC (permalink / raw) To: Nathan Sidwell Cc: Bernd Edlinger, Richard Biener, gcc-patches, Jakub Jelinek, Jeff Law, Jason Merrill On Fri, May 19, 2017 at 10:10:23AM -0400, Nathan Sidwell wrote: > On 05/19/2017 10:05 AM, Bernd Edlinger wrote: > > > hwi cannot be the root cause of the problem, > > because it can only be long_integer_type_node > > or long_long_integer_type_node, otherwise > > an error would be triggered. > > that's the error I made with the static fns. PCH moves things around, so > anything that can be streamed via PCH must be GTY marked. Also, I'm not > sure if the current GC is a compacting GC (given PCH can compact things?) other than pch which I'm not sure about I'm pretty sure its not, and is just basic mark and sweep. That said if modules can get merged for gcc 8 I'm very tempted to rm pch now. Trev > > nathan > -- > Nathan Sidwell ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Try harder to fix recently introduced crashes in ggc_collect 2017-05-24 11:21 ` Trevor Saunders @ 2017-05-24 19:12 ` Jason Merrill 2017-05-24 19:29 ` Nathan Sidwell 0 siblings, 1 reply; 17+ messages in thread From: Jason Merrill @ 2017-05-24 19:12 UTC (permalink / raw) To: Trevor Saunders Cc: Nathan Sidwell, Bernd Edlinger, Richard Biener, gcc-patches, Jakub Jelinek, Jeff Law On Wed, May 24, 2017 at 7:04 AM, Trevor Saunders <tbsaunde@tbsaunde.org> wrote: > On Fri, May 19, 2017 at 10:10:23AM -0400, Nathan Sidwell wrote: >> On 05/19/2017 10:05 AM, Bernd Edlinger wrote: >> >> > hwi cannot be the root cause of the problem, >> > because it can only be long_integer_type_node >> > or long_long_integer_type_node, otherwise >> > an error would be triggered. >> >> that's the error I made with the static fns. PCH moves things around, so >> anything that can be streamed via PCH must be GTY marked. Also, I'm not >> sure if the current GC is a compacting GC (given PCH can compact things?) > > other than pch which I'm not sure about I'm pretty sure its not, and is > just basic mark and sweep. > > That said if modules can get merged for gcc 8 I'm very tempted to rm pch > now. I think it would be premature to remove PCH from GCC 8. The Modules specification is far from stable, and moving current PCH users to Modules will take significant work (at least if we get something like the current draft rather than the relatively transparent scheme that clang uses). Jason ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] Try harder to fix recently introduced crashes in ggc_collect 2017-05-24 19:12 ` Jason Merrill @ 2017-05-24 19:29 ` Nathan Sidwell 0 siblings, 0 replies; 17+ messages in thread From: Nathan Sidwell @ 2017-05-24 19:29 UTC (permalink / raw) To: Jason Merrill, Trevor Saunders Cc: Bernd Edlinger, Richard Biener, gcc-patches, Jakub Jelinek, Jeff Law On 05/24/2017 03:02 PM, Jason Merrill wrote: > I think it would be premature to remove PCH from GCC 8. The Modules > specification is far from stable, and moving current PCH users to > Modules will take significant work (at least if we get something like > the current draft rather than the relatively transparent scheme that > clang uses). I agree. Although I now have function decls and inline function bodies working. Everything else is missing, and I know I'm not handling some things 'correctly'. nathan -- Nathan Sidwell ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2017-05-24 19:28 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-05-19 17:25 [PATCH] Try harder to fix recently introduced crashes in ggc_collect Dominique d'Humières 2017-05-19 17:31 ` Bernd Edlinger 2017-05-19 18:14 ` Dominique d'Humières 2017-05-22 7:36 ` Richard Biener 2017-05-22 16:55 ` Martin Sebor 2017-05-22 18:32 ` Jason Merrill 2017-05-22 20:43 ` Jason Merrill -- strict thread matches above, loose matches on Subject: below -- 2017-05-18 15:22 [PATCH] Try " Bernd Edlinger 2017-05-18 15:36 ` Richard Biener 2017-05-18 20:51 ` [PATCH] Try harder " Bernd Edlinger 2017-05-19 0:16 ` Nathan Sidwell 2017-05-19 7:58 ` Richard Biener 2017-05-19 11:06 ` Nathan Sidwell 2017-05-19 14:10 ` Bernd Edlinger 2017-05-19 14:15 ` Nathan Sidwell 2017-05-19 14:34 ` Bernd Edlinger 2017-05-24 11:21 ` Trevor Saunders 2017-05-24 19:12 ` Jason Merrill 2017-05-24 19:29 ` Nathan Sidwell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).