* [Bug bootstrap/55792] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
@ 2012-12-22 18:43 ` hjl.tools at gmail dot com
2012-12-22 20:13 ` hjl.tools at gmail dot com
` (35 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: hjl.tools at gmail dot com @ 2012-12-22 18:43 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
H.J. Lu <hjl.tools at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2012-12-22
Ever Confirmed|0 |1
--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> 2012-12-22 18:43:19 UTC ---
Also happens with revision 194692:
http://gcc.gnu.org/ml/gcc-regression/2012-12/msg00401.html
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
2012-12-22 18:43 ` [Bug bootstrap/55792] " hjl.tools at gmail dot com
@ 2012-12-22 20:13 ` hjl.tools at gmail dot com
2013-01-03 19:03 ` hjl.tools at gmail dot com
` (34 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: hjl.tools at gmail dot com @ 2012-12-22 20:13 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> 2012-12-22 20:12:50 UTC ---
ASAN:SIGSEGV
=================================================================
==19402== ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 (pc
0x00000067ce31 sp 0x7ffff81baa60 bp 0x000001000000 T0)
AddressSanitizer can not provide additional info.
#0 0x67ce30
(/export/build/gnu/gcc-lto-fdo-asan/build-x86_64-linux/prev-gcc/lto1+0x67ce30)
gnu-mic-2:pts/0[235]> addr2line -e lto1 0x67ce30
/export/gnu/import/git/gcc-misc/gcc/ggc-page.c:594
gnu-mic-2:pts/0[236]>
Also
../../src-trunk/gcc/df-core.c: In function 'df_analyze':
../../src-trunk/gcc/df-core.c:1269:1: internal compiler error: Segmentation
fault
}
^
0xb3adf7 crash_signal
../../src-trunk/gcc/toplev.c:334
0x546c3a lookup_page_table_entry
../../src-trunk/gcc/ggc-page.c:594
0x546c3a ggc_set_mark(void const*)
../../src-trunk/gcc/ggc-page.c:1477
0x8b65cf gt_ggc_mx_dw_loc_descr_struct(void*)
/export/gnu/import/git/gcc-test-profile/bld/gcc/gtype-desc.c:390
0x8b65f8 gt_ggc_mx_dw_loc_descr_struct(void*)
/export/gnu/import/git/gcc-test-profile/bld/gcc/gtype-desc.c:392
0x694b98 gt_ggc_mx_dw_loc_list_struct(void*)
./gt-dwarf2out.h:371
0x6a51d1 gt_ggc_mx(dw_attr_struct&)
./gt-dwarf2out.h:181
0x6a4d02 gt_ggc_mx<dw_attr_struct>
../../src-trunk/gcc/vec.h:1141
0x6a4d02 gt_ggc_mx_vec_dw_attr_node_va_gc_
./gt-dwarf2out.h:164
0x6a4d02 gt_ggc_mx_die_struct(void*)
./gt-dwarf2out.h:398
0x6a4b8d gt_ggc_mx_die_struct(void*)
./gt-dwarf2out.h:400
0x5039d2 gt_ggc_mx_lang_tree_node(void*)
./gtype-lto.h:369
0x503509 gt_ggc_mx_lang_tree_node(void*)
./gtype-lto.h:55
0x503937 gt_ggc_mx_lang_tree_node(void*)
./gtype-lto.h:357
0x503509 gt_ggc_mx_lang_tree_node(void*)
./gtype-lto.h:55
0x503919 gt_ggc_mx_lang_tree_node(void*)
./gtype-lto.h:356
0x503973 gt_ggc_mx_lang_tree_node(void*)
./gtype-lto.h:359
0x5038e5 gt_ggc_mx_lang_tree_node(void*)
./gtype-lto.h:354
0x501f1d gt_ggc_mx_lang_tree_node(void*)
./gtype-lto.h:263
0x8b7615 gt_ggc_mx_symtab_node_def(void*)
/export/gnu/import/git/gcc-test-profile/bld/gcc/gtype-desc.c:708
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
2012-12-22 18:43 ` [Bug bootstrap/55792] " hjl.tools at gmail dot com
2012-12-22 20:13 ` hjl.tools at gmail dot com
@ 2013-01-03 19:03 ` hjl.tools at gmail dot com
2013-01-04 23:58 ` hjl.tools at gmail dot com
` (33 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: hjl.tools at gmail dot com @ 2013-01-03 19:03 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> 2013-01-03 19:03:25 UTC ---
I got
==23584== ERROR: AddressSanitizer: heap-buffer-overflow on address
0x7f03d1089238 at pc 0xb9284a bp 0x7fffbd507b60 sp 0x7fffbd507b58
READ of size 1 at 0x7f03d1089238 thread T0
#0 0xb92849
(/export/build/gnu/gcc-lto-fdo-asan/build-x86_64-linux/prev-gcc/lto1+0xb92849)
0x7f03d1089238 is located 504 bytes inside of 4072-byte region
[0x7f03d1089040,0x7f03d108a028)
freed by thread T0 here:
#0 0x3afde5e
(/export/build/gnu/gcc-lto-fdo-asan/build-x86_64-linux/prev-gcc/lto1+0x3afde5e)
#1 0x3aebcfc
(/export/build/gnu/gcc-lto-fdo-asan/build-x86_64-linux/prev-gcc/lto1+0x3aebcfc)
previously allocated by thread T0 here:
#0 0x3afdfd4
(/export/build/gnu/gcc-lto-fdo-asan/build-x86_64-linux/prev-gcc/lto1+0x3afdfd4)
#1 0x3af6b1e
(/export/build/gnu/gcc-lto-fdo-asan/build-x86_64-linux/prev-gcc/lto1+0x3af6b1e)
Shadow byte and word:
0x1fe07a211247: fa
0x1fe07a211240: fa fa fa fa fa fa fa fa
More shadow bytes:
0x1fe07a211220: fa fa fa fa fa fa fa fa
0x1fe07a211228: fa fa fa fa fa fa fa fa
0x1fe07a211230: fa fa fa fa fa fa fa fa
0x1fe07a211238: fa fa fa fa fa fa fa fa
=>0x1fe07a211240: fa fa fa fa fa fa fa fa
0x1fe07a211248: fa fa fa fa fa fa fa fa
0x1fe07a211250: fa fa fa fa fa fa fa fa
0x1fe07a211258: fa fa fa fa fa fa fa fa
0x1fe07a211260: fa fa fa fa fa fa fa fa
[hjl@gnu-mic-2 prev-gcc]$ addr2line -e lto1 0xb92849
/export/gnu/import/git/gcc-misc/gcc/dwarf2out.c:22425
[hjl@gnu-mic-2 prev-gcc]$ addr2line -e lto1 0x3afde5e
/export/gnu/import/git/gcc-misc/libsanitizer/asan/asan_malloc_linux.cc:60
[hjl@gnu-mic-2 prev-gcc]$ addr2line -e lto1 0x3aebcfc
/export/gnu/import/git/gcc-misc/libiberty/hashtab.c:584
[hjl@gnu-mic-2 prev-gcc]$ addr2line -e lto1 0x3afdfd4
/export/gnu/import/git/gcc-misc/libsanitizer/asan/asan_malloc_linux.cc:86
[hjl@gnu-mic-2 prev-gcc]$ addr2line -e lto1 0x3af6b1e
/export/gnu/import/git/gcc-misc/libiberty/xmalloc.c:162
[hjl@gnu-mic-2 prev-gcc]$
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (2 preceding siblings ...)
2013-01-03 19:03 ` hjl.tools at gmail dot com
@ 2013-01-04 23:58 ` hjl.tools at gmail dot com
2013-01-05 16:47 ` hjl.tools at gmail dot com
` (32 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: hjl.tools at gmail dot com @ 2013-01-04 23:58 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> 2013-01-04 23:57:55 UTC ---
Created attachment 29085
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29085
A patch to move lto_global_var_decls to lto/lto.c
With this patch, I got
lto1: internal compiler error: Segmentation fault
0x997fc5 crash_signal
/export/gnu/import/git/gcc/gcc/toplev.c:334
0x545095 ggc_get_size(void const*)
/export/gnu/import/git/gcc/gcc/ggc-page.c:1531
0x7453cf ggc_realloc_stat(void*, unsigned long)
/export/gnu/import/git/gcc/gcc/ggc-common.c:199
0x52b01a void va_gc::reserve<tree_node*, va_gc>(vec<tree_node*, va_gc,
vl_embed>*&, unsigned int, bool)
/export/gnu/import/git/gcc/gcc/vec.h:379
0x52ae82 bool vec_safe_reserve<tree_node*, va_gc>(vec<tree_node*, va_gc,
vl_embed>*&, unsigned int, bool)
/export/gnu/import/git/gcc/gcc/vec.h:657
0x53c953 tree_node** vec_safe_push<tree_node*, va_gc>(vec<tree_node*, va_gc,
vl_embed>*&, tree_node* const&)
/export/gnu/import/git/gcc/gcc/vec.h:749
0x53bee2 lto_main()
/export/gnu/import/git/gcc/gcc/lto/lto.c:3407
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[5]: *** [/tmp/cci2rOkJ.ltrans0.ltrans.o] Error 1
lto-wrapper: make returned 2 exit status
/usr/local/x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[4]: *** [build/genhooks] Error 1
make[4]: *** Waiting for unfinished jobs....
rm cpp.pod gfdl.pod gcov.pod gfortran.pod gcc.pod fsf-funding.pod
make[4]: Leaving directory `/export/build/gnu/gcc-lto/build-x86_64-linux/gcc'
make[3]: *** [all-stage2-gcc] Error 2
make[3]: Leaving directory `/export/build/gnu/gcc-lto/build-x86_64-linux'
make[2]: *** [stage2-bubble] Error 2
make[2]: Leaving directory `/export/build/gnu/gcc-lto/build-x86_64-linux'
make[1]: *** [bootstrap] Error 2
make[1]: Leaving directory `/export/build/gnu/gcc-lto/build-x86_64-linux'
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (3 preceding siblings ...)
2013-01-04 23:58 ` hjl.tools at gmail dot com
@ 2013-01-05 16:47 ` hjl.tools at gmail dot com
2013-01-05 17:21 ` hjl.tools at gmail dot com
` (31 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: hjl.tools at gmail dot com @ 2013-01-05 16:47 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> 2013-01-05 16:47:08 UTC ---
The page is freed since there is nothing in it:
#0 set_page_table_entry (p=0x7ffff1ab8000, entry=0x0)
at /export/gnu/import/git/gcc/gcc/ggc-page.c:640
#1 0x0000000000544514 in free_page (entry=0x17a1d70)
at /export/gnu/import/git/gcc/gcc/ggc-page.c:948
#2 0x0000000000545a41 in sweep_pages ()
at /export/gnu/import/git/gcc/gcc/ggc-page.c:1886
#3 0x0000000000545ed0 in ggc_collect ()
at /export/gnu/import/git/gcc/gcc/ggc-page.c:2094
#4 0x00000000008acc6e in execute_todo (flags=2)
at /export/gnu/import/git/gcc/gcc/passes.c:2023
#5 0x00000000008ad5cd in execute_one_pass (pass=0x16bd620 <pass_final>)
at /export/gnu/import/git/gcc/gcc/passes.c:2349
#6 0x00000000008ad732 in execute_pass_list (pass=0x16bd620 <pass_final>)
at /export/gnu/import/git/gcc/gcc/passes.c:2383
#7 0x00000000008ad763 in execute_pass_list (pass=0x16be6c0 <pass_postreload>)
at /export/gnu/import/git/gcc/gcc/passes.c:2384
#8 0x00000000008ad763 in execute_pass_list (
pass=0x16be660 <pass_rest_of_compilation>)
at /export/gnu/import/git/gcc/gcc/passes.c:2384
#9 0x00000000005d9c06 in expand_function (node=0x7ffff1b55250)
at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641
#10 0x00000000005da0c1 in expand_all_functions ()
at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745
---Type <return> to continue, or q <return> to quit---
#11 0x00000000005dab4b in compile ()
at /export/gnu/import/git/gcc/gcc/cgraphunit.c:2043
#12 0x000000000053beaa in lto_main ()
at /export/gnu/import/git/gcc/gcc/lto/lto.c:3393
#13 0x0000000000998859 in compile_file ()
at /export/gnu/import/git/gcc/gcc/toplev.c:545
#14 0x000000000099a83c in do_compile ()
at /export/gnu/import/git/gcc/gcc/toplev.c:1878
#15 0x000000000099a9a7 in toplev_main (argc=26, argv=0x7fffffffdff8)
at /export/gnu/import/git/gcc/gcc/toplev.c:1954
#16 0x0000000000ffeee0 in main (argc=26, argv=0x7fffffffdff8)
at /export/gnu/import/git/gcc/gcc/main.c:36
(gdb)
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (4 preceding siblings ...)
2013-01-05 16:47 ` hjl.tools at gmail dot com
@ 2013-01-05 17:21 ` hjl.tools at gmail dot com
2013-01-07 10:13 ` rguenth at gcc dot gnu.org
` (30 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: hjl.tools at gmail dot com @ 2013-01-05 17:21 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
H.J. Lu <hjl.tools at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu.org
Target Milestone|--- |4.8.0
--- Comment #6 from H.J. Lu <hjl.tools at gmail dot com> 2013-01-05 17:21:05 UTC ---
LTO uses GC pages after they have been freed by final pass.
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (5 preceding siblings ...)
2013-01-05 17:21 ` hjl.tools at gmail dot com
@ 2013-01-07 10:13 ` rguenth at gcc dot gnu.org
2013-01-07 15:41 ` hjl.tools at gmail dot com
` (29 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-01-07 10:13 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-07 10:12:53 UTC ---
It's a global, why should it get collected?
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (6 preceding siblings ...)
2013-01-07 10:13 ` rguenth at gcc dot gnu.org
@ 2013-01-07 15:41 ` hjl.tools at gmail dot com
2013-01-07 16:02 ` rguenth at gcc dot gnu.org
` (28 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: hjl.tools at gmail dot com @ 2013-01-07 15:41 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> 2013-01-07 15:40:16 UTC ---
(In reply to comment #7)
> It's a global, why should it get collected?
Because it is empty when ggc_collect is called.
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (7 preceding siblings ...)
2013-01-07 15:41 ` hjl.tools at gmail dot com
@ 2013-01-07 16:02 ` rguenth at gcc dot gnu.org
2013-01-07 16:03 ` [Bug bootstrap/55792] [4.8 Regression] " rguenth at gcc dot gnu.org
` (27 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-01-07 16:02 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dnovillo at gcc dot gnu.org
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-07 16:01:52 UTC ---
Eh. Diego, how does GTY((user)) work here? It smells like a bug in vec.h
to me.
/* Garbage collection support for vec<T, A, vl_embed>. */
template<typename T>
void
gt_ggc_mx (vec<T, va_gc> *v)
{
extern void gt_ggc_mx (T &);
for (unsigned i = 0; i < v->length (); i++)
gt_ggc_mx ((*v)[i]);
}
doesn't it need to mark the vec itself? Maybe automatic registration of
roots (this is a GC root) does not work with GTY((user))?
As far as I understand HJ the vec struct itself is GCed but the global
var pointing to it (the root) is not zeroed (I say it shouldn't be collected
at all).
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (8 preceding siblings ...)
2013-01-07 16:02 ` rguenth at gcc dot gnu.org
@ 2013-01-07 16:03 ` rguenth at gcc dot gnu.org
2013-01-07 17:55 ` dnovillo at gcc dot gnu.org
` (26 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-01-07 16:03 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P1
Summary|Bad memory access with |[4.8 Regression] Bad memory
|profiledbootstrap and LTO |access with
| |profiledbootstrap and LTO
--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-07 16:02:38 UTC ---
vec + GC related regression.
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (9 preceding siblings ...)
2013-01-07 16:03 ` [Bug bootstrap/55792] [4.8 Regression] " rguenth at gcc dot gnu.org
@ 2013-01-07 17:55 ` dnovillo at gcc dot gnu.org
2013-01-07 22:14 ` hjl.tools at gmail dot com
` (25 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: dnovillo at gcc dot gnu.org @ 2013-01-07 17:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #11 from Diego Novillo <dnovillo at gcc dot gnu.org> 2013-01-07 17:54:14 UTC ---
(In reply to comment #9)
> Eh. Diego, how does GTY((user)) work here? It smells like a bug in vec.h
> to me.
>
> /* Garbage collection support for vec<T, A, vl_embed>. */
>
> template<typename T>
> void
> gt_ggc_mx (vec<T, va_gc> *v)
> {
> extern void gt_ggc_mx (T &);
> for (unsigned i = 0; i < v->length (); i++)
> gt_ggc_mx ((*v)[i]);
> }
>
> doesn't it need to mark the vec itself? Maybe automatic registration of
> roots (this is a GC root) does not work with GTY((user))?
No. The root is/should be marked by the code calling gt_ggc_mx. gengtype will
generate code like:
if (ggc_test_and_set_mark (x))
{
gt_ggc_mx (x);
}
ggc_test_and_set_mark() is the one that marks the root. Has gengtype generated
a function for this global? It should be something like this
void
gt_ggc_mx_vec_<mangled_type_name> (void *x_p)
{
vec<type_name,va_gc> * const x = (vec<type_name,va_gc> *)x_p;
if (ggc_test_and_set_mark (x))
{
gt_ggc_mx (x);
}
}
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (10 preceding siblings ...)
2013-01-07 17:55 ` dnovillo at gcc dot gnu.org
@ 2013-01-07 22:14 ` hjl.tools at gmail dot com
2013-01-07 23:30 ` hjl.tools at gmail dot com
` (24 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: hjl.tools at gmail dot com @ 2013-01-07 22:14 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #12 from H.J. Lu <hjl.tools at gmail dot com> 2013-01-07 22:13:33 UTC ---
(In reply to comment #4)
> Created attachment 29085 [details]
> A patch to move lto_global_var_decls to lto/lto.c
>
> With this patch, I got
>
> lto1: internal compiler error: Segmentation fault
> 0x997fc5 crash_signal
> /export/gnu/import/git/gcc/gcc/toplev.c:334
> 0x545095 ggc_get_size(void const*)
This patch misses:
diff --cc gcc/lto/config-lang.in
index 90235b0,90235b0..839d359
--- a/gcc/lto/config-lang.in
+++ b/gcc/lto/config-lang.in
@@@ -22,7 -22,7 +22,7 @@@ language="lto
compilers="lto1\$(exeext)"
stagestuff="lto1\$(exeext)"
--gtfiles="\$(srcdir)/lto/lto-tree.h \$(srcdir)/lto/lto-lang.c
\$(srcdir)/lto/lt
o.c"
++gtfiles="\$(srcdir)/lto/lto-tree.h \$(srcdir)/lto/lto-lang.c
\$(srcdir)/lto/lt
o.c \$(srcdir)/lto/lto.h"
# LTO is a special front end. From a user's perspective it is not
# really a language, but a middle end feature. However, the GIMPLE
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (11 preceding siblings ...)
2013-01-07 22:14 ` hjl.tools at gmail dot com
@ 2013-01-07 23:30 ` hjl.tools at gmail dot com
2013-01-08 1:20 ` hjl.tools at gmail dot com
` (23 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: hjl.tools at gmail dot com @ 2013-01-07 23:30 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #13 from H.J. Lu <hjl.tools at gmail dot com> 2013-01-07 23:30:15 UTC ---
For the testcase at
https://sites.google.com/site/x32abi/documents/jc1.ltrans23.o.xz?attredirects=0&d=1
[hjl@gnu-6 gcc]$ ./lto1 -quiet -dumpdir ./ -dumpbase jc1.ltrans23
-mtune=generic -march=x86-64 -mtune=generic -march=x86-64 -auxbase-strip
jc1.ltrans23.ltrans.o -g -O2 -Wextra -Wpedantic -version -frandom-seed=1
-fprofile-use -fno-exceptions -fasynchronous-unwind-tables -fno-common -fltrans
~/tmp/jc1.ltrans23.o -o x.s
GNU GIMPLE (GCC) version 4.8.0 20130107 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.2 20120921 (Red Hat 4.7.2-2), GMP version
5.0.2, MPFR version 3.1.0, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU GIMPLE (GCC) version 4.8.0 20130107 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.2 20120921 (Red Hat 4.7.2-2), GMP version
5.0.2, MPFR version 3.1.0, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
In file included from :1642:0:
/export/gnu/import/git/gcc/gcc/recog.c: In function ‘peep2_find_free_register’:
/export/gnu/import/git/gcc/gcc/recog.c:3074:0: internal compiler error:
Segmentation fault
peep2_find_free_register (int from, int to, const char *class_str,
^
0x998b6d crash_signal
/export/gnu/import/git/gcc/gcc/toplev.c:334
0x544540 lookup_page_table_entry
/export/gnu/import/git/gcc/gcc/ggc-page.c:594
0x5455f5 ggc_set_mark(void const*)
/export/gnu/import/git/gcc/gcc/ggc-page.c:1477
0x79e602 gt_ggc_mx_dw_loc_descr_struct(void*)
/export/build/gnu/gcc/build-x86_64-linux/gcc/gtype-desc.c:390
0x79e635 gt_ggc_mx_dw_loc_descr_struct(void*)
/export/build/gnu/gcc/build-x86_64-linux/gcc/gtype-desc.c:392
0x65d538 gt_ggc_mx_dw_loc_list_struct(void*)
./gt-dwarf2out.h:371
0x65ced2 gt_ggc_mx(dw_attr_struct&)
./gt-dwarf2out.h:181
0x65ce3c gt_ggc_mx_vec_dw_attr_node_va_gc_(void*)
./gt-dwarf2out.h:164
0x65d62b gt_ggc_mx_die_struct(void*)
./gt-dwarf2out.h:398
0x65d665 gt_ggc_mx_die_struct(void*)
./gt-dwarf2out.h:400
0x65d665 gt_ggc_mx_die_struct(void*)
./gt-dwarf2out.h:400
0x525697 gt_ggc_mx_lang_tree_node(void*)
./gtype-lto.h:369
0x523a2d gt_ggc_mx_lang_tree_node(void*)
./gtype-lto.h:55
0x5255f4 gt_ggc_mx_lang_tree_node(void*)
./gtype-lto.h:357
0x523a2d gt_ggc_mx_lang_tree_node(void*)
./gtype-lto.h:55
0x5255d7 gt_ggc_mx_lang_tree_node(void*)
./gtype-lto.h:356
0x52562e gt_ggc_mx_lang_tree_node(void*)
./gtype-lto.h:359
0x5256d9 gt_ggc_mx_lang_tree_node(void*)
./gtype-lto.h:375
0x52559d gt_ggc_mx_lang_tree_node(void*)
./gtype-lto.h:354
0x52559d gt_ggc_mx_lang_tree_node(void*)
./gtype-lto.h:354
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
[hjl@gnu-6 gcc]$
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (12 preceding siblings ...)
2013-01-07 23:30 ` hjl.tools at gmail dot com
@ 2013-01-08 1:20 ` hjl.tools at gmail dot com
2013-01-08 10:17 ` rguenth at gcc dot gnu.org
` (22 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: hjl.tools at gmail dot com @ 2013-01-08 1:20 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #14 from H.J. Lu <hjl.tools at gmail dot com> 2013-01-08 01:19:29 UTC ---
(In reply to comment #13)
> For the testcase at
>
> https://sites.google.com/site/x32abi/documents/jc1.ltrans23.o.xz?attredirects=0&d=1
>
> [hjl@gnu-6 gcc]$ ./lto1 -quiet -dumpdir ./ -dumpbase jc1.ltrans23
> -mtune=generic -march=x86-64 -mtune=generic -march=x86-64 -auxbase-strip
> jc1.ltrans23.ltrans.o -g -O2 -Wextra -Wpedantic -version -frandom-seed=1
> -fprofile-use -fno-exceptions -fasynchronous-unwind-tables -fno-common -fltrans
> ~/tmp/jc1.ltrans23.o -o x.s
Remove -fprofile-use or add -fno-tracer fix ICE.
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (13 preceding siblings ...)
2013-01-08 1:20 ` hjl.tools at gmail dot com
@ 2013-01-08 10:17 ` rguenth at gcc dot gnu.org
2013-01-08 17:13 ` hjl.tools at gmail dot com
` (21 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-01-08 10:17 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-08 10:17:16 UTC ---
(In reply to comment #11)
> (In reply to comment #9)
> > Eh. Diego, how does GTY((user)) work here? It smells like a bug in vec.h
> > to me.
> >
> > /* Garbage collection support for vec<T, A, vl_embed>. */
> >
> > template<typename T>
> > void
> > gt_ggc_mx (vec<T, va_gc> *v)
> > {
> > extern void gt_ggc_mx (T &);
> > for (unsigned i = 0; i < v->length (); i++)
> > gt_ggc_mx ((*v)[i]);
> > }
> >
> > doesn't it need to mark the vec itself? Maybe automatic registration of
> > roots (this is a GC root) does not work with GTY((user))?
>
> No. The root is/should be marked by the code calling gt_ggc_mx. gengtype will
> generate code like:
>
> if (ggc_test_and_set_mark (x))
> {
> gt_ggc_mx (x);
> }
>
> ggc_test_and_set_mark() is the one that marks the root. Has gengtype generated
> a function for this global? It should be something like this
>
> void
> gt_ggc_mx_vec_<mangled_type_name> (void *x_p)
> {
> vec<type_name,va_gc> * const x = (vec<type_name,va_gc> *)x_p;
> if (ggc_test_and_set_mark (x))
> {
> gt_ggc_mx (x);
> }
> }
There is
EXPORTED_CONST struct ggc_root_tab gt_ggc_r_gtype_desc_c[] = {
...
{
<o_global_var_decls,
1,
sizeof (lto_global_var_decls),
>_ggc_mx_vec_tree_va_gc_,
>_pch_nx_vec_tree_va_gc_
},
in gtype-desc.c, which looks like
void
gt_ggc_mx_vec_tree_va_gc_ (void *x_p)
{
vec<tree,va_gc> * const x = (vec<tree,va_gc> *)x_p;
if (ggc_test_and_set_mark (x))
{
gt_ggc_mx (x);
}
}
with
/* If EXPR is not NULL and previously unmarked, mark it and evaluate
to true. Otherwise evaluate to false. */
#define ggc_test_and_set_mark(EXPR) \
((EXPR) != NULL && ((void *) (EXPR)) != (void *) 1 && ! ggc_set_mark (EXPR))
this indeed looks correct to me given vec.h's
template<typename T>
void
gt_ggc_mx (vec<T, va_gc> *v)
{
extern void gt_ggc_mx (T &);
for (unsigned i = 0; i < v->length (); i++)
gt_ggc_mx ((*v)[i]);
}
and the generated(?)
void
gt_ggc_mx (union tree_node *& x)
{
if (x)
gt_ggc_mx_lang_tree_node ((void *) x);
}
So I'm still not sure what HJ means with "it's collected". GC roots are
never collected. HJ, should your patch fix anything? What do you think
the bug is?
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (14 preceding siblings ...)
2013-01-08 10:17 ` rguenth at gcc dot gnu.org
@ 2013-01-08 17:13 ` hjl.tools at gmail dot com
2013-01-09 0:23 ` hjl.tools at gmail dot com
` (20 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: hjl.tools at gmail dot com @ 2013-01-08 17:13 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #16 from H.J. Lu <hjl.tools at gmail dot com> 2013-01-08 17:12:57 UTC ---
(In reply to comment #15)
> So I'm still not sure what HJ means with "it's collected". GC roots are
> never collected. HJ, should your patch fix anything? What do you think
> the bug is?
My patch is an optimization, not a fix.
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (15 preceding siblings ...)
2013-01-08 17:13 ` hjl.tools at gmail dot com
@ 2013-01-09 0:23 ` hjl.tools at gmail dot com
2013-01-09 9:32 ` rguenth at gcc dot gnu.org
` (19 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: hjl.tools at gmail dot com @ 2013-01-09 0:23 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #17 from H.J. Lu <hjl.tools at gmail dot com> 2013-01-09 00:22:18 UTC ---
gimple_location is duplicated by:
#1 0x0000000000751f32 in gimple_copy (stmt=0x7fffe8d75a00)
at /export/gnu/import/git/gcc/gcc/gimple.c:2205
#2 0x00000000009c960d in gimple_duplicate_bb (bb=0x7fffe8d768f0)
at /export/gnu/import/git/gcc/gcc/tree-cfg.c:5397
#3 0x00000000005b27a5 in duplicate_block (bb=0x7fffe8d768f0,
e=0x7fffe8d793f0, after=0x7fffe8d76888)
at /export/gnu/import/git/gcc/gcc/cfghooks.c:1012
#4 0x000000000099c511 in tail_duplicate ()
at /export/gnu/import/git/gcc/gcc/tracer.c:323
#5 0x000000000099c765 in tracer ()
at /export/gnu/import/git/gcc/gcc/tracer.c:380
#6 0x00000000008ae0e6 in execute_one_pass (pass=0x16d18a0 <pass_tracer>)
at /export/gnu/import/git/gcc/gcc/passes.c:2335
#7 0x00000000008ae2da in execute_pass_list (pass=0x16d18a0 <pass_tracer>)
at /export/gnu/import/git/gcc/gcc/passes.c:2383
#8 0x00000000008ae30b in execute_pass_list (
pass=0x16d07e0 <pass_all_optimizations>)
at /export/gnu/import/git/gcc/gcc/passes.c:2384
#9 0x00000000005da366 in expand_function (node=0x7ffff17536f0)
at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641
#10 0x00000000005da821 in expand_all_functions ()
at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745
(gdb) p copy
$176 = (gimple) 0x7fffe8e0a320
(gdb)
Later, the original location is removed:
#0 remove_unused_locals ()
at /export/gnu/import/git/gcc/gcc/tree-ssa-live.c:793
#1 0x00000000008ad5cb in execute_function_todo (data=0x8800)
at /export/gnu/import/git/gcc/gcc/passes.c:1952
#2 0x00000000008ac965 in do_per_function (
callback=0x8ad4ae <execute_function_todo(void*)>, data=0x8800)
at /export/gnu/import/git/gcc/gcc/passes.c:1703
#3 0x00000000008ad765 in execute_todo (flags=34816)
at /export/gnu/import/git/gcc/gcc/passes.c:2001
#4 0x00000000008ae175 in execute_one_pass (
pass=0x16d3220 <pass_cleanup_cfg_post_optimizing>)
at /export/gnu/import/git/gcc/gcc/passes.c:2349
#5 0x00000000008ae2da in execute_pass_list (
pass=0x16d3220 <pass_cleanup_cfg_post_optimizing>)
at /export/gnu/import/git/gcc/gcc/passes.c:2383
#6 0x00000000005da366 in expand_function (node=0x7ffff17536f0)
at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641
#7 0x00000000005da821 in expand_all_functions ()
at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745
and freed. Then we copy the freed gimple_location:
#0 expand_gimple_stmt_1 (stmt=0x7fffe8e0a320)
at /export/gnu/import/git/gcc/gcc/cfgexpand.c:2202
#1 0x00000000005a7786 in expand_gimple_stmt (stmt=0x7fffe8e0a320)
at /export/gnu/import/git/gcc/gcc/cfgexpand.c:2305
#2 0x00000000005ad975 in expand_gimple_basic_block (bb=0x7fffe8d76888,
disable_tail_calls=false)
at /export/gnu/import/git/gcc/gcc/cfgexpand.c:4084
#3 0x00000000005af426 in gimple_expand_cfg ()
at /export/gnu/import/git/gcc/gcc/cfgexpand.c:4603
#4 0x00000000008ae0e6 in execute_one_pass (pass=0x16ce300 <pass_expand>)
at /export/gnu/import/git/gcc/gcc/passes.c:2335
#5 0x00000000008ae2da in execute_pass_list (pass=0x16ce300 <pass_expand>)
at /export/gnu/import/git/gcc/gcc/passes.c:2383
#6 0x00000000005da366 in expand_function (node=0x7ffff17536f0)
at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641
#7 0x00000000005da821 in expand_all_functions ()
at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745
#8 0x00000000005db2ab in compile ()
at /export/gnu/import/git/gcc/gcc/cgraphunit.c:2043
#9 0x000000000053c60a in lto_main ()
at /export/gnu/import/git/gcc/gcc/lto/lto.c:3390
#10 0x0000000000999401 in compile_file ()
at /export/gnu/import/git/gcc/gcc/toplev.c:545
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (16 preceding siblings ...)
2013-01-09 0:23 ` hjl.tools at gmail dot com
@ 2013-01-09 9:32 ` rguenth at gcc dot gnu.org
2013-01-09 16:11 ` hjl.tools at gmail dot com
` (18 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-01-09 9:32 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #18 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-09 09:31:45 UTC ---
(In reply to comment #17)
> gimple_location is duplicated by:
>
> #1 0x0000000000751f32 in gimple_copy (stmt=0x7fffe8d75a00)
> at /export/gnu/import/git/gcc/gcc/gimple.c:2205
> #2 0x00000000009c960d in gimple_duplicate_bb (bb=0x7fffe8d768f0)
> at /export/gnu/import/git/gcc/gcc/tree-cfg.c:5397
> #3 0x00000000005b27a5 in duplicate_block (bb=0x7fffe8d768f0,
> e=0x7fffe8d793f0, after=0x7fffe8d76888)
> at /export/gnu/import/git/gcc/gcc/cfghooks.c:1012
> #4 0x000000000099c511 in tail_duplicate ()
> at /export/gnu/import/git/gcc/gcc/tracer.c:323
> #5 0x000000000099c765 in tracer ()
> at /export/gnu/import/git/gcc/gcc/tracer.c:380
> #6 0x00000000008ae0e6 in execute_one_pass (pass=0x16d18a0 <pass_tracer>)
> at /export/gnu/import/git/gcc/gcc/passes.c:2335
> #7 0x00000000008ae2da in execute_pass_list (pass=0x16d18a0 <pass_tracer>)
> at /export/gnu/import/git/gcc/gcc/passes.c:2383
> #8 0x00000000008ae30b in execute_pass_list (
> pass=0x16d07e0 <pass_all_optimizations>)
> at /export/gnu/import/git/gcc/gcc/passes.c:2384
> #9 0x00000000005da366 in expand_function (node=0x7ffff17536f0)
> at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641
> #10 0x00000000005da821 in expand_all_functions ()
> at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745
> (gdb) p copy
> $176 = (gimple) 0x7fffe8e0a320
> (gdb)
The BLOCK of the location is kept live by being referenced by the stmt
copy (what kind is the stmt? the only stmt not well handled seems to
be CLOBBERs)
> Later, the original location is removed:
>
> #0 remove_unused_locals ()
> at /export/gnu/import/git/gcc/gcc/tree-ssa-live.c:793
> #1 0x00000000008ad5cb in execute_function_todo (data=0x8800)
> at /export/gnu/import/git/gcc/gcc/passes.c:1952
> #2 0x00000000008ac965 in do_per_function (
> callback=0x8ad4ae <execute_function_todo(void*)>, data=0x8800)
> at /export/gnu/import/git/gcc/gcc/passes.c:1703
> #3 0x00000000008ad765 in execute_todo (flags=34816)
> at /export/gnu/import/git/gcc/gcc/passes.c:2001
> #4 0x00000000008ae175 in execute_one_pass (
> pass=0x16d3220 <pass_cleanup_cfg_post_optimizing>)
> at /export/gnu/import/git/gcc/gcc/passes.c:2349
> #5 0x00000000008ae2da in execute_pass_list (
> pass=0x16d3220 <pass_cleanup_cfg_post_optimizing>)
> at /export/gnu/import/git/gcc/gcc/passes.c:2383
> #6 0x00000000005da366 in expand_function (node=0x7ffff17536f0)
> at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641
> #7 0x00000000005da821 in expand_all_functions ()
> at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745
>
> and freed.
You probably mean BLOCK - it should be still live as referenced from
the stmt, or cleaned from the stmt if it was a debug stmt.
> Then we copy the freed gimple_location:
>
> #0 expand_gimple_stmt_1 (stmt=0x7fffe8e0a320)
> at /export/gnu/import/git/gcc/gcc/cfgexpand.c:2202
> #1 0x00000000005a7786 in expand_gimple_stmt (stmt=0x7fffe8e0a320)
> at /export/gnu/import/git/gcc/gcc/cfgexpand.c:2305
> #2 0x00000000005ad975 in expand_gimple_basic_block (bb=0x7fffe8d76888,
> disable_tail_calls=false)
> at /export/gnu/import/git/gcc/gcc/cfgexpand.c:4084
> #3 0x00000000005af426 in gimple_expand_cfg ()
> at /export/gnu/import/git/gcc/gcc/cfgexpand.c:4603
> #4 0x00000000008ae0e6 in execute_one_pass (pass=0x16ce300 <pass_expand>)
> at /export/gnu/import/git/gcc/gcc/passes.c:2335
> #5 0x00000000008ae2da in execute_pass_list (pass=0x16ce300 <pass_expand>)
> at /export/gnu/import/git/gcc/gcc/passes.c:2383
> #6 0x00000000005da366 in expand_function (node=0x7ffff17536f0)
> at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641
> #7 0x00000000005da821 in expand_all_functions ()
> at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745
> #8 0x00000000005db2ab in compile ()
> at /export/gnu/import/git/gcc/gcc/cgraphunit.c:2043
> #9 0x000000000053c60a in lto_main ()
> at /export/gnu/import/git/gcc/gcc/lto/lto.c:3390
> #10 0x0000000000999401 in compile_file ()
> at /export/gnu/import/git/gcc/gcc/toplev.c:545
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (17 preceding siblings ...)
2013-01-09 9:32 ` rguenth at gcc dot gnu.org
@ 2013-01-09 16:11 ` hjl.tools at gmail dot com
2013-01-09 17:13 ` hjl.tools at gmail dot com
` (17 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: hjl.tools at gmail dot com @ 2013-01-09 16:11 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #19 from H.J. Lu <hjl.tools at gmail dot com> 2013-01-09 16:11:06 UTC ---
The BLOCK tree node is cleared by
(gdb) bt
#0 0x000000336b4882ee in __memset_sse2 () from /lib64/libc.so.6
#1 0x0000000000545fdf in clear_marks ()
at /export/gnu/import/git/gcc/gcc/ggc-page.c:1815
#2 0x0000000000546621 in ggc_collect ()
at /export/gnu/import/git/gcc/gcc/ggc-page.c:2086
#3 0x00000000008ad816 in execute_todo (flags=2102)
at /export/gnu/import/git/gcc/gcc/passes.c:2023
#4 0x00000000008ae175 in execute_one_pass (pass=0x17b9c70)
at /export/gnu/import/git/gcc/gcc/passes.c:2349
#5 0x00000000008ae2da in execute_pass_list (pass=0x17b9c70)
at /export/gnu/import/git/gcc/gcc/passes.c:2383
#6 0x00000000008ae30b in execute_pass_list (
pass=0x16d07e0 <pass_all_optimizations>)
at /export/gnu/import/git/gcc/gcc/passes.c:2384
#7 0x00000000005da366 in expand_function (node=0x7ffff16f5378)
at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641
#8 0x00000000005da821 in expand_all_functions ()
at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745
#9 0x00000000005db2ab in compile ()
at /export/gnu/import/git/gcc/gcc/cgraphunit.c:2043
#10 0x000000000053c60a in lto_main ()
at /export/gnu/import/git/gcc/gcc/lto/lto.c:3390
#11 0x0000000000999401 in compile_file ()
---Type <return> to continue, or q <return> to quit---
at /export/gnu/import/git/gcc/gcc/toplev.c:545
#12 0x000000000099b3e4 in do_compile ()
at /export/gnu/import/git/gcc/gcc/toplev.c:1878
#13 0x000000000099b54f in toplev_main (argc=28, argv=0x7fffffffdc78)
at /export/gnu/import/git/gcc/gcc/toplev.c:1954
#14 0x0000000000fff958 in main (argc=28, argv=0x7fffffffdc78)
at /export/gnu/import/git/gcc/gcc/main.c:36
(gdb)
When we remap a block:
static void
remap_block (tree *block, copy_body_data *id)
{
tree old_block;
tree new_block;
/* Make the new block. */
old_block = *block;
new_block = make_node (BLOCK);
TREE_USED (new_block) = TREE_USED (old_block);
BLOCK_ABSTRACT_ORIGIN (new_block) = old_block;
BLOCK_SOURCE_LOCATION (new_block) = BLOCK_SOURCE_LOCATION (old_block);
BLOCK_NONLOCALIZED_VARS (new_block)
= vec_safe_copy (BLOCK_NONLOCALIZED_VARS (old_block));
*block = new_block;
/* Remap its variables. */
BLOCK_VARS (new_block) = remap_decls (BLOCK_VARS (old_block),
&BLOCK_NONLOCALIZED_VARS (new_block),
id);
we didn't register it with GC root.
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (18 preceding siblings ...)
2013-01-09 16:11 ` hjl.tools at gmail dot com
@ 2013-01-09 17:13 ` hjl.tools at gmail dot com
2013-01-09 18:22 ` rguenth at gcc dot gnu.org
` (16 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: hjl.tools at gmail dot com @ 2013-01-09 17:13 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #20 from H.J. Lu <hjl.tools at gmail dot com> 2013-01-09 17:12:45 UTC ---
we put the remapped block in line_table:
#0 0x000000000101d8cf in get_combined_adhoc_loc (set=0x7ffff7ffc000,
locus=968541695, data=0x7fffe8d6fe60)
at /export/gnu/import/git/gcc/libcpp/line-map.c:146
#1 0x00000000009f839d in gimple_set_block (g=0x7fffe8d759b0,
block=0x7fffe8d6fe60) at /export/gnu/import/git/gcc/gcc/gimple.h:1226
#2 0x0000000000a016fd in remap_gimple_stmt (stmt=0x7fffe910e0a0,
id=0x7fffffffd900) at /export/gnu/import/git/gcc/gcc/tree-inline.c:1473
#3 0x0000000000a01a04 in copy_bb (id=0x7fffffffd900, bb=0x7fffe910c888,
frequency_scale=1000000, count_scale=1779)
at /export/gnu/import/git/gcc/gcc/tree-inline.c:1539
#4 0x0000000000a03f56 in copy_cfg_body (id=0x7fffffffd900, count=48912247,
frequency_scale=1000000, entry_block_map=0x7ffff138aaf8,
exit_block_map=0x7fffe8d58270, blocks_to_copy=0x0, new_entry=0x0)
at /export/gnu/import/git/gcc/gcc/tree-inline.c:2259
#5 0x0000000000a047fa in copy_body (id=0x7fffffffd900, count=48912247,
frequency_scale=1000000, entry_block_map=0x7ffff138aaf8,
exit_block_map=0x7fffe8d58270, blocks_to_copy=0x0, new_entry=0x0)
at /export/gnu/import/git/gcc/gcc/tree-inline.c:2457
#6 0x0000000000a0881e in expand_call_inline (bb=0x7ffff138aaf8,
stmt=0x7ffff1390980, id=0x7fffffffd900)
at /export/gnu/import/git/gcc/gcc/tree-inline.c:4041
#7 0x0000000000a08c6f in gimple_expand_calls_inline (bb=0x7ffff138aaf8,
id=0x7fffffffd900) at /export/gnu/import/git/gcc/gcc/tree-inline.c:4147
But tree node in line_table is ignored by GC.
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (19 preceding siblings ...)
2013-01-09 17:13 ` hjl.tools at gmail dot com
@ 2013-01-09 18:22 ` rguenth at gcc dot gnu.org
2013-01-09 18:38 ` hjl.tools at gmail dot com
` (15 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-01-09 18:22 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-09 18:20:32 UTC ---
(In reply to comment #19)
> The BLOCK tree node is cleared by
>
> (gdb) bt
> #0 0x000000336b4882ee in __memset_sse2 () from /lib64/libc.so.6
> #1 0x0000000000545fdf in clear_marks ()
> at /export/gnu/import/git/gcc/gcc/ggc-page.c:1815
> #2 0x0000000000546621 in ggc_collect ()
> at /export/gnu/import/git/gcc/gcc/ggc-page.c:2086
> #3 0x00000000008ad816 in execute_todo (flags=2102)
> at /export/gnu/import/git/gcc/gcc/passes.c:2023
> #4 0x00000000008ae175 in execute_one_pass (pass=0x17b9c70)
> at /export/gnu/import/git/gcc/gcc/passes.c:2349
> #5 0x00000000008ae2da in execute_pass_list (pass=0x17b9c70)
> at /export/gnu/import/git/gcc/gcc/passes.c:2383
> #6 0x00000000008ae30b in execute_pass_list (
> pass=0x16d07e0 <pass_all_optimizations>)
> at /export/gnu/import/git/gcc/gcc/passes.c:2384
> #7 0x00000000005da366 in expand_function (node=0x7ffff16f5378)
> at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641
> #8 0x00000000005da821 in expand_all_functions ()
> at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745
> #9 0x00000000005db2ab in compile ()
> at /export/gnu/import/git/gcc/gcc/cgraphunit.c:2043
> #10 0x000000000053c60a in lto_main ()
> at /export/gnu/import/git/gcc/gcc/lto/lto.c:3390
> #11 0x0000000000999401 in compile_file ()
> ---Type <return> to continue, or q <return> to quit---
> at /export/gnu/import/git/gcc/gcc/toplev.c:545
> #12 0x000000000099b3e4 in do_compile ()
> at /export/gnu/import/git/gcc/gcc/toplev.c:1878
> #13 0x000000000099b54f in toplev_main (argc=28, argv=0x7fffffffdc78)
> at /export/gnu/import/git/gcc/gcc/toplev.c:1954
> #14 0x0000000000fff958 in main (argc=28, argv=0x7fffffffdc78)
> at /export/gnu/import/git/gcc/gcc/main.c:36
> (gdb)
>
> When we remap a block:
> static void
> remap_block (tree *block, copy_body_data *id)
> {
> tree old_block;
> tree new_block;
>
> /* Make the new block. */
> old_block = *block;
> new_block = make_node (BLOCK);
> TREE_USED (new_block) = TREE_USED (old_block);
> BLOCK_ABSTRACT_ORIGIN (new_block) = old_block;
> BLOCK_SOURCE_LOCATION (new_block) = BLOCK_SOURCE_LOCATION (old_block);
> BLOCK_NONLOCALIZED_VARS (new_block)
> = vec_safe_copy (BLOCK_NONLOCALIZED_VARS (old_block));
> *block = new_block;
>
> /* Remap its variables. */
> BLOCK_VARS (new_block) = remap_decls (BLOCK_VARS (old_block),
> &BLOCK_NONLOCALIZED_VARS (new_block),
> id);
>
> we didn't register it with GC root.
Remapped blocks are supposed to be linked into the BLOCK tree of the
destination. What's the backtrace of this remap_block?
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (20 preceding siblings ...)
2013-01-09 18:22 ` rguenth at gcc dot gnu.org
@ 2013-01-09 18:38 ` hjl.tools at gmail dot com
2013-01-09 22:52 ` hjl.tools at gmail dot com
` (14 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: hjl.tools at gmail dot com @ 2013-01-09 18:38 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #22 from H.J. Lu <hjl.tools at gmail dot com> 2013-01-09 18:37:10 UTC ---
(In reply to comment #21)
> Remapped blocks are supposed to be linked into the BLOCK tree of the
It didn't happen.
> destination. What's the backtrace of this remap_block?
Breakpoint 5, remap_block (block=0x7fffffffd580, id=0x7fffffffd900)
at /export/gnu/import/git/gcc/gcc/tree-inline.c:624
624 BLOCK_VARS (new_block) = remap_decls (BLOCK_VARS (old_block),
(gdb) bt
#0 remap_block (block=0x7fffffffd580, id=0x7fffffffd900)
at /export/gnu/import/git/gcc/gcc/tree-inline.c:624
#1 0x00000000009fe52a in remap_blocks (block=0x7fffe9107550,
id=0x7fffffffd900) at /export/gnu/import/git/gcc/gcc/tree-inline.c:645
#2 0x00000000009fe586 in remap_blocks (block=0x7fffe9107500,
id=0x7fffffffd900) at /export/gnu/import/git/gcc/gcc/tree-inline.c:648
#3 0x00000000009fe586 in remap_blocks (block=0x7fffe91074b0,
id=0x7fffffffd900) at /export/gnu/import/git/gcc/gcc/tree-inline.c:648
#4 0x00000000009fe586 in remap_blocks (block=0x7fffe9107460,
id=0x7fffffffd900) at /export/gnu/import/git/gcc/gcc/tree-inline.c:648
#5 0x00000000009fe586 in remap_blocks (block=0x7fffe9107410,
id=0x7fffffffd900) at /export/gnu/import/git/gcc/gcc/tree-inline.c:648
#6 0x0000000000a082fc in expand_call_inline (bb=0x7ffff138aaf8,
stmt=0x7ffff1390980, id=0x7fffffffd900)
at /export/gnu/import/git/gcc/gcc/tree-inline.c:3958
#7 0x0000000000a08c6f in gimple_expand_calls_inline (bb=0x7ffff138aaf8,
id=0x7fffffffd900) at /export/gnu/import/git/gcc/gcc/tree-inline.c:4147
#8 0x0000000000a0924b in optimize_inline_calls (fn=0x7fffec94b300)
at /export/gnu/import/git/gcc/gcc/tree-inline.c:4301
#9 0x00000000007d2f1e in inline_transform (node=0x7ffff17536f0)
at /export/gnu/import/git/gcc/gcc/ipa-inline-transform.c:418
#10 0x00000000008adbe3 in execute_one_ipa_transform_pass (node=0x7ffff17536f0,
ipa_pass=0x16cfc80 <pass_ipa_inline>)
---Type <return> to continue, or q <return> to quit---
at /export/gnu/import/git/gcc/gcc/passes.c:2177
#11 0x00000000008add31 in execute_all_ipa_transforms ()
at /export/gnu/import/git/gcc/gcc/passes.c:2213
#12 0x00000000005da348 in expand_function (node=0x7ffff17536f0)
at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1634
#13 0x00000000005da821 in expand_all_functions ()
at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745
#14 0x00000000005db2ab in compile ()
at /export/gnu/import/git/gcc/gcc/cgraphunit.c:2043
#15 0x000000000053c60a in lto_main ()
at /export/gnu/import/git/gcc/gcc/lto/lto.c:3390
#16 0x0000000000999401 in compile_file ()
at /export/gnu/import/git/gcc/gcc/toplev.c:545
#17 0x000000000099b3e4 in do_compile ()
at /export/gnu/import/git/gcc/gcc/toplev.c:1878
#18 0x000000000099b54f in toplev_main (argc=28, argv=0x7fffffffdc78)
at /export/gnu/import/git/gcc/gcc/toplev.c:1954
#19 0x0000000000fff958 in main (argc=28, argv=0x7fffffffdc78)
at /export/gnu/import/git/gcc/gcc/main.c:36
(gdb)
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (21 preceding siblings ...)
2013-01-09 18:38 ` hjl.tools at gmail dot com
@ 2013-01-09 22:52 ` hjl.tools at gmail dot com
2013-01-10 11:30 ` rguenth at gcc dot gnu.org
` (13 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: hjl.tools at gmail dot com @ 2013-01-09 22:52 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #23 from H.J. Lu <hjl.tools at gmail dot com> 2013-01-09 22:51:36 UTC ---
The old BLOCK came from
(gdb) bt
#0 remap_block (block=0x7fffffffd690, id=0x7fffffffd840) at
/export/gnu/import/git/gcc/gcc/tree-inline.c:624
#1 0x00000000009fe52a in remap_blocks (block=0x7ffff1393d20,
id=0x7fffffffd840)
at /export/gnu/import/git/gcc/gcc/tree-inline.c:645
#2 0x00000000009fe586 in remap_blocks (block=0x7ffff1385370,
id=0x7fffffffd840)
at /export/gnu/import/git/gcc/gcc/tree-inline.c:648
#3 0x00000000009fe586 in remap_blocks (block=0x7ffff1385320,
id=0x7fffffffd840)
at /export/gnu/import/git/gcc/gcc/tree-inline.c:648
---Type <return> to continue, or q <return> to quit---
#4 0x00000000009fe586 in remap_blocks (block=0x7ffff1385280,
id=0x7fffffffd840)
at /export/gnu/import/git/gcc/gcc/tree-inline.c:648
#5 0x00000000009fe586 in remap_blocks (block=0x7ffff13851e0,
id=0x7fffffffd840)
at /export/gnu/import/git/gcc/gcc/tree-inline.c:648
#6 0x0000000000a0bc63 in tree_function_versioning (old_decl=0x7fffec94b400,
new_decl=0x7fffe9105000, tree_map=0x0,
update_clones=true, args_to_skip=0x0, skip_return=false,
blocks_to_copy=0x0, new_entry=0x0)
at /export/gnu/import/git/gcc/gcc/tree-inline.c:5225
---Type <return> to continue, or q <return> to quit---
#7 0x00000000007d2d05 in save_inline_function_body (node=0x7ffff1753818)
at /export/gnu/import/git/gcc/gcc/ipa-inline-transform.c:354
#8 0x00000000007d2ec6 in inline_transform (node=0x7ffff1753818) at
/export/gnu/import/git/gcc/gcc/ipa-inline-transform.c:411
#9 0x00000000008adbe3 in execute_one_ipa_transform_pass (node=0x7ffff1753818,
ipa_pass=0x16cfc80 <pass_ipa_inline>)
at /export/gnu/import/git/gcc/gcc/passes.c:2177
#10 0x00000000008add31 in execute_all_ipa_transforms () at
/export/gnu/import/git/gcc/gcc/passes.c:2213
#11 0x00000000005da348 in expand_function (node=0x7ffff1753818) at
/export/gnu/import/git/gcc/gcc/cgraphunit.c:1634
---Type <return> to continue, or q <return> to quit---
#12 0x00000000005da821 in expand_all_functions () at
/export/gnu/import/git/gcc/gcc/cgraphunit.c:1745
#13 0x00000000005db2ab in compile () at
/export/gnu/import/git/gcc/gcc/cgraphunit.c:2043
#14 0x000000000053c60a in lto_main () at
/export/gnu/import/git/gcc/gcc/lto/lto.c:3390
#15 0x0000000000999401 in compile_file () at
/export/gnu/import/git/gcc/gcc/toplev.c:545
#16 0x000000000099b3e4 in do_compile () at
/export/gnu/import/git/gcc/gcc/toplev.c:1878
#17 0x000000000099b54f in toplev_main (argc=28, argv=0x7fffffffdc78) at
/export/gnu/import/git/gcc/gcc/toplev.c:1954
#18 0x0000000000fff958 in main (argc=28, argv=0x7fffffffdc78) at
/export/gnu/import/git/gcc/gcc/main.c:36
(gdb) p id->block
$90 = (tree) 0x0
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (22 preceding siblings ...)
2013-01-09 22:52 ` hjl.tools at gmail dot com
@ 2013-01-10 11:30 ` rguenth at gcc dot gnu.org
2013-01-10 12:16 ` rguenth at gcc dot gnu.org
` (12 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-01-10 11:30 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
--- Comment #24 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-10 11:29:16 UTC ---
Created attachment 29139
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29139
patch to verify locations as LTO expects them
This verifies that all stmts locations (missing expr locations) have a BLOCK
that is in the functions BLOCK tree (_not_ counting abstract origins, as LTO
does not stream the abstract part of the BLOCK tree!). It fires on trivial
inlining testcases which means that LTO will end up with the issue you
are seeing.
Ugh. Investigating.
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (23 preceding siblings ...)
2013-01-10 11:30 ` rguenth at gcc dot gnu.org
@ 2013-01-10 12:16 ` rguenth at gcc dot gnu.org
2013-01-10 13:43 ` rguenth at gcc dot gnu.org
` (11 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-01-10 12:16 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #29139|0 |1
is obsolete| |
--- Comment #25 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-10 12:15:41 UTC ---
Created attachment 29140
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29140
updated patch with fixes
Fix for virtual operands (shouldn't be relevant for LTO). My guess would still
be IPA opts, so can you check if it triggers? I'm doing regular bootstrap /
testing and will commit the virtuals fix independently.
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (24 preceding siblings ...)
2013-01-10 12:16 ` rguenth at gcc dot gnu.org
@ 2013-01-10 13:43 ` rguenth at gcc dot gnu.org
2013-01-10 14:08 ` rguenth at gcc dot gnu.org
` (10 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-01-10 13:43 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #26 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-10 13:42:33 UTC ---
Author: rguenth
Date: Thu Jan 10 13:42:27 2013
New Revision: 195084
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195084
Log:
2013-01-10 Richard Biener <rguenther@suse.de>
PR bootstrap/55792
* tree-into-ssa.c (rewrite_add_phi_arguments): Do not set
locations for virtual PHI arguments.
(rewrite_update_phi_arguments): Likewise.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-into-ssa.c
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (25 preceding siblings ...)
2013-01-10 13:43 ` rguenth at gcc dot gnu.org
@ 2013-01-10 14:08 ` rguenth at gcc dot gnu.org
2013-01-10 14:12 ` rguenth at gcc dot gnu.org
` (9 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-01-10 14:08 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #29140|0 |1
is obsolete| |
--- Comment #27 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-10 14:07:55 UTC ---
Created attachment 29141
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29141
updated checker
Also verify expressions. Bootstrapped ok, target libs building now, testing
pending.
I'll give it a LTO profiledbootstrap try as well ... if that's not it then
the issue must be elsewhere :(
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (26 preceding siblings ...)
2013-01-10 14:08 ` rguenth at gcc dot gnu.org
@ 2013-01-10 14:12 ` rguenth at gcc dot gnu.org
2013-01-10 15:29 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-01-10 14:12 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #28 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-10 14:11:43 UTC ---
Another possibility lies in DEBUG stmts which we do not consider at all ...
(in the checker, that is).
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (27 preceding siblings ...)
2013-01-10 14:12 ` rguenth at gcc dot gnu.org
@ 2013-01-10 15:29 ` rguenth at gcc dot gnu.org
2013-01-10 15:35 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-01-10 15:29 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #29 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-10 15:28:38 UTC ---
(In reply to comment #27)
> Created attachment 29141 [details]
> updated checker
>
> Also verify expressions. Bootstrapped ok, target libs building now, testing
> pending.
>
> I'll give it a LTO profiledbootstrap try as well ... if that's not it then
> the issue must be elsewhere :(
Besides a few fortran ICEs in the testsuite a regular bootstrap and regtest
went ok with this version.
The Fortran fronted has ADDR_EXPRs of FUNCTION_DECLs which have a location
with bogus BLOCK.
FAIL: gfortran.dg/class_array_15.f03 -O0 (internal compiler error)
FAIL: gfortran.dg/class_array_15.f03 -O0 (test for excess errors)
WARNING: gfortran.dg/class_array_15.f03 -O0 compilation failed to produce
exec
utable
FAIL: gfortran.dg/typebound_operator_13.f03 -O0 (internal compiler error)
FAIL: gfortran.dg/typebound_operator_13.f03 -O0 (test for excess errors)
WARNING: gfortran.dg/typebound_operator_13.f03 -O0 compilation failed to
produ
ce executable
FAIL: gfortran.dg/typebound_operator_7.f03 -O0 (internal compiler error)
FAIL: gfortran.dg/typebound_operator_7.f03 -O0 (test for excess errors)
WARNING: gfortran.dg/typebound_operator_7.f03 -O0 compilation failed to
produc
e executable
FAIL: gfortran.dg/typebound_operator_8.f03 -O0 (internal compiler error)
FAIL: gfortran.dg/typebound_operator_8.f03 -O0 (test for excess errors)
WARNING: gfortran.dg/typebound_operator_8.f03 -O0 compilation failed to
produc
e executable
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (28 preceding siblings ...)
2013-01-10 15:29 ` rguenth at gcc dot gnu.org
@ 2013-01-10 15:35 ` rguenth at gcc dot gnu.org
2013-01-10 17:03 ` hjl.tools at gmail dot com
` (6 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-01-10 15:35 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #30 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-10 15:34:39 UTC ---
LTO profiled-bootstrap revals:
/space/rguenther/src/svn/trunk/gcc/reginfo.c: In function 'reg_scan':
/space/rguenther/src/svn/trunk/gcc/reginfo.c:1015:0: error: location references
block not in block tree
reg_scan (rtx f, unsigned int nregs ATTRIBUTE_UNUSED)
^
"ee"
fmt_351 = "ee";
/space/rguenther/src/svn/trunk/gcc/reginfo.c:1015:0: internal compiler error:
verify_gimple failed
this is a &STRING_CST node. Needs to be tracked down ... more IPA stuff needs
to use copy_tree_without_location.
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (29 preceding siblings ...)
2013-01-10 15:35 ` rguenth at gcc dot gnu.org
@ 2013-01-10 17:03 ` hjl.tools at gmail dot com
2013-01-10 19:36 ` hjl.tools at gmail dot com
` (5 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: hjl.tools at gmail dot com @ 2013-01-10 17:03 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #31 from H.J. Lu <hjl.tools at gmail dot com> 2013-01-10 17:03:13 UTC ---
(In reply to comment #30)
> LTO profiled-bootstrap revals:
>
> /space/rguenther/src/svn/trunk/gcc/reginfo.c: In function 'reg_scan':
> /space/rguenther/src/svn/trunk/gcc/reginfo.c:1015:0: error: location references
> block not in block tree
> reg_scan (rtx f, unsigned int nregs ATTRIBUTE_UNUSED)
> ^
> "ee"
> fmt_351 = "ee";
This is the same problem in comment #13:
In file included from :4457:0:
/export/gnu/import/git/gcc/gcc/reginfo.c: In function ‘reg_scan’:
/export/gnu/import/git/gcc/gcc/reginfo.c:1015:0: error: location references
block not in block tree
reg_scan (rtx f, unsigned int nregs ATTRIBUTE_UNUSED)
^
"ee"
fmt_388 = "ee";
/export/gnu/import/git/gcc/gcc/reginfo.c:1015:0: internal compiler error:
verify_gimple failed
0x9c7dc8 verify_gimple_in_cfg(function*)
/export/gnu/import/git/gcc/gcc/tree-cfg.c:4726
0x8ad9e0 execute_function_todo
/export/gnu/import/git/gcc/gcc/passes.c:1968
0x8acd04 do_per_function
/export/gnu/import/git/gcc/gcc/passes.c:1703
0x8adb04 execute_todo
/export/gnu/import/git/gcc/gcc/passes.c:2001
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (30 preceding siblings ...)
2013-01-10 17:03 ` hjl.tools at gmail dot com
@ 2013-01-10 19:36 ` hjl.tools at gmail dot com
2013-01-11 17:37 ` hubicka at ucw dot cz
` (4 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: hjl.tools at gmail dot com @ 2013-01-10 19:36 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #32 from H.J. Lu <hjl.tools at gmail dot com> 2013-01-10 19:36:08 UTC ---
(In reply to comment #30)
> LTO profiled-bootstrap revals:
>
> /space/rguenther/src/svn/trunk/gcc/reginfo.c: In function 'reg_scan':
> /space/rguenther/src/svn/trunk/gcc/reginfo.c:1015:0: error: location references
> block not in block tree
> reg_scan (rtx f, unsigned int nregs ATTRIBUTE_UNUSED)
> ^
> "ee"
> fmt_351 = "ee";
>
> /space/rguenther/src/svn/trunk/gcc/reginfo.c:1015:0: internal compiler error:
> verify_gimple failed
>
> this is a &STRING_CST node. Needs to be tracked down ... more IPA stuff needs
> to use copy_tree_without_location.
I think this BLOCK comes from LTO streamer.
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (31 preceding siblings ...)
2013-01-10 19:36 ` hjl.tools at gmail dot com
@ 2013-01-11 17:37 ` hubicka at ucw dot cz
2013-01-14 13:43 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: hubicka at ucw dot cz @ 2013-01-11 17:37 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #33 from Jan Hubicka <hubicka at ucw dot cz> 2013-01-11 17:36:48 UTC ---
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
>
> --- Comment #32 from H.J. Lu <hjl.tools at gmail dot com> 2013-01-10 19:36:08 UTC ---
> (In reply to comment #30)
> > LTO profiled-bootstrap revals:
> >
> > /space/rguenther/src/svn/trunk/gcc/reginfo.c: In function 'reg_scan':
> > /space/rguenther/src/svn/trunk/gcc/reginfo.c:1015:0: error: location references
> > block not in block tree
> > reg_scan (rtx f, unsigned int nregs ATTRIBUTE_UNUSED)
> > ^
> > "ee"
> > fmt_351 = "ee";
> >
> > /space/rguenther/src/svn/trunk/gcc/reginfo.c:1015:0: internal compiler error:
> > verify_gimple failed
> >
> > this is a &STRING_CST node. Needs to be tracked down ... more IPA stuff needs
> > to use copy_tree_without_location.
>
> I think this BLOCK comes from LTO streamer.
I guess we could add assert to lto streamer to not read any local blocks during
WPA. I will try that.
Honza
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (32 preceding siblings ...)
2013-01-11 17:37 ` hubicka at ucw dot cz
@ 2013-01-14 13:43 ` rguenth at gcc dot gnu.org
2013-01-14 13:50 ` rguenth at gcc dot gnu.org
` (2 subsequent siblings)
36 siblings, 0 replies; 38+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-01-14 13:43 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #34 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-14 13:42:36 UTC ---
static void
output_node_opt_summary (struct output_block *ob,
struct cgraph_node *node,
lto_symtab_encoder_t encoder)
{
...
gcc_assert (EXPR_LOCATION (map->new_tree) == UNKNOWN_LOCATION);
isn't recursively checking EXPR_LOCATION.
Index: gcc/lto-cgraph.c
===================================================================
--- gcc/lto-cgraph.c (revision 195144)
+++ gcc/lto-cgraph.c (working copy)
@@ -1492,6 +1492,22 @@ output_edge_opt_summary (struct output_b
{
}
+static tree
+verify_no_location (tree *tp, int *walk_subtrees, void *)
+{
+ if (EXPR_P (*tp))
+ gcc_assert (EXPR_LOCATION (*tp) == UNKNOWN_LOCATION);
+ else
+ *walk_subtrees = 0;
+ return NULL_TREE;
+}
+
+static void
+verify_no_location (tree expr)
+{
+ walk_tree (&expr, verify_no_location_r, NULL, NULL);
+}
+
/* Output optimization summary for NODE to OB. */
static void
@@ -1536,7 +1552,9 @@ output_node_opt_summary (struct output_b
mechanism to store function local declarations into summaries. */
gcc_assert (parm);
streamer_write_uhwi (ob, parm_num);
- gcc_assert (EXPR_LOCATION (map->new_tree) == UNKNOWN_LOCATION);
+#ifdef ENABLE_CHECKING
+ verify_no_location (map->new_tree);
+#endif
stream_write_tree (ob, map->new_tree, true);
bp = bitpack_create (ob->main_stream);
bp_pack_value (&bp, map->replace_p, 1);
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (33 preceding siblings ...)
2013-01-14 13:43 ` rguenth at gcc dot gnu.org
@ 2013-01-14 13:50 ` rguenth at gcc dot gnu.org
2013-01-14 13:51 ` rguenth at gcc dot gnu.org
2013-01-15 14:32 ` rguenth at gcc dot gnu.org
36 siblings, 0 replies; 38+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-01-14 13:50 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #35 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-14 13:48:47 UTC ---
And the following may fix it at a single central place.
Index: gcc/tree-inline.c
===================================================================
--- gcc/tree-inline.c (revision 195144)
+++ gcc/tree-inline.c (working copy)
@@ -2563,11 +2563,11 @@ setup_one_parameter (copy_body_data *id,
basic_block bb, tree *vars)
{
gimple init_stmt = NULL;
- tree var;
- tree rhs = value;
+ tree var, rhs;
tree def = (gimple_in_ssa_p (cfun)
? ssa_default_def (id->src_cfun, p) : NULL);
+ rhs = value = unshare_expr_without_location (value);
if (value
&& value != error_mark_node
&& !useless_type_conversion_p (TREE_TYPE (p), TREE_TYPE (value)))
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (34 preceding siblings ...)
2013-01-14 13:50 ` rguenth at gcc dot gnu.org
@ 2013-01-14 13:51 ` rguenth at gcc dot gnu.org
2013-01-15 14:32 ` rguenth at gcc dot gnu.org
36 siblings, 0 replies; 38+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-01-14 13:51 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #36 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-14 13:50:49 UTC ---
Or more conservative, dropping less locations:
Index: gcc/tree-inline.c
===================================================================
--- gcc/tree-inline.c (revision 195144)
+++ gcc/tree-inline.c (working copy)
@@ -5190,7 +5190,7 @@ tree_function_versioning (tree old_decl,
replace_info = (*tree_map)[i];
if (replace_info->replace_p)
{
- tree op = replace_info->new_tree;
+ tree op = unshare_expr_without_location (replace_info->new_tree);
if (!replace_info->old_tree)
{
int i = replace_info->parm_num;
@@ -5199,18 +5199,10 @@ tree_function_versioning (tree old_decl,
i --;
replace_info->old_tree = parm;
}
-
-
- STRIP_NOPS (op);
-
- if (TREE_CODE (op) == VIEW_CONVERT_EXPR)
- op = TREE_OPERAND (op, 0);
-
gcc_assert (TREE_CODE (replace_info->old_tree) == PARM_DECL);
+
init = setup_one_parameter (&id, replace_info->old_tree,
- replace_info->new_tree, id.src_fn,
- NULL,
- &vars);
+ op, id.src_fn, NULL, &vars);
if (init)
init_stmts.safe_push (init);
}
^ permalink raw reply [flat|nested] 38+ messages in thread* [Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
2012-12-22 18:05 [Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO hjl.tools at gmail dot com
` (35 preceding siblings ...)
2013-01-14 13:51 ` rguenth at gcc dot gnu.org
@ 2013-01-15 14:32 ` rguenth at gcc dot gnu.org
36 siblings, 0 replies; 38+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-01-15 14:32 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #37 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-15 14:31:39 UTC ---
According to gcc-regression this issue has fixed itself by whatever patch.
Double-checked with a pristine trunk LTO profiledbootstrap.
^ permalink raw reply [flat|nested] 38+ messages in thread