[Bug libgcc/56846] _Unwind_Backtrace on ARM and noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846 --- Comment #14 from Yvan Roux yroux at gcc dot gnu.org --- No I meant FSF 4.8 branch. The bug log only show a commit to trunk and GCC 4.9 FSF branch. It's only in trunk (the backport I made was in Linaro 4.9 branch). For FSF branches check with the maintainers and/or ping Tony, I don't mind doing it, but it's maybe better if done by the patch owner.
[Bug sanitizer/63845] New: c-c++-common/asan/bitfield-1.c fails on i?86 -with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63845 Bug ID: 63845 Summary: c-c++-common/asan/bitfield-1.c fails on i?86 -with -fpic Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Target: i686-pc-linux-gnu Found when running testsuite on x86_64 -m32 with -fpic: $ ~/gcc-build/gcc/cc1 -quiet -fsanitize=address -m32 -fpic bitfield-1.c bitfield-1.c: In function ‘main’: bitfield-1.c:23:1: internal compiler error: in df_refs_verify, at df-scan.c:4088 } ^ 0x6e9a6b df_refs_verify ../../gcc-svn/trunk/gcc/df-scan.c:4088 0x6ed861 df_insn_refs_verify ../../gcc-svn/trunk/gcc/df-scan.c:4161 0x6ede02 df_bb_verify ../../gcc-svn/trunk/gcc/df-scan.c:4188 0x6f1457 df_scan_verify() ../../gcc-svn/trunk/gcc/df-scan.c:4320 0x6df084 df_verify() ../../gcc-svn/trunk/gcc/df-core.c:1860 0x6df084 df_analyze_1 ../../gcc-svn/trunk/gcc/df-core.c:1248 0x8ddbdb ira ../../gcc-svn/trunk/gcc/ira.c:5158 0x8ddbdb execute ../../gcc-svn/trunk/gcc/ira.c:5507 Please submit a full bug report, The failure with -O2 is a bit different: $ ~/gcc-build/gcc/cc1 -quiet -fsanitize=address -m32 -fpic -O2 bitfield-1.c bitfield-1.c: In function ‘main’: bitfield-1.c:23:1: internal compiler error: Segmentation fault } ^ 0xa4ea8f crash_signal ../../gcc-svn/trunk/gcc/toplev.c:358 0x6ea7ff df_install_ref ../../gcc-svn/trunk/gcc/df-scan.c:2331 0x6edfa5 df_install_refs ../../gcc-svn/trunk/gcc/df-scan.c:2413 0x6ee57b df_refs_add_to_chains ../../gcc-svn/trunk/gcc/df-scan.c:2466 0x6f07dc df_bb_refs_record(int, bool) ../../gcc-svn/trunk/gcc/df-scan.c:3399 0x6f098c df_scan_blocks() ../../gcc-svn/trunk/gcc/df-scan.c:629 0x6ddb52 rest_of_handle_df_initialize ../../gcc-svn/trunk/gcc/df-core.c:746 Please submit a full bug report,
[Bug sanitizer/63845] [5 Regression] c-c++-common/asan/bitfield-1.c fails on i?86 -with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63845 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-13 CC||mpolacek at gcc dot gnu.org Known to work||4.9.2 Target Milestone|--- |5.0 Summary|c-c++-common/asan/bitfield- |[5 Regression] |1.c fails on i?86 -with |c-c++-common/asan/bitfield- |-fpic |1.c fails on i?86 -with ||-fpic Ever confirmed|0 |1 Known to fail||5.0 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug sanitizer/63845] [5 Regression] c-c++-common/asan/bitfield-[12345].c fails on i?86 -with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63845 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Summary|[5 Regression] |[5 Regression] |c-c++-common/asan/bitfield- |c-c++-common/asan/bitfield- |1.c fails on i?86 -with |[12345].c fails on i?86 |-fpic |-with -fpic --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- -Os -g fails: ~/gcc-build/gcc/cc1 -quiet -fsanitize=address -m32 -fpic -Os -g bitfield-1.c bitfield-1.c: In function ‘main’: bitfield-1.c:23:1: internal compiler error: in operator[], at vec.h:736 } ^ 0x1046c07 vecdf_ref_d*, va_heap, vl_embed::operator[](unsigned int) ../../gcc-svn/trunk/gcc/vec.h:736 0x1046c07 vecdf_ref_d*, va_heap, vl_ptr::operator[](unsigned int) ../../gcc-svn/trunk/gcc/vec.h:1202 0x1046c07 process_uses ../../gcc-svn/trunk/gcc/fwprop.c:212 0x10472ad single_def_use_dom_walker::before_dom_children(basic_block_def*) ../../gcc-svn/trunk/gcc/fwprop.c:253 0x103e3d7 dom_walker::walk(basic_block_def*) ../../gcc-svn/trunk/gcc/domwalk.c:188 0x1046884 build_single_def_use_links ../../gcc-svn/trunk/gcc/fwprop.c:310 0x1046884 fwprop_init ../../gcc-svn/trunk/gcc/fwprop.c:1415 0x104875a fwprop ../../gcc-svn/trunk/gcc/fwprop.c:1460 0x104875a execute ../../gcc-svn/trunk/gcc/fwprop.c:1509 Please submit a full bug report,
[Bug sanitizer/63846] New: c-c++-common/asan/misalign-[12].c fails on i?86 with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63846
Bug ID: 63846
Summary: c-c++-common/asan/misalign-[12].c fails on i?86 with
-fpic
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Found when running testsuite on x86_64 -m32 with -fpic:
$ ~/gcc-build/gcc/cc1 -quiet -fsanitize=address -m32 -fpic misalign-1.c
misalign-1.c: In function ‘main’:
misalign-1.c:36:1: error: insn does not satisfy its constraints:
}
^
(insn 122 3 4 2 (set (reg:SI 0 ax [109])
(reg:SI 109)) misalign-1.c:27 90 {*movsi_internal}
(nil))
misalign-1.c:36:1: internal compiler error: in extract_constrain_insn_cached,
at recog.c:2242
0x9efbf8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-svn/trunk/gcc/rtl-error.c:110
0x9efc1f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-svn/trunk/gcc/rtl-error.c:121
0x9bf159 extract_constrain_insn_cached(rtx_insn*)
../../gcc-svn/trunk/gcc/recog.c:2242
0xd81e57 insn_default_length(rtx_insn*)
../../gcc-svn/trunk/gcc/config/i386/i386.md:13082
0x788292 shorten_branches(rtx_insn*)
../../gcc-svn/trunk/gcc/final.c:1208
0x78891f rest_of_handle_shorten_branches
../../gcc-svn/trunk/gcc/final.c:4567
0x78891f execute
../../gcc-svn/trunk/gcc/final.c:4596
Please submit a full bug report,
[Bug tree-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61559 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #17 from Richard Biener rguenth at gcc dot gnu.org --- Fixed. Note I've only implemented what is necessary for the testcase not what was discussed additionally.
[Bug tree-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61559 --- Comment #16 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Nov 13 08:45:29 2014 New Revision: 217464 URL: https://gcc.gnu.org/viewcvs?rev=217464root=gccview=rev Log: 2014-12-13 Richard Biener rguent...@suse.de PR middle-end/61559 * match.pd: Implement bswap patterns for transforms checked by gcc.dg/builtin-bswap-8.c. Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd
[Bug ipa/63671] [5 Regression] 21% tramp3d-v4 performance hit due to -fdevirtualize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63671 --- Comment #10 from rguenther at suse dot de rguenther at suse dot de --- On Wed, 12 Nov 2014, hubicka at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63671 --- Comment #9 from Jan Hubicka hubicka at gcc dot gnu.org --- With early VRP (but also without) the inliner seems to now suffer from extreme roundoff errors at badness. With VRP the first uninlined function still has badness 0: Considering std::_Bit_reference std::_Bit_reference::operator=(bool)/797 with 15 size to be inlined into built-in/47767 in /aux/hubicka/tramp3d-v4.cpp:38764 Estimated badness is 0, frequency 0.71. Badness calculation for built-in/47767 - std::_Bit_reference std::_Bit_reference::operator=(bool)/797 size growth 8, time 5 inline hints: declared_inline 0: guessed profile. frequency 0.709000, benefit 0.002000%, time w/o inlining 56, time w inlining 46 overall growth 612 (current) 398 (original) not inlinable: built-in/47767 - std::_Bit_reference std::_Bit_reference::operator=(bool)/797, --param inline-unit-growth limit reached Estimating body: std::basic_ostreamchar, _Traits std::operator(std::basic_ostreamchar, _Traits, const char*) [with _Traits = std::char_traitschar]/2076 Known to be false: not inlined, op1 == 0B, op1 changed size:7 time:22 so inline decisions are basically random. I tuned this few times, but it is hard to balance the fixpoint arithmetic to not get into 0. The function in question is very small, but there are too many of them. I wonder if we can't switch inliner to std::priority_queue and use sreal to drive the priority queue? Or one can hold fractions and compare in wide int calculations. I think using sreal is fine - I expect that to be faster than using wide_int (and smaller). Random inlining decisions are bad :/ (and hard to debug) Richard.
[Bug other/63847] New: FAIL: c-c++-common/cilk-plus/AN/builtin_fn_custom.c execution test on i?86 with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63847 Bug ID: 63847 Summary: FAIL: c-c++-common/cilk-plus/AN/builtin_fn_custom.c execution test on i?86 with -fpic Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com Target: i686-pc-linux-gnu Following cilkplus tests fail on i?86 with -fpic: FAIL: c-c++-common/cilk-plus/AN/builtin_fn_custom.c -O1 -fcilkplus execution test FAIL: c-c++-common/cilk-plus/AN/builtin_fn_custom.c -O2 -ftree-vectorize -fcilkplus execution test FAIL: c-c++-common/cilk-plus/AN/builtin_fn_custom.c -O3 -fcilkplus execution test FAIL: c-c++-common/cilk-plus/AN/builtin_fn_custom.c -g -O1 -fcilkplus execution test FAIL: c-c++-common/cilk-plus/AN/builtin_fn_custom.c -g -O2 -ftree-vectorize -fcilkplus execution test FAIL: c-c++-common/cilk-plus/AN/builtin_fn_custom.c -g -O3 -fcilkplus execution test FAIL: c-c++-common/cilk-plus/AN/builtin_fn_custom.c -O3 -ftree-vectorize -fcilkplus -g execution test -O1 -fcilkplus -m32: $ ./builtin_fn_custom.exe $ echo $? 0 -O1 -fcilkplus -m32 -fpic: $ ./builtin_fn_custom.exe $ echo $? 1
[Bug libgcc/56846] _Unwind_Backtrace on ARM and noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846 --- Comment #15 from thopre01 at gcc dot gnu.org --- I'll take care of it.
[Bug target/63848] New: [5.0 regression] FAIL: c-c++-common/torture/builtin-arith-overflow-17.c -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63848 Bug ID: 63848 Summary: [5.0 regression] FAIL: c-c++-common/torture/builtin-arith-overflow-17.c -O0 execution test Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: jakub at redhat dot com Target: ia64-*-* This fails at any opt level. Also failing are b-a-o-18.c (t103sub) and b-a-o-6.c (t153add). Breakpoint 2, bar () at /usr/local/gcc/gcc-20141113/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow.h:17 17v++; (gdb) bt #0 bar () at /usr/local/gcc/gcc-20141113/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow.h:17 #1 0x40044430 in t132_1add (x=0x3fff, y=0x4000) at /usr/local/gcc/gcc-20141113/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-17.c:10 #2 0x40044c90 in t132add () at /usr/local/gcc/gcc-20141113/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-17.c:10 #3 0x4006e670 in main () at /usr/local/gcc/gcc-20141113/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-17.c:18 (gdb) c Continuing. Breakpoint 2, bar () at /usr/local/gcc/gcc-20141113/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow.h:17 17v++; (gdb) bt #0 bar () at /usr/local/gcc/gcc-20141113/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow.h:17 #1 0x40044600 in t132_2add (y=0x4000) at /usr/local/gcc/gcc-20141113/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-17.c:10 #2 0x40044cf0 in t132add () at /usr/local/gcc/gcc-20141113/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-17.c:10 #3 0x4006e670 in main () at /usr/local/gcc/gcc-20141113/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-17.c:18 (gdb) c Continuing. Breakpoint 2, bar () at /usr/local/gcc/gcc-20141113/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow.h:17 17v++; (gdb) bt #0 bar () at /usr/local/gcc/gcc-20141113/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow.h:17 #1 0x400449d0 in t132_4add (x=0x3fff) at /usr/local/gcc/gcc-20141113/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-17.c:10 #2 0x40044db0 in t132add () at /usr/local/gcc/gcc-20141113/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-17.c:10 #3 0x4006e670 in main () at /usr/local/gcc/gcc-20141113/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-17.c:18 (gdb) c Continuing. Breakpoint 2, bar () at /usr/local/gcc/gcc-20141113/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow.h:17 17v++; (gdb) bt #0 bar () at /usr/local/gcc/gcc-20141113/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow.h:17 #1 0x40044f70 in t132add () at /usr/local/gcc/gcc-20141113/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-17.c:10 #2 0x4006e670 in main () at /usr/local/gcc/gcc-20141113/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-17.c:18 (gdb) c Continuing. Program received signal SIGABRT, Aborted. 0xa0040721 in __kernel_syscall_via_break () (gdb) bt #0 0xa0040721 in __kernel_syscall_via_break () #1 0x201b2ad0 in *__GI_raise (sig=optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:67 #2 0x201b53b0 in *__GI_abort () at abort.c:92 #3 0x400450d0 in t132add () at /usr/local/gcc/gcc-20141113/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-17.c:10 #4 0x4006e670 in main () at /usr/local/gcc/gcc-20141113/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-17.c:18
[Bug sanitizer/63845] [5 Regression] c-c++-common/asan/bitfield-[12345].c fails on i?86 -with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63845 Igor Zamyatin izamyatin at gmail dot com changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #3 from Igor Zamyatin izamyatin at gmail dot com --- I already posted a patch - http://gcc.gnu.org/ml/gcc-patches/2014-10/msg03318.html Will ping it today
[Bug tree-optimization/63844] open mp parallelization prevents vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63844 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization, openmp Blocks||53947 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- We have a duplicate (or related) bug somewhere.
[Bug tree-optimization/63843] [5 Regression] wrong code generation at -O1 and higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63843 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-* Priority|P3 |P1
[Bug other/63847] FAIL: c-c++-common/cilk-plus/AN/builtin_fn_custom.c execution test on i?86 with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63847 --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- Ah, excess FP precision issue at: double x, yy, array3[NUMBER], array4[NUMBER]; double max_value = 0.000, min_value = 0.000, add_value, mul_value = 1.00; ... if (x != max_value) return 1; Breakpoint 1, main () at /home/uros/gcc-svn/trunk/gcc/testsuite/c-c++-common/cilk-plus/AN/builtin_fn_custom.c:62 62if (x != max_value) 0x080485fb +302: cmp$0x64,%eax 0x080485fe +305: jne0x80485de main()+273 = 0x08048600 +307: fucomip %st(1),%st 0x08048602 +309: fstp %st(0) 0x08048604 +311: jp 0x8048614 main()+327 R7: Valid 0x3efffdffac37ffdaffc37dffb000 +0.9909090909090909616 =R6: Valid 0x3efffdffac37ffdaffc37dffae26 +0.9909090909090909359 R5: Empty 0x31ffd3ffd562ff92ffab7eff865c R4: Empty 0x31ffd3ffd562ff92ffab7eff865c R3: Empty 0x R2: Empty 0x R1: Empty 0x R0: Empty 0x These tests need either checks with tolerances or -ffloat-store.
[Bug tree-optimization/63841] Incorrect strlen optimization after complete unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63841 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-13 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. Seems to be an opportunity to remove the clobber to be able to remove a dead store... ;)
[Bug sanitizer/63839] ICE: tree check: expected ssa_name, have var_decl in simplify_builtin_call, at tree-ssa-forwprop.c:1441 with -fsanitize=unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63839 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug driver/63837] [5 Regression] r217391 causes kernel build errors with GCC_COMPARE_DEBUG=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63837 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING Target Milestone|--- |5.0 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- From reading here it sounds like this is a kernel makefile bug, not a GCC one?
[Bug ipa/63814] g++.dg/ipa/pr61160-1.C fails with -m32 on darwin14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63814 --- Comment #10 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Uroš Bizjak from comment #9) (In reply to Igor Zamyatin from comment #7) So, is this compile time failure or runtime failure (or both for two tests)? You can run the testsuite with -m32 -fpic on linux using: make -j 4 -k check RUNTESTFLAGS=--target_board=unix/-m32/-fpic I see: FAIL: g++.dg/ipa/pr61160-2.C -std=gnu++98 execution test FAIL: g++.dg/ipa/pr61160-2.C -std=gnu++11 execution test FAIL: g++.dg/ipa/pr61160-2.C -std=gnu++14 execution test with the above command on i686-linux-gnu.
[Bug tree-optimization/63841] [4.8/4.9/5 Regression] Incorrect strlen optimization after complete unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63841 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |4.8.4 Summary|Incorrect strlen|[4.8/4.9/5 Regression] |optimization after complete |Incorrect strlen |unroll |optimization after complete ||unroll --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r181172. I'll take a look during stage3.
[Bug tree-optimization/63800] [5 Regression] ICE on valid code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63800 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug ipa/63814] g++.dg/ipa/pr61160-1.C fails with -m32 on darwin14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63814 --- Comment #11 from Igor Zamyatin izamyatin at gmail dot com --- Will take a look. Thanks!
[Bug sanitizer/63839] ICE: tree check: expected ssa_name, have var_decl in simplify_builtin_call, at tree-ssa-forwprop.c:1441 with -fsanitize=unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63839 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Ok, so inlining introduces __builtin_unreachable () during inlining of a noreturn call. Then at some point somebody folds that statement (forwprop) and ubsan instrumentation triggers via fold_builtin_0. Now - BUILT_IN_UBSAN_HANDLE_BUILTIN_UNREACHABLE requires virtual operands but BUILT_IN_UNREACHABLE is const. Thus this folding breaks virtual SSA form - which folding may not do. And kaboom, simplify_builtin_call doesn't expect broken virtual SSA form. It seems that this randomly instrumenting late introduced __builtin_unreachable()s is broken. Instrumenting via folding is anyway IMHO.
[Bug sanitizer/63839] ICE: tree check: expected ssa_name, have var_decl in simplify_builtin_call, at tree-ssa-forwprop.c:1441 with -fsanitize=unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63839 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Assignee|rguenth at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Thus mine.
[Bug driver/63837] [5 Regression] r217391 causes kernel build errors with GCC_COMPARE_DEBUG=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63837 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #5 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Here's a testcase: markus@x4 tmp % GCC_COMPARE_DEBUG=1 gcc -Wpointer-sign -c -x c /dev/null cc1: fatal error: input file ‘/dev/null’ is the same as output file compilation terminated. gcc: error: during -fcompare-debug recompilation markus@x4 tmp % GCC_COMPARE_DEBUG=0 gcc -Wpointer-sign -c -x c /dev/null (4.9 is fine) markus@x4 tmp % GCC_COMPARE_DEBUG=1 gcc -Wpointer-sign -c -x c /dev/null markus@x4 tmp %
[Bug c++/63849] New: [4.9/5.0 Regression] ICE on variadic alias template with wrappers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63849
Bug ID: 63849
Summary: [4.9/5.0 Regression] ICE on variadic alias template
with wrappers
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reagentoo at gmail dot com
The following invalid (or perhaps invalid, I think) code snippet triggers an
ICE in GCC 4.9.2 and 5.0.0 (2014):
template class _T, class...
using First = _T;// we should not use this
// alias with only
// one pack parameter (?)
template template class... class _Successor,
int,
class... _Xs
struct Overlay
{
using O = _Successor_Xs...;
};
template class... _Pack
struct List
{
template int _s
using O = typename OverlayList, _s, _Pack...::O;
template template class... class _S
using Pass = _S_Pack...;
template int _i
using At = typename O_i
::template PassFirst;
};
template int _i
using At = typename Listint, char
::template At_i;
template int _i
void func_crash(At_i) {}
int main(int argc, char *argv[])
{
char ccc;
int iii;
func_crash0(iii);
}
GCC 5.0.0 (2014) output:
prog.cc: In instantiation of 'void func_crash(At_i) [with int _i = 0; At_i
= int]':
prog.cc:31:6: internal compiler error: in write_name, at cp/mangle.c:801
void func_crash(At_i) {}
^
[Bug sanitizer/63806] #UBSAN ignores signed char possible overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63806 --- Comment #5 from Yury Gribov y.gribov at samsung dot com --- I've posted feature request upstream: http://llvm.org/bugs/show_bug.cgi?id=21530
[Bug libfortran/60324] Handle arbitrarily long path names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324 --- Comment #8 from Janne Blomqvist jb at gcc dot gnu.org --- Author: jb Date: Thu Nov 13 12:05:01 2014 New Revision: 217480 URL: https://gcc.gnu.org/viewcvs?rev=217480root=gccview=rev Log: PR 60324 Unbounded stack allocations in libgfortran. 2014-11-13 Janne Blomqvist j...@gcc.gnu.org PR libfortran/60324 * configure: Regenerated. * configure.ac (AM_CFLAGS): Add Werror=vla. * libgfortran.h (gfc_alloca): Remove macro. (fc_strdup_notrim): New prototype. * intrinsics/access.c (access_func): Use fc_strdup rather than stack allocation. * intrinsics/chdir.c (chdir_i4_sub): Likewise. (chdir_i8_sub): Likewise. * intrinsics/chmod.c (chmod_internal): New function, move logic here. (chmod_func): Call chmod_internal. * intrinsics/env.c (getenv): Use fc_strdup rather than stack allocation. (get_environment_variable_i4): Likewise. * intrinsics/execute_command_line.c (execute_command_line): Likewise. * intrinsics/hostnm.c (hostnm_0): New function, use static buffer rather than VLA. (hostnm_i4_sub): Call hostnm_0. (hostnm_i8_sub): Likewise. (hostnm): Likewise. * intrinsics/link.c (link_internal): New function, use fc_strdup rather than stack allocation. (link_i4_sub): Call link_internal. (link_i8_sub): Likewise. (link_i4): Likewise. (link_i8): Likewise. * intrinsics/perror.c (perror_sub): Use fc_strdup rather than stack allocation. * intrinsics/random.c (random_seed_i4): Use static buffer rather than VLA, use _Static_assert to make sure it's big enough. * intrinsics/rename.c (rename_internal): New function, use fc_strdup rather than stack allocation. (rename_i4_sub): Call rename_internal. (rename_i8_sub): Likewise. (rename_i4): Likewise. (rename_i8): Likewise. * intrinsics/stat.c (stat_i4_sub_0): Use fc_strdup rather than stack allocation. (stat_i8_sub_0): Likewise. * intrinsics/symlink.c (symlnk_internal): New function, use fc_strdup rather than stack allocation. (symlnk_i4_sub): Call symlnk_internal. (symlnk_i8_sub): Likewise. (symlnk_i4): Likewise. (symlnk_i8): Likewise. * intrinsics/system.c (system_sub): Use fc_strdup rather than stack allocation. * intrinsics/unlink.c (unlink_i4_sub): Likewise. * io/file_pos.c (READ_CHUNK): Make it a macro rather than variable. * io/list_read.c (nml_get_obj_data): Use fixed stack buffer, fall back to xmalloc/free for large sizes. * io/read.c (read_f): Likewise. * io/transfer.c (MAX_READ): Make it a macro rather than variable. (WRITE_CHUNK): Likewise. * io/write_float.def (write_float): Use fixed stack buffer, fall back to xmalloc/free for large sizes. * runtime/string.c (fc_strdup_notrim): New function. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/intrinsics/access.c trunk/libgfortran/intrinsics/chdir.c trunk/libgfortran/intrinsics/chmod.c trunk/libgfortran/intrinsics/env.c trunk/libgfortran/intrinsics/execute_command_line.c trunk/libgfortran/intrinsics/hostnm.c trunk/libgfortran/intrinsics/link.c trunk/libgfortran/intrinsics/perror.c trunk/libgfortran/intrinsics/random.c trunk/libgfortran/intrinsics/rename.c trunk/libgfortran/intrinsics/stat.c trunk/libgfortran/intrinsics/symlnk.c trunk/libgfortran/intrinsics/system.c trunk/libgfortran/intrinsics/unlink.c trunk/libgfortran/io/file_pos.c trunk/libgfortran/io/list_read.c trunk/libgfortran/io/read.c trunk/libgfortran/io/transfer.c trunk/libgfortran/io/write_float.def trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/string.c
[Bug sanitizer/63846] c-c++-common/asan/misalign-[12].c fails on i?86 with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63846 Igor Zamyatin izamyatin at gmail dot com changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #1 from Igor Zamyatin izamyatin at gmail dot com --- According to this - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534#c48 it's the same as PR63845 (for which I've already posted a patch)
[Bug libfortran/60324] Handle arbitrarily long path names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Janne Blomqvist jb at gcc dot gnu.org --- Fixed on trunk, closing.
[Bug sanitizer/63850] New: Building TSAN for Aarch64 results in assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63850
Bug ID: 63850
Summary: Building TSAN for Aarch64 results in assembler
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: venkataramanan.kumar at amd dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
After enabling TSAN for Aarch64, building it results in Assembler errors.
tmp/cc02YOZf.s:22856: Error: unknown mnemonic `call' -- `call
__tsan_trace_switch_thunk'
/tmp/cc02YOZf.s:22856: Error: operand 1 should be an integer or stack
pointer register -- `add $1024,%rsp'
/tmp/cc02YOZf.s:23297: Error: operand 1 should be an integer or stack
pointer register -- `sub $1024,%rsp'
The function TraceAddEvent adds HACKY_CALL which is defined for X86_64.
void ALWAYS_INLINE TraceAddEvent(ThreadState *thr, FastState fs,
EventType typ, u64 addr) {
if (!kCollectHistory)
return;
DCHECK_GE((int)typ, 0);
DCHECK_LE((int)typ, 7);
DCHECK_EQ(GetLsb(addr, 61), addr);
StatInc(thr, StatEvents);
u64 pos = fs.GetTracePos();
if (UNLIKELY((pos % kTracePartSize) == 0)) {
#ifndef TSAN_GO
HACKY_CALL(__tsan_trace_switch);
#else
TraceSwitch(thr);
#endif
}
Event *trace = (Event*)GetThreadTrace(fs.tid());
Event *evp = trace[pos];
Event ev = (u64)addr | ((u64)typ 61);
*evp = ev;
}
} // namespace __tsan
#if TSAN_DEBUG == 0
// The caller may not create the stack frame for itself at all,
// so we create a reserve stack frame for it (1024b must be enough).
#define HACKY_CALL(f) \
__asm__ __volatile__(sub $1024, %%rsp; \
CFI_INL_ADJUST_CFA_OFFSET(1024) \
.hidden #f _thunk; \
call #f _thunk; \
add $1024, %%rsp; \
CFI_INL_ADJUST_CFA_OFFSET(-1024) \
::: memory, cc);
#else
#define HACKY_CALL(f) f()
#endif
Making #if 0 TSAN_DEBUG == 0 also results in Assembler errors. TSAN make
system includes x86_64 assembly file.
I am looking at ways to fix it and functionally build TSAN for Aarch64
[Bug sanitizer/63850] Building TSAN for Aarch64 results in assembler Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63850 Dmitry Vyukov dvyukov at google dot com changed: What|Removed |Added CC||dvyukov at google dot com --- Comment #1 from Dmitry Vyukov dvyukov at google dot com --- Hi, The easiest way to disable disable the assembly is to switch hacky call to normal call: #if TSAN_DEBUG == 0 #define HACKY_CALL(f) \ __asm__ __volatile__(sub $1024, %%rsp; \ CFI_INL_ADJUST_CFA_OFFSET(1024) \ .hidden #f _thunk; \ call #f _thunk; \ add $1024, %%rsp; \ CFI_INL_ADJUST_CFA_OFFSET(-1024) \ ::: memory, cc); #else #define HACKY_CALL(f) f() #endif It should work, but just will be a bit slower. We use this mode for Go language: #ifndef TSAN_GO HACKY_CALL(__tsan_trace_switch); #else TraceSwitch(thr); #endif But note that tsan is tested only on amd64 so far. So there can be other issues. In particular, shadow memory layout and atomic operations. Also any changes to tsan must go to llvm repo first and then be integrated into gcc. Please refer to: https://code.google.com/p/address-sanitizer/wiki/HowToContribute
[Bug tree-optimization/63817] ICE in verify_gimple_in_cfg tree-cfg.c:5039 (arm)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63817 --- Comment #5 from Jan-Benedict Glaw jbg...@lug-owl.de --- Bug seems to be gone.
[Bug tree-optimization/63828] [5 Regression] g++.dg/ipa/devirt-47.C fails for x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63828 --- Comment #6 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org --- Author: hjl Date: Thu Nov 13 13:08:12 2014 New Revision: 217483 URL: https://gcc.gnu.org/viewcvs?rev=217483root=gccview=rev Log: Use POINTER_SIZE to check for pointer size PR tree-optimization/63828 * ipa-polymorphic-call.c (possible_placement_new): Check POINTER_SIZE, instead of BITS_PER_WORD, for pointer size. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-polymorphic-call.c
[Bug sanitizer/63850] Building TSAN for Aarch64 results in assembler Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63850 clyon at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-11-13 Ever confirmed|0 |1 --- Comment #2 from clyon at gcc dot gnu.org --- Thanks for your comment. Since we are GCC developers, our plan is to work in the GCC tree, then update our patches for submission in llvm. (Same way I did for ASAN on ARM/AArch64). As a side note, making HACKY_CALL be a normal call is not sufficient: a patch in the Makefile is also needed, as it unconditionally involves an x86_64 assembly file.
[Bug driver/63837] [5 Regression] r217391 causes kernel build errors with GCC_COMPARE_DEBUG=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63837
--- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
Thanks for the testcase. It seems that the GCC_COMPARE_DEBUG=0 uses a temporary
file
./cc1 -quiet -iprefix
/home/manuel/test1/217394M/build/gcc/../lib/gcc/x86_64-unknown-linux-gnu/5.0.0/
-isystem ./include -isystem ./include-fixed /dev/null -quiet -dumpbase null
-mtune=generic -march=x86-64 -auxbase null -Wpointer-sign
-fcompare-debug=-gtoggle -frandom-seed=0x6daada6b94b95048
-fdump-final-insns=/tmp/cc3xSGvK.gkd -o /tmp/cc3L00jg.s
but the GCC_COMPARE_DEBUG=1 uses /dev/null:
./cc1 -quiet -iprefix
/home/manuel/test1/217394M/build/gcc/../lib/gcc/x86_64-unknown-linux-gnu/5.0.0/
-isystem ./include -isystem ./include-fixed /dev/null -quiet -dumpbase null.gk
-mtune=generic -march=x86-64 -auxbase null -gtoggle -Wpointer-sign -w
-fcompare-debug=-gtoggle -fcompare-debug-second -o /dev/null
-frandom-seed=0x6daada6b94b95048 -fdump-final-insns=/tmp/ccMDEp8L.gk.gkd
which triggers the heuristic. I can simply ignore /dev/null when checking for
input==output. I'm testing this patch:
Index: gcc.c
===
--- gcc.c (revision 217457)
+++ gcc.c (working copy)
@@ -4047,11 +4047,12 @@ process_command (unsigned int decoded_op
read_cmdline_option (global_options, global_options_set,
decoded_options + j, UNKNOWN_LOCATION,
CL_DRIVER, handlers, global_dc);
}
- if (output_file strcmp (output_file, -))
+ if (output_file strcmp (output_file, -)
+ strcmp (output_file, HOST_BIT_BUCKET))
{
int i;
for (i = 0; i n_infiles; i++)
if ((!infiles[i].language || infiles[i].language[0] != '*')
canonical_filename_eq (infiles[i].name, output_file))
Index: toplev.c
===
--- toplev.c(revision 217457)
+++ toplev.c(working copy)
@@ -940,11 +940,12 @@ init_asm_output (const char *name)
strcat (dumpname, .s);
asm_file_name = dumpname;
}
if (!strcmp (asm_file_name, -))
asm_out_file = stdout;
- else if (!canonical_filename_eq (asm_file_name, name))
+ else if (!canonical_filename_eq (asm_file_name, name)
+ || !strcmp (asm_file_name, HOST_BIT_BUCKET))
asm_out_file = fopen (asm_file_name, w);
else
/* Use fatal_error (UNKOWN_LOCATION) instead of just fatal_error to
prevent gcc from printing the first line in the current file. */
fatal_error (UNKNOWN_LOCATION,
If you can test it on your side, it would be helpful.
[Bug rtl-optimization/63365] [ARM] Incorrect copy propagation for vclz intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63365 clyon at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from clyon at gcc dot gnu.org --- Fixed in trunk as r217014. 4.9 branch: r217488. 4.8 branch: r217490.
[Bug driver/63837] [5 Regression] r217391 causes kernel build errors with GCC_COMPARE_DEBUG=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63837
--- Comment #7 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #6)
Thanks for the testcase. It seems that the GCC_COMPARE_DEBUG=0 uses a
temporary file
./cc1 -quiet -iprefix
/home/manuel/test1/217394M/build/gcc/../lib/gcc/x86_64-unknown-linux-gnu/5.0.
0/ -isystem ./include -isystem ./include-fixed /dev/null -quiet -dumpbase
null -mtune=generic -march=x86-64 -auxbase null -Wpointer-sign
-fcompare-debug=-gtoggle -frandom-seed=0x6daada6b94b95048
-fdump-final-insns=/tmp/cc3xSGvK.gkd -o /tmp/cc3L00jg.s
but the GCC_COMPARE_DEBUG=1 uses /dev/null:
./cc1 -quiet -iprefix
/home/manuel/test1/217394M/build/gcc/../lib/gcc/x86_64-unknown-linux-gnu/5.0.
0/ -isystem ./include -isystem ./include-fixed /dev/null -quiet -dumpbase
null.gk -mtune=generic -march=x86-64 -auxbase null -gtoggle
-Wpointer-sign -w -fcompare-debug=-gtoggle -fcompare-debug-second -o
/dev/null -frandom-seed=0x6daada6b94b95048
-fdump-final-insns=/tmp/ccMDEp8L.gk.gkd
which triggers the heuristic. I can simply ignore /dev/null when checking
for input==output. I'm testing this patch:
Index: gcc.c
===
--- gcc.c (revision 217457)
+++ gcc.c (working copy)
@@ -4047,11 +4047,12 @@ process_command (unsigned int decoded_op
read_cmdline_option (global_options, global_options_set,
decoded_options + j, UNKNOWN_LOCATION,
CL_DRIVER, handlers, global_dc);
}
- if (output_file strcmp (output_file, -))
+ if (output_file strcmp (output_file, -)
+ strcmp (output_file, HOST_BIT_BUCKET))
{
int i;
for (i = 0; i n_infiles; i++)
if ((!infiles[i].language || infiles[i].language[0] != '*')
canonical_filename_eq (infiles[i].name, output_file))
Index: toplev.c
===
--- toplev.c(revision 217457)
+++ toplev.c(working copy)
@@ -940,11 +940,12 @@ init_asm_output (const char *name)
strcat (dumpname, .s);
asm_file_name = dumpname;
}
if (!strcmp (asm_file_name, -))
asm_out_file = stdout;
- else if (!canonical_filename_eq (asm_file_name, name))
+ else if (!canonical_filename_eq (asm_file_name, name)
+ || !strcmp (asm_file_name, HOST_BIT_BUCKET))
asm_out_file = fopen (asm_file_name, w);
else
/* Use fatal_error (UNKOWN_LOCATION) instead of just fatal_error to
prevent gcc from printing the first line in the current file. */
fatal_error (UNKNOWN_LOCATION,
If you can test it on your side, it would be helpful.
Your patch fixes the issue. Thank you.
[Bug rtl-optimization/63823] [5.0 Regression] MIPS will not build due to LRA ICE with 64 bit ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63823
--- Comment #5 from Robert Suchanek robert.suchanek at imgtec dot com ---
It appears that enabling the debug info can trigger the ICE. In the testcase,
after the patch, an instruction 1136 gets deleted and all references to pseudo
704 meant to be updated.
The following change in process_bb_lives () triggers the assertion later in the
pass.
+ EXECUTE_IF_SET_IN_BITMAP
+ (lra_reg_info[dst_regno].insn_bitmap, 0, uid, bi)
+ {
+ insn = lra_insn_recog_data[uid]-insn;
+ lra_substitute_pseudo_within_insn (insn, dst_regno,
+SET_SRC (set));
+ lra_update_insn_regno_info (insn);
+ }
On the first iteration, the list of insns using pseudo 704 is correct:
(gdb) call debug_bitmap(lra_reg_info[704].insn_bitmap)
first = 0x188b720 current = 0x188b770 indx = 3
0x188b720 next = 0x188b770 prev = (nil) indx = 2
bits = { 343 }
0x188b770 next = (nil) prev = 0x188b720 indx = 3
bits = { 384 }
Insn 343 gets updated, pseudo 704 is replaced with original pseudo 234.
However, the call to lra_update_insn_regno_info destroys the remaining
references to pseudo 704 via invalidate_insn_data_regno_info so we end up with
the following:
(gdb) call debug_bitmap(lra_reg_info[704].insn_bitmap)
first = 0x1855770 current = 0x1855770 indx = 3
0x1855770 next = (nil) prev = (nil) indx = 3
bits = { 384 }
The next iteration(s) in EXECUTE_IF_SET_IN_BITMAP will not happen as
bmp_iter_set () returns false. Insn 384 is left unchanged and the compiler
fails later on assertion.
[Bug middle-end/49721] convert_memory_address_addr_space may generate invalid new insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49721 --- Comment #36 from Yvan Roux yroux at gcc dot gnu.org --- Author: yroux Date: Thu Nov 13 14:00:48 2014 New Revision: 217497 URL: https://gcc.gnu.org/viewcvs?rev=217497root=gccview=rev Log: 2014-11-13 Yvan Roux yvan.r...@linaro.org Backport from trunk r216229, r216230. 2014-10-14 Andrew Pinski apin...@cavium.com * explow.c (convert_memory_address_addr_space): Rename to ... (convert_memory_address_addr_space_1): This. Add in_const argument. Inside a CONST RTL, permute the conversion and addition of constant for zero and sign extended pointers. (convert_memory_address_addr_space): New function. 2014-10-14 Andrew Pinski apin...@cavium.com Revert: 2011-08-19 H.J. Lu hongjiu...@intel.com PR middle-end/49721 * explow.c (convert_memory_address_addr_space): Also permute the conversion and addition of constant for zero-extend. Modified: branches/linaro/gcc-4_9-branch/gcc/ChangeLog.linaro branches/linaro/gcc-4_9-branch/gcc/explow.c
[Bug tree-optimization/63841] [4.8/4.9/5 Regression] Incorrect strlen optimization after complete unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63841 --- Comment #4 from Teresa Johnson tejohnson at google dot com --- On Thu, Nov 13, 2014 at 1:27 AM, jakub at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63841 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |4.8.4 Summary|Incorrect strlen|[4.8/4.9/5 Regression] |optimization after complete |Incorrect strlen |unroll |optimization after complete ||unroll --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r181172. I'll take a look during stage3. I have a fix under review: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01481.html Teresa -- You are receiving this mail because: You are on the CC list for the bug. You reported the bug.
[Bug sanitizer/63850] Building TSAN for Aarch64 results in assembler Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63850 --- Comment #3 from Dmitry Vyukov dvyukov at google dot com --- Sure, you can do local experimentation in gcc. Yes, gcc Makefile will need to be updated as well. But I am more concerned about shadow memory layout. Tsan mapping is somewhat different from asan.
[Bug rtl-optimization/63823] [5.0 Regression] MIPS will not build due to LRA ICE with 64 bit ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63823
--- Comment #6 from Vladimir Makarov vmakarov at gcc dot gnu.org ---
(In reply to Robert Suchanek from comment #5)
It appears that enabling the debug info can trigger the ICE. In the
testcase, after the patch, an instruction 1136 gets deleted and all
references to pseudo 704 meant to be updated.
The following change in process_bb_lives () triggers the assertion later in
the pass.
+ EXECUTE_IF_SET_IN_BITMAP
+ (lra_reg_info[dst_regno].insn_bitmap, 0, uid, bi)
+ {
+ insn = lra_insn_recog_data[uid]-insn;
+ lra_substitute_pseudo_within_insn (insn, dst_regno,
+SET_SRC (set));
+ lra_update_insn_regno_info (insn);
+ }
On the first iteration, the list of insns using pseudo 704 is correct:
(gdb) call debug_bitmap(lra_reg_info[704].insn_bitmap)
first = 0x188b720 current = 0x188b770 indx = 3
0x188b720 next = 0x188b770 prev = (nil) indx = 2
bits = { 343 }
0x188b770 next = (nil) prev = 0x188b720 indx = 3
bits = { 384 }
Insn 343 gets updated, pseudo 704 is replaced with original pseudo 234.
However, the call to lra_update_insn_regno_info destroys the remaining
references to pseudo 704 via invalidate_insn_data_regno_info so we end up
with the following:
(gdb) call debug_bitmap(lra_reg_info[704].insn_bitmap)
first = 0x1855770 current = 0x1855770 indx = 3
0x1855770 next = (nil) prev = (nil) indx = 3
bits = { 384 }
The next iteration(s) in EXECUTE_IF_SET_IN_BITMAP will not happen as
bmp_iter_set () returns false. Insn 384 is left unchanged and the compiler
fails later on assertion.
Thanks for analyzing this, Robert. I've been working on some LRA
rematerialization issues and found this too. I'll post a patch fixing this
issue soon. If it works for you, I'll commit it on this week.
[Bug rtl-optimization/63823] [5.0 Regression] MIPS will not build due to LRA ICE with 64 bit ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63823 --- Comment #7 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Created attachment 33956 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33956action=edit The proposed patch Here is the proposed patch.
[Bug preprocessor/63831] [5 Regression] r217292 causes segfaults with -MM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63831 --- Comment #9 from emsr at gcc dot gnu.org --- This problem exists also with my baby __has_cpp_attribute. I have to actually solve this. The real answer to this is to also give c-family/c-ppoutput.c a callback to pretty print these built-in macros. I'll post after tests complete.
[Bug target/63762] [ARM]GCC generates UNPREDICTABLE STR with Rn = Rt when hard-float abi is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63762 --- Comment #2 from Renlin Li renlin.li at arm dot com --- r278 is derived from r224 which is a VFP_LO_REGS. find_cost_and_classes assigns r278's class as GENERAL_REGS, and assign it hard_reg 2. Another new pseudo register r290 is created from r278, and assigned to the same hard_register and register class (GENERAL_REGS). The pref_class of r290 is derived from its original reg (r224), which is VFP_LO_REGS In lra during the hard register assignment process, conflict is checked for r302 which is a GENERAL_REGS. r290 is not considered, because of different register classes(reg_pref[290].pref_class == VFP_LO_REGS ). Hard register number 2 is chosen in this case.
[Bug target/63762] [ARM]GCC generates UNPREDICTABLE STR with Rn = Rt when hard-float abi is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63762 --- Comment #3 from Renlin Li renlin.li at arm dot com --- Created attachment 33957 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33957action=edit ira dump
[Bug preprocessor/63831] [5 Regression] r217292 causes segfaults with -MM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63831 emsr at gcc dot gnu.org changed: What|Removed |Added Attachment #33949|0 |1 is obsolete|| Attachment #33952|0 |1 is obsolete|| --- Comment #10 from emsr at gcc dot gnu.org --- Created attachment 33958 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33958action=edit Add a callback for preprocessor pretty printing. As noted, the real answer to prevent these preprocessor-only crashes is to provide a callback that handles __has_attribute. I don't know how pretty the output is - I figure we can address that later if needs be. But the crashing doesn't happen and we get output. Testsuite is still running. -- libcpp: 2014-11-13 Edward Smith-Rowland 3dw...@verizon.net * expr.c (parse_has_attribute): Only call pfile-cb.has_attribute if it is non-null. gcc/c-family: 2014-11-13 Edward Smith-Rowland 3dw...@verizon.net * c-lex.c (cb_has_attribute): Remove old comment. * c-cppbuiltin.c (cb_has_attribute): New callback; (init_pp_output): Set it. gcc/testsuite: 2014-11-13 Edward Smith-Rowland 3dw...@verizon.net * g++.dg/cpp1y/pr63831.C: New. * g++.dg/cpp1y/pr63831.h: New.
[Bug tree-optimization/63841] [4.8/4.9/5 Regression] Incorrect strlen optimization after complete unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63841 --- Comment #5 from tejohnson at gcc dot gnu.org --- Author: tejohnson Date: Thu Nov 13 15:36:48 2014 New Revision: 217505 URL: https://gcc.gnu.org/viewcvs?rev=217505root=gccview=rev Log: 2014-11-13 Teresa Johnson tejohn...@google.com gcc: PR tree-optimization/63841 * tree.c (initializer_zerop): A clobber does not zero initialize. gcc/testsuite: PR tree-optimization/63841 * g++.dg/tree-ssa/pr63841.C: New test. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr63841.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c
[Bug ipa/63851] New: ipa-icf miscompiles gfortran.dg/assumed_rank_(8|9|10).f90 at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63851
Bug ID: 63851
Summary: ipa-icf miscompiles
gfortran.dg/assumed_rank_(8|9|10).f90 at -O2 and above
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: dominiq at lps dot ens.fr
CC: fxcoudert at gcc dot gnu.org, iains at gcc dot gnu.org,
marxin at gcc dot gnu.org
On x86_64-apple-darwin14 ipa-icf miscompiles
gfortran.dg/assumed_rank_(8|9|10).f90 at -O2 and above (see pr63622 comment 7).
Reduced test for assumed_rank_8.f90
[Book15] f90/bug% cat assumed_rank_8_red.f90
program main
implicit none
interface
subroutine check (x)
integer :: x(..)
end subroutine check
end interface
integer, allocatable :: kk
integer, pointer :: ll
call g (null())
kk = 489
call h (kk)
contains
subroutine g (x)
integer, pointer, intent(in) :: x(..)
call check (x)
end subroutine
subroutine h (x)
integer, allocatable :: x(..)
call check (x)
end subroutine
end program main
[Book15] f90/bug% cat assumed_rank_8_c_red.c
/* Called by assumed_rank_8.f90 and assumed_rank_9.f90. */
#include stdlib.h /* For abort(). */
struct a {
int *dat;
};
void check_ (struct a *x)
{
if (*x-dat != 489)
abort ();
}
[Book15] f90/bug% gfc -O2 assumed_rank_8_red.f90 assumed_rank_8_c_red.c
[Book15] f90/bug% a.out
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x10ec7a5c2
#1 0x10ec7ad60
#2 0x7fff81c71f19
#3 0x10ec71e73
#4 0x10ec71eb5
Segmentation fault
If I comment the first 'call check (x)', the abort goes away.
A reduced test for assumed_rank_10.f90 (fails only with -m32) has been posted
in pr63622 comment 34.
[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793 --- Comment #5 from howarth at bromo dot med.uc.edu --- Checking this issue with current gcc trunk on x86_64 linux, I see differently handling of sumpartgrid in the emitted assembly... $ grep sumpartgrid convmix_kfeta.s movabsq$sumpartgrid.3500@GOTOFF, %rax movabsq$sumpartgrid.3500@GOTOFF, %rax movabsq$sumpartgrid.3500@GOTOFF, %rdx movabsq$sumpartgrid.3500@GOTOFF, %rdx movabsq$sumpartgrid.3500@GOTOFF, %rdx .localsumpartgrid.3500 .largecommsumpartgrid.3500,400,64 for -mcmodel=medium
[Bug ipa/63852] New: acats failures On x86_64-apple-darwin14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63852 Bug ID: 63852 Summary: acats failures On x86_64-apple-darwin14 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: charlet at gcc dot gnu.org, ebotcazou at gcc dot gnu.org, iains at gcc dot gnu.org, marxin at gcc dot gnu.org On x86_64-apple-darwin14 after r216305 I see the following failures === acats tests === FAIL:c760002 FAIL:c761002 FAIL:cc1224a FAIL:cc3007a FAIL:cc3007b From the acats.log the errors are ,.,. C761002 ACATS 2.5 14-11-13 08:49:28 C761002 Check that objects of a controlled type created by an allocator are finalized appropriately. Check that Unchecked_Deallocation of a controlled object causes finalization of that object. raised CONSTRAINT_ERROR : erroneous memory access FAIL: c761002 ,.,. C760002 ACATS 2.5 14-11-13 08:49:24^M C760002 Check that assignment causes the Adjust operation of the type to be called. Check that Adjust is called after copying the value of the source expression to the target object. Check that Adjust is called for all controlled components when the containing object is assigned. Check that Adjust is called for components before the containing object is adjusted. Check that Adjust is not called for a Limited_Controlled type by the implementation. raised PROGRAM_ERROR : System.Storage_Pools.Subpools.Allocate_Any_Controlled: allocation after finalization started^M FAIL: c760002 ,.,. CC1224A ACATS 2.5 14-11-13 09:02:10 CC1224A FOR ARRAY TYPES WITH A NONLIMITED COMPONENT TYPE (OF A FORMAL AND NONFORMAL GENERIC TYPE), CHECK THAT THE FOLLOWING OPERATIONS ARE IMPLICITY DECLARED AND ARE, THEREFORE, AVAILABLE WITHIN THE GENERIC -- UNIT: ASSIGNMENT, THE OPERATION ASSOCIATED WITH AGGREGATE NOTATION, MEMBERSHIP TESTS, THE OPERATION ASSOCIATED WITH INDEXED COMPONENTS, QUALIFICATION, EXPLICIT CONVERSION, 'SIZE, 'ADDRESS, 'FIRST, 'FIRST (N), 'LAST, 'LAST (N), 'RANGE, 'RANGE (N), 'LENGTH, 'LENGTH (N). raised CONSTRAINT_ERROR : erroneous memory access FAIL: cc1224a ,.,. CC3007A ACATS 2.5 14-11-13 09:02:29 CC3007A NAMES IN GENERICS ARE STATICALLY BOUND. * CC3007A WRONG EXCEPTION RAISED 2. CC3007A FAILED . FAIL: cc3007a ,.,. CC3007B ACATS 2.5 14-11-13 09:02:31 CC3007B CHECK THAT THE NAMES IN A GENERIC INSTANTIATION ARE STAICALLY IDENTIFIED (I.E., BOUND) AT THE TEXTUAL POINT OF THE INSTANTIATION, AND ARE BOUND BEFORE BEING SUBSTITUTED FOR THE CORRESPONDING GENERIC FORMAL PARAMETERS IN THE SPECIFICATION AND BODY TEMPLATES. SEE AI-00365/05-BI-WJ.. - CC3007B ENTERING FIRST BLOCK. * CC3007B PROBLEM WITH ARRAY TYPES - 1. * CC3007B PROBLEM WITH ARRAY ELEMENTS - 1. raised CONSTRAINT_ERROR : erroneous memory access FAIL: cc3007b
[Bug target/63762] [ARM]GCC generates UNPREDICTABLE STR with Rn = Rt when hard-float abi is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63762 --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to Renlin Li from comment #2) r278 is derived from r224 which is a VFP_LO_REGS. find_cost_and_classes assigns r278's class as GENERAL_REGS, and assign it hard_reg 2. Another new pseudo register r290 is created from r278, and assigned to the same hard_register and register class (GENERAL_REGS). The pref_class of r290 is derived from its original reg (r224), which is VFP_LO_REGS In lra during the hard register assignment process, conflict is checked for r302 which is a GENERAL_REGS. r290 is not considered, because of different register classes(reg_pref[290].pref_class == VFP_LO_REGS ). Hard register number 2 is chosen in this case. R2 should not be in VFP_LO_REGS - how does IRA end up choosing that ?
[Bug rtl-optimization/63823] [5.0 Regression] MIPS will not build due to LRA ICE with 64 bit ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63823 --- Comment #8 from Robert Suchanek robert.suchanek at imgtec dot com --- Yes, the patch works. Glibc built fine on mips64-linux-gnu target. Thanks Vlad.
[Bug bootstrap/63622] [5.0 Regression] Bootstrap fails on x86_64-apple-darwin1[34] after revision r216305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622 --- Comment #36 from Dominique d'Humieres dominiq at lps dot ens.fr --- Please file test suite failures as new PR (one new PR per test failure with a different backtrace, ideally). It's very hard to track as such (the subject is not accurate any more, the discussion is convoluted, etc.) I have filled pr63851 for the fortran failures and pr63852 for the acats ones. Any objection against closing this PR as FIXED?
[Bug sanitizer/63802] UBSan doesn't catch misaligned access if address is 16-bytes (or more) aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63802 Yury Gribov y.gribov at samsung dot com changed: What|Removed |Added CC||y.gribov at samsung dot com --- Comment #1 from Yury Gribov y.gribov at samsung dot com --- Hm, it looks like UBSan uses min_align_of_type to caclulate alignment of access. This is limited by BIGGEST_ALIGNMENT which is 16 bytes on x86. Any particular reason we are not using TYPE_ALIGN_UNIT? Being unable to verify user alignments makes this check much less useful.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 Martin Liška marxin at gcc dot gnu.org changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #214 from Martin Liška marxin at gcc dot gnu.org --- I've just found ICE for r217480 with LTO and -O2: lto1: internal compiler error: in lto_output_node, at lto-cgraph.c:462 0x7ce411 lto_output_node ../../gcc/lto-cgraph.c:462 0x7ce411 output_symtab() ../../gcc/lto-cgraph.c:974 0x7db276 lto_output() ../../gcc/lto-streamer-out.c:2309 0x814671 write_lto ../../gcc/passes.c:2346 0x8177c1 ipa_write_optimization_summaries(lto_symtab_encoder_d*) ../../gcc/passes.c:2545 0x59512a do_stream_out ../../gcc/lto/lto.c:2475 0x59a41f stream_out ../../gcc/lto/lto.c:2538 0x59a41f lto_wpa_write_files ../../gcc/lto/lto.c:2655 0x59a41f do_whole_program_analysis ../../gcc/lto/lto.c:3323 0x59a41f lto_main() ../../gcc/lto/lto.c:3443 if (tag == LTO_symtab_analyzed_node) gcc_assert (clone_of || !node-clone_of); ^ if (!clone_of) streamer_write_hwi_stream (ob-main_stream, LCC_NOT_FOUND); else streamer_write_hwi_stream (ob-main_stream, ref); If needed I will try to reduce objects that are part of WPA phase. Martin
[Bug bootstrap/63853] New: [5.0 Regression] The use of strchrnul breaks bootstrap on x86_64-apple-darwin14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853 Bug ID: 63853 Summary: [5.0 Regression] The use of strchrnul breaks bootstrap on x86_64-apple-darwin14. Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: fxcoudert at gcc dot gnu.org, howarth at bromo dot med.uc.edu, iains at gcc dot gnu.org, jakub at gcc dot gnu.org, kyukhin at gcc dot gnu.org The use of strchrnul breaks bootstrap at stage1 on x86_64-apple-darwin14: ... g++ -c -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../work/gcc -I../../work/gcc/. -I../../work/gcc/../include -I./../intl -I../../work/gcc/../libcpp/include -I/opt/mp/include -I../../work/gcc/../libdecnumber -I../../work/gcc/../libdecnumber/dpd -I../libdecnumber -I../../work/gcc/../libbacktrace -DCLOOG_INT_GMP -I/opt/mp/include -o lto-wrapper.o -MT lto-wrapper.o -MMD -MP -MF ./.deps/lto-wrapper.TPo ../../work/gcc/lto-wrapper.c ../../work/gcc/lto-wrapper.c: In function 'unsigned int parse_env_var(const char*, char***, const char*)': ../../work/gcc/lto-wrapper.c:427:35: error: 'strchrnul' was not declared in this scope nextval = strchrnul (curval, ':'); ^ ../../work/gcc/lto-wrapper.c: In function 'void append_offload_options(obstack*, const char*, cl_decoded_option*, unsigned int)': ../../work/gcc/lto-wrapper.c:584:34: error: 'strchrnul' was not declared in this scope next = strchrnul (cur, ','); ^ Makefile:1058: recipe for target 'lto-wrapper.o' failed ... See Jakub's comment at https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02205.html
[Bug sanitizer/63802] UBSan doesn't catch misaligned access if address is 16-bytes (or more) aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63802 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Supposedly for TYPE_USER_ALIGN we could use TYPE_ALIGN_UNIT, but for other types we need to use min_align_of_type, otherwise we mishandle e.g. long long on i?86, which has TYPE_ALIGN_UNIT of 8, but when in struct is only 4 byte aligned, thus we can't assert 8 byte alignment for all long long * dereferences.
[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793 --- Comment #6 from howarth at bromo dot med.uc.edu --- This may be where the usage of @GOTOFF was introduced for -mcmodel=medium... https://gcc.gnu.org/ml/gcc-patches/2005-07/msg00046.html https://gcc.gnu.org/ml/gcc-patches/2005-07/msg01134.html https://gcc.gnu.org/ml/gcc-patches/2005-07/msg01593.html
[Bug sanitizer/63802] UBSan doesn't catch misaligned access if address is 16-bytes (or more) aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63802 --- Comment #3 from Yury Gribov y.gribov at samsung dot com --- Agreed, I'll cook a patch for tomorrow then.
[Bug tree-optimization/63828] [5 Regression] g++.dg/ipa/devirt-47.C fails for x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63828 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from H.J. Lu hjl.tools at gmail dot com --- Fixed.
[Bug bootstrap/63853] [5.0 Regression] The use of strchrnul breaks bootstrap on x86_64-apple-darwin14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-13 Ever confirmed|0 |1 --- Comment #2 from Iain Sandoe iains at gcc dot gnu.org --- it's also in gcc/gcc.c (and breaks *darwin* at least)
[Bug bootstrap/63853] [5.0 Regression] The use of strchrnul breaks bootstrap on x86_64-apple-darwin14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853 Ilya Verbin iverbin at gmail dot com changed: What|Removed |Added CC||iverbin at gmail dot com --- Comment #1 from Ilya Verbin iverbin at gmail dot com --- Oops, I removed strchrnul from mkoffload, but it remains in lto-wrapper. I will fix it.
[Bug bootstrap/63853] [5.0 Regression] The use of strchrnul breaks bootstrap on x86_64-apple-darwin14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853
--- Comment #3 from Iain Sandoe iains at gcc dot gnu.org ---
… does libiberty want an implementation?
const char *
strchrnul (const char *s, int c)
{
char *snew = strrchr(s, c);
if (snew != NULL)
return snew;
return (s + strlen (s));
}
[Bug bootstrap/63853] [5.0 Regression] The use of strchrnul breaks bootstrap on x86_64-apple-darwin14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- That is not what strchrnul does though. If is char *p = strchr (s, c); if (p) return p; else return strchr (s, '\0');
[Bug rtl-optimization/63365] [ARM] Incorrect copy propagation for vclz intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63365 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org Target Milestone|--- |4.8.4
[Bug bootstrap/63853] [5.0 Regression] The use of strchrnul breaks bootstrap on x86_64-apple-darwin14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853 --- Comment #5 from Ilya Verbin iverbin at gmail dot com --- So, I'll implement strchrnul in libiberty, ok?
[Bug bootstrap/63853] [5.0 Regression] The use of strchrnul breaks bootstrap on x86_64-apple-darwin14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added CC||dje at gcc dot gnu.org Host||*-*-darwin*, *-*-aix* --- Comment #6 from David Edelsohn dje at gcc dot gnu.org --- strchrnul() is a GNU extension.
[Bug jit/63854] New: Fix memory leaks seen in JIT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63854 Bug ID: 63854 Summary: Fix memory leaks seen in JIT Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Created attachment 33959 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33959action=edit Log from valgrind I'm attaching a log from valgrind on test-factorial.c, running 5 in-process iterations. PATH=.:$PATH \ LD_LIBRARY_PATH=. \ LIBRARY_PATH=. \ valgrind \ --leak-check=full \ testsuite/jit/test-factorial.exe 21 | tee test-factorial.valgrind.log Summary is: ==57820== LEAK SUMMARY: ==57820==definitely lost: 84,140 bytes in 578 blocks ==57820==indirectly lost: 257,864 bytes in 3,185 blocks ==57820== possibly lost: 0 bytes in 0 blocks ==57820==still reachable: 572,159 bytes in 3,112 blocks ==57820== suppressed: 0 bytes in 0 blocks Various things show up as leaking 4 or 5 times; presumably those are per-invocation leaks that we ought to fix to avoid them affecting jit users.
[Bug jit/63854] Fix memory leaks seen in JIT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63854 --- Comment #1 from dmalcolm at gcc dot gnu.org --- Note to self: this was with r217427.
[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793 --- Comment #7 from howarth at bromo dot med.uc.edu --- This seems to be due to the fact that on x86_64 linux, auto-host.h contains... /* Define true if the assembler supports '.long foo@GOTOFF'. */ #ifndef USED_FOR_TARGET #define HAVE_AS_GOTOFF_IN_DATA 1 #endif but on x86_64 darwin, we have... /* Define true if the assembler supports '.long foo@GOTOFF'. */ #ifndef USED_FOR_TARGET #define HAVE_AS_GOTOFF_IN_DATA 0 #endif
[Bug bootstrap/63853] [5.0 Regression] The use of strchrnul breaks bootstrap on x86_64-apple-darwin14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- I think it is more work than just changing the few spots.
[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793
--- Comment #8 from howarth at bromo dot med.uc.edu ---
It appears the two instances of the use of HAVE_AS_GOTOFF_IN_DATA are in
gcc/config/i386/i386.c
void
ix86_output_addr_diff_elt (FILE *file, int value, int rel)
{
const char *directive = ASM_LONG;
#ifdef ASM_QUAD
if (TARGET_64BIT CASE_VECTOR_MODE == DImode)
directive = ASM_QUAD;
#else
gcc_assert (!TARGET_64BIT);
#endif
/* We can't use @GOTOFF for text labels on VxWorks; see gotoff_operand. */
if (TARGET_64BIT || TARGET_VXWORKS_RTP)
fprintf (file, %s%s%d-%s%d\n,
directive, LPREFIX, value, LPREFIX, rel);
else if (HAVE_AS_GOTOFF_IN_DATA)
fprintf (file, ASM_LONG %s%d@GOTOFF\n, LPREFIX, value);
#if TARGET_MACHO
else if (TARGET_MACHO)
{
fprintf (file, ASM_LONG %s%d-, LPREFIX, value);
machopic_output_function_base_name (file);
putc ('\n', file);
}
#endif
else
asm_fprintf (file, ASM_LONG %U%s+[.-%s%d]\n,
GOT_SYMBOL_NAME, LPREFIX, value);
}
^L
/* Generate either mov $0, reg or xor reg, reg, as appropriate
for the target. */
and in gcc/config/i386/i386.md
(define_expand tablejump
[(parallel [(set (pc) (match_operand 0 indirect_branch_operand))
(use (label_ref (match_operand 1)))])]
{
/* In PIC mode, the table entries are stored GOT (32-bit) or PC (64-bit)
relative. Convert the relative address to an absolute address. */
if (flag_pic)
{
rtx op0, op1;
enum rtx_code code;
/* We can't use @GOTOFF for text labels on VxWorks;
see gotoff_operand. */
if (TARGET_64BIT || TARGET_VXWORKS_RTP)
{
code = PLUS;
op0 = operands[0];
op1 = gen_rtx_LABEL_REF (Pmode, operands[1]);
}
else if (TARGET_MACHO || HAVE_AS_GOTOFF_IN_DATA)
{
code = PLUS;
op0 = operands[0];
op1 = pic_offset_table_rtx;
}
else
{
code = MINUS;
op0 = pic_offset_table_rtx;
op1 = operands[0];
}
operands[0] = expand_simple_binop (Pmode, code, op0, op1, NULL_RTX, 0,
OPTAB_DIRECT);
}
[Bug bootstrap/63853] [5.0 Regression] The use of strchrnul breaks bootstrap on x86_64-apple-darwin14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853 --- Comment #8 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #4) That is not what strchrnul does though. If is char *p = strchr (s, c); if (p) return p; else return strchr (s, '\0'); fair enough, if that's preferred .. was just following the description from a random Linux man page: http://linux.die.net/man/3/strchrnul
[Bug bootstrap/63853] [5.0 Regression] The use of strchrnul breaks bootstrap on x86_64-apple-darwin14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853
--- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr ---
I just completed a clean bootstrap of r217511 with the following patch
--- ../_clean/gcc/gcc.c2014-11-13 15:29:00.0 +0100
+++ gcc/gcc.c2014-11-13 17:59:47.0 +0100
@@ -3375,12 +3375,16 @@ handle_foffload_option (const char *arg)
if (arg[0] == '-')
return;
- end = strchrnul (arg, '=');
+ end = strchr (arg, '=');
+ if (end == NULL)
+end = strchr (arg, '\0');
cur = arg;
while (cur end)
{
- next = strchrnul (cur, ',');
+ next = strchr (cur, ',');
+ if (next == NULL)
+next = strchr (cur, '\0');
next = (next end) ? end : next;
target = XNEWVEC (char, next - cur + 1);
@@ -3400,7 +3404,9 @@ handle_foffload_option (const char *arg)
c = OFFLOAD_TARGETS;
while (c)
{
- n = strchrnul (c, ',');
+ n = strchr (c, ',');
+ if (n == NULL)
+n = strchr (c, '\0');
if (strlen (target) == (size_t) (n - c)
strncmp (target, c, n - c) == 0)
@@ -3421,7 +3427,9 @@ handle_foffload_option (const char *arg)
c = offload_targets;
do
{
- n = strchrnul (c, ':');
+ n = strchr (c, ':');
+ if (n == NULL)
+n = strchr (c, '\0');
if (strlen (target) == (size_t) (n - c)
strncmp (c, target, n - c) == 0)
--- ../_clean/gcc/lto-wrapper.c2014-11-13 15:29:00.0 +0100
+++ gcc/lto-wrapper.c2014-11-13 17:54:48.0 +0100
@@ -424,7 +424,9 @@ parse_env_var (const char *str, char ***
values = (char**) xmalloc (num * sizeof (char*));
curval = str;
- nextval = strchrnul (curval, ':');
+ nextval = strchr (curval, ':');
+ if (nextval == NULL)
+nextval = strchr (curval, '\0');
int append_len = append ? strlen (append) : 0;
for (i = 0; i num; i++)
@@ -436,7 +438,9 @@ parse_env_var (const char *str, char ***
if (append)
strcat (values[i], append);
curval = nextval + 1;
- nextval = strchrnul (curval, ':');
+ nextval = strchr (curval, ':');
+ if (nextval == NULL)
+nextval = strchr (curval, '\0');
}
*pvalues = values;
return num;
@@ -581,7 +585,9 @@ append_offload_options (obstack *argv_ob
while (cur opts)
{
- next = strchrnul (cur, ',');
+ next = strchr (cur, ',');
+ if (next == NULL)
+next = strchr (cur, '\0');
next = (next opts) ? opts : next;
if (strlen (target) == (size_t) (next - cur)
[Bug bootstrap/63853] [5.0 Regression] The use of strchrnul breaks bootstrap on x86_64-apple-darwin14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853 --- Comment #10 from Andreas Schwab sch...@linux-m68k.org --- How about using strcspn?
[Bug bootstrap/63853] [5.0 Regression] The use of strchrnul breaks bootstrap on x86_64-apple-darwin14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853
--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #9)
I just completed a clean bootstrap of r217511 with the following patch
This is ok for trunk so that we don't have bootstrap breakages for too long.
That said, most of the strchrnul uses look to me like completely unnecessary.
--- ../_clean/gcc/gcc.c 2014-11-13 15:29:00.0 +0100
+++ gcc/gcc.c 2014-11-13 17:59:47.0 +0100
@@ -3375,12 +3375,16 @@ handle_foffload_option (const char *arg)
if (arg[0] == '-')
return;
- end = strchrnul (arg, '=');
+ end = strchr (arg, '=');
+ if (end == NULL)
+end = strchr (arg, '\0');
cur = arg;
while (cur end)
{
- next = strchrnul (cur, ',');
+ next = strchr (cur, ',');
+ if (next == NULL)
+ next = strchr (cur, '\0');
E.g. here. If strchr (cur, ',') returns NULL, then what
strchr (cur, '\0'); returns is either equal to end, or end, so we can just
set next = end;.
strncpy (target, cur, next - cur);
memcpy should be used instead.
- n = strchrnul (c, ',');
+ n = strchr (c, ',');
+ if (n == NULL)
+ n = strchr (c, '\0');
if (strlen (target) == (size_t) (n - c)
Here, strlen (target) should be known, isn't it next - cur ?
(and another spot with that).
Also,
offload_targets = xstrdup (target);
(could have instead just set offload_targets = target;
and ensure it isn't freed, say by setting target = NULL).
And:
offload_targets
= XRESIZEVEC (char, offload_targets,
strlen (offload_targets) + strlen (target) + 2);
if (strlen (offload_targets) != 0)
strcat (offload_targets, :);
strcat (offload_targets, target);
Compute strlen (offload_targets) once, strlen (target) is known (next - cur),
and don't compute it 5 times instead.
size_t offload_targets_len = strlen (offload_targets);
offload_targets = XRESIZEVEC (char, offload_targets,
offload_targets_len + (next - cur)
+ 2);
if (offload_targets_len)
offload_targets[offload_targets_len++] = ':';
memcpy (offload_targets + offload_targets_len, target, next -
cur);
? Especially if (strlen (offload_targets) != 0) is very expensive way of
if (*offload_targets)
The tree-ssa-strlen.c pass will presumably optimize some of this, but given
the conditional likely not all of that.
Sorry for not catching that during review.
s + strcspn (s, =) instead of strchrnul (s, '=') is reasonable too.
[Bug sanitizer/63855] New: [5 Regression] ICE: SIGSEGV in ipa_comdats with -fsanitize=null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63855 Bug ID: 63855 Summary: [5 Regression] ICE: SIGSEGV in ipa_comdats with -fsanitize=null Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Created attachment 33960 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33960action=edit reduced testcase $ gcc -O -fkeep-inline-functions -fsanitize=null testcase.C ==22060== Invalid read of size 8 ==22060==at 0x180E214: ipa_comdats (ipa-comdats.c:340) ==22060==by 0x180E214: (anonymous namespace)::pass_ipa_comdats::execute(function*) (ipa-comdats.c:381) ==22060==by 0xCCBE78: execute_one_pass(opt_pass*) (passes.c:2269) ==22060==by 0xCCCAD1: execute_ipa_pass_list(opt_pass*) (passes.c:2663) ==22060==by 0x9B3B69: ipa_passes (cgraphunit.c:2088) ==22060==by 0x9B3B69: symbol_table::compile() (cgraphunit.c:2172) ==22060==by 0x9B5687: symbol_table::finalize_compilation_unit() (cgraphunit.c:2325) ==22060==by 0x785449: cp_write_global_declarations() (decl2.c:4677) ==22060==by 0xDC3BD3: compile_file() (toplev.c:583) ==22060==by 0x694528: do_compile (toplev.c:2020) ==22060==by 0x694528: toplev::main(int, char**) (toplev.c:2117) ==22060==by 0x694B78: main (main.c:38) ==22060== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==22060== testcase.C:5:4: internal compiler error: Segmentation fault B b; ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r217458 - ICE 4_9 r216937 - OK
[Bug ipa/63856] New: [5 Regression] ICE: verify_gimple failed: invalid argument to gimple call with -O2 -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63856 Bug ID: 63856 Summary: [5 Regression] ICE: verify_gimple failed: invalid argument to gimple call with -O2 -fPIC Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 33961 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33961action=edit reduced testcase Compiler output: $ gcc -O2 -fPIC testcase.c testcase.c: In function 'f': testcase.c:12:1: error: invalid argument to gimple call } ^ A # .MEM_3 = VDEF .MEM_1(D) retval.2_4 = g.localalias.0 (A, N_2(D)); [tail call] testcase.c:12:1: internal compiler error: verify_gimple failed 0xc40994 verify_gimple_in_cfg(function*, bool) /mnt/svn/gcc-trunk/gcc/tree-cfg.c:5039 0xb0d396 execute_function_todo /mnt/svn/gcc-trunk/gcc/passes.c:1868 0xb0dced do_per_function /mnt/svn/gcc-trunk/gcc/passes.c:1602 0xb0de03 execute_todo /mnt/svn/gcc-trunk/gcc/passes.c:1925 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. Tested revisions: r217458 - ICE 4_9 r216937 - OK
[Bug sanitizer/63855] [5 Regression] ICE: SIGSEGV in ipa_comdats with -fsanitize=null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63855 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-13 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug preprocessor/63831] [5 Regression] r217292 causes segfaults with -MM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63831 --- Comment #11 from Iain Sandoe iains at gcc dot gnu.org --- unfortunaely, not quite (yet) complete. I tried 217505 + c#10 - on x86_64-darwin12 all langs bootstrap proceeds up to the build of Ada lib. I reverted r217292 and re-tried - bootstrap passed, so still some gremlin remains (i'll be glad to try to analyse, but no cycles until the weekend). Also thanks for doing this work! Clang compatibility is a _very_ useful thing on Darwin.
[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793 --- Comment #9 from howarth at bromo dot med.uc.edu --- Created attachment 33962 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33962action=edit assembly file for convex_kfeta.s on x86_64 linux Generated with gfortran -c -I/home/howarth/dist_netcdf-fortran-4.4.1/include -mcmodel=medium -fconvert=little-endian -finit-local-zero -fno-range-check convmix_kfeta.f90 --save-temps
[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793 --- Comment #10 from howarth at bromo dot med.uc.edu --- Jakub, Do you have any insights on where the code generation for darwin would fork from linux to use %rip rather than @GOTOFF. The darwin linker developer says for large code (which I assume means both -mcmodel=medium/large), darwin should be using @GOT rather than %rip. The most obvious places are those using the conditional HAVE_AS_GOTOFF_IN_DATA which is set to 0 on darwin, but I am concerned that could be a red herring and we need to look elsewhere in gcc/config/i386/i386.[c/md].
[Bug tree-optimization/63841] [4.8/4.9/5 Regression] Incorrect strlen optimization after complete unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63841 --- Comment #6 from tejohnson at gcc dot gnu.org --- Author: tejohnson Date: Thu Nov 13 21:51:11 2014 New Revision: 217522 URL: https://gcc.gnu.org/viewcvs?rev=217522root=gccview=rev Log: 2014-11-13 Teresa Johnson tejohn...@google.com gcc: PR tree-optimization/63841 * tree-ssa-strlen.c (strlen_optimize_stmt): Ignore clobbers. 2014-11-13 Teresa Johnson tejohn...@google.com gcc/testsuite: PR tree-optimization/63841 * testsuite/g++.dg/tree-ssa/pr63841.C: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/tree-ssa/pr63841.C Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/tree-ssa-strlen.c
[Bug bootstrap/63853] [5.0 Regression] The use of strchrnul breaks bootstrap on x86_64-apple-darwin14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853 --- Comment #12 from iverbin at gcc dot gnu.org --- Author: iverbin Date: Thu Nov 13 22:06:15 2014 New Revision: 217524 URL: https://gcc.gnu.org/viewcvs?rev=217524root=gccview=rev Log: 2014-11-13 Dominique Dhumieres domi...@lps.ens.fr PR bootstrap/63853 gcc/ * gcc.c (handle_foffload_option): Replace strchrnul with strchr. * lto-wrapper.c (parse_env_var, append_offload_options): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc.c trunk/gcc/lto-wrapper.c
[Bug ipa/63856] [5 Regression] ICE: verify_gimple failed: invalid argument to gimple call with -O2 -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63856 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-13 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- It is caused by r216305.
[Bug c/59984] OpenMP and Cilk Plus SIMD pragma makes loop incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59984 --- Comment #12 from Stupachenko Evgeny evstupac at gmail dot com --- Created attachment 33963 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33963action=edit test case where pragma simd disable vectorization The following test case compiled with -Ofast vectorize the loop in the GetXsum function. Adding -fopenmp leads to failed vectorization due to: simd_issue.cpp:26:18: note: not vectorized: data ref analysis failed D.2329[_7].x = _12; It looks like before the patch in this Bug loop was vectorized with -fopenmp.
[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793 --- Comment #11 from howarth at bromo dot med.uc.edu --- FYI, the darwin linker developer had the following comments on @GOTOFF.. This may be a red herring. @GOTOFF is a different concept. IIRC, the ELF runtime sets of RBX to point to the GOT table. @GOTOFF is for accessing variables that are a (link time) fixed offset in the GOT table. Darwin does not support @GOTOFF at all. Local variables are accessed RIP-rel, or if large, indirectly via @GOT. However, outside of the sections of gcc/config/i386/i386.[c/md] conditional on HAVE_AS_GOTOFF_IN_DATA, I don't see any other obvious places where %rip would be emitted for Mach-O but not linux.
[Bug debug/63581] undefined references in debug_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63581 --- Comment #2 from xur at gcc dot gnu.org --- Author: xur Date: Fri Nov 14 00:30:31 2014 New Revision: 217530 URL: https://gcc.gnu.org/viewcvs?rev=217530root=gccview=rev Log: 2014-11-13 Rong Xu x...@google.com gcc: PR debug/63581 * cfgrtl.c (emit_barrier_after_bb): Append the barrier to the footer, instead of unconditionally overwritten gcc/testsuite: PR debug/63581 * g++.dg/tree-prof/pr63581.C: New test. Added: trunk/gcc/testsuite/g++.dg/tree-prof/pr63581.C Modified: trunk/gcc/ChangeLog trunk/gcc/cfgrtl.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793
--- Comment #12 from Iain Sandoe iains at gcc dot gnu.org ---
caveat: I have not examined this bug…
.. but I have the following patch in my Q (solves a problem when GAS is the
assembler). This should not fire unless the configuration says that the
assembler supports gotoff in data (which GAS does, of course)
Otherwise, I'm not aware of any darwin-specific support for mcmodel= .. no-one
has had time to look at it ...
.. if the patch makes a difference, look for a config error.
---
gcc_assert (!TARGET_64BIT);
#endif
/* We can't use @GOTOFF for text labels on VxWorks; see gotoff_operand. */
if (TARGET_64BIT || TARGET_VXWORKS_RTP)
fprintf (file, %s%s%d-%s%d\n,
directive, LPREFIX, value, LPREFIX, rel);
- else if (HAVE_AS_GOTOFF_IN_DATA)
-fprintf (file, ASM_LONG %s%d@GOTOFF\n, LPREFIX, value);
#if TARGET_MACHO
else if (TARGET_MACHO)
{
fprintf (file, ASM_LONG %s%d-, LPREFIX, value);
machopic_output_function_base_name (file);
putc ('\n', file);
}
#endif
+ else if (HAVE_AS_GOTOFF_IN_DATA)
+fprintf (file, ASM_LONG %s%d@GOTOFF\n, LPREFIX, value);
else
asm_fprintf (file, ASM_LONG %U%s+[.-%s%d]\n,
GOT_SYMBOL_NAME, LPREFIX, value);
}
/* Generate either mov $0, reg or xor reg, reg, as appropriate
[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793 --- Comment #13 from howarth at bromo dot med.uc.edu --- (In reply to howarth from comment #11) FYI, the darwin linker developer had the following comments on @GOTOFF.. This may be a red herring. @GOTOFF is a different concept. IIRC, the ELF runtime sets of RBX to point to the GOT table. @GOTOFF is for accessing variables that are a (link time) fixed offset in the GOT table. Darwin does not support @GOTOFF at all. Local variables are accessed RIP-rel, or if large, indirectly via @GOT. However, outside of the sections of gcc/config/i386/i386.[c/md] conditional on HAVE_AS_GOTOFF_IN_DATA, I don't see any other obvious places where %rip would be emitted for Mach-O but not linux. Empirically, it seems logical that this bug should be in the section conditional on HAVE_AS_GOTOFF_IN_DATA because the problematic symbol with the core name sumpartgrid shows up as in a grep of the assembly as... movabsq$sumpartgrid.3500@GOTOFF, %rax on linux, while on darwin it shows up as leaq_sumpartgrid.2471(%rip), %rax I am assuming that the emission of @GOTOFF on linux is entirely under the control of the HAVE_AS_GOTOFF_IN_DATA conditional and thus should point us at the section that needs to be enhanced to use GOT on darwin for -mcmodel=medium/large.
[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793
--- Comment #14 from howarth at bromo dot med.uc.edu ---
(In reply to Iain Sandoe from comment #12)
caveat: I have not examined this bug…
.. but I have the following patch in my Q (solves a problem when GAS is the
assembler). This should not fire unless the configuration says that the
assembler supports gotoff in data (which GAS does, of course)
Otherwise, I'm not aware of any darwin-specific support for mcmodel= ..
no-one has had time to look at it ...
.. if the patch makes a difference, look for a config error.
---
gcc_assert (!TARGET_64BIT);
#endif
/* We can't use @GOTOFF for text labels on VxWorks; see gotoff_operand.
*/
if (TARGET_64BIT || TARGET_VXWORKS_RTP)
fprintf (file, %s%s%d-%s%d\n,
directive, LPREFIX, value, LPREFIX, rel);
- else if (HAVE_AS_GOTOFF_IN_DATA)
-fprintf (file, ASM_LONG %s%d@GOTOFF\n, LPREFIX, value);
#if TARGET_MACHO
else if (TARGET_MACHO)
{
fprintf (file, ASM_LONG %s%d-, LPREFIX, value);
machopic_output_function_base_name (file);
putc ('\n', file);
}
#endif
+ else if (HAVE_AS_GOTOFF_IN_DATA)
+fprintf (file, ASM_LONG %s%d@GOTOFF\n, LPREFIX, value);
else
asm_fprintf (file, ASM_LONG %U%s+[.-%s%d]\n,
GOT_SYMBOL_NAME, LPREFIX, value);
}
/* Generate either mov $0, reg or xor reg, reg, as appropriate
I don't see how this will help. Nick was clear that darwin doesn't support
@GOTOFF and that the problem is that we need to emit @GOT rather than %rip for
large code models (aka 64-bit) per his original comments...
---
This is a little known aspect of x86_64 mach-o that allows the use of the small
code model everywhere (that is not need a large code model). When the compiler
references “large” ( = 1MB) zero-fill data, it should do it through the GOT
(instead of direct RIP relative reference).
When the linker lays out the output, if it is bigger than 2GB, it moves all
large zero-fill symbols to a new __DATA,__huge section which the linker puts
last. As long as all the uses of moved large data is through the GOT, this
just works and you can have very large mach-o binaries.
In this case the file from convmix_kfeta.o defines _sumpartgrid.2471 (which is
a 4MB zero-fill symbol) but that same file has a reference to
_sumpartgrid.2471 from the function _convmix_kfeta_ that is RIP relative
(instead of using the GOT).
[Bug fortran/63857] New: fixed form OpenACC directive ICE with -fopenacc -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63857 Bug ID: 63857 Summary: fixed form OpenACC directive ICE with -fopenacc -fopenmp Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: cesar at codesourcery dot com Created attachment 33964 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33964action=edit test case The attached test case causes gfortran to ICE when -fopenmp is used with -fopenacc. It looks like there is a problem with the way that continuations are handled in openmp/openacc directives.
[Bug fortran/63858] New: fixed form OpenACC directive ICE with -fopenacc -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63858 Bug ID: 63858 Summary: fixed form OpenACC directive ICE with -fopenacc -fopenmp Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: cesar at codesourcery dot com The attached test case causes gfortran to ICE when -fopenmp is used with -fopenacc. It looks like there is a problem with the way that continuations are handled in openmp/openacc directives.
[Bug fortran/63859] New: OpenACC DEVICE_RESIDENT clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63859 Bug ID: 63859 Summary: OpenACC DEVICE_RESIDENT clause Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: cesar at codesourcery dot com The OpenACC DEVICE_RESIDENT clause isn't fully supported in gfortran.
[Bug ipa/63671] [5 Regression] 21% tramp3d-v4 performance hit due to -fdevirtualize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63671 --- Comment #11 from Jan Hubicka hubicka at ucw dot cz --- I think using sreal is fine - I expect that to be faster than using wide_int (and smaller). Random inlining decisions are bad :/ (and hard to debug) Yep, this was hitting us from time to time and I usually was able to just tweak badness calculation, but sreal would reduce this maintenance burden. I will give this a try with Martin's fibheap/sreal patchset.
[Bug libstdc++/63860] New: Ill-formed std::pair::swap implementation?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63860 Bug ID: 63860 Summary: Ill-formed std::pair::swap implementation? Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com According to http://llvm.org/bugs/show_bug.cgi?id=21565 and http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20141110/118441.html std::pair::swap implementation in libstdc++ in GCC 4.8.3 is ill-formed. I checked trunk and it isn't changed. Is libstdc++ wrong here?
[Bug libstdc++/63860] Ill-formed std::pair::swap implementation?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63860 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Most likely because 4.8.3 did not fully implement C++11.
[Bug fortran/63861] New: OpenACC coarray ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861 Bug ID: 63861 Summary: OpenACC coarray ICE Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: cesar at codesourcery dot com Coarrays in OpenACC accelerated regions causes an ICE in gfortran. The test case gcc/testsuite/gfortran.dg/goacc/coarray.f95 reproduces this failure. It's unclear whether OpenACC 2.0a even supports coarrays. Regardless, this test case shouldn't cause an ICE.
