[Bug lto/55466] [4.8 Regression] Revision 191466 destroyed DWARF debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55466 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-11-26 16:36:10 UTC --- (In reply to comment #2) Hmm, I suppose this is because we no longer merge symbols that are not part of symtab, but used only for debugging Honza global_options is certainly used. Aggressively removing unused vars is ok even if that drops debug info for them. We lost debug info on most, if not all, used data variables. It seems that their type infos are also gone. We can't tell extern int *foo; from extern int foo[];
[Bug lto/55474] New: global-buffer-overflow in lto-wrapper.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55474 Bug #: 55474 Summary: global-buffer-overflow in lto-wrapper.c Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86-64, hjl/asan branch configured with --with-build-config=bootstrap-asan reports: [hjl@gnu-mic-1 gcc]$ /export/build/gnu/gcc-x32-mx32-asan/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc-x32-mx32-asan/build-x86_64-linux/gcc/ /export/gnu/import/git/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/20010124-1.c /export/gnu/import/git/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/20010124-1-lib.c /export/gnu/import/git/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c -fno-diagnostics-show-caret -w -O2 -flto -fno-use-linker-plugin -flto-partition=none -fno-tree-loop-distribute-patterns -lm = ==22576== ERROR: AddressSanitizer: global-buffer-overflow on address 0x004d24c4 at pc 0x405ac6 bp 0xca30 sp 0xca2c READ of size 4 at 0x004d24c4 thread T0 #0 0x405ac5 (/export/build/gnu/gcc-x32-mx32-asan/build-x86_64-linux/gcc/lto-wrapper+0x405ac5) 0x004d24c4 is located 28 bytes to the left of global variable 'global_options_init (options.c)' (0x4d24e0) of size 2440 0x004d24c4 is located 24 bytes to the right of global variable 'lang_names (options.c)' (0x4d2480) of size 44 Shadow byte and word: 0x2009a498: f9 0x2009a498: f9 f9 f9 f9 More shadow bytes: 0x2009a488: 04 f9 f9 f9 0x2009a48c: f9 f9 f9 f9 0x2009a490: 00 00 00 00 0x2009a494: 00 04 f9 f9 =0x2009a498: f9 f9 f9 f9 0x2009a49c: 00 00 00 00 0x2009a4a0: 00 00 00 00 0x2009a4a4: 00 00 00 00 0x2009a4a8: 00 00 00 00 Stats: 0M malloced (0M for red zones) by 142 calls Stats: 0M realloced by 4 calls Stats: 0M freed by 44 calls Stats: 0M really freed by 0 calls Stats: 3M (898 full pages) mmaped in 7 calls mmaps by size class: 7:4095; 8:2047; 9:1023; 10:511; 11:255; 12:128; 13:64; mallocs by size class: 7:103; 8:12; 9:12; 10:8; 11:1; 12:1; 13:5; frees by size class: 7:27; 8:2; 9:6; 10:5; 11:1; 13:3; rfrees by size class: Stats: malloc large: 0 small slow: 8 ==22576== ABORTING collect2: error: lto-wrapper returned 1 exit status [hjl@gnu-mic-1 gcc]$ addr2line -e /export/build/gnu/gcc-x32-mx32-asan/build-x86_64-linux/gcc/lto-wrapper 0x405ac5 /export/gnu/import/git/gcc/gcc/lto-wrapper.c:397 [hjl@gnu-mic-1 gcc]$
[Bug fortran/55475] New: heap-buffer-overflow in fortran/error.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55475 Bug #: 55475 Summary: heap-buffer-overflow in fortran/error.c Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com [hjl@gnu-mic-1 gfortran]$ /export/build/gnu/gcc-x32-mx32-asan/build-x86_64-linux/gcc/testsuite/gfortran6/../../gfortran -B/export/build/gnu/gcc-x32-mx32-asan/build-x86_64-linux/gcc/testsuite/gfortran6/../../ -B/export/build/gnu/gcc-x32-mx32-asan/build-x86_64-linux/x86_64-unknown-linux-gnu/./libgfortran/ /export/gnu/import/git/gcc/gcc/testsuite/gfortran.dg/line_length_4.f90 -fno-diagnostics-show-caret -O -Wline-truncation -ffree-line-length-80 -S -mx32 -o line_length_4.s /export/gnu/import/git/gcc/gcc/testsuite/gfortran.dg/line_length_4.f90:8.85: 25 ), Explanation ! = ==18910== ERROR: AddressSanitizer: heap-buffer-overflow on address 0xf6820398 at pc 0x583c85 bp 0x9ed0 sp 0x9ecc READ of size 4 at 0xf6820398 thread T0 #0 0x583c84 (/export/build/gnu/gcc-x32-mx32-asan/build-x86_64-linux/gcc/f951+0x583c84) 0xf6820398 is located 0 bytes to the right of 344-byte region [0xf6820240,0xf6820398) allocated by thread T0 here: #0 0x24ae2dc (/export/build/gnu/gcc-x32-mx32-asan/build-x86_64-linux/gcc/f951+0x24ae2dc) #1 0x24a2c63 (/export/build/gnu/gcc-x32-mx32-asan/build-x86_64-linux/gcc/f951+0x24a2c63) Shadow byte and word: 0x3ed04073: fb 0x3ed04070: 00 00 00 fb More shadow bytes: 0x3ed04060: 00 00 00 00 0x3ed04064: 00 00 00 00 0x3ed04068: 00 00 00 00 0x3ed0406c: 00 00 00 00 =0x3ed04070: 00 00 00 fb 0x3ed04074: fb fb fb fb 0x3ed04078: fa fa fa fa 0x3ed0407c: fa fa fa fa 0x3ed04080: fa fa fa fa Stats: 0M malloced (0M for red zones) by 3129 calls Stats: 0M realloced by 312 calls Stats: 0M freed by 961 calls Stats: 0M really freed by 0 calls Stats: 5M (1285 full pages) mmaped in 10 calls mmaps by size class: 7:4095; 8:2047; 9:1023; 10:511; 11:255; 12:128; 13:64; 14:32; 15:16; 17:4; mallocs by size class: 7:2646; 8:171; 9:77; 10:138; 11:81; 12:4; 13:7; 14:1; 15:2; 17:2; frees by size class: 7:688; 8:62; 9:68; 10:132; 11:9; 12:1; 13:1; rfrees by size class: Stats: malloc large: 4 small slow: 30 ==18910== ABORTING[hjl@gnu-mic-1 gfortran]$ addr2line -e ../../f951 0x583c84 /export/gnu/import/git/gcc/gcc/fortran/error.c:393 [hjl@gnu-mic-1 gfortran]$
[Bug ada/55485] New: stack-buffer-overflow in sem_ch8.adb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55485 Bug #: 55485 Summary: stack-buffer-overflow in sem_ch8.adb Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86-64, hjl/asan branch gives: /export/build/gnu/gcc-asan/build-x86_64-linux/./gcc/xgcc -B/export/build/gnu/gcc-asan/build-x86_64-linux/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include-c -g -O2 -fpic -W -Wall -gnatpg -nostdinc s-auxdec.adb -o s-auxdec.o ==2916== ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff47f1b588 at pc 0xb6e8f4 bp 0x7fff47f1b4e0 sp 0x7fff47f1b4d8 WRITE of size 4 at 0x7fff47f1b588 thread T0 #0 0xb6e8f3 (/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/gnat1+0xb6e8f3) Address 0x7fff47f1b588 is located at offset 72 in frame ada__exceptions__raise_current_excep of T0's stack: This frame has 1 object(s): [32, 40) 'id' HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) Shadow byte and word: 0x1fffe8fe36b1: f3 0x1fffe8fe36b0: f3 f3 f3 f3 00 00 00 00 More shadow bytes: 0x1fffe8fe3690: 00 00 00 00 00 00 00 00 0x1fffe8fe3698: 00 00 00 00 00 00 00 00 0x1fffe8fe36a0: 00 00 00 00 00 00 00 00 0x1fffe8fe36a8: f1 f1 f1 f1 00 f4 f4 f4 =0x1fffe8fe36b0: f3 f3 f3 f3 00 00 00 00 0x1fffe8fe36b8: 00 00 00 00 00 00 00 00 0x1fffe8fe36c0: 00 00 00 00 00 00 00 00 0x1fffe8fe36c8: 00 00 00 00 00 00 00 00 0x1fffe8fe36d0: 00 00 00 00 00 00 00 00 Stats: 4M malloced (2M for red zones) by 2930 calls Stats: 0M realloced by 258 calls Stats: 0M freed by 567 calls Stats: 0M really freed by 0 calls Stats: 9M (2443 full pages) mmaped in 16 calls mmaps by size class: 7:4095; 8:2047; 9:1023; 10:511; 11:255; 12:128; 13:64; 14:32; 15:16; 16:8; 17:4; 18:6; 19:1; 21:1; mallocs by size class: 7:1785; 8:688; 9:53; 10:88; 11:226; 12:35; 13:17; 14:14; 15:6; 16:7; 17:3; 18:6; 19:1; 21:1; frees by size class: 7:267; 8:52; 9:32; 10:67; 11:131; 12:16; 13:1; 14:1; rfrees by size class: Stats: malloc large: 24 small slow: 49 ==2916== ABORTING make[9]: *** [s-auxdec.o] Error 1 [hjl@gnu-mic-2 ~]$ addr2line -e /export/build/gnu/gcc-asan/build-x86_64-linux/gcc/gnat1 0xb6e8f3 /export/gnu/import/git/gcc/gcc/ada/sem_ch8.adb:4038 [hjl@gnu-mic-2 ~]$
[Bug middle-end/55496] New: False positive -Werror=uninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55496 Bug #: 55496 Summary: False positive -Werror=uninitialized Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86-64, revision 193864 configured with --prefix=/usr/4.8.0 --enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld --with-build-config=bootstrap-lto --with-fpmath=sse --enable-languages=c,c++,fortran,java,lto,objc and built with make bld profiledbootstrap -j 8 on a 8-core machine gave /export/gnu/import/git/gcc-test-profile/bld/./prev-gcc/g++ -B/export/gnu/import/git/gcc-test-profile/bld/./prev-gcc/ -B/usr/4.8.0/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/export/gnu/import/git/gcc-test-profile/bld/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/export/gnu/import/git/gcc-test-profile/bld/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/export/gnu/import/git/gcc-test-profile/bld/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/export/gnu/import/git/gcc-test-profile/bld/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/export/gnu/import/git/gcc-test-profile/src-trunk/libstdc++-v3/libsupc++ -L/export/gnu/import/git/gcc-test-profile/bld/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/export/gnu/import/git/gcc-test-profile/bld/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c -g -O2 -flto=jobserver -frandom-seed=1 -fprofile-use -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../src-trunk/gcc -I../../src-trunk/gcc/. -I../../src-trunk/gcc/../include -I../../src-trunk/gcc/../libcpp/include -I../../src-trunk/gcc/../libdecnumber -I../../src-trunk/gcc/../libdecnumber/bid -I../libdecnumber -I../../src-trunk/gcc/../libbacktrace ../../src-trunk/gcc/cfg.c -o cfg.o ../../src-trunk/gcc/cfg.c: In function 'scale_bbs_frequencies_gcov_type(basic_block_def**, int, long, long)': ../../src-trunk/gcc/cfg.c:945:8: error: 'e' may be used uninitialized in this function [-Werror=uninitialized] edge e; cc1plus: all warnings being treated as errors make[6]: *** [cfg.o] Error 1 make[6]: *** Waiting for unfinished jobs rm gcj-dbtool.pod jcf-dump.pod jv-convert.pod grmic.pod gcov.pod gcj.pod gc-analyze.pod gfdl.pod cpp.pod gij.pod gfortran.pod gcc.pod fsf-funding.pod make[6]: Leaving directory `/export/gnu/import/git/gcc-test-profile/bld/gcc' make[5]: *** [all-stagefeedback-gcc] Error 2 make[5]: Leaving directory `/export/gnu/import/git/gcc-test-profile/bld' make[4]: *** [stagefeedback-bubble] Error 2 make[4]: Leaving directory `/export/gnu/import/git/gcc-test-profile/bld' make[3]: *** [profiledbootstrap] Error 2 make[3]: Leaving directory `/export/gnu/import/git/gcc-test-profile/bld' 11063.14user 498.20system 41:50.07elapsed 460%CPU (0avgtext+0avgdata 521396maxresident)k 55104inputs+14523280outputs (2major+111666564minor)pagefaults 0swaps make[2]: *** [profiledbootstrap] Error 2
[Bug lto/54795] global-buffer-overflow in lto_write_options
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54795 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|4.8.0 |4.7.3 Resolution||FIXED --- Comment #29 from H.J. Lu hjl.tools at gmail dot com 2012-11-28 14:40:09 UTC --- Fixed for 4.7.3 and 4.8.
[Bug lto/55474] global-buffer-overflow in lto-wrapper.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55474 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.3 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-11-28 14:41:23 UTC --- Fixed for 4.7.3 and 4.8.
[Bug sanitizer/55371] [asan] False -Werror=uninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55371 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-11-28 19:29:25 UTC --- Also /export/gnu/import/git/gcc/libgfortran/intrinsics/unpack_generic.c: In function ‘unpack_internal’: /export/gnu/import/git/gcc/libgfortran/intrinsics/unpack_generic.c:149:12: warning: ‘rstride[0]’ may be used uninitialized in this function [-Wuninitialized] rstride0 = rstride[0]; ^ /export/gnu/import/git/gcc/libgfortran/intrinsics/unpack_generic.c:150:12: warning: ‘fstride[0]’ may be used uninitialized in this function [-Wuninitialized] fstride0 = fstride[0]; ^ /export/gnu/import/git/gcc/libgfortran/intrinsics/unpack_generic.c:151:12: warning: ‘mstride[0]’ may be used uninitialized in this function [-Wuninitialized] mstride0 = mstride[0]; ^
[Bug sanitizer/55519] New: [asan] False positive -Wmaybe-uninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55519 Bug #: 55519 Summary: [asan] False positive -Wmaybe-uninitialized Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: do...@gcc.gnu.org, dvyu...@gcc.gnu.org, ja...@gcc.gnu.org, k...@gcc.gnu.org When -fsanitize=address is used with -O2 -flto=jobserver -frandom-seed=1, I got /export/gnu/import/git/gcc/gcc/tree-ssa-loop-im.c: In function ‘store_motion_loop(loop*, bitmap_head_def*)’: /export/gnu/import/git/gcc/gcc/tree-ssa-loop-im.c:2014:29: warning: ‘store_flag’ may be used uninitialized in this function [-Wmaybe-uninitialized] NULL_TREE, NULL_TREE); ^ /export/gnu/import/git/gcc/gcc/tree-ssa-loop-im.c:2113:17: note: ‘store_flag’ was declared here tree tmp_var, store_flag; /export/gnu/import/git/gcc/gcc/gcc.c: In function ‘do_spec_1(char const*, int, char const*)’: /export/gnu/import/git/gcc/gcc/../include/obstack.h:337:52: warning: ‘save_growing_value’ may be used uninitialized in this function [-Wmaybe-uninitialized] _obstack_memcpy (__o-next_free, (where), __len); \ ^ /export/gnu/import/git/gcc/gcc/gcc.c:5489:9: note: ‘save_growing_value’ was declared here void *save_growing_value;
[Bug lto/55466] [4.8 Regression] Revision 191466 destroyed DWARF debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55466
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-11-28
Ever Confirmed|0 |1
--- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2012-11-28 21:26:30
UTC ---
The problem is in
static void
lto_write_globals (void)
{
tree *vec = lto_global_var_decls-address ();
int len = lto_global_var_decls-length ();
wrapup_global_declarations (vec, len);
emit_debug_global_declarations (vec, len);
vec_free (lto_global_var_decls);
}
LTO no longer maintains its own symbol table and it uses varpool for
variables instead. lto_global_var_decls is almost empty. That
is why debug info on variables is lost.
[Bug lto/55466] [4.8 Regression] Revision 191466 destroyed DWARF debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55466 --- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2012-11-29 19:07:23 UTC --- (In reply to comment #5) Created attachment 28829 [details] Proposed fix I suppose something across these lines should do the trick. I am not sure what exactly is the codition for var to be needed to go through wrapup_global_decl. Also I think types are usually going in there, too. It doesn't work: lto1: internal compiler error: Segmentation fault 0x994661 crash_signal /export/gnu/import/git/gcc/gcc/toplev.c:334 0x5206c8 gt_ggc_mx_lang_tree_node(void*) ./gtype-lto.h:37 0x522623 gt_ggc_mx_lang_tree_node(void*) ./gtype-lto.h:389 0x522539 gt_ggc_mx_lang_tree_node(void*) ./gtype-lto.h:380 0x5399ab gt_ggc_ma_gimple_type_leader ./gt-lto-lto.h:154 0x7419c4 ggc_mark_root_tab /export/gnu/import/git/gcc/gcc/ggc-common.c:138 0x741a74 ggc_mark_roots() /export/gnu/import/git/gcc/gcc/ggc-common.c:157 0x5433e5 ggc_collect() /export/gnu/import/git/gcc/gcc/ggc-page.c:2087 0x5388b4 read_cgraph_and_symbols /export/gnu/import/git/gcc/gcc/lto/lto.c:2993 0x5393c9 lto_main() /export/gnu/import/git/gcc/gcc/lto/lto.c:3383 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.
[Bug lto/55466] [4.8 Regression] Revision 191466 destroyed DWARF debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55466
--- Comment #7 from H.J. Lu hjl.tools at gmail dot com 2012-11-29 19:08:28
UTC ---
This patch:
diff --git a/gcc/lto-symtab.c b/gcc/lto-symtab.c
index 0b0cdac..295fd37 100644
--- a/gcc/lto-symtab.c
+++ b/gcc/lto-symtab.c
@@ -443,10 +443,6 @@ lto_symtab_merge_decls_1 (symtab_node first)
symtab_prevail_in_asm_name_hash (prevailing);
- /* Record the prevailing variable. */
- if (TREE_CODE (prevailing-symbol.decl) == VAR_DECL)
-vec_safe_push (lto_global_var_decls, prevailing-symbol.decl);
-
/* Diagnose mismatched objects. */
for (e = prevailing-symbol.next_sharing_asm_name;
e; e = e-symbol.next_sharing_asm_name)
diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
index 376af85..177fbfc 100644
--- a/gcc/lto/lto.c
+++ b/gcc/lto/lto.c
@@ -2910,6 +2910,7 @@ read_cgraph_and_symbols (unsigned nfiles, const char
**fnames)
struct cgraph_node *node;
int count = 0;
struct lto_file_decl_data **decl_data;
+ struct varpool_node *vnode;
init_cgraph ();
@@ -3088,6 +3089,10 @@ read_cgraph_and_symbols (unsigned nfiles, const char
**fnames)
timevar_pop (TV_IPA_LTO_CGRAPH_MERGE);
+ /* Record the global variables. */
+ FOR_EACH_DEFINED_VARIABLE (vnode)
+vec_safe_push (lto_global_var_decls, vnode-symbol.decl);
+
timevar_push (TV_IPA_LTO_DECL_INIT_IO);
/* Indicate that the cgraph is built and ready. */
or
diff --git a/gcc/lto-symtab.c b/gcc/lto-symtab.c
index 0b0cdac..295fd37 100644
--- a/gcc/lto-symtab.c
+++ b/gcc/lto-symtab.c
@@ -443,10 +443,6 @@ lto_symtab_merge_decls_1 (symtab_node first)
symtab_prevail_in_asm_name_hash (prevailing);
- /* Record the prevailing variable. */
- if (TREE_CODE (prevailing-symbol.decl) == VAR_DECL)
-vec_safe_push (lto_global_var_decls, prevailing-symbol.decl);
-
/* Diagnose mismatched objects. */
for (e = prevailing-symbol.next_sharing_asm_name;
e; e = e-symbol.next_sharing_asm_name)
diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
index 376af85..c7e1100 100644
--- a/gcc/lto/lto.c
+++ b/gcc/lto/lto.c
@@ -3373,6 +3373,8 @@ lto_main (void)
if (!seen_error ())
{
+ struct varpool_node *vnode;
+
/* If WPA is enabled analyze the whole call graph and create an
optimization plan. Otherwise, read in all the function
bodies and continue with optimization. */
@@ -3398,6 +3400,10 @@ lto_main (void)
if (flag_lto_report)
print_lto_report_1 ();
}
+
+ /* Record the global variables. */
+ FOR_EACH_DEFINED_VARIABLE (vnode)
+vec_safe_push (lto_global_var_decls, vnode-symbol.decl);
}
/* Here we make LTO pretend to be a parser. */
seem to work.
[Bug sanitizer/55533] New: Can't bootstrap libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55533
Bug #: 55533
Summary: Can't bootstrap libsanitizer
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: do...@gcc.gnu.org, dvyu...@gcc.gnu.org,
ja...@gcc.gnu.org, k...@gcc.gnu.org
Created attachment 28830
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28830
A patch to boostrap libsanitizer
When bootstrap libsanitizer with
target_modules = { module= libsanitizer;
bootstrap=true;
lib_path=.libs; };
on Linux/ia32 and Linux/x86-64, I got
/bin/sh ../libtool --tag=CXX --mode=compile
/export/build/gnu/gcc/build-x86_64-linux/./gcc/xg++
-B/export/build/gnu/gcc/build-x86_64-linux/./gcc/ -nostdinc++
-funconfigured-libstdc++-v3
-L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/usr/gcc-4.8.0/x86_64-unknown-linux-gnu/bin/
-B/usr/gcc-4.8.0/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/gcc-4.8.0/x86_64-unknown-linux-gnu/include -isystem
/usr/gcc-4.8.0/x86_64-unknown-linux-gnu/sys-include-D_GNU_SOURCE -D_DEBUG
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I.
-I/export/gnu/import/git/gcc/libsanitizer/interception -I
/export/gnu/import/git/gcc/libsanitizer/include -Wall -W
-Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC
-fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables
-fvisibility=hidden -Wno-variadic-macros -Wno-c99-extensions -g -O2
-D_GNU_SOURCE -c -o interception_linux.lo
/export/gnu/import/git/gcc/libsanitizer/interception/interception_linux.cc
xg++: error: unrecognized command line option ‘-funconfigured-libstdc++-v3’
make[5]: *** [interception_linux.lo] Error 1
make[5]: *** Waiting for unfinished jobs
From Makefile.tpl:
# CXX_FOR_TARGET is tricky to get right for target libs that require a
# functional C++ compiler. When we recurse, if we expand
# CXX_FOR_TARGET before configuring libstdc++-v3, we won't get
# libstdc++ include flags from the script. Instead, we get an
# -funconfigured-* word, so that we'll get errors if this invalid C++
# command line is used for anything, but also so that we can use the
# word to decide whether or not to pass on this CXX_FOR_TARGET. If we
# don't pass it on, sub-make will use the default definition, that
# re-expands it at the time of use, so we'll get it right when we need
# it. One potential exception is the expansion of CXX_FOR_TARGET
# passed down as part of CXX within TARGET_FLAGS, but this wouldn't
# really work, for C++ host programs can't depend on the current-stage
# C++ target library.
CXX_FOR_TARGET_FLAG_TO_PASS = \
$(shell if echo $(CXX_FOR_TARGET) | grep -funconfigured-
/dev/null; then :; else echo 'CXX_FOR_TARGET=$(CXX_FOR_TARGET)';
fi)
When we expand CXX_FOR_TARGET for libsanitizer before configuring it,
libstdc++-v3/scripts/testsuite_flags isn't available yet. The solution
is to set raw_cxx=true and use -I to include libstdc++ header file
explicitly when the C++ library is used for bootstrap.
[Bug sanitizer/55533] Can't bootstrap libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55533 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-11/msg02480.htm ||l Last reconfirmed||2012-11-29 Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-11-29 20:21:37 UTC --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2012-11/msg02480.html
[Bug bootstrap/55552] New: --enable-gold=default doesn't work with in-tree binutils
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2 Bug #: 2 Summary: --enable-gold=default doesn't work with in-tree binutils Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com Toplevel configure supports: # Handle --enable-gold, --enable-ld. # --disable-gold [--enable-ld] # Build only ld. Default option. # --enable-gold [--enable-ld] # Build both gold and ld. Install gold as ld.gold, install ld # as ld.bfd and ld. # --enable-gold=default [--enable-ld] # Build both gold and ld. Install gold as ld.gold and ld, # install ld as ld.bfd. # --enable-gold[=default] --disable-ld # Build only gold, which is then installed as both ld.gold and ld. # --enable-gold --enable-ld=default # Build both gold (installed as ld.gold) and ld (installed as ld # and ld.bfd). # In other words, ld is default # --enable-gold=default --enable-ld=default # Error. However, gcc directory doesn't handle --enable-gold=default properly.
[Bug bootstrap/55552] --enable-gold=default doesn't work with in-tree binutils
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-11/msg02568.htm ||l --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-11-30 19:50:36 UTC --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2012-11/msg02568.html
[Bug debug/53860] [4.8 Regression] ICE: in should_move_die_to_comdat, at dwarf2out.c:6254 with -fkeep-inline-functions -fdebug-types-section -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53860 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2012-12-01 16:11:05 UTC --- Fixed.
[Bug bootstrap/55556] New: gcc/exec-tool.in isn't parallel build safe in combined tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 Bug #: 6 Summary: gcc/exec-tool.in isn't parallel build safe in combined tree Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com When bootstrap GCC and binutils in a combined-tree, prev-gcc/as has ORIGINAL_AS_FOR_TARGET=../gas/as-new ... dir=gas prog=as-new if test -x $scriptdir/../$dir/$prog; then exec $scriptdir/../$dir/$prog else exec $scriptdir/../prev-$dir/$prog fi When we are building gas parallel with bintils, gold, gprof and ld, we may run into race condition that prev-gcc/as checks ../gas/as-new at the same time when we are creating it.
[Bug middle-end/55555] [4.8 Regression] miscompilation at -O2 (tree-pre?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 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 #3 from H.J. Lu hjl.tools at gmail dot com 2012-12-01 19:17:36 UTC --- It is caused by revision 193098: http://gcc.gnu.org/ml/gcc-cvs/2012-11/msg00045.html
[Bug driver/55470] Support -fuse-ld=bfd and -fuse-ld=gold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55470 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Summary|Enable both ld and gold in |Support -fuse-ld=bfd and |gcc |-fuse-ld=gold --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-12-01 19:24:38 UTC --- A minimum patch is at http://gcc.gnu.org/git/?p=gcc.git;a=patch;h=ae2d4a12a0be6dd66db9d87d5caddd9496b13981
[Bug target/50829] avx extra copy for _mm256_insertf128_pd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50829 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||areg.melikadamyan at gmail ||dot com, hjl.tools at gmail ||dot com --- Comment #11 from H.J. Lu hjl.tools at gmail dot com 2012-12-01 20:26:32 UTC --- (In reply to comment #10) Created attachment 28846 [details] Use subreg Hmm, I don't understand why we use UNSPEC_CAST. I tried the attached patch to use a subreg instead. It passed bootstrap+testsuite and generates optimal code for the testcase of this PR. So, any idea what advantage the unspec has over a subreg? And if none, what is the best way to use a subreg? subreg didn't work before.
[Bug target/50829] avx extra copy for _mm256_insertf128_pd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50829 --- Comment #12 from H.J. Lu hjl.tools at gmail dot com 2012-12-01 22:22:28 UTC --- Also see PR 44551.
[Bug tree-optimization/55569] [4.8 Regression] ICE: in check_probability, at basic-block.h:944 with -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55569 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2012-12-03 15:19:33 UTC --- It is caused by revision 193241: http://gcc.gnu.org/ml/gcc-cvs/2012-11/msg00188.html
[Bug sanitizer/55577] New: g++.dg/asan/asan_test.C failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55577 Bug #: 55577 Summary: g++.dg/asan/asan_test.C failures Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: do...@gcc.gnu.org, dvyu...@gcc.gnu.org, ja...@gcc.gnu.org, k...@gcc.gnu.org On Linux/x86, revision 194082 gave FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_BitFieldPositiveTest x-bf1 = 0 execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_BitFieldPositiveTest x-bf2 = 0 execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_BitFieldPositiveTest x-bf3 = 0 execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_BitFieldPositiveTest x-bf4 = 0 execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_BuiltinLongJmpTest execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_FileNameInGlobalReportTest Ident(p[15]) execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_GlobalStringConstTest Ident(p[15]) execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_GlobalTest fs2[Ident(-1)] = 0 execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_GlobalTest func_static15[Ident(15 + 9)] = 0 execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_GlobalTest func_static15[Ident(15)] = 0 execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_GlobalTest static110[Ident(110)] = 0 execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_GlobalTest static110[Ident(110+7)] = 0 execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_LongJmpTest execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_SigLongJmpTest execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_SignalTest *c = 0 output pattern test, should match AddressSanitizer: SEGV on unknown address FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_SignalTest *c = 0 output pattern test, should match AddressSanitizer: SEGV on unknown address FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_ThreadStackReuseTest execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_ThreadedTest ThreadedTestSpawn() output pattern test, should match Thread T.*created.*Thread T.*created.*Thread T.*created
[Bug c++/55564] 4.8 Regression] internal error using decltype of a template type parameter for late-specified function result type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55564 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||mjambor at suse dot cz Target Milestone|--- |4.8.0 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-12-03 17:49:32 UTC --- It is caused by revision 190830: http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00809.html
[Bug c++/55564] 4.8 Regression] internal error using decltype of a template type parameter for late-specified function result type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55564 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||jason at redhat dot com --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2012-12-03 18:07:06 UTC --- (In reply to comment #3) It is caused by revision 190830: http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00809.html Oops. Right revision, wrong link: http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00808.html
[Bug rtl-optimization/55583] Extended shift instruction on x86-64 is not used, producing unoptimal code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55583 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-04 CC||areg.melikadamyan at gmail ||dot com, hjl.tools at gmail ||dot com, ubizjak at gmail ||dot com Ever Confirmed|0 |1 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2012-12-04 00:21:02 UTC --- Clang generates: movla(%rip), %eax shldl$2, %eax, b(%rip) ret at -O2.
[Bug lto/55592] linking with -flto always links in libgcc:s.so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55592 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||hjl.tools at gmail dot com Resolution||INVALID --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-12-04 13:58:20 UTC --- It is a bug in bfd linker in the GNU binutils. It works fine with both bfd linker and gold from the Linux binutils. Please open a binutils bug.
[Bug middle-end/55597] New: [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55597
Bug #: 55597
Summary: [4.8 Regression] internal compiler error: in
plus_constant, at explow.c:88
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
On Linux/x86-64, revision 194159 gave:
[hjl@gnu-ivb-1 gcc]$ cat /tmp/testcase.c
struct initial_sp {
void *sp;
int mask;
};
void foo (int *);
__thread struct initial_sp __morestack_initial_sp;
void __morestack_release_segments (void) {
foo (__morestack_initial_sp.mask);
}
[hjl@gnu-ivb-1 gcc]$ ./xgcc -B./ -fPIC -O2 -mx32 -S -maddress-mode=long
/tmp/testcase.c
/tmp/testcase.c: In function ‘__morestack_release_segments’:
/tmp/testcase.c:9:1: internal compiler error: in plus_constant, at explow.c:88
}
^
0x7321f3 plus_constant(machine_mode, rtx_def*, long)
/export/gnu/import/git/gcc/gcc/explow.c:88
0x5fdee7 init_alias_analysis()
/export/gnu/import/git/gcc/gcc/alias.c:2945
0xfce2ce cse_main
/export/gnu/import/git/gcc/gcc/cse.c:6543
0xfd010e rest_of_handle_cse
/export/gnu/import/git/gcc/gcc/cse.c:7435
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-ivb-1 gcc]$
[Bug middle-end/55597] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55597 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-04 CC||bonzini at gnu dot org Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-12-04 22:29:34 UTC --- It is caused by revision 193868: http://gcc.gnu.org/ml/gcc-cvs/2012-11/msg00816.html
[Bug middle-end/55597] internal compiler error: in plus_constant, at explow.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55597 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Component|target |middle-end --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2012-12-04 23:49:48 UTC --- (In reply to comment #4) And for the record: This can never be a regression, X32 doesn't exist in previous GCC releases. Last time when I checked, GCC 4.7 supports x32.
[Bug middle-end/55597] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55597 --- Comment #7 from H.J. Lu hjl.tools at gmail dot com 2012-12-05 17:28:11 UTC --- It is generated by (gdb) bt #0 set_unique_reg_note (insn=0x719a07e0, kind=REG_EQUAL, datum=0x71ab4460) at /export/gnu/import/git/gcc/gcc/emit-rtl.c:4958 #1 0x00726f1b in set_dst_reg_note (insn=0x719a07e0, kind=REG_EQUAL, datum=0x71ab4460, dst=0x71ab44c0) at /export/gnu/import/git/gcc/gcc/emit-rtl.c:5018 #2 0x00949cbb in emit_libcall_block_1 (insns=0x71ab2730, target=0x71ab44c0, result=0x71ab4500, equiv=0x71ab4460, equiv_may_trap=false) at /export/gnu/import/git/gcc/gcc/optabs.c:3936 #3 0x00949d10 in emit_libcall_block (insns=0x71ab2730, target=0x71ab44c0, result=0x71ab4500, equiv=0x71ab4460) at /export/gnu/import/git/gcc/gcc/optabs.c:3945 #4 0x00d082fa in legitimize_tls_address (x=0x71ab4460, model=TLS_MODEL_REAL, for_mov=true) at /export/gnu/import/git/gcc/gcc/config/i386/i386.c:12805 #5 0x00d0f4bb in ix86_expand_move (mode=SImode, operands=0x7fffc920) at /export/gnu/import/git/gcc/gcc/config/i386/i386.c:15936 #6 0x00dc1b60 in gen_movsi (operand0=0x71ab44a0, operand1=0x71aac2f0) at /export/gnu/import/git/gcc/gcc/config/i386/i386.md:1701 #7 0x00750380 in emit_move_insn_1 (x=0x71ab44a0, y=0x71aac2f0) at /export/gnu/import/git/gcc/gcc/expr.c:3417 #8 0x007507cd in emit_move_insn (x=0x71ab44a0, y=0x71aac2f0) ---Type return to continue, or q return to quit--- at /export/gnu/import/git/gcc/gcc/expr.c:3511 #9 0x00733def in copy_to_mode_reg (mode=SImode, x=0x71aac2f0) at /export/gnu/import/git/gcc/gcc/explow.c:645 #10 0x009537f9 in maybe_legitimize_operand ( icode=CODE_FOR_zero_extendsidi2, opno=1, op=0x7fffcad0) at /export/gnu/import/git/gcc/gcc/optabs.c:8069 #11 0x00953ac8 in maybe_legitimize_operands ( icode=CODE_FOR_zero_extendsidi2, opno=0, nops=2, ops=0x7fffcac0) at /export/gnu/import/git/gcc/gcc/optabs.c:8131 #12 0x00953b5b in maybe_gen_insn (icode=CODE_FOR_zero_extendsidi2, nops=2, ops=0x7fffcac0) at /export/gnu/import/git/gcc/gcc/optabs.c:8149 #13 0x00949697 in maybe_emit_unop_insn ( icode=CODE_FOR_zero_extendsidi2, target=0x71ab4480, op0=0x71aac2f0, code=ZERO_EXTEND) at /export/gnu/import/git/gcc/gcc/optabs.c:3765 #14 0x0094976b in emit_unop_insn (icode=CODE_FOR_zero_extendsidi2, target=0x71ab4480, op0=0x71aac2f0, code=ZERO_EXTEND) at /export/gnu/import/git/gcc/gcc/optabs.c:3787 #15 0x00748f7a in convert_move (to=0x71ab4480, from=0x71aac2f0, unsignedp=1) at /export/gnu/import/git/gcc/gcc/expr.c:607 (gdb) f 2 #2 0x00949cbb in emit_libcall_block_1 (insns=0x71ab2730, target=0x71ab44c0, result=0x71ab4500, equiv=0x71ab4460, equiv_may_trap=false) at /export/gnu/import/git/gcc/gcc/optabs.c:3936 3936 set_dst_reg_note (last, REG_EQUAL, copy_rtx (equiv), target); (gdb) call debug_rtx (last) (insn 6 5 0 (set (reg:DI 61) (reg:DI 0 ax)) x.i:8 -1 (nil)) (gdb) call debug_rtx (equiv) (symbol_ref:SI (__morestack_initial_sp) [flags 0x10] var_decl 0x719bf390 __morestack_initial_sp) (gdb)
[Bug middle-end/55597] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55597 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2012-12-05 17:55:51 UTC --- Does this patch diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index a24e407..b496490 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -12802,6 +12802,8 @@ legitimize_tls_address (rtx x, enum tls_model model, bool for_mov) end_sequence (); RTL_CONST_CALL_P (insns) = 1; + if (GET_MODE (x) != Pmode) +x = gen_rtx_ZERO_EXTEND (Pmode, x); emit_libcall_block (insns, dest, rax, x); } else make any senses?
[Bug c++/55606] New: sorry, unimplemented: non-trivial designated initializers not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55606
Bug #: 55606
Summary: sorry, unimplemented: non-trivial designated
initializers not supported
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
[hjl@gnu-6 build]$ cat x.c
struct foo {
char x[128];
unsigned* i;
};
struct foo x = {
i: 0
};
[hjl@gnu-6 build]$ gcc -S x.c
[hjl@gnu-6 build]$ g++ -S x.c
x.c:7:1: sorry, unimplemented: non-trivial designated initializers not
supported
[hjl@gnu-6 build]$
[Bug middle-end/55597] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55597 --- Comment #10 from H.J. Lu hjl.tools at gmail dot com 2012-12-06 00:21:55 UTC --- (In reply to comment #9) I think it is better to fixup all sites where equivalent is used: It works. Thanks.
[Bug c++/55606] sorry, unimplemented: non-trivial designated initializers not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55606
--- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2012-12-06 00:29:07
UTC ---
why does
struct foo x = {
i: 0
};
work?
[Bug c++/55606] sorry, unimplemented: non-trivial designated initializers not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55606 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-12-06 00:30:11 UTC --- BTW, clang works fine: [hjl@gnu-6 tmp]$ /opt/llvm.old/bin/clang -c i.c i.c:6:5: warning: use of GNU old-style field designator extension [-Wgnu-designator] i: 0 ^~ .i = 1 warning generated. [hjl@gnu-6 tmp]$
[Bug c++/55606] sorry, unimplemented: non-trivial designated initializers not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55606
--- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2012-12-06 00:32:46
UTC ---
[hjl@gnu-6 tmp]$ cat i.cc
struct foo {
char x[128];
unsigned* i;
};
struct foo x = {
.i = 0
};
[hjl@gnu-6 tmp]$ /opt/llvm.old/bin/clang -c i.cc
[hjl@gnu-6 tmp]$ g++ -c i.cc
i.cc:7:1: sorry, unimplemented: non-trivial designated initializers not
supported
[hjl@gnu-6 tmp]$
[Bug c++/55606] sorry, unimplemented: non-trivial designated initializers not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55606
--- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2012-12-06 00:35:38
UTC ---
This works:
[hjl@gnu-6 tmp]$ cat i.cc
struct foo {
char x[128];
unsigned* i;
};
struct foo x = {
foo,
.i = 0
};
[hjl@gnu-6 tmp]$ g++ -c i.cc
[hjl@gnu-6 tmp]$
[Bug middle-end/55597] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55597 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #14 from H.J. Lu hjl.tools at gmail dot com 2012-12-07 03:44:21 UTC --- Fixed.
[Bug bootstrap/55615] New: [4.8 Regression] Failed to bootstrap with --with-arch=core2 --with-cpu=atom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55615 Bug #: 55615 Summary: [4.8 Regression] Failed to bootstrap with --with-arch=core2 --with-cpu=atom Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: areg.melikadam...@gmail.com, ubiz...@gmail.com On Linux/x86, configured with --with-arch=core2 --with-cpu=atom, revision 194299 gave: 0x886f4b5 crash_signal ../../src-trunk/gcc/toplev.c:334 0x8b290da distance_non_agu_define_in_bb ../../src-trunk/gcc/config/i386/i386.c:16944 0x8b2928f distance_non_agu_define ../../src-trunk/gcc/config/i386/i386.c:17002 0x8b2968f ix86_lea_outperforms ../../src-trunk/gcc/config/i386/i386.c:17168 0x8b29994 ix86_use_lea_for_mov(rtx_def*, rtx_def**) ../../src-trunk/gcc/config/i386/i386.c:17278 /bin/sh ../libtool --tag CXX --tag disable-shared --mode=compile /export/gnu/import/git/gcc-test-ia32/bld/./gcc/xgcc -shared-libgcc -B/export/gnu/import/git/gcc-test-ia32/bld/./gcc -nostdinc++ -L/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/src -L/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/src/.libs -B/usr/local/i686-linux/bin/ -B/usr/local/i686-linux/lib/ -isystem /usr/local/i686-linux/include -isystem /usr/local/i686-linux/sys-include -I/export/gnu/import/git/gcc-test-ia32/src-trunk/libstdc++-v3/../libgcc -I/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/include/i686-linux -I/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/include -I/export/gnu/import/git/gcc-test-ia32/src-trunk/libstdc++-v3/libsupc++ -prefer-pic -D_GLIBCXX_SHARED -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once-ffunction-sections -fdata-sections -frandom-seed=new_opnt.lo -g -O2 -D_GNU_SOURCE -c -o new_opnt.lo ../../../../src-trunk/libstdc++-v3/libsupc++/new_opnt.cc 0x8c5704c output_78 ../../src-trunk/gcc/config/i386/i386.md:2191 0x85a6ae7 get_insn_template(int, rtx_def*) ../../src-trunk/gcc/final.c:1939 0x85a7ee0 final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*) ../../src-trunk/gcc/final.c:2792 0x85a69b1 final(rtx_def*, _IO_FILE*, int) ../../src-trunk/gcc/final.c:1908 0x85aa397 rest_of_handle_final ../../src-trunk/gcc/final.c:4271 libtool: compile: /export/gnu/import/git/gcc-test-ia32/bld/./gcc/xgcc -shared-libgcc -B/export/gnu/import/git/gcc-test-ia32/bld/./gcc -nostdinc++ -L/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/src -L/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/src/.libs -B/usr/local/i686-linux/bin/ -B/usr/local/i686-linux/lib/ -isystem /usr/local/i686-linux/include -isystem /usr/local/i686-linux/sys-include -I/export/gnu/import/git/gcc-test-ia32/src-trunk/libstdc++-v3/../libgcc -I/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/include/i686-linux -I/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/include -I/export/gnu/import/git/gcc-test-ia32/src-trunk/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=new_op.lo -g -O2 -D_GNU_SOURCE -c ../../../../src-trunk/libstdc++-v3/libsupc++/new_op.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o new_op.o 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[8]: *** [eh_personality.lo] Error 1
[Bug lto/55466] [4.8 Regression] Revision 191466 destroyed DWARF debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55466
--- Comment #9 from H.J. Lu hjl.tools at gmail dot com 2012-12-07 13:02:12
UTC ---
I am testing this patch:
---
diff --git a/gcc/lto-symtab.c b/gcc/lto-symtab.c
index 0b0cdac..295fd37 100644
--- a/gcc/lto-symtab.c
+++ b/gcc/lto-symtab.c
@@ -443,10 +443,6 @@ lto_symtab_merge_decls_1 (symtab_node first)
symtab_prevail_in_asm_name_hash (prevailing);
- /* Record the prevailing variable. */
- if (TREE_CODE (prevailing-symbol.decl) == VAR_DECL)
-vec_safe_push (lto_global_var_decls, prevailing-symbol.decl);
-
/* Diagnose mismatched objects. */
for (e = prevailing-symbol.next_sharing_asm_name;
e; e = e-symbol.next_sharing_asm_name)
diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
index 376af85..c637ec8 100644
--- a/gcc/lto/lto.c
+++ b/gcc/lto/lto.c
@@ -3083,8 +3083,16 @@ read_cgraph_and_symbols (unsigned nfiles, const char
**fnames)
supports inlining, so we can push it here by hand. In future we need to
stream
this field into ltrans compilation. */
if (flag_ltrans)
-FOR_EACH_DEFINED_FUNCTION (node)
- node-ipa_transforms_to_apply.safe_push
((ipa_opt_pass)pass_ipa_inline);
+{
+ struct varpool_node *vnode;
+
+ FOR_EACH_DEFINED_FUNCTION (node)
+node-ipa_transforms_to_apply.safe_push ((ipa_opt_pass)pass_ipa_inline);
+
+ /* Record the global variables. */
+ FOR_EACH_DEFINED_VARIABLE (vnode)
+vec_safe_push (lto_global_var_decls, vnode-symbol.decl);
+}
timevar_pop (TV_IPA_LTO_CGRAPH_MERGE);
---
[Bug c++/55127] [4.8 regression] Incorrect dependent scope error with partial specialization of non-type parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55127 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Priority|P1 |P3 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2012-12-07 13:27:59 UTC --- It is caused by revision 190830: http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00808.html
[Bug lto/55466] [4.8 Regression] Revision 191466 destroyed DWARF debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55466
--- Comment #10 from H.J. Lu hjl.tools at gmail dot com 2012-12-07 18:49:10
UTC ---
(In reply to comment #7)
This patch:
diff --git a/gcc/lto-symtab.c b/gcc/lto-symtab.c
index 0b0cdac..295fd37 100644
--- a/gcc/lto-symtab.c
+++ b/gcc/lto-symtab.c
@@ -443,10 +443,6 @@ lto_symtab_merge_decls_1 (symtab_node first)
symtab_prevail_in_asm_name_hash (prevailing);
- /* Record the prevailing variable. */
- if (TREE_CODE (prevailing-symbol.decl) == VAR_DECL)
-vec_safe_push (lto_global_var_decls, prevailing-symbol.decl);
-
/* Diagnose mismatched objects. */
for (e = prevailing-symbol.next_sharing_asm_name;
e; e = e-symbol.next_sharing_asm_name)
diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
index 376af85..177fbfc 100644
--- a/gcc/lto/lto.c
+++ b/gcc/lto/lto.c
@@ -2910,6 +2910,7 @@ read_cgraph_and_symbols (unsigned nfiles, const char
**fnames)
struct cgraph_node *node;
int count = 0;
struct lto_file_decl_data **decl_data;
+ struct varpool_node *vnode;
init_cgraph ();
@@ -3088,6 +3089,10 @@ read_cgraph_and_symbols (unsigned nfiles, const char
**fnames)
timevar_pop (TV_IPA_LTO_CGRAPH_MERGE);
+ /* Record the global variables. */
+ FOR_EACH_DEFINED_VARIABLE (vnode)
+vec_safe_push (lto_global_var_decls, vnode-symbol.decl);
+
timevar_push (TV_IPA_LTO_DECL_INIT_IO);
/* Indicate that the cgraph is built and ready. */
or
diff --git a/gcc/lto-symtab.c b/gcc/lto-symtab.c
index 0b0cdac..295fd37 100644
--- a/gcc/lto-symtab.c
+++ b/gcc/lto-symtab.c
@@ -443,10 +443,6 @@ lto_symtab_merge_decls_1 (symtab_node first)
symtab_prevail_in_asm_name_hash (prevailing);
- /* Record the prevailing variable. */
- if (TREE_CODE (prevailing-symbol.decl) == VAR_DECL)
-vec_safe_push (lto_global_var_decls, prevailing-symbol.decl);
-
/* Diagnose mismatched objects. */
for (e = prevailing-symbol.next_sharing_asm_name;
e; e = e-symbol.next_sharing_asm_name)
diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
index 376af85..c7e1100 100644
--- a/gcc/lto/lto.c
+++ b/gcc/lto/lto.c
@@ -3373,6 +3373,8 @@ lto_main (void)
if (!seen_error ())
{
+ struct varpool_node *vnode;
+
/* If WPA is enabled analyze the whole call graph and create an
optimization plan. Otherwise, read in all the function
bodies and continue with optimization. */
@@ -3398,6 +3400,10 @@ lto_main (void)
if (flag_lto_report)
print_lto_report_1 ();
}
+
+ /* Record the global variables. */
+ FOR_EACH_DEFINED_VARIABLE (vnode)
+vec_safe_push (lto_global_var_decls, vnode-symbol.decl);
}
/* Here we make LTO pretend to be a parser. */
seem to work.
It doesn't work. When gcc is configured with
--enable-languages=c,c++,fortran,java,lto,objc,obj-c++,go, I got
lto1: internal compiler error: in add_AT_specification, at dwarf2out.c:3985
0x629ad9 add_AT_specification
/export/gnu/import/git/gcc/gcc/dwarf2out.c:3985
0x64dabb gen_variable_die
/export/gnu/import/git/gcc/gcc/dwarf2out.c:18327
0x65336b gen_decl_die
/export/gnu/import/git/gcc/gcc/dwarf2out.c:20033
0x653fcd dwarf2out_decl(tree_node*)
/export/gnu/import/git/gcc/gcc/dwarf2out.c:20348
0x6535f9 dwarf2out_global_decl
/export/gnu/import/git/gcc/gcc/dwarf2out.c:20083
0x997703 emit_debug_global_declarations(tree_node**, int)
/export/gnu/import/git/gcc/gcc/toplev.c:530
0x521aaa lto_write_globals
/export/gnu/import/git/gcc/gcc/lto/lto-lang.c:1067
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[6]: *** [/tmp/cc3yYR7d.ltrans4.ltrans.o] Error 1
lto-wrapper: make returned 2 exit status
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[5]: *** [go1] Error 1
[Bug debug/52857] DW_OP_GNU_regval_type is generated with INVALID_REGNUM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52857 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #9 from H.J. Lu hjl.tools at gmail dot com 2012-12-07 22:11:26 UTC --- Fixed.
[Bug sanitizer/55374] [asan] Wrong linking order of libasan and libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55374
--- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-12-08 17:05:51
UTC ---
[hjl@gnu-6 gcc]$ cat /tmp/bad.cc
#include new
int
main ()
{
int *buf = new int(30);
buf[30]=1;
return 0;
}
[hjl@gnu-6 gcc]$ ./release/usr/gcc-4.8.0/bin/g++ -fsanitize=address /tmp/bad.cc
-static-libasan -static-libstdc++
/export/build/gnu/gcc/release/usr/gcc-4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib64/libasan.a(asan_new_delete.o):
In function `operator new(unsigned long)':
/export/gnu/import/git/gcc/libsanitizer/asan/asan_new_delete.cc:41: multiple
definition of `operator new(unsigned long)'
/export/build/gnu/gcc/release/usr/gcc-4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib64/libstdc++.a(new_op.o):/export/gnu/import/git/gcc/libstdc++-v3/libsupc++/new_op.cc:45:
first defined here
/export/build/gnu/gcc/release/usr/gcc-4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib64/libasan.a(asan_new_delete.o):
In function `operator delete(void*)':
/export/gnu/import/git/gcc/libsanitizer/asan/asan_new_delete.cc:54: multiple
definition of `operator delete(void*)'
/export/build/gnu/gcc/release/usr/gcc-4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib64/libstdc++.a(del_op.o):/export/gnu/import/git/gcc/libstdc++-v3/libsupc++/del_op.cc:46:
first defined here
collect2: error: ld returned 1 exit status
[hjl@gnu-6 gcc]$
[Bug sanitizer/55374] [asan] -static-libasan -static-libstdc++ doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55374 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.8.0 Summary|[asan] Wrong linking order |[asan] -static-libasan |of libasan and libstdc++|-static-libstdc++ doesn't ||work
[Bug sanitizer/55374] [asan] -static-libasan -static-libstdc++ doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55374 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-11/msg01872.htm ||l Last reconfirmed||2012-12-08 Ever Confirmed|0 |1 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2012-12-08 17:11:16 UTC --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01872.html
[Bug middle-end/55279] New pseudo registers aren't supported in CSE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55279 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2012-12-09 15:33:53 UTC --- Any passes which allocate a table for maximum number of registers can't deal with new pseudo registers. But there is nothing to check and enforce it.
[Bug middle-end/55279] New pseudo registers aren't supported in CSE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55279
--- Comment #9 from H.J. Lu hjl.tools at gmail dot com 2012-12-10 01:05:09
UTC ---
(In reply to comment #8)
(In reply to comment #7)
(In reply to comment #5)
Why can't cse_reg_info_table() be modified to intercept this?
Correction: get_cse_reg_info()
Like so, quick-and-dirty hack. HJ, can you try and see if this
keeps valgrind happy?
Index: cse.c
===
--- cse.c (revision 194325)
+++ cse.c (working copy)
@@ -833,6 +833,7 @@
static inline struct cse_reg_info *
get_cse_reg_info (unsigned int regno)
{
+ init_cse_reg_info (regno + 1);
struct cse_reg_info *p = cse_reg_info_table[regno];
/* If this entry has not been initialized, go ahead and initialize
I got
/export/gnu/import/git/sources/gcc-release/gcc/testsuite/gcc.dg/Warray-bounds.c:92:1:
internal compiler error: in insert_regs, at cse.c:1159^M
0xce1db0 insert_regs^M
/export/gnu/import/git/sources/gcc-release/gcc/cse.c:1159^M
0xce4fbb cse_insn^M
/export/gnu/import/git/sources/gcc-release/gcc/cse.c:5793^M
0xce719b cse_extended_basic_block^M
/export/gnu/import/git/sources/gcc-release/gcc/cse.c:6408^M
0xce719b cse_main^M
/export/gnu/import/git/sources/gcc-release/gcc/cse.c:6586^M
0xce7675 rest_of_handle_cse^M
/export/gnu/import/git/sources/gcc-release/gcc/cse.c:7436^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
Please include the complete backtrace with any bug report.^M
See http://gcc.gnu.org/bugs.html for instructions.^M
[Bug bootstrap/55640] New: --with-build-config=bootstrap-lto doesn't work with go
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55640 Bug #: 55640 Summary: --with-build-config=bootstrap-lto doesn't work with go Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86-64, when GCC was configured with --enable-bootstrap --with-build-config=bootstrap-lto --enable-languages=c,c++,fortran,java,lto,objc,obj-c++,go I got lto1: internal compiler error: in add_AT_specification, at dwarf2out.c:3985 0x629ad9 add_AT_specification /export/gnu/import/git/gcc/gcc/dwarf2out.c:3985 0x64dabb gen_variable_die /export/gnu/import/git/gcc/gcc/dwarf2out.c:18327 0x65336b gen_decl_die /export/gnu/import/git/gcc/gcc/dwarf2out.c:20033 0x653fcd dwarf2out_decl(tree_node*) /export/gnu/import/git/gcc/gcc/dwarf2out.c:20348 0x6535f9 dwarf2out_global_decl /export/gnu/import/git/gcc/gcc/dwarf2out.c:20083 0x997703 emit_debug_global_declarations(tree_node**, int) /export/gnu/import/git/gcc/gcc/toplev.c:530 0x521aaa lto_write_globals /export/gnu/import/git/gcc/gcc/lto/lto-lang.c:1067 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[6]: *** [/tmp/cc3yYR7d.ltrans4.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[5]: *** [go1] Error 1
[Bug bootstrap/55640] --with-build-config=bootstrap-lto doesn't work with go
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55640 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME Target Milestone|--- |4.8.0 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-12-10 15:37:32 UTC --- Fixed as of revision 194359.
[Bug lto/55466] [4.8 Regression] Revision 191466 destroyed DWARF debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55466 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #12 from H.J. Lu hjl.tools at gmail dot com 2012-12-10 16:39:40 UTC --- Fixed.
[Bug bootstrap/55644] bootstrap-lto fails on current trunk (with and without profiledbootstrap)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-11 Ever Confirmed|0 |1 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2012-12-11 13:56:47 UTC --- This may be related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55519 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55496
[Bug sanitizer/55533] Can't bootstrap libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55533 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-12-11 23:39:49 UTC --- Fixed.
[Bug target/55672] [4.8 Regression] -fstack-check=generic ICEs in print_reg, at config/i386/i386.c:13868
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55672
--- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2012-12-18 15:11:38
UTC ---
This is what we changed in reload for stack realignment:
diff --git a/gcc/reload1.c b/gcc/reload1.c
index f28b01c..9b81062 100644
--- a/gcc/reload1.c
+++ b/gcc/reload1.c
@@ -3663,8 +3663,11 @@ update_eliminables (HARD_REG_SET *pset)
frame_pointer_needed = 1;
for (ep = reg_eliminate; ep reg_eliminate[NUM_ELIMINABLE_REGS]; ep++)
{
- if (ep-can_eliminate ep-from == FRAME_POINTER_REGNUM
- ep-to != HARD_FRAME_POINTER_REGNUM)
+ if (ep-can_eliminate
+ ep-from == FRAME_POINTER_REGNUM
+ ep-to != HARD_FRAME_POINTER_REGNUM
+ (! SUPPORTS_STACK_ALIGNMENT
+ || ! crtl-stack_realign_needed))
frame_pointer_needed = 0;
if (! ep-can_eliminate ep-can_eliminate_previous)
@@ -3720,7 +3723,10 @@ init_elim_table (void)
ep-to = ep1-to;
ep-can_eliminate = ep-can_eliminate_previous
= (CAN_ELIMINATE (ep-from, ep-to)
- ! (ep-to == STACK_POINTER_REGNUM frame_pointer_needed));
+ ! (ep-to == STACK_POINTER_REGNUM
+ frame_pointer_needed
+ (! SUPPORTS_STACK_ALIGNMENT
+|| ! stack_realign_fp)));
}
#else
reg_eliminate[0].from = reg_eliminate_1[0].from;
LRA should have similar codes.
[Bug target/55672] [4.8 Regression] -fstack-check=generic ICEs in print_reg, at config/i386/i386.c:13868
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55672 --- Comment #7 from H.J. Lu hjl.tools at gmail dot com 2012-12-18 19:42:59 UTC --- LRA doesn't handle HARD_FRAME_POINTER_IS_FRAME_POINTER at all.
[Bug rtl-optimization/55672] [4.8 Regression] -fstack-check=generic ICEs in print_reg, at config/i386/i386.c:13868
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55672 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Component|target |rtl-optimization --- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2012-12-18 20:35:17 UTC --- (In reply to comment #4) If stack_realign_p is true, frame_pointer_needed is also true. So we can use fp to eliminate frame but i386.c::x86_can_eliminate prohibits it. The code looks strange: if (stack_realign_fp) return ((from == ARG_POINTER_REGNUM to == HARD_FRAME_POINTER_REGNUM) || (from == FRAME_POINTER_REGNUM to == STACK_POINTER_REGNUM)); So we permit to change argument pointer but not frame pointer to FP which again is strange IMHO. Changing the code to if (stack_realign_fp) return ((from == ARG_POINTER_REGNUM to == HARD_FRAME_POINTER_REGNUM) || (from == FRAME_POINTER_REGNUM to == STACK_POINTER_REGNUM) || (from == FRAME_POINTER_REGNUM to == HARD_FRAME_POINTER_REGNUM)); solves the problem. It fixes ICE, but generates questionable code: main: .LFB0: .cfi_startproc pushl%ebp .cfi_def_cfa_offset 8 .cfi_offset 5, -8 movl%esp, %ebp .cfi_def_cfa_register 5 andl$-16, %esp subl$8236, %esp orl$0, (%esp) addl$8204, %esp cmpl$4, -40(%ebp) je.L2 callabort .L2: movl$0, %eax leave .cfi_restore 5 .cfi_def_cfa 4, 4 ret Without LRA, we got main: .LFB0: .cfi_startproc pushl%ebp .cfi_def_cfa_offset 8 .cfi_offset 5, -8 movl%esp, %ebp .cfi_def_cfa_register 5 andl$-16, %esp subl$8236, %esp orl$0, (%esp) addl$8204, %esp cmpl$4, (%esp) je.L2 callabort .L2: movl$0, %eax leave .cfi_restore 5 .cfi_def_cfa 4, 4 ret The difference is --- x.s2012-12-18 12:24:17.072888139 -0800 +++ no-lra.s2012-12-18 12:30:11.419157548 -0800 @@ -14,7 +14,7 @@ main: subl$8236, %esp orl$0, (%esp) addl$8204, %esp -cmpl$4, -40(%ebp) +cmpl$4, (%esp) je.L2 callabort .L2: I think LRA generated code is wrong. The reason we don't allow converting software frame pointer to hardware frame pointer is when stack alignment is needed, hardware frame pointer is used to save stack pointer. We can no longer use it for software frame pointer.
[Bug sanitizer/55739] New: asan doesn't work on common symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739
Bug #: 55739
Summary: asan doesn't work on common symbols
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: do...@gcc.gnu.org, dvyu...@gcc.gnu.org,
ja...@gcc.gnu.org, k...@gcc.gnu.org
[hjl@gnu-6 bound-1]$ cat c.c
#include stdio.h
int c[30];
void
foo (int a[])
{
printf (10: %d\n, a[10]);
}
[hjl@gnu-6 bound-1]$ cat m.c
#include stdio.h
extern int c[];
void foo (int []);
int
main ()
{
c[30] = 1;
foo (c);
printf (30: %d\n, c[30]);
return 0;
}
[hjl@gnu-6 bound-1]$ make
/export/build/gnu/gcc/build-x86_64-linux/gcc/../../release/usr/gcc-4.8.0/bin/gcc
-fsanitize=address -O -static-libasan -c -o m.o m.c
/export/build/gnu/gcc/build-x86_64-linux/gcc/../../release/usr/gcc-4.8.0/bin/gcc
-fsanitize=address -O -static-libasan -c -o c.o c.c
/export/build/gnu/gcc/build-x86_64-linux/gcc/../../release/usr/gcc-4.8.0/bin/gcc
-fsanitize=address -O -static-libasan -o x m.o c.o
./x
10: 0
30: 1
[hjl@gnu-6 bound-1]$
[Bug sanitizer/55739] asan doesn't work on common symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2012-12-19 13:42:12 UTC --- If upper address or size of the common symbol is available to ASAN at compile time as a special symbol generated by assembler/linker, will it help?
[Bug sanitizer/55739] asan doesn't work on common symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2012-12-19 16:58:34 UTC --- The symbol size is always available at link-time or run-time. We just never find a use for it in program itself. We can add relocations for foo@BOUND, which resolve to original calculation of symbol foo + size of foo.
[Bug fortran/55341] address-sanitizer and Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341 --- Comment #36 from H.J. Lu hjl.tools at gmail dot com 2012-12-20 17:31:04 UTC --- (In reply to comment #34) (In reply to comment #33) Using--with-build-config=bootstrap-asan should do that for you. Seems like I'm doing something wrong, this fails for me after configuring with: ../gcc/configure --prefix=/data/vjoost/gnu/gcc_trunk/install --enable-languages=c,c++,fortran --disable-multilib --enable-plugins --disable-werror --with-build-config=bootstrap-asan /data/vjoost/gnu/binutils-2.23.1/install/bin/ld: error: /data/vjoost/gnu/gcc_trunk/obj/prev-x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/libasan.a(asan_new_delete.o): multiple definition of 'operator new(unsigned long)' /data/vjoost/gnu/binutils-2.23.1/install/bin/ld: /data/vjoost/gnu/gcc_trunk/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(new_op.o): This is PR 55374.
[Bug fortran/55341] address-sanitizer and Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341 --- Comment #38 from H.J. Lu hjl.tools at gmail dot com 2012-12-20 17:49:44 UTC --- (In reply to comment #37) H.J., How are you working around PR55371 in your --with-build-config=bootstrap-asan builds? I configure GCC with --disable-werror.
[Bug sanitizer/55374] [asan] -static-libasan -static-libstdc++ doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55374 --- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2012-12-20 19:24:49 UTC --- (In reply to comment #5) After applying your patch, I now get to the errors below any known workaround ? ../../gcc/libiberty/regex.c:4497: error: undefined reference to '__asan_report_store1' ../../gcc/libiberty/regex.c:4497: error: undefined reference to You need http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00810.html http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00809.html
[Bug sanitizer/55374] [asan] -static-libasan -static-libstdc++ doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55374 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2012-12-20 19:58:44 UTC --- (In reply to comment #7) Thanks now bootstrap completes. It seems to me that libgfortran is not built with -fsanitize=address despite --with-build-config=bootstrap-asan Is there a way to make that happen ? bootstrap-asan is for bootstrapping GCC with -fsanitize=address. It is orthogonal from compiling target run-time libraries with -fsanitize=address.
[Bug bootstrap/55792] New: Bad memory access with profiledbootstrap and LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792 Bug #: 55792 Summary: Bad memory access with profiledbootstrap and LTO Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86-64, revision 193848 configured with --prefix=/usr/local --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-languages=c,c++ --enable-bootstrap --with-build-config=bootstrap-lto --disable-werror gave /tmp/ccDjvfDH.s: Assembler messages: /tmp/ccDjvfDH.s:1094284: Error: invalid character (0xc7) in mnemonic make[4]: *** [/tmp/cc66Zjao.ltrans24.ltrans.o] Error 1 make[4]: *** Waiting for unfinished jobs 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[3]: *** [cc1plus] Error 1 rm gcov.pod cpp.pod gfdl.pod gcc.pod fsf-funding.pod make[3]: Leaving directory `/export/project/git/gcc-regression-bootstrap/master/193848/bld/gcc' make[2]: *** [all-stagefeedback-gcc] Error 2 make[2]: Leaving directory `/export/project/git/gcc-regression-bootstrap/master/193848/bld' make[1]: *** [stagefeedback-bubble] Error 2 make[1]: Leaving directory `/export/project/git/gcc-regression-bootstrap/master/193848/bld' make: *** [profiledbootstrap] Error 2 The invalid character (0xc7) is in DWARF debug section.
[Bug bootstrap/55792] Bad memory access with profiledbootstrap and LTO
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
[Bug bootstrap/55792] Bad memory access with profiledbootstrap and LTO
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 0x0008 (pc 0x0067ce31 sp 0x781baa60 bp 0x0100 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_mxdw_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
[Bug rtl-optimization/55838] [4.6/4.7/4.8 Regression] ICE in extract_insn (unrecognizable insn) with -O -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55838 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2013-01-01 18:06:37 UTC --- (const_int 129 [0x81]) isn't considered as a valid const int for QImode.
[Bug rtl-optimization/55838] [4.6/4.7/4.8 Regression] ICE in extract_insn (unrecognizable insn) with -O -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55838 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2013-01-01 18:53:32 UTC --- The original regression was introduced by http://gcc.gnu.org/ml/gcc-cvs/2004-05/msg00653.html
[Bug rtl-optimization/55838] [4.6/4.7/4.8 Regression] ICE in extract_insn (unrecognizable insn) with -O -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55838
--- Comment #10 from H.J. Lu hjl.tools at gmail dot com 2013-01-01 23:02:02
UTC ---
This patch avoids using (const_int 129 [0x81]) as step in QImode:
diff --git a/gcc/loop-iv.c b/gcc/loop-iv.c
index 50b7536..aafaae4 100644
--- a/gcc/loop-iv.c
+++ b/gcc/loop-iv.c
@@ -421,6 +421,8 @@ iv_constant (struct rtx_iv *iv, rtx cst, enum machine_mode
mode)
static bool
iv_subreg (struct rtx_iv *iv, enum machine_mode mode)
{
+ rtx step;
+
/* If iv is invariant, just calculate the new value. */
if (iv-step == const0_rtx
!iv-first_special)
@@ -442,13 +444,17 @@ iv_subreg (struct rtx_iv *iv, enum machine_mode mode)
if (GET_MODE_BITSIZE (mode) GET_MODE_BITSIZE (iv-mode))
return false;
+ step = simplify_gen_binary (MULT, iv-extend_mode, iv-step, iv-mult);
+ if (trunc_int_for_mode (INTVAL (step), mode) != INTVAL (step))
+ return false;
+
iv-extend = IV_UNKNOWN_EXTEND;
iv-mode = mode;
iv-base = simplify_gen_binary (PLUS, iv-extend_mode, iv-delta,
simplify_gen_binary (MULT, iv-extend_mode,
iv-base, iv-mult));
- iv-step = simplify_gen_binary (MULT, iv-extend_mode, iv-step, iv-mult);
+ iv-step = step;
iv-mult = const1_rtx;
iv-delta = const0_rtx;
iv-first_special = false;
[Bug sanitizer/55844] New: -fsanitize=address -Os -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55844
Bug #: 55844
Summary: -fsanitize=address -Os -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer -m64 doesn't work
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: do...@gcc.gnu.org, dvyu...@gcc.gnu.org,
ja...@gcc.gnu.org, k...@gcc.gnu.org
c-c++-common/asan/null-deref-1.c fails with -m64 since
-fsanitize=address -Os -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
-m64
still omit frame pointer:
[hjl@gnu-tools-1 gcc]$ cat /tmp/x.c
void
NullDeref(int *ptr)
{
ptr[10]++;
}
[hjl@gnu-tools-1 gcc]$
/export/build/gnu/gcc-x32-mx32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32-mx32/build-x86_64-linux/gcc/ /tmp/x.c -S -Os
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 -fsanitize=address
[hjl@gnu-tools-1 gcc]$ cat x.s
.filex.c
.text
.globlNullDeref
.typeNullDeref, @function
NullDeref:
.LFB0:
.cfi_startproc
movq%rdi, %rax
leaq40(%rdi), %rdi
movabsq$17592186044416, %rdx
movq%rdi, %rcx
shrq$3, %rcx
movb(%rcx,%rdx), %dl
movq%rdi, %rcx
andl$7, %ecx
addl$3, %ecx
cmpb%dl, %cl
jl.L2
testb%dl, %dl
je.L2
pushq%rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
call__asan_report_load4
.L2:
.cfi_def_cfa 7, 8
.cfi_restore 6
incl40(%rax)
ret
.cfi_endproc
.LFE0:
.sizeNullDeref, .-NullDeref
.section.text.startup,ax,@progbits
.type_GLOBAL__sub_I_00099_0_NullDeref, @function
_GLOBAL__sub_I_00099_0_NullDeref:
.LFB1:
.cfi_startproc
pushq%rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
popq%rbp
.cfi_def_cfa 7, 8
jmp__asan_init
.cfi_endproc
.LFE1:
.size_GLOBAL__sub_I_00099_0_NullDeref,
.-_GLOBAL__sub_I_00099_0_NullDeref
.section.init_array.00099,aw
.align 8
.quad_GLOBAL__sub_I_00099_0_NullDeref
.identGCC: (GNU) 4.8.0 20130101 (experimental)
.section.note.GNU-stack,,@progbits
[hjl@gnu-tools-1 gcc]$
/export/build/gnu/gcc-x32-mx32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32-mx32/build-x86_64-linux/gcc/ /tmp/x.c -S -Os
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64
[hjl@gnu-tools-1 gcc]$ cat x.s
.filex.c
.text
.globlNullDeref
.typeNullDeref, @function
NullDeref:
.LFB0:
.cfi_startproc
pushq%rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
incl40(%rdi)
movq%rsp, %rbp
.cfi_def_cfa_register 6
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.sizeNullDeref, .-NullDeref
.identGCC: (GNU) 4.8.0 20130101 (experimental)
.section.note.GNU-stack,,@progbits
[hjl@gnu-tools-1 gcc]$
[Bug bootstrap/55792] Bad memory access with profiledbootstrap and LTO
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]$
[Bug bootstrap/55792] Bad memory access with profiledbootstrap and LTO
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::reservetree_node*, va_gc(vectree_node*, va_gc, vl_embed*, unsigned int, bool) /export/gnu/import/git/gcc/gcc/vec.h:379 0x52ae82 bool vec_safe_reservetree_node*, va_gc(vectree_node*, va_gc, vl_embed*, unsigned int, bool) /export/gnu/import/git/gcc/gcc/vec.h:657 0x53c953 tree_node** vec_safe_pushtree_node*, va_gc(vectree_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'
[Bug bootstrap/55792] Bad memory access with profiledbootstrap and LTO
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=0x71ab8000, entry=0x0) at /export/gnu/import/git/gcc/gcc/ggc-page.c:640 #1 0x00544514 in free_page (entry=0x17a1d70) at /export/gnu/import/git/gcc/gcc/ggc-page.c:948 #2 0x00545a41 in sweep_pages () at /export/gnu/import/git/gcc/gcc/ggc-page.c:1886 #3 0x00545ed0 in ggc_collect () at /export/gnu/import/git/gcc/gcc/ggc-page.c:2094 #4 0x008acc6e in execute_todo (flags=2) at /export/gnu/import/git/gcc/gcc/passes.c:2023 #5 0x008ad5cd in execute_one_pass (pass=0x16bd620 pass_final) at /export/gnu/import/git/gcc/gcc/passes.c:2349 #6 0x008ad732 in execute_pass_list (pass=0x16bd620 pass_final) at /export/gnu/import/git/gcc/gcc/passes.c:2383 #7 0x008ad763 in execute_pass_list (pass=0x16be6c0 pass_postreload) at /export/gnu/import/git/gcc/gcc/passes.c:2384 #8 0x008ad763 in execute_pass_list ( pass=0x16be660 pass_rest_of_compilation) at /export/gnu/import/git/gcc/gcc/passes.c:2384 #9 0x005d9c06 in expand_function (node=0x71b55250) at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641 #10 0x005da0c1 in expand_all_functions () at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745 ---Type return to continue, or q return to quit--- #11 0x005dab4b in compile () at /export/gnu/import/git/gcc/gcc/cgraphunit.c:2043 #12 0x0053beaa in lto_main () at /export/gnu/import/git/gcc/gcc/lto/lto.c:3393 #13 0x00998859 in compile_file () at /export/gnu/import/git/gcc/gcc/toplev.c:545 #14 0x0099a83c in do_compile () at /export/gnu/import/git/gcc/gcc/toplev.c:1878 #15 0x0099a9a7 in toplev_main (argc=26, argv=0x7fffdff8) at /export/gnu/import/git/gcc/gcc/toplev.c:1954 #16 0x00ffeee0 in main (argc=26, argv=0x7fffdff8) at /export/gnu/import/git/gcc/gcc/main.c:36 (gdb)
[Bug bootstrap/55792] Bad memory access with profiledbootstrap and LTO
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.
[Bug bootstrap/55792] Bad memory access with profiledbootstrap and LTO
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.
[Bug driver/55470] Support -fuse-ld=bfd and -fuse-ld=gold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55470 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2013-01-07 17:17:13 UTC --- Fixed.
[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
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
[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
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=0d=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]$
[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
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=0d=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.
[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
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.
[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
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 0x00751f32 in gimple_copy (stmt=0x7fffe8d75a00) at /export/gnu/import/git/gcc/gcc/gimple.c:2205 #2 0x009c960d in gimple_duplicate_bb (bb=0x7fffe8d768f0) at /export/gnu/import/git/gcc/gcc/tree-cfg.c:5397 #3 0x005b27a5 in duplicate_block (bb=0x7fffe8d768f0, e=0x7fffe8d793f0, after=0x7fffe8d76888) at /export/gnu/import/git/gcc/gcc/cfghooks.c:1012 #4 0x0099c511 in tail_duplicate () at /export/gnu/import/git/gcc/gcc/tracer.c:323 #5 0x0099c765 in tracer () at /export/gnu/import/git/gcc/gcc/tracer.c:380 #6 0x008ae0e6 in execute_one_pass (pass=0x16d18a0 pass_tracer) at /export/gnu/import/git/gcc/gcc/passes.c:2335 #7 0x008ae2da in execute_pass_list (pass=0x16d18a0 pass_tracer) at /export/gnu/import/git/gcc/gcc/passes.c:2383 #8 0x008ae30b in execute_pass_list ( pass=0x16d07e0 pass_all_optimizations) at /export/gnu/import/git/gcc/gcc/passes.c:2384 #9 0x005da366 in expand_function (node=0x717536f0) at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641 #10 0x005da821 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 0x008ad5cb in execute_function_todo (data=0x8800) at /export/gnu/import/git/gcc/gcc/passes.c:1952 #2 0x008ac965 in do_per_function ( callback=0x8ad4ae execute_function_todo(void*), data=0x8800) at /export/gnu/import/git/gcc/gcc/passes.c:1703 #3 0x008ad765 in execute_todo (flags=34816) at /export/gnu/import/git/gcc/gcc/passes.c:2001 #4 0x008ae175 in execute_one_pass ( pass=0x16d3220 pass_cleanup_cfg_post_optimizing) at /export/gnu/import/git/gcc/gcc/passes.c:2349 #5 0x008ae2da in execute_pass_list ( pass=0x16d3220 pass_cleanup_cfg_post_optimizing) at /export/gnu/import/git/gcc/gcc/passes.c:2383 #6 0x005da366 in expand_function (node=0x717536f0) at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641 #7 0x005da821 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 0x005a7786 in expand_gimple_stmt (stmt=0x7fffe8e0a320) at /export/gnu/import/git/gcc/gcc/cfgexpand.c:2305 #2 0x005ad975 in expand_gimple_basic_block (bb=0x7fffe8d76888, disable_tail_calls=false) at /export/gnu/import/git/gcc/gcc/cfgexpand.c:4084 #3 0x005af426 in gimple_expand_cfg () at /export/gnu/import/git/gcc/gcc/cfgexpand.c:4603 #4 0x008ae0e6 in execute_one_pass (pass=0x16ce300 pass_expand) at /export/gnu/import/git/gcc/gcc/passes.c:2335 #5 0x008ae2da in execute_pass_list (pass=0x16ce300 pass_expand) at /export/gnu/import/git/gcc/gcc/passes.c:2383 #6 0x005da366 in expand_function (node=0x717536f0) at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641 #7 0x005da821 in expand_all_functions () at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745 #8 0x005db2ab in compile () at /export/gnu/import/git/gcc/gcc/cgraphunit.c:2043 #9 0x0053c60a in lto_main () at /export/gnu/import/git/gcc/gcc/lto/lto.c:3390 #10 0x00999401 in compile_file () at /export/gnu/import/git/gcc/gcc/toplev.c:545
[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
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 0x00336b4882ee in __memset_sse2 () from /lib64/libc.so.6
#1 0x00545fdf in clear_marks ()
at /export/gnu/import/git/gcc/gcc/ggc-page.c:1815
#2 0x00546621 in ggc_collect ()
at /export/gnu/import/git/gcc/gcc/ggc-page.c:2086
#3 0x008ad816 in execute_todo (flags=2102)
at /export/gnu/import/git/gcc/gcc/passes.c:2023
#4 0x008ae175 in execute_one_pass (pass=0x17b9c70)
at /export/gnu/import/git/gcc/gcc/passes.c:2349
#5 0x008ae2da in execute_pass_list (pass=0x17b9c70)
at /export/gnu/import/git/gcc/gcc/passes.c:2383
#6 0x008ae30b in execute_pass_list (
pass=0x16d07e0 pass_all_optimizations)
at /export/gnu/import/git/gcc/gcc/passes.c:2384
#7 0x005da366 in expand_function (node=0x716f5378)
at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641
#8 0x005da821 in expand_all_functions ()
at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745
#9 0x005db2ab in compile ()
at /export/gnu/import/git/gcc/gcc/cgraphunit.c:2043
#10 0x0053c60a in lto_main ()
at /export/gnu/import/git/gcc/gcc/lto/lto.c:3390
#11 0x00999401 in compile_file ()
---Type return to continue, or q return to quit---
at /export/gnu/import/git/gcc/gcc/toplev.c:545
#12 0x0099b3e4 in do_compile ()
at /export/gnu/import/git/gcc/gcc/toplev.c:1878
#13 0x0099b54f in toplev_main (argc=28, argv=0x7fffdc78)
at /export/gnu/import/git/gcc/gcc/toplev.c:1954
#14 0x00fff958 in main (argc=28, argv=0x7fffdc78)
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.
[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
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 0x0101d8cf in get_combined_adhoc_loc (set=0x77ffc000, locus=968541695, data=0x7fffe8d6fe60) at /export/gnu/import/git/gcc/libcpp/line-map.c:146 #1 0x009f839d in gimple_set_block (g=0x7fffe8d759b0, block=0x7fffe8d6fe60) at /export/gnu/import/git/gcc/gcc/gimple.h:1226 #2 0x00a016fd in remap_gimple_stmt (stmt=0x7fffe910e0a0, id=0x7fffd900) at /export/gnu/import/git/gcc/gcc/tree-inline.c:1473 #3 0x00a01a04 in copy_bb (id=0x7fffd900, bb=0x7fffe910c888, frequency_scale=100, count_scale=1779) at /export/gnu/import/git/gcc/gcc/tree-inline.c:1539 #4 0x00a03f56 in copy_cfg_body (id=0x7fffd900, count=48912247, frequency_scale=100, entry_block_map=0x7138aaf8, exit_block_map=0x7fffe8d58270, blocks_to_copy=0x0, new_entry=0x0) at /export/gnu/import/git/gcc/gcc/tree-inline.c:2259 #5 0x00a047fa in copy_body (id=0x7fffd900, count=48912247, frequency_scale=100, entry_block_map=0x7138aaf8, exit_block_map=0x7fffe8d58270, blocks_to_copy=0x0, new_entry=0x0) at /export/gnu/import/git/gcc/gcc/tree-inline.c:2457 #6 0x00a0881e in expand_call_inline (bb=0x7138aaf8, stmt=0x71390980, id=0x7fffd900) at /export/gnu/import/git/gcc/gcc/tree-inline.c:4041 #7 0x00a08c6f in gimple_expand_calls_inline (bb=0x7138aaf8, id=0x7fffd900) at /export/gnu/import/git/gcc/gcc/tree-inline.c:4147 But tree node in line_table is ignored by GC.
[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
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=0x7fffd580, id=0x7fffd900) 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=0x7fffd580, id=0x7fffd900) at /export/gnu/import/git/gcc/gcc/tree-inline.c:624 #1 0x009fe52a in remap_blocks (block=0x7fffe9107550, id=0x7fffd900) at /export/gnu/import/git/gcc/gcc/tree-inline.c:645 #2 0x009fe586 in remap_blocks (block=0x7fffe9107500, id=0x7fffd900) at /export/gnu/import/git/gcc/gcc/tree-inline.c:648 #3 0x009fe586 in remap_blocks (block=0x7fffe91074b0, id=0x7fffd900) at /export/gnu/import/git/gcc/gcc/tree-inline.c:648 #4 0x009fe586 in remap_blocks (block=0x7fffe9107460, id=0x7fffd900) at /export/gnu/import/git/gcc/gcc/tree-inline.c:648 #5 0x009fe586 in remap_blocks (block=0x7fffe9107410, id=0x7fffd900) at /export/gnu/import/git/gcc/gcc/tree-inline.c:648 #6 0x00a082fc in expand_call_inline (bb=0x7138aaf8, stmt=0x71390980, id=0x7fffd900) at /export/gnu/import/git/gcc/gcc/tree-inline.c:3958 #7 0x00a08c6f in gimple_expand_calls_inline (bb=0x7138aaf8, id=0x7fffd900) at /export/gnu/import/git/gcc/gcc/tree-inline.c:4147 #8 0x00a0924b in optimize_inline_calls (fn=0x7fffec94b300) at /export/gnu/import/git/gcc/gcc/tree-inline.c:4301 #9 0x007d2f1e in inline_transform (node=0x717536f0) at /export/gnu/import/git/gcc/gcc/ipa-inline-transform.c:418 #10 0x008adbe3 in execute_one_ipa_transform_pass (node=0x717536f0, 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 0x008add31 in execute_all_ipa_transforms () at /export/gnu/import/git/gcc/gcc/passes.c:2213 #12 0x005da348 in expand_function (node=0x717536f0) at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1634 #13 0x005da821 in expand_all_functions () at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745 #14 0x005db2ab in compile () at /export/gnu/import/git/gcc/gcc/cgraphunit.c:2043 #15 0x0053c60a in lto_main () at /export/gnu/import/git/gcc/gcc/lto/lto.c:3390 #16 0x00999401 in compile_file () at /export/gnu/import/git/gcc/gcc/toplev.c:545 #17 0x0099b3e4 in do_compile () at /export/gnu/import/git/gcc/gcc/toplev.c:1878 #18 0x0099b54f in toplev_main (argc=28, argv=0x7fffdc78) at /export/gnu/import/git/gcc/gcc/toplev.c:1954 #19 0x00fff958 in main (argc=28, argv=0x7fffdc78) at /export/gnu/import/git/gcc/gcc/main.c:36 (gdb)
[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
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=0x7fffd690, id=0x7fffd840) at /export/gnu/import/git/gcc/gcc/tree-inline.c:624 #1 0x009fe52a in remap_blocks (block=0x71393d20, id=0x7fffd840) at /export/gnu/import/git/gcc/gcc/tree-inline.c:645 #2 0x009fe586 in remap_blocks (block=0x71385370, id=0x7fffd840) at /export/gnu/import/git/gcc/gcc/tree-inline.c:648 #3 0x009fe586 in remap_blocks (block=0x71385320, id=0x7fffd840) at /export/gnu/import/git/gcc/gcc/tree-inline.c:648 ---Type return to continue, or q return to quit--- #4 0x009fe586 in remap_blocks (block=0x71385280, id=0x7fffd840) at /export/gnu/import/git/gcc/gcc/tree-inline.c:648 #5 0x009fe586 in remap_blocks (block=0x713851e0, id=0x7fffd840) at /export/gnu/import/git/gcc/gcc/tree-inline.c:648 #6 0x00a0bc63 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 0x007d2d05 in save_inline_function_body (node=0x71753818) at /export/gnu/import/git/gcc/gcc/ipa-inline-transform.c:354 #8 0x007d2ec6 in inline_transform (node=0x71753818) at /export/gnu/import/git/gcc/gcc/ipa-inline-transform.c:411 #9 0x008adbe3 in execute_one_ipa_transform_pass (node=0x71753818, ipa_pass=0x16cfc80 pass_ipa_inline) at /export/gnu/import/git/gcc/gcc/passes.c:2177 #10 0x008add31 in execute_all_ipa_transforms () at /export/gnu/import/git/gcc/gcc/passes.c:2213 #11 0x005da348 in expand_function (node=0x71753818) at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1634 ---Type return to continue, or q return to quit--- #12 0x005da821 in expand_all_functions () at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745 #13 0x005db2ab in compile () at /export/gnu/import/git/gcc/gcc/cgraphunit.c:2043 #14 0x0053c60a in lto_main () at /export/gnu/import/git/gcc/gcc/lto/lto.c:3390 #15 0x00999401 in compile_file () at /export/gnu/import/git/gcc/gcc/toplev.c:545 #16 0x0099b3e4 in do_compile () at /export/gnu/import/git/gcc/gcc/toplev.c:1878 #17 0x0099b54f in toplev_main (argc=28, argv=0x7fffdc78) at /export/gnu/import/git/gcc/gcc/toplev.c:1954 #18 0x00fff958 in main (argc=28, argv=0x7fffdc78) at /export/gnu/import/git/gcc/gcc/main.c:36 (gdb) p id-block $90 = (tree) 0x0
[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
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.
[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
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.
[Bug bootstrap/55556] gcc/exec-tool.in isn't parallel build safe in combined tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2013-01-11 13:49:33 UTC --- Fixed by: http://gcc.gnu.org/ml/gcc-cvs/2013-01/msg00282.html
[Bug target/55953] hand loop faster then builtin memset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55953 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2013-01-12 02:10:33 UTC --- Can you try memset in glibc instead of builtin memset?
[Bug tree-optimization/48766] [4.6/4.7/4.8 Regression] Infinite recursion in fold_binary_loc()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48766 --- Comment #13 from H.J. Lu hjl.tools at gmail dot com 2013-01-14 15:48:41 UTC --- (In reply to comment #12) Created attachment 29161 [details] gcc48-pr48766.patch Untested fix. Seems in the previous option processing the negative options cancel their corresponding positive options (and vice versa), and only the last occurrence of the option from the command line remains and the patch just disables -fwrapv if -ftrapv comes after -fwrapv, and vice versa. So e.g. -fwrapv -ftrapv -fwrapv results in -fwrapv -fwrapv -ftrapv results in -ftrapv -fwrapv -ftrapv -fno-wrapv results in -ftrapv -ftrapv -fwrapv -fno-trapv results in -fwrapv etc. Why not use Negative in common.opt?
[Bug fortran/54767] [4.7/4.8 Regression] Incorrect code generated with -O2 -fcheck=bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54767 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2013-01-14 21:46:17 UTC --- It is caused by revision 176918: http://gcc.gnu.org/ml/gcc-cvs/2011-07/msg01186.html
[Bug sanitizer/55739] asan doesn't work on common symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739 --- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2013-01-14 22:11:16 UTC --- Created attachment 29165 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29165 A prototype If as, ld and ld.so provide size info via symbol@size, we can do .LASAN0: # __beg: .quadcommon_data # __size: .quadcommon_data@size # __size_with_redzone: .quadcommon_data@size + 40 # __name: .quad.LC0 # __has_dynamic_init: .quad0 [hjl@gnu-6 pr55739]$ make /export/build/gnu/gcc/build-x86_64-linux/gcc/../../release/usr/gcc-4.8.0/bin/gcc -fsanitize=address -O -static-libasan -c -o m.o m.c /export/build/gnu/gcc/build-x86_64-linux/gcc/../../release/usr/gcc-4.8.0/bin/gcc -fsanitize=address -O -static-libasan -c -o c.o c.c /export/build/gnu/gcc/build-x86_64-linux/gcc/../../release/usr/gcc-4.8.0/bin/gcc -fsanitize=address -O -static-libasan -c size.S /export/build/gnu/gcc/build-x86_64-linux/gcc/../../release/usr/gcc-4.8.0/bin/gcc -fsanitize=address -O -static-libasan -o x m.o c.o size.o ./x 10: 0 29: 1 = ==1454== ERROR: AddressSanitizer: global-buffer-overflow on address 0x02e70a18 at pc 0x401dc5 bp 0x7fffde90 sp 0x7fffde70 WRITE of size 4 at 0x02e70a18 thread T0 #0 0x401dc4 (/export/home/hjl/bugs/gcc/pr55739/x+0x401dc4) 0x02e70a18 is located 0 bytes to the right of global variable 'c (d.c)' (0x2e709a0) of size 120 'c (d.c)' is ascii string '' Shadow bytes around the buggy address: 0x105ce0f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x105ce100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x105ce110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x105ce120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x105ce130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =0x105ce140: 00 00 00[f9]f9 f9 f9 f9 00 00 00 00 00 00 00 00 0x105ce150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x105ce160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x105ce170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x105ce180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x105ce190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap righ redzone: fb Freed Heap region: fd Stack left redzone:f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return:f5 Stack use after scope: f8 Global redzone:f9 Global init order: f6 Poisoned by user: f7 ASan internal: fe Stats: 0M malloced (0M for red zones) by 0 calls Stats: 0M realloced by 0 calls Stats: 0M freed by 0 calls Stats: 0M really freed by 0 calls Stats: 0M (0M-0M) mmaped; 0 maps, 0 unmaps mmaps by size class: mallocs by size class: frees by size class: rfrees by size class: Stats: malloc large: 0 small slow: 0 Stats: StackDepot: 0 ids; 0M mapped ==1454== ABORTING make: *** [all] Error 1 [hjl@gnu-6 pr55739]$ readelf -s c.o | grep common_data 17: 0020 120 OBJECT GLOBAL DEFAULT COM common_data [hjl@gnu-6 pr55739]$
[Bug sanitizer/55739] asan doesn't work on common symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739 --- Comment #7 from H.J. Lu hjl.tools at gmail dot com 2013-01-15 02:19:55 UTC --- There are already R_386_SIZE32 38 word32 Z + A R_X86_64_SIZE32 32 word32 Z + A R_X86_64_SIZE64 33 word64 Z + A They should work here.
[Bug debug/56006] New: [4.8 Regression] Many guality testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56006 Bug #: 56006 Summary: [4.8 Regression] Many guality testsuite failures Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86, revision 195227 gave FAIL: gcc.dg/guality/drap.c -O1 line 21 a == 5 FAIL: gcc.dg/guality/drap.c -O1 line 22 b == 6 FAIL: gcc.dg/guality/drap.c -O2 line 21 a == 5 FAIL: gcc.dg/guality/drap.c -O2 line 22 b == 6 FAIL: gcc.dg/guality/drap.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 21 a == 5 FAIL: gcc.dg/guality/drap.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 22 b == 6 FAIL: gcc.dg/guality/drap.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects line 21 a == 5 FAIL: gcc.dg/guality/drap.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects line 22 b == 6 FAIL: gcc.dg/guality/drap.c -O3 -fomit-frame-pointer line 21 a == 5 FAIL: gcc.dg/guality/drap.c -O3 -fomit-frame-pointer line 22 b == 6 FAIL: gcc.dg/guality/drap.c -O3 -g line 21 a == 5 FAIL: gcc.dg/guality/drap.c -O3 -g line 22 b == 6 FAIL: gcc.dg/guality/drap.c -Os line 21 a == 5 FAIL: gcc.dg/guality/drap.c -Os line 22 b == 6 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg1 == 1 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg2 == 2 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg3 == 3 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg4 == 4 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg5 == 5 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg6 == 6 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg7 == 30 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg1 == 1 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg2 == 2 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg3 == 3 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg4 == 4 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg5 == 5 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg6 == 6 FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg7 == 30 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 16 arg1 == 1 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 16 arg2 == 2 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 16 arg3 == 3 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 16 arg4 == 4 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 16 arg5 == 5 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 16 arg6 == 6 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 16 arg7 == 30 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 18 arg1 == 1 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 18 arg2 == 2 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 18 arg3 == 3 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 18 arg4 == 4 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 18 arg5 == 5 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 18 arg6 == 6 FAIL: gcc.dg/guality/pr36728-1.c -O2 line 18 arg7 == 30 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 16 arg1 == 1 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 16 arg2 == 2 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 16 arg3 == 3 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 16 arg4 == 4 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 16 arg5 == 5 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 16 arg6 == 6 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 16 arg7 == 30 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 18 arg1 == 1 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 18 arg2 == 2 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 18 arg3 == 3 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 18 arg4 == 4 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 18 arg5 == 5 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 18 arg6 == 6 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 18 arg7 == 30 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects line 16 arg4 == 4 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects line 16 arg5 == 5 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects line 16 arg6 == 6 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects line 16 arg7
[Bug sanitizer/55739] asan doesn't work on common symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2013-01-17 16:40:48 UTC --- (In reply to comment #7) There are already R_386_SIZE32 38 word32 Z + A R_X86_64_SIZE32 32 word32 Z + A R_X86_64_SIZE64 33 word64 Z + A Their support has been checked into glibc and binutils. Can address sanitizer use them?
[Bug sanitizer/55739] asan doesn't work on common symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739 --- Comment #10 from H.J. Lu hjl.tools at gmail dot com 2013-01-17 16:48:53 UTC --- (In reply to comment #9) (In reply to comment #8) Their support has been checked into glibc and binutils. Can address sanitizer use them? What about all the other targets that asan now supports? Those targets won't support common symbols until they implement size relocation.
[Bug sanitizer/55739] asan doesn't work on common symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739 --- Comment #12 from H.J. Lu hjl.tools at gmail dot com 2013-01-17 16:57:29 UTC --- Size relocation means that all instances of # __beg: .quadcommon_data # __size: .quadcommon_data@size # __size_with_redzone: .quadcommon_data@size + 40 resolve to the same address and size at link-time or run-time. Can we take advantage of it?
[Bug ada/56030] Ada fails to build when targeting x32 non multilib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56030 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Depends on||54040 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2013-01-18 20:06:03 UTC --- X32 isn't usable for Ada. See PR 54040.
