[Bug rtl-optimization/63637] [4.9/5 Regression] CSE on x86 asm()-s no longer working due to PR/60663 fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63637 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-17 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.9.3 Summary|CSE on x86 asm()-s no |[4.9/5 Regression] CSE on |longer working due to |x86 asm()-s no longer |PR/60663 fix|working due to PR/60663 fix Ever confirmed|0 |1
[Bug rtl-optimization/64110] [5 Regression] ICE: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64110
--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org ---
Looking at the generated assembly, I see there:
movw%di, -80(%rbp)
vpbroadcastw-80(%rbp), %ymm1
vmovdqa %ymm1, -80(%rbp)
I'd have expected
vmovd %edi, %xmm1
vpbroadcastw%xmm1, %ymm1
vmovdqa %ymm1, -80(%rbp)
Is there some bug in the *vec_dupv16hi pattern that LRA can't use the !r
alternative? %di should be valid nonimmediate_operand in HImode. For e.g.
typedef unsigned short V __attribute__((vector_size (32)));
V foo (unsigned short x)
{
return (V) { x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x };
}
we emit what I expect. In the latter case, at *.ira we have:
(insn 2 5 3 2 (set (reg:SI 90 [ x ])
(reg:SI 5 di [ x ])) pr64110-4.c:3 90 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 5 di [ x ])
(nil)))
(note 3 2 4 2 NOTE_INSN_DELETED)
(note 4 3 7 2 NOTE_INSN_FUNCTION_BEG)
(insn 7 4 12 2 (set (reg:V16HI 92 [ D.2291 ])
(vec_duplicate:V16HI (subreg:HI (reg:SI 90 [ x ]) 0))) pr64110-4.c:4
4233 {*vec_dupv16hi}
(expr_list:REG_DEAD (reg:SI 90 [ x ])
(nil)))
and in the former case we have:
(insn 27 36 28 2 (set (reg:SI 178 [ x ])
(reg:SI 5 di [ x ])) pr64110.c:10 90 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 5 di [ x ])
(nil)))
(insn 28 27 29 2 (set (reg/v:HI 177 [ x ])
(subreg:HI (reg:SI 178 [ x ]) 0)) pr64110.c:10 92 {*movhi_internal}
(expr_list:REG_DEAD (reg:SI 178 [ x ])
(nil)))
(note 29 28 89 2 NOTE_INSN_FUNCTION_BEG)
(insn 89 29 247 2 (set (reg:V16HI 214 [ vect_cst_.21 ])
(vec_duplicate:V16HI (reg/v:HI 177 [ x ]))) 4233 {*vec_dupv16hi}
(nil))
which isn't that much different...
[Bug sanitizer/64336] Template functions are not instrumented at -O0 and -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64336 --- Comment #1 from Bernd Edlinger bernd.edlinger at hotmail dot de --- hmm... in this example at tsan.c, instrument_expr() is exiting twice here: if (TREE_READONLY (base) || (TREE_CODE (base) == VAR_DECL DECL_HARD_REGISTER (base))) return false; because TREE_READONLY (base) == true !
[Bug libstdc++/64302] The match_results::cbegin()/cend() return incorrect results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64302 --- Comment #1 from Tim Shen timshen at gcc dot gnu.org --- Author: timshen Date: Wed Dec 17 09:25:44 2014 New Revision: 218810 URL: https://gcc.gnu.org/viewcvs?rev=218810root=gccview=rev Log: PR libstdc++/64302 PR libstdc++/64303 * include/bits/regex.h (match_results::cbegin, match_results::cend, regex_token_iterator::regex_token_iterator, regex_token_iterator::_M_normalize_result): Fix match_results cbegin and cend and regex_token_iterator::_M_result invariant. * include/bits/regex.tcc: Fix regex_token_iterator::_M_result invariant. * testsuite/28_regex/iterators/regex_token_iterator/64303.cc: Testcase. Added: trunk/libstdc++-v3/testsuite/28_regex/iterators/regex_token_iterator/64303.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/regex.h trunk/libstdc++-v3/include/bits/regex.tcc
[Bug libstdc++/64303] The regex_token_iterator's copy constructor creates an incorrect iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64303 --- Comment #1 from Tim Shen timshen at gcc dot gnu.org --- Author: timshen Date: Wed Dec 17 09:25:44 2014 New Revision: 218810 URL: https://gcc.gnu.org/viewcvs?rev=218810root=gccview=rev Log: PR libstdc++/64302 PR libstdc++/64303 * include/bits/regex.h (match_results::cbegin, match_results::cend, regex_token_iterator::regex_token_iterator, regex_token_iterator::_M_normalize_result): Fix match_results cbegin and cend and regex_token_iterator::_M_result invariant. * include/bits/regex.tcc: Fix regex_token_iterator::_M_result invariant. * testsuite/28_regex/iterators/regex_token_iterator/64303.cc: Testcase. Added: trunk/libstdc++-v3/testsuite/28_regex/iterators/regex_token_iterator/64303.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/regex.h trunk/libstdc++-v3/include/bits/regex.tcc
[Bug sanitizer/64289] ICE with -fsanitize=float-cast-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64289 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Dec 17 09:26:49 2014 New Revision: 218811 URL: https://gcc.gnu.org/viewcvs?rev=218811root=gccview=rev Log: PR sanitizer/64289 * c-convert.c: Include ubsan.h. (convert): For real - integral casts and -fsanitize=float-cast-overflow don't call convert_to_integer, but instead instrument the float cast directly. * c-c++-common/ubsan/pr64289.c: New test. Added: trunk/gcc/testsuite/c-c++-common/ubsan/pr64289.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-convert.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/64322] More optimize opportunity for constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64322 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Dec 17 09:29:12 2014 New Revision: 218812 URL: https://gcc.gnu.org/viewcvs?rev=218812root=gccview=rev Log: PR tree-optimization/64322 * tree-vrp.c (extract_range_from_binary_expr_1): Attempt to derive range for RSHIFT_EXPR even if vr0 range is not VR_RANGE or is symbolic. * gcc.dg/tree-ssa/vrp95.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp95.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug sanitizer/64336] Template functions are not instrumented at -O0 and -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64336 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-17 Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- This sounds like a bug in whatever sets TREE_READONLY on the MEM_REF. Apparently build2_stat sets read_only = 1 and clears it if the arguments aren't read-only, but that of course makes no sense for MEM_REF, even if the arguments are TREE_READONLY, that has nothing to do with TREE_READONLY of the MEM_REF itself. So, perhaps: --- gcc/tree.c.jj 2014-12-15 10:36:23.0 +0100 +++ gcc/tree.c 2014-12-17 10:48:07.216729576 +0100 @@ -4352,7 +4352,7 @@ build2_stat (enum tree_code code, tree t arguments are as well. */ constant = (TREE_CODE_CLASS (code) == tcc_comparison || TREE_CODE_CLASS (code) == tcc_binary); - read_only = 1; + read_only = TREE_CODE_CLASS (code) != tcc_reference; side_effects = TREE_SIDE_EFFECTS (t); PROCESS_ARG (0); ? INDIRECT_REF in build1_stat also sets TREE_READONLY to 0...
[Bug sanitizer/64337] New: ThreadSanitizer: std::thread + lambda false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64337
Bug ID: 64337
Summary: ThreadSanitizer: std::thread + lambda false positive
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: p.bartosiewi at partner dot samsung.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
I think this is a false positive tsan warning:
$ cat tsan.cpp
#include thread
#include cstdio
int main() {
int str = 5;
auto f = [=] {
printf(str: %d\n, str);
};
std::thread t(f);
t.join();
}
$ g++ --version
g++ (GCC) 4.9.2 20141101 (Red Hat 4.9.2-1)
$ ./a.out
str: 5
==
WARNING: ThreadSanitizer: data race (pid=21079)
Write of size 8 at 0x7d0cefd8 by thread T1:
#0 operator delete(void*) null:0 (libtsan.so.0+0x0004c8c0)
#1 deallocate /usr/include/c++/4.9.2/ext/new_allocator.h:110
(a.out+0x20ed)
#2 deallocate /usr/include/c++/4.9.2/bits/alloc_traits.h:383
(a.out+0x1fdc)
#3 _M_destroy /usr/include/c++/4.9.2/bits/shared_ptr_base.h:535
(a.out+0x2758)
#4 null null:0 (libstdc++.so.6+0x000bae11)
Previous atomic write of size 4 at 0x7d0cefd8 by main thread:
#0 __tsan_atomic32_fetch_add null:0 (libtsan.so.0+0x00020a7e)
#1 __exchange_and_add /usr/include/c++/4.9.2/ext/atomicity.h:49
(a.out+0x14b0)
#2 __exchange_and_add_dispatch /usr/include/c++/4.9.2/ext/atomicity.h:82
(a.out+0x1567)
#3 std::_Sp_counted_base(__gnu_cxx::_Lock_policy)2::_M_release()
/usr/include/c++/4.9.2/bits/shared_ptr_base.h:146 (a.out+0x2d4f)
#4 std::__shared_count(__gnu_cxx::_Lock_policy)2::~__shared_count()
/usr/include/c++/4.9.2/bits/shared_ptr_base.h:666 (a.out+0x2d1a)
#5 std::__shared_ptrstd::thread::_Impl_base,
(__gnu_cxx::_Lock_policy)2::~__shared_ptr()
/usr/include/c++/4.9.2/bits/shared_ptr_base.h:914 (a.out+0x2c25)
#6 std::shared_ptrstd::thread::_Impl_base::~shared_ptr()
/usr/include/c++/4.9.2/bits/shared_ptr.h:93 (a.out+0x2c51)
#7 threadmain()::lambda() /usr/include/c++/4.9.2/thread:135
(a.out+0x1747)
#8 main tsan.cpp:11 (a.out+0x1606)
Location is heap block of size 48 at 0x7d0cefd0 allocated by main thread:
#0 operator new(unsigned long) null:0 (libtsan.so.0+0x0004cb42)
#1 allocate /usr/include/c++/4.9.2/ext/new_allocator.h:104
(a.out+0x204d)
#2 allocate /usr/include/c++/4.9.2/bits/alloc_traits.h:357
(a.out+0x1f31)
#3
__shared_countstd::thread::_Implstd::_Bind_simplemain()::lambda()() ,
std::allocatorstd::thread::_Implstd::_Bind_simplemain()::lambda()() ,
std::_Bind_simplemain()::lambda()()
/usr/include/c++/4.9.2/bits/shared_ptr_base.h:616 (a.out+0x1dfd)
#4
__shared_ptrstd::allocatorstd::thread::_Implstd::_Bind_simplemain()::lambda()()
, std::_Bind_simplemain()::lambda()()
/usr/include/c++/4.9.2/bits/shared_ptr_base.h:1090 (a.out+0x1d2f)
#5
shared_ptrstd::allocatorstd::thread::_Implstd::_Bind_simplemain()::lambda()()
, std::_Bind_simplemain()::lambda()()
/usr/include/c++/4.9.2/bits/shared_ptr.h:316 (a.out+0x1cc3)
#6
allocate_sharedstd::thread::_Implstd::_Bind_simplemain()::lambda()() ,
std::allocatorstd::thread::_Implstd::_Bind_simplemain()::lambda()() ,
std::_Bind_simplemain()::lambda()()
/usr/include/c++/4.9.2/bits/shared_ptr.h:588 (a.out+0x1c54)
#7 make_sharedstd::thread::_Implstd::_Bind_simplemain()::lambda()()
, std::_Bind_simplemain()::lambda()()
/usr/include/c++/4.9.2/bits/shared_ptr.h:604 (a.out+0x1b15)
#8 _M_make_routinestd::_Bind_simplemain()::lambda()()
/usr/include/c++/4.9.2/thread:193 (a.out+0x1995)
#9 threadmain()::lambda() /usr/include/c++/4.9.2/thread:135
(a.out+0x1715)
#10 main tsan.cpp:11 (a.out+0x1606)
Thread T1 (tid=21081, running) created by main thread at:
#0 pthread_create null:0 (libtsan.so.0+0x0004ac26)
#1 std::thread::_M_start_thread(std::shared_ptrstd::thread::_Impl_base)
null:0 (libstdc++.so.6+0x000baed8)
#2 main tsan.cpp:11 (a.out+0x1606)
SUMMARY: ThreadSanitizer: data race ??:0 operator delete(void*)
==
ThreadSanitizer: reported 1 warnings
[Bug sanitizer/64337] ThreadSanitizer: std::thread + lambda false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64337 --- Comment #1 from Piotr Bartosiewicz p.bartosiewi at partner dot samsung.com --- There is a very similar bug report https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57507 but the code from that one does not trigger a warning with gcc 4.9.
[Bug sanitizer/64337] ThreadSanitizer: std::thread + lambda false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64337 Dmitry Vyukov dvyukov at google dot com changed: What|Removed |Added CC||dvyukov at google dot com --- Comment #2 from Dmitry Vyukov dvyukov at google dot com --- Looks like dup of issue 57507
[Bug libstdc++/64302] The match_results::cbegin()/cend() return incorrect results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64302 --- Comment #2 from Tim Shen timshen at gcc dot gnu.org --- Author: timshen Date: Wed Dec 17 10:27:21 2014 New Revision: 218814 URL: https://gcc.gnu.org/viewcvs?rev=218814root=gccview=rev Log: 2014-12-17 Tim Shen tims...@google.com PR libstdc++/64302 PR libstdc++/64303 Backported form mainline 2014-12-17 Tim Shen tims...@google.com * include/bits/regex.h (match_results::cbegin, match_results::cend, regex_token_iterator::regex_token_iterator, regex_token_iterator::_M_normalize_result): Fix match_results cbegin and cend and regex_token_iterator::_M_result invariant. * include/bits/regex.tcc: Fix regex_token_iterator::_M_result invariant. * testsuite/28_regex/iterators/regex_token_iterator/64303.cc: Testcase. Added: branches/gcc-4_9-branch/libstdc++-v3/testsuite/28_regex/iterators/regex_token_iterator/64303.cc Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/bits/regex.h branches/gcc-4_9-branch/libstdc++-v3/include/bits/regex.tcc
[Bug libstdc++/64303] The regex_token_iterator's copy constructor creates an incorrect iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64303 --- Comment #2 from Tim Shen timshen at gcc dot gnu.org --- Author: timshen Date: Wed Dec 17 10:27:21 2014 New Revision: 218814 URL: https://gcc.gnu.org/viewcvs?rev=218814root=gccview=rev Log: 2014-12-17 Tim Shen tims...@google.com PR libstdc++/64302 PR libstdc++/64303 Backported form mainline 2014-12-17 Tim Shen tims...@google.com * include/bits/regex.h (match_results::cbegin, match_results::cend, regex_token_iterator::regex_token_iterator, regex_token_iterator::_M_normalize_result): Fix match_results cbegin and cend and regex_token_iterator::_M_result invariant. * include/bits/regex.tcc: Fix regex_token_iterator::_M_result invariant. * testsuite/28_regex/iterators/regex_token_iterator/64303.cc: Testcase. Added: branches/gcc-4_9-branch/libstdc++-v3/testsuite/28_regex/iterators/regex_token_iterator/64303.cc Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/bits/regex.h branches/gcc-4_9-branch/libstdc++-v3/include/bits/regex.tcc
[Bug target/64338] [5 Regression] ICE in swap_condition, at jump.c:628
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64338 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||i?86-*-* Target Milestone|--- |5.0
[Bug target/64338] New: [5 Regression] ICE in swap_condition, at jump.c:628
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64338 Bug ID: 64338 Summary: [5 Regression] ICE in swap_condition, at jump.c:628 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Created attachment 34295 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34295action=edit preprocessed source ./cc1plus -quiet KDChartCartesianAxis.ii -quiet -mtune=generic -march=i586 -g -O2 -fomit-frame-pointer -fno-exceptions -fno-check-new -fno-threadsafe-statics -fvisibility=hidden -fvisibility-inlines-hidden -fPIC -m32 /home/abuild/rpmbuild/BUILD/calligra-2.8.6/3rdparty/kdchart/src/KDChartCartesianAxis.cpp: In member function 'virtual void KDChart::CartesianAxis::paintCtx(KDChart::PaintContext*)': /home/abuild/rpmbuild/BUILD/calligra-2.8.6/3rdparty/kdchart/src/KDChartCartesianAxis.cpp:1426:1: internal compiler error: in swap_condition, at jump.c:628 0xda1ad1 swap_condition(rtx_code) /space/rguenther/src/svn/trunk2/gcc/jump.c:628 0xb7664d emit_store_flag_1 /space/rguenther/src/svn/trunk2/gcc/expmed.c:5227 0xb76d47 emit_store_flag(rtx_def*, rtx_code, rtx_def*, rtx_def*, machine_mode, int, int) /space/rguenther/src/svn/trunk2/gcc/expmed.c:5434 0x1303358 ix86_expand_int_movcc(rtx_def**) /space/rguenther/src/svn/trunk2/gcc/config/i386/i386.c:20929 0x1303ab0 ix86_expand_int_movcc(rtx_def**) /space/rguenther/src/svn/trunk2/gcc/config/i386/i386.c:21098 0x144a08b gen_movqicc(rtx_def*, rtx_def*, rtx_def*, rtx_def*) /space/rguenther/src/svn/trunk2/gcc/config/i386/i386.md:16600 0xe547c8 insn_gen_fn::operator()(rtx_def*, rtx_def*, rtx_def*, rtx_def*) const /space/rguenther/src/svn/trunk2/gcc/recog.h:305 0xe53741 maybe_gen_insn(insn_code, unsigned int, expand_operand*) /space/rguenther/src/svn/trunk2/gcc/optabs.c:8377 0xe53a3e maybe_expand_insn(insn_code, unsigned int, expand_operand*) /space/rguenther/src/svn/trunk2/gcc/optabs.c:8407 0xe4a8b7 emit_conditional_move(rtx_def*, rtx_code, rtx_def*, rtx_def*, machine_mode, rtx_def*, rtx_def*, machine_mode, int) /space/rguenther/src/svn/trunk2/gcc/optabs.c:4614 0x17f2c00 noce_emit_cmove /space/rguenther/src/svn/trunk2/gcc/ifcvt.c:1498 0x17f31c1 noce_try_cmove /space/rguenther/src/svn/trunk2/gcc/ifcvt.c:1578 0x17f5d73 noce_process_if_block /space/rguenther/src/svn/trunk2/gcc/ifcvt.c:2754 0x17f6fa6 noce_find_if_block /space/rguenther/src/svn/trunk2/gcc/ifcvt.c:3214 0x17f7651 find_if_header /space/rguenther/src/svn/trunk2/gcc/ifcvt.c:3423 0x17fa187 if_convert /space/rguenther/src/svn/trunk2/gcc/ifcvt.c:4572 0x17fa4bd execute /space/rguenther/src/svn/trunk2/gcc/ifcvt.c:4718 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 target/62642] [4.8/4.9/5 Regression] x86 rdtsc is moved through barrier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62642 --- Comment #5 from M8R-ynb11d at mailinator dot com --- I originally put the barriers there in a futile attempt to work around the bug. Can anyone tell me whether I actually need them, or whether the intrinsic carries with it an implicit built-in barrier to prevent reordering? Ideally I'd like to write portable code using only intrinsics and not gcc-specific asm() stuff, so I hope that it's the latter.
[Bug rtl-optimization/64164] [4.9/5 Regression] one more stack slot used due to one less inlining level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164 --- Comment #5 from Patrick Marlier patrick.marlier at gmail dot com --- The regression starts from this commit: trunk@200103 commit f82f0ea592c2d78077e03f5a1a3b9b40751cc116 Author: law law@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Fri Jun 14 18:52:32 2013 + * gimple.h (gimple_can_coalesce_p): Prototype. * tree-ssa-coalesce.c (gimple_can_coalesce_p): New function. (create_outofssa_var_map, coalesce_partitions): Use it. * tree-ssa-uncprop.c (uncprop_into_successor_phis): Similarly. * tree-ssa-live.c (var_map_base_init): Use TYPE_CANONICAL if it's available. * gcc.dg/tree-ssa/coalesce-1.c: New test. And especially from this: gcc/tree-ssa-coalesce.c:gimple_can_coalesce_p (tree name1, tree name2) ... /* If the types are not the same, check for a canonical type match. This (for example) allows coalescing when the types are fundamentally the same, but just have different names. Note pointer types with different address spaces may have the same canonical type. Those are rejected for coalescing by the types_compatible_p check. */ if (TYPE_CANONICAL (t1) TYPE_CANONICAL (t1) == TYPE_CANONICAL (t2) types_compatible_p (t1, t2)) return true; But as Richard mentioned, I think the problem is in the RTL part.
[Bug middle-end/63568] Missed optimization (a ~mask) | (b mask) = a ^ ((a ^ b) mask)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63568 --- Comment #9 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Wed Dec 17 11:48:33 2014 New Revision: 218816 URL: https://gcc.gnu.org/viewcvs?rev=218816root=gccview=rev Log: PR middle-end/63568 * match.pd: Add (x ~m) | (y m) - ((x ^ y) m) ^ x pattern. * gcc.dg/pr63568.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr63568.c Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/63259] Detecting byteswap sequence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259 --- Comment #12 from thopre01 at gcc dot gnu.org --- (In reply to Oleg Endo from comment #11) (In reply to thopre01 from comment #10) I have the same gimple and for me the bswap is correctly detected. Can you break at find_bswap_or_nop just after calling find_bswap_or_nop_1 on the if (!source_stmt) and show me the output of p/x n-n ? n-n = 0x0102 limit = 4 That's good, it means the pattern is recognized. Is there an optab defined for bswap16? For both, test_099 and test_08. Indeed, my mistake. Ok I tested a bit and found that the problem is the depth at which it's looking. Try to recompile tree-ssa-math-opts.c after increasing the limit number in find_bswap_or_nop. Right now the limit will evaluate to 4 and the gimple I have has a depth of 5. I've tried ... limit += 10 + (int) ceil_log2 ((unsigned HOST_WIDE_INT) limit); ... but it doesn't change anything here. Same as the other pattern, can you try to print n-n in hex with this new limit? My guess is that the pattern is now recognized but fails later for the same reason as above. Best regards.
[Bug middle-end/62103] Incorrect folding of bitfield in a union on big endian targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62103 thopre01 at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from thopre01 at gcc dot gnu.org --- Fixed in all the branch currently supported
[Bug middle-end/63568] Missed optimization (a ~mask) | (b mask) = a ^ ((a ^ b) mask)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63568 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug testsuite/64328] addr_equal-1.c fails execution.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64328 --- Comment #4 from Tejas Belagod belagod at gcc dot gnu.org --- Author: belagod Date: Wed Dec 17 12:15:36 2014 New Revision: 218817 URL: https://gcc.gnu.org/viewcvs?rev=218817root=gccview=rev Log: PR testsuite/64328 * gcc.dg/addr_equal-1.c: Not supported for -fPIC. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/addr_equal-1.c
[Bug testsuite/64328] addr_equal-1.c fails execution.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64328 Tejas Belagod belagod at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Tejas Belagod belagod at gcc dot gnu.org --- Fixed by r218817.
[Bug tree-optimization/64322] More optimize opportunity for constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64322 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- So, is this fix acceptable to the reporter? The explanation in the combiner is that in the first testcase you have multiple uses of the load of 0x1L constant and therefore it is not attempted to be combined with the second use (division), changing that is undesirable I think, combine is already expensive as is.
[Bug middle-end/64182] [5 Regression] wide-int rounding division is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64182 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #10 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed?
[Bug middle-end/64339] New: reject unsafe options in pragma GCC optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64339 Bug ID: 64339 Summary: reject unsafe options in pragma GCC optimize Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: manu at gcc dot gnu.org Some options are known to be unsafe to set via pragma GCC optimize. See: https://sourceware.org/ml/libc-alpha/2014-12/msg00597.html and https://sourceware.org/ml/libc-alpha/2014-12/msg00599.html It would be better to add a flag to the *.opt files to mark safe options explicitly, such that specifying any option that is not safe produces a fatal error.
[Bug c++/48026] #pragma optimize ignored for C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48026 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- This is probably because the preprocessor runs before the #pragmas are handled. If so, this is the same issue as for #pragma GCC diagnostics in C++ (PR53431).
[Bug sanitizer/64336] Template functions are not instrumented at -O0 and -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64336 --- Comment #3 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Yes, this patch seems to work... But why did this only cause problems with template expansions and nothing else ?
[Bug middle-end/64327] ../../gcc/gcc/rtlanal.c:4881:48: runtime error: shift exponent 4294967295 is too large for 64-bit type 'long unsigned int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64327 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-17 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- I see that too.
[Bug target/64338] [5 Regression] ICE in swap_condition, at jump.c:628
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64338
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-12-17
CC||trippels at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
(gdb) p code
$1 = UNKNOWN
markus@x4 tmp % cat KDChartCartesianAxis.ii
enum Orientation
{
};
class A
{
public:
A ();
};
class B
{
public:
int m_fn1 ();
};
class C
{
class D;
D *m_fn2 ();
void m_fn3 (void *);
int m_fn4 ();
};
class F
{
public:
void m_fn5 (const int = 0);
};
class G
{
public:
F *m_fn6 ();
};
class H
{
public:
int subStepWidth;
};
class C::D
{
friend class C;
G *m_fn7 ();
};
Orientation a;
void
C::m_fn3 (void *)
{
int b = a;
H c;
if (b)
m_fn2 ()-m_fn7 ()-m_fn6 ()-m_fn5 ();
double d;
if (m_fn4 ())
d = c.subStepWidth 0;
A e (b ? A () : A ());
B f;
f.m_fn1 () d m_fn2 ();
}
markus@x4 tmp % g++ -c -mtune=generic -march=i586 -m32 -O2
KDChartCartesianAxis.ii
KDChartCartesianAxis.ii: In member function ‘void C::m_fn3(void*)’:
KDChartCartesianAxis.ii:55:1: internal compiler error: in swap_condition, at
jump.c:628
[Bug target/64254] [5 Regression] FAIL: c-c++-common/torture/vshuf-(v4si|v8hi).c -O* (internal compiler error) between r218540 and r218566.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64254 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- The failures for c-c++-common/torture/vshuf-(v4si|v8hi).c are gone at r218812 (they were still present at r218658), see https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg02164.html I have no interest in bisecting the range. The gcc.target/i386/avx512bw-vpbroadcast[bw]-1.c failures are tracked in pr64311. Closing as FIXED.
[Bug ipa/63851] [5 Regression] 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 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr --- Results with the patch in comment 5 at https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg02164.html. Note that the test gfortran.dg/assumed_rank_10.f90 fails at run time when compiled with '-O2 -funroll-loops -m32'. Without '-funroll-loops' the test succeeds at run time.
[Bug middle-end/64340] New: [5 Regression] FAIL: gnat.dg/lto8.adb (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64340 Bug ID: 64340 Summary: [5 Regression] FAIL: gnat.dg/lto8.adb (internal compiler error) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr Between revisions r218766 (OK) and r218797 (ICE) the test gnat.dg/lto8.adb has started to fail. The ICE is /opt/gcc/p_work/gcc/testsuite/gnat.dg/lto8_pkg.ads: In function 'lto8_pkg___elabs': /opt/gcc/p_work/gcc/testsuite/gnat.dg/lto8_pkg.ads:4:1: internal compiler error: in expand_gimple_stmt_1, at cfgexpand.c:3420
[Bug middle-end/64340] [5 Regression] FAIL: gnat.dg/lto8.adb (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64340 --- Comment #1 from Andreas Schwab sch...@linux-m68k.org --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64043#c11
[Bug target/61296] Excessive alignment in ix86_data_alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296
--- Comment #16 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org ---
Author: hjl
Date: Wed Dec 17 14:22:57 2014
New Revision: 218818
URL: https://gcc.gnu.org/viewcvs?rev=218818root=gccview=rev
Log:
Add -malign-data={abi|compat|cachineline}
Add -malign-data={abi|compat,cachineline} to control how GCC aligns
variables. compat uses increased alignment value compatible with
GCC 4.8 and earlier, abi uses alignment value as specified by the
psABI, and cacheline uses increased alignment value to match the
cache line size. compat is the default.
gcc/
PR target/61296
* config/i386/i386-opts.h (ix86_align_data): New enum.
* config/i386/i386.c (ix86_data_alignment): Return the ABI
alignment value for -malign-data=abi, the cachine line size
for -malign-data=cachineline and the older GCC compatible
alignment value for for -malign-data=compat.
* config/i386/i386.opt (malign-data=): New.
* doc/invoke.texi: Document -malign-data=.
gcc/testsuite/
PR target/61296
* gcc.target/i386/pr61296-2.c: New.
* gcc.target/i386/pr61296-2.c: Likewise.
* gcc.target/i386/pr61296-3.c: Likewise.
* gcc.target/i386/pr61296-4.c: Likewise.
* gcc.target/i386/pr61296-5.c: Likewise.
* gcc.target/i386/pr61296-6.c: Likewise.
* gcc.target/i386/pr61296-7.c: Likewise.
Added:
trunk/gcc/testsuite/gcc.target/i386/pr61296-1.c
trunk/gcc/testsuite/gcc.target/i386/pr61296-2.c
trunk/gcc/testsuite/gcc.target/i386/pr61296-3.c
trunk/gcc/testsuite/gcc.target/i386/pr61296-4.c
trunk/gcc/testsuite/gcc.target/i386/pr61296-5.c
trunk/gcc/testsuite/gcc.target/i386/pr61296-6.c
trunk/gcc/testsuite/gcc.target/i386/pr61296-7.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386-opts.h
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.opt
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/64322] More optimize opportunity for constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64322 --- Comment #8 from rguenther at suse dot de rguenther at suse dot de --- On Wed, 17 Dec 2014, jakub at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64322 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- So, is this fix acceptable to the reporter? The explanation in the combiner is that in the first testcase you have multiple uses of the load of 0x1L constant and therefore it is not attempted to be combined with the second use (division), changing that is undesirable I think, combine is already expensive as is. True, though eventually changing this just for constants (thus (const ...) and CONST_INT and ...) might be worth the additional overhead. I can imagine targets that don't support (large) immediates being pessimized very much otherwise.
[Bug lto/64043] [5 Regression] ICE (segfault) with LTO: in tree_check/tree.h:2758 get_binfo_at_offset/tree.c:11914
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64043 --- Comment #12 from Dominique d'Humieres dominiq at lps dot ens.fr --- This breaks ada: ... It is now pr64340.
[Bug tree-optimization/64330] [5 Regression] IPA-ICF merges const exported vars that could be addressable in other TUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64330 Yury Gribov y.gribov at samsung dot com changed: What|Removed |Added CC||y.gribov at samsung dot com --- Comment #6 from Yury Gribov y.gribov at samsung dot com --- (In reply to Jakub Jelinek from comment #5) (In reply to Kostya Serebryany from comment #4) So, maybe the ODR checker in the current form is not that useless. Sorry, couldn't resist :) But it isn't really an ODR checker. Basically a symbol aliasing checker.
[Bug target/61296] Excessive alignment in ix86_data_alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #17 from H.J. Lu hjl.tools at gmail dot com --- Fixed in GCC 5.
[Bug target/64338] [5 Regression] ICE in swap_condition, at jump.c:628
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64338 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r217646.
[Bug rtl-optimization/64010] [msp430-elf] struct function dereference clobbers parameter passed to function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64010 --- Comment #12 from Ulrich Weigand uweigand at gcc dot gnu.org --- Author: uweigand Date: Wed Dec 17 15:07:28 2014 New Revision: 218821 URL: https://gcc.gnu.org/viewcvs?rev=218821root=gccview=rev Log: 2014-12-17 Ulrich Weigand ulrich.weig...@de.ibm.com Backport from mainline 2014-12-03 Ulrich Weigand ulrich.weig...@de.ibm.com PR rtl-optimization/64010 * reload.c (push_reload): Before reusing a register contained in an operand as input reload register, ensure that it is not used in CALL_INSN_FUNCTION_USAGE. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/reload.c
[Bug rtl-optimization/64010] [msp430-elf] struct function dereference clobbers parameter passed to function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64010 --- Comment #13 from Ulrich Weigand uweigand at gcc dot gnu.org --- Since this has been in mainline for two weeks without reported issues, and it should in general be a safe change, I've backported the patch to 4.9 now.
[Bug rtl-optimization/64010] [msp430-elf] struct function dereference clobbers parameter passed to function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64010 Ulrich Weigand uweigand at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |uweigand at gcc dot gnu.org --- Comment #14 from Ulrich Weigand uweigand at gcc dot gnu.org --- Fixed.
[Bug target/64331] regcprop propagates registers noted as REG_DEAD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64331 --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Is it just REG_USED/REG_DEAD notes, or is register liveliness (df_regs_ever_live_p etc..) also not guaranteed to be up to date? These REG_UNUSED/REG_DEAD notes are special because they are not maintained incrementally by the DF framework, i.e. the insn manipulation routines don't cause them to be updated, so they are really valid only just after they are recomputed. The rest of the liveness info is updated incrementally (if DF is asked to).
[Bug rtl-optimization/64341] [5 regression] ICE in expand_expr_addr_expr_1, at expr.c:7718
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64341 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug rtl-optimization/64341] New: [5 regression] ICE in expand_expr_addr_expr_1, at expr.c:7718
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64341 Bug ID: 64341 Summary: [5 regression] ICE in expand_expr_addr_expr_1, at expr.c:7718 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: ebotcazou at gcc dot gnu.org Host: sparc*-sun-solaris2.* Target: sparc*-sun-solaris2.* Build: sparc*-sun-solaris2.* Since 20141021 (r216502), I see a the following ICE on 32-bit Solaris/SPARC: FAIL: 21_strings/basic_string/modifiers/replace/wchar_t/4.cc (test for excess errors) WARNING: 21_strings/basic_string/modifiers/replace/wchar_t/4.cc compilation failed to produce executable Excess errors: /vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/replace/wchar_t/4.cc:29:1: internal compiler error: in expand_expr_addr_expr_1, at expr.c:7718 0x66fe7f expand_expr_addr_expr_1 /vol/gcc/src/hg/trunk/local/gcc/expr.c:7718 0x66284b expand_expr_addr_expr /vol/gcc/src/hg/trunk/local/gcc/expr.c:7832 0x66284b expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /vol/gcc/src/hg/trunk/local/gcc/expr.c:10706 0x66284b expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /vol/gcc/src/hg/trunk/local/gcc/expr.c:10706 0x54a53f expand_normal /vol/gcc/src/hg/trunk/local/gcc/expr.h:305 0x54a53f precompute_register_parameters /vol/gcc/src/hg/trunk/local/gcc/calls.c:869 0x54a53f expand_call(tree_node*, rtx_def*, int) /vol/gcc/src/hg/trunk/local/gcc/calls.c:3119 0x6619b7 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /vol/gcc/src/hg/trunk/local/gcc/expr.c:10474 0x55e00b expand_expr /vol/gcc/src/hg/trunk/local/gcc/expr.h:299 0x55e00b expand_call_stmt /vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:2347 0x55e00b expand_gimple_stmt_1 /vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:3293 0x55e00b expand_gimple_stmt /vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:3447 0x563883 expand_gimple_basic_block /vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:5280 0x565fdb execute /vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:5889 Since 20141030 (r216932), there's another failure with the same ICE, again only for 32-bit: FAIL: g++.dg/ipa/pr63587-2.C -std=gnu++11 (internal compiler error) FAIL: g++.dg/ipa/pr63587-2.C -std=gnu++11 (test for excess errors) FAIL: g++.dg/ipa/pr63587-2.C -std=gnu++14 (internal compiler error) FAIL: g++.dg/ipa/pr63587-2.C -std=gnu++14 (test for excess errors) Excess errors: /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/ipa/pr63587-2.C:21:3: internal compiler error: in expand_expr_addr_expr_1, at expr.c:7718 0x66fe7f expand_expr_addr_expr_1 /vol/gcc/src/hg/trunk/local/gcc/expr.c:7718 0x66284b expand_expr_addr_expr /vol/gcc/src/hg/trunk/local/gcc/expr.c:7718 0x66284b expand_expr_addr_expr /vol/gcc/src/hg/trunk/local/gcc/expr.c:7832 0x66284b expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /vol/gcc/src/hg/trunk/local/gcc/expr.c:10706 0x54a53f expand_normal /vol/gcc/src/hg/trunk/local/gcc/expr.h:305 0x54a53f precompute_register_parameters /vol/gcc/src/hg/trunk/local/gcc/calls.c:869 0x54a53f expand_call(tree_node*, rtx_def*, int) /vol/gcc/src/hg/trunk/local/gcc/calls.c:3119 0x6619b7 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /vol/gcc/src/hg/trunk/local/gcc/expr.c:10474 0x67043f store_expr_with_bounds(tree_node*, rtx_def*, int, bool, tree_node*) /vol/gcc/src/hg/trunk/local/gcc/expr.c:5365 0x678e37 expand_assignment(tree_node*, tree_node*, bool) /vol/gcc/src/hg/trunk/local/gcc/expr.c:5137 0x55d803 expand_call_stmt /vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:2345 0x55d803 expand_gimple_stmt_1 /vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:3293 0x55d803 expand_gimple_stmt_1 /vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:3293 0x55d803 expand_gimple_stmt /vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:3447 0x563883 expand_gimple_basic_block /vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:5280 0x565fdb execute /vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:5889 This might be a dup (or at least related) to PR rtl-optimization/64033. Rainer
[Bug c/63336] cilkplus array notation ICE in find_rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63336 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-17 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug target/63908] [e500v2] float_besselcase failed on e500v2 platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63908 --- Comment #8 from joseph at codesourcery dot com joseph at codesourcery dot com --- Olivier Hainque referred to having a 4.9 version of his patch, I suggest you ask him.
[Bug middle-end/64340] [5 Regression] FAIL: gnat.dg/lto8.adb (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64340 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug target/64342] New: [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64342
Bug ID: 64342
Summary: [5 Regression] Tests failing when compiled with '-m32
-fpic' after r216154.
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dominiq at lps dot ens.fr
CC: hjl at gcc dot gnu.org, howarth at bromo dot med.uc.edu,
iains at gcc dot gnu.org, ienkovich at gcc dot gnu.org,
kyukhin at gcc dot gnu.org
The following failures have been caused by r216154 and reported at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534#c69
FAIL: gcc.target/i386/avx512f-kandnw-1.c scan-assembler-times kandnw[
t]+[^{\\n]*%k[0-7](?:\\n|[ t]+#) 1
FAIL: gcc.target/i386/funcspec-5.c (test for excess errors)
FAIL: gcc.target/i386/fuse-caller-save-rec.c scan-assembler-not pop
FAIL: gcc.target/i386/fuse-caller-save-rec.c scan-assembler-not push
FAIL: gcc.target/i386/fuse-caller-save-rec.c scan-assembler-times
addl\\t%[re]?dx, %[re]?ax 1
FAIL: gcc.target/i386/fuse-caller-save-xmm.c scan-assembler-times
addpd\\t%xmm1, %xmm0 1
FAIL: gcc.target/i386/fuse-caller-save-xmm.c scan-assembler-times
movapd\\t%xmm0, %xmm1 1
FAIL: gcc.target/i386/fuse-caller-save.c scan-assembler-not pop
FAIL: gcc.target/i386/fuse-caller-save.c scan-assembler-not push
FAIL: gcc.target/i386/fuse-caller-save.c scan-assembler-times
addl\\t%[re]?d[ix], %[re]?ax 1
They require to compile the tests with '-fpic -m32' and are still present at
r218812, see
https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg02164.html
https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg02159.html
[Bug lto/64343] New: [5 Regression] lto compile options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64343 Bug ID: 64343 Summary: [5 Regression] lto compile options Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch somewhere between r218726 and r218773 (1day) code compiled linked with FCFLAGS = -flto=jobserver -ffree-form -cpp LDFLAGS = $(FCFLAGS) -O3 -funroll-loops -ffast-math -march=native -fuse-linker-plugin -flto=jobserver seems to remain in unoptimized form, while previously they would be optimized at -O3. It does now seem like the compile time flags and not the ld flags control the optimization level of the binary.
[Bug lto/64343] [5 Regression] lto compile options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64343 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- possibly caused by r218767 ?
[Bug tree-optimization/64330] [5 Regression] IPA-ICF merges const exported vars that could be addressable in other TUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64330 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org --- I think the test should be something like VIRTUAL || -fmerge-all-constants || (!TREE_ADDRESSABLE ! externally_visible) te current code seems to miss the externally_visible flag. Indeed you can not merge symbols that may have address taken. How does asan behave with aliases? Honza
[Bug lto/64343] [5 Regression] lto compile options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64343 --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org --- This is intended change. Compiling with -O0 -flto and linking with -O3 will not really give you -O3 optimized code in earlier compilers either; you will not get any of early optimizations and inlining will not use any of the more advanced optimizations. THe purpose of OPTIMIZE/TARGET_OPTION node streaming is to make LTO closer to non-LTO copmilation by making the compile time flags to matter. This allows you to i.e. combine -ffast-math/-fno-fast-math units well or build part of program with different target options.
[Bug middle-end/64340] [5 Regression] FAIL: gnat.dg/lto8.adb (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64340 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org --- Seems more of preloading needs tobe skipped. I will dig into that.
[Bug sanitizer/64344] New: [5 Regression] [UBSAN] ICE with -fsanitize=float-cast-overflow [ICE in -fsanitize=float-cast-overflow]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64344
Bug ID: 64344
Summary: [5 Regression] [UBSAN] ICE with
-fsanitize=float-cast-overflow [ICE in
-fsanitize=float-cast-overflow]
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
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,
mpolacek at gcc dot gnu.org
New since today:
$ gcc -w -fsanitize=float-cast-overflow new8.i
new8.i: In function ‘float2long’:
new8.i:11:23: internal compiler error: in -fsanitize=float-cast-overflow
*exponent = (int32 )log((double )value);
^
0x9058fb gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:8451
For the following program:
/* --*/
typedef enum {
PARAPROX_Q_EXTRA_FAST = 4
} pthread_cond_t;
extern int drand48_r (struct drand48_data *__restrict __buffer,
int __reject3)
{
}
typedef int int32;
float2long(int32 *mantisse, int32 *exponent, float value)
{
*exponent = (int32 )log((double )value);
}
[Bug lto/64343] [5 Regression] lto compile options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64343 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- OK,fine with me.
[Bug ipa/64325] [5 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64325 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-12-17 Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org --- mine.
[Bug sanitizer/64344] [5 Regression] [UBSAN] ICE with -fsanitize=float-cast-overflow [ICE in -fsanitize=float-cast-overflow]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64344 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #0) New since today: Tested with r218820, I think it was working this morning (r218809?). new8.i: In function ‘float2long’: new8.i:11:23: internal compiler error: in -fsanitize=float-cast-overflow Pasto - should have been: $ gcc -w -fsanitize=float-cast-overflow new8.i new8.i: In function ‘float2long’: new8.i:11:23: internal compiler error: in gimplify_expr, at gimplify.c:8451 *exponent = (int32 )log((double )value); ^ 0x9058fb gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:8451
[Bug go/61265] gccgo: ICE in verify_gimple_in_seq [GoSmith]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61265
--- Comment #2 from Chris Manghane cmang at google dot com ---
A slightly smaller program can reproduce this as well:
package main
var a = [1][0]int{B}[0]
var B = [0]int{}
func main() {}
This error occurs because in Gcc_backend::fill_in_array, the type of B, [0]int,
is represented using build_array_type(int, build_index_type(len - 1)), where
len is 0 in this case, giving it a range of [0:MAX_INT] where it should be
[0:0]. The following patch fixes this behavior:
Index: gcc/go/go-gcc.cc
==
--- a/gcc/go/go-gcc.cc
+++ b/gcc/go/go-gcc.cc
@@ -887,9 +887,13 @@ Gcc_backend::fill_in_array(Btype* fill, Btype*
element_type,
// build_index_type takes the maximum index, which is one less than
// the length.
- tree index_type_tree = build_index_type(fold_build2(MINUS_EXPR, sizetype,
- length_tree,
- size_one_node));
+ tree index_type_tree = NULL_TREE;
+ if (length_tree == size_zero_node)
+index_type_tree = build_index_type(size_zero_node);
+ else
+index_type_tree = build_index_type(fold_build2(MINUS_EXPR, sizetype,
+ length_tree,
+ size_one_node));
tree fill_tree = fill-get_tree();
TREE_TYPE(fill_tree) = element_type_tree;
[Bug target/64011] Fail to compile pr48335-2.c on big-endian aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64011 Jiong Wang jiwang at gcc dot gnu.org changed: What|Removed |Added Target|aarch64-linux-gnu |aarch64-linux-gnu, ||arm-linux-gnu Status|NEW |ASSIGNED Version|4.9.3 |5.0 --- Comment #1 from Jiong Wang jiwang at gcc dot gnu.org --- the same problem exist on ARM when BFI instruction available, and because there are more strict constraint, it's actually ICE on ARM. ./cc1 -march=armv7-a -O2 big-bug.c -nostdinc -mbig-endian big-bug.c: In function ‘f5’: big-bug.c:16:1: error: unrecognizable insn: } ^ (insn 8 7 9 2 (set (zero_extract:SI (subreg:SI (reg/v:SF 112 [ s+4 ]) 0) (const_int 16 [0x10]) (const_int -8 [0xfff8])) (reg/v:SI 113 [ x ])) big-bug.c:13 -1 (nil)) big-bug.c:16:1: internal compiler error: in extract_insn, at recog.c:2327 0xc704af _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) ../../gcc/gcc/rtl-error.c:110 0xc704f0 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) ../../gcc/gcc/rtl-error.c:118 0xc252b9 extract_insn(rtx_insn*) ../../gcc/gcc/recog.c:2327 0x978084 instantiate_virtual_regs_in_insn ../../gcc/gcc/function.c:1582 0x979461 instantiate_virtual_regs ../../gcc/gcc/function.c:1950 0x979534 execute
[Bug tree-optimization/64330] [5 Regression] IPA-ICF merges const exported vars that could be addressable in other TUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64330 --- Comment #8 from Martin Liška marxin at gcc dot gnu.org --- Thank you for the missing externally visible attribute. I've been testing following patch: diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c index b193200..0685019 100644 --- a/gcc/ipa-icf.c +++ b/gcc/ipa-icf.c @@ -1131,8 +1131,12 @@ sem_variable::parse (varpool_node *node, bitmap_obstack *stack) tree decl = node-decl; bool readonly = TYPE_P (decl) ? TYPE_READONLY (decl) : TREE_READONLY (decl); - bool can_handle = readonly (DECL_VIRTUAL_P (decl) -|| !TREE_ADDRESSABLE (decl)); + if (!readonly) +return NULL; + + bool can_handle = DECL_VIRTUAL_P (decl) + || flag_merge_constants = 2 + || (!TREE_ADDRESSABLE (decl) !node-externally_visible); if (!can_handle) return NULL; As soon as tests finish, I will send it to ML. Martin
[Bug go/61263] gccgo: fatal error: schedule: holding locks [GoSmith]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61263 Chris Manghane cmang at google dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||cmang at google dot com Resolution|--- |FIXED Assignee|ian at airs dot com|cmang at google dot com --- Comment #1 from Chris Manghane cmang at google dot com --- Ran this one hundred thousand times with GOGC=0 and unmodified GOGC, could not reproduce at all. Marking as resolved; this might have been fixed with other various fixes to add type precision to heap.
[Bug tree-optimization/64330] [5 Regression] IPA-ICF merges const exported vars that could be addressable in other TUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64330 --- Comment #9 from Jan Hubicka hubicka at ucw dot cz --- Thank you for the missing externally visible attribute. I've been testing following patch: diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c index b193200..0685019 100644 --- a/gcc/ipa-icf.c +++ b/gcc/ipa-icf.c @@ -1131,8 +1131,12 @@ sem_variable::parse (varpool_node *node, bitmap_obstack *stack) tree decl = node-decl; bool readonly = TYPE_P (decl) ? TYPE_READONLY (decl) : TREE_READONLY (decl); - bool can_handle = readonly (DECL_VIRTUAL_P (decl) -|| !TREE_ADDRESSABLE (decl)); + if (!readonly) +return NULL; + + bool can_handle = DECL_VIRTUAL_P (decl) + || flag_merge_constants = 2 + || (!TREE_ADDRESSABLE (decl) !node-externally_visible); if (!can_handle) return NULL; As soon as tests finish, I will send it to ML. Thanks, the patch is OK if it passes. Also please be sure that we won't merge DECL_EXTERNAL at all. Producing an extenral alias is not going to save any code. Honza Martin -- You are receiving this mail because: You are on the CC list for the bug.
[Bug fortran/64173] [F03] ICE involving procedure pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64173 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code CC||janus at gcc dot gnu.org Summary|ICE involving derived type |[F03] ICE involving |function pointers |procedure pointer component --- Comment #3 from janus at gcc dot gnu.org --- Here is a slightly reduced test case: implicit none type :: r_magnus_ivp_t integer, allocatable :: jc procedure(abscissa_), nopass, pointer :: abscissa_p end type abstract interface function abscissa_ () result (x) real, allocatable :: x(:) end function end interface contains function doinit () result (iv) type(r_magnus_ivp_t) :: iv end function end The backtrace on trunk is: internal compiler error: in gfc_conv_descriptor_data_set, bei fortran/trans-array.c:172 0x6803bd gfc_conv_descriptor_data_set(stmtblock_t*, tree_node*, tree_node*) /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-array.c:172 0x694b6c structure_alloc_comps /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-array.c:7785 0x695895 gfc_nullify_alloc_comp(gfc_symbol*, tree_node*, int) /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-array.c:7999 0x6a744e gfc_generate_function_code(gfc_namespace*) /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-decl.c:5806 0x6a6b67 gfc_generate_contained_functions /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-decl.c:4912 0x6a6b67 gfc_generate_function_code(gfc_namespace*) /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-decl.c:5707 0x67f7b8 gfc_generate_code(gfc_namespace*) /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans.c:1945 0x6399f0 translate_all_program_units /home/jweil/gcc/gcc50/trunk/gcc/fortran/parse.c:4949 0x6399f0 gfc_parse_file() /home/jweil/gcc/gcc50/trunk/gcc/fortran/parse.c:5146 0x678665 gfc_be_parse_file /home/jweil/gcc/gcc50/trunk/gcc/fortran/f95-lang.c:222
[Bug fortran/64173] [F03] ICE involving procedure pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64173 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org --- Comment #4 from janus at gcc dot gnu.org --- Turns out the fix is pretty much trivial: Index: gcc/fortran/trans-array.c === --- gcc/fortran/trans-array.c(Revision 218782) +++ gcc/fortran/trans-array.c(Arbeitskopie) @@ -7775,7 +7775,7 @@ structure_alloc_comps (gfc_symbol * der_type, tree break; case NULLIFY_ALLOC_COMP: - if (c-attr.pointer) + if (c-attr.pointer || c-attr.proc_pointer) continue; else if (c-attr.allocatable (c-attr.dimension|| c-attr.codimension)) Will commit after regtesting ...
[Bug fortran/61952] ICE allocattion of array of type of type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61952 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||janus at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #3 from janus at gcc dot gnu.org --- The ICE here is also fixed by the patch for PR 64173, which shows that it is indeed a duplicate. *** This bug has been marked as a duplicate of bug 64173 ***
[Bug fortran/64173] [F03] ICE involving procedure pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64173 janus at gcc dot gnu.org changed: What|Removed |Added CC||valeryweber at hotmail dot com --- Comment #5 from janus at gcc dot gnu.org --- *** Bug 61952 has been marked as a duplicate of this bug. ***
[Bug middle-end/64340] [5 Regression] FAIL: gnat.dg/lto8.adb (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64340 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-17 CC||danglin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from John David Anglin danglin at gcc dot gnu.org --- Also seen on hppa-unknown-linux-gnu.
[Bug c++/64333] C++14 constexpr gives wrong results when a looping constexpr function is evaluated twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64333 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Dec 17 20:41:18 2014 New Revision: 218832 URL: https://gcc.gnu.org/viewcvs?rev=218832root=gccview=rev Log: PR c++/64333 * constexpr.c (cxx_bind_parameters_in_call): non_constant_args parm. (cxx_eval_call_expression): Don't cache calls with non-constant args. (cxx_eval_constant_expression) [COMPOUND_EXPR]: Pass true for lval. (cxx_eval_unary_expression, cxx_eval_binary_expression) (cxx_eval_conditional_expression): Passfalse for lval. Added: trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-initlist1.C trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-loop2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c
[Bug c++/64333] C++14 constexpr gives wrong results when a looping constexpr function is evaluated twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64333 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Target Milestone|--- |5.0 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Fixed.
[Bug target/53987] [SH] Unnecessary zero-extension before cmp/eq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53987 --- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org --- It seems that converting unsigned values to signed values, i.e. replacing zero-extensions with sign-extensions and recombining sign-extensions with loads could make sense in general. For example, the following code from CSiBE mpeg2dec-0.3.1/libmpeg2/motion_comp.s contains sequences like: _MC_put_x_8_c: .align 2 .L24: mov.b @r5,r0 sett extu.b r0,r1 mov.b @(1,r5),r0 extu.b r0,r0 addcr1,r0 sharr0 mov.b r0,@r4 sett mov.b @(1,r5),r0 extu.b r0,r3 mov.b @(2,r5),r0 extu.b r0,r1 mov r3,r0 addcr1,r0 sharr0 mov.b r0,@(1,r4) Here effectively only 8 bit values are calculated. The zero-extensions can be omitted, since the higher bits do not influence the result of the lowest 8 bits and the higher bits are discarded after the 8 bit stores.
[Bug fortran/64173] [F03] ICE involving procedure pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64173 --- Comment #6 from janus at gcc dot gnu.org --- Author: janus Date: Wed Dec 17 21:12:42 2014 New Revision: 218834 URL: https://gcc.gnu.org/viewcvs?rev=218834root=gccview=rev Log: 2014-12-17 Janus Weil ja...@gcc.gnu.org PR fortran/64173 * trans-array.c (structure_alloc_comps): Do not nullify procedure pointer components. 2014-12-17 Janus Weil ja...@gcc.gnu.org PR fortran/64173 * gfortran.dg/proc_ptr_comp_40.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_40.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/64173] [F03] ICE involving procedure pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64173 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from janus at gcc dot gnu.org --- Fixed on trunk with r218834. Closing. Thanks for the report!
[Bug rtl-optimization/64110] [5 Regression] ICE: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64110 --- Comment #12 from Vladimir Makarov vmakarov at gcc dot gnu.org --- I've just fixed the problem reported by H.J.
[Bug ipa/63851] [5 Regression] 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 --- Comment #9 from howarth at bromo dot med.uc.edu --- (In reply to Dominique d'Humieres from comment #8) Results with the patch in comment 5 at https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg02164.html. Note that the test gfortran.dg/assumed_rank_10.f90 fails at run time when compiled with '-O2 -funroll-loops -m32'. Without '-funroll-loops' the test succeeds at run time. And, as before, appending -fno-ipa-icf to the failing test cases compile flags suppresses the failure.
[Bug rtl-optimization/64110] [5 Regression] ICE: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64110 --- Comment #13 from Vladimir Makarov vmakarov at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #11) Looking at the generated assembly, I see there: movw%di, -80(%rbp) vpbroadcastw-80(%rbp), %ymm1 vmovdqa %ymm1, -80(%rbp) I'd have expected vmovd %edi, %xmm1 vpbroadcastw%xmm1, %ymm1 vmovdqa %ymm1, -80(%rbp) Is there some bug in the *vec_dupv16hi pattern that LRA can't use the !r alternative? %di should be valid nonimmediate_operand in HImode. For e.g. I know about the problem. It is coming from a different treatment of ! in LRA and reload. I am going to work on this but as the fix would be in very sensitive LRA part. I am afraid to fix it before my vacation. So probably it will be solved only in January.
[Bug target/39570] cabs and cabsf are named differently on NetBSD 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39570 Kai-Uwe Eckhardt kuehro at gmx dot de changed: What|Removed |Added CC||kuehro at gmx dot de --- Comment #12 from Kai-Uwe Eckhardt kuehro at gmx dot de --- Created attachment 34296 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34296action=edit a set of four patches for snapshot 20141214 I have used the darwin files as templates and made the necessary changes. It reduces test failures from over 15000 (all run tests) to 27 in 3 files (patch for PR 48244 applied as well).
[Bug go/61265] gccgo: ICE in verify_gimple_in_seq [GoSmith]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61265
--- Comment #3 from Chris Manghane cmang at google dot com ---
Sorry for the noise, responding with new information as I discover it.
The above patch doesn't really work (it fails a few tests) because this isn't a
problem with zero-sized array types, but rather a problem with zero-sized
elements in array types.
This same bug can be reproduced by
package main
var a = [1]struct{}{B}[0]
var B = struct{}{}
func main(){}
because struct{} is a zero-sized type and the backend implementation makes
assumptions about zero-sized globals for the linker. A better approach is to
just avoid constructing an array of zero-sized values and evaluate the
zero-valued expressions for their side effects. This is be done in
https://codereview.appspot.com/191970043/.
[Bug target/64345] New: [SH] Improve single bit extraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64345
Bug ID: 64345
Summary: [SH] Improve single bit extraction
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
Single bit extractions can be done through the T bit.
Some examples:
unsigned int test0 (unsigned int x)
{
return ((x 4) ^ 1) 1;
}
unsigned int test1 (unsigned int x)
{
return ((x 4) 1) ^ 1;
}
unsigned int test2 (unsigned int x)
{
return ~(x 4) 1;
}
now:
mov r4,r0
shlr2 r0
shlr2 r0
xor #1,r0
and #1,r0
non-sh2a:
mov r4,r0
tst #(14),r0
movtr0
sh2a:
bld #4,r4
movrt r0
unsigned int test3 (unsigned int x)
{
return ((~x 4) 1);
}
now:
not r4,r4
mov r4,r0
shlr2 r0
shlr2 r0
rts
and #1,r0
non-sh2a:
mov r4,r0
tst #(14),r0
movtr0
sh2a:
bld #4,r4
movrt r0
unsigned int test4 (unsigned int x)
{
return (x 4) 1;
}
now:
mov r4,r0
shlr2 r0
shlr2 r0
and #1,r0
non-sh2:
not r4,r0
tst #(14),r0
movtr0
sh2a (1):
mov r4,r0
tst #(14),r0
movrt r0
sh2a (2)
bld #4,r4
movtr0
This can be realized by implementing zero_extract combine patterns such as:
set (reg:SI 170 [ D.1727 ])
(zero_extract:SI (xor:SI (reg:SI 4 r4 [ x ])
(const_int 16 [0x10]))
(const_int 1 [0x1])
(const_int 4 [0x4])))
Using the recently added support for multi-set patterns in combine, the T bit
contents can be described exactly, instead of simply T bit clobbers.
If the bit position is 0...7 the SH2A bld insn can be used. For higher bit
positions it might be better to load a constant and use the tst rm,rn insn.
Alternatively the reg can be shifted right via shlr8 and shlr16 before the tst
insn. However, in this case it's probably better to use a shld + and #1,r0
sequence, if dynamic shifts are available. Although that forces the result
value into r0, which might need to be moved into another reg. With the tst
insn, r0 is used only as a temporary scratch register.
[Bug target/51244] [SH] Inefficient conditional branch and code around T bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #81 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Wed Dec 17 22:52:21 2014 New Revision: 218847 URL: https://gcc.gnu.org/viewcvs?rev=218847root=gccview=rev Log: gcc/ PR target/51244 * config/sh/sh_treg_combine.cc (sh_treg_combine::try_optimize_cbranch): Combine ccreg inversion and cbranch into inverted cbranch. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh_treg_combine.cc
[Bug c/59708] clang-compatible checked arithmetic builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59708 --- Comment #30 from Pat Haugen pthaugen at gcc dot gnu.org --- (In reply to Pat Haugen from comment #29) (In reply to Jakub Jelinek from comment #28) Assuming fixed. builtin-arith-overflow-14/17 are fixed with the patch, but builtin-arith-overflow-1/10/11 still fail for me. builtin-arith-overflow-1 has been fixed by testsuite patch. builtin-arith-overflow-10/11 are target problem, I'm working on a fix.
[Bug rtl-optimization/64110] [5 Regression] ICE: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64110 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Vladimir Makarov from comment #13) (In reply to Jakub Jelinek from comment #11) Looking at the generated assembly, I see there: movw%di, -80(%rbp) vpbroadcastw-80(%rbp), %ymm1 vmovdqa %ymm1, -80(%rbp) I'd have expected vmovd %edi, %xmm1 vpbroadcastw%xmm1, %ymm1 vmovdqa %ymm1, -80(%rbp) Is there some bug in the *vec_dupv16hi pattern that LRA can't use the !r alternative? %di should be valid nonimmediate_operand in HImode. For e.g. I know about the problem. It is coming from a different treatment of ! in LRA and reload. I am going to work on this but as the fix would be in very sensitive LRA part. I am afraid to fix it before my vacation. So probably it will be solved only in January. Np, and thanks a lot. The ! has been added by me for PR63594, so it isn't there from the era when i?86 backend was using reload. If there is a better way to express that RA should prefer to use memory or xmm register and only use r constraint if it already is in a r register and doesn't need to be reloaded, I can use that. Whether it is ?, ??? or something else. ! description in gcc docs just fitted most what I wanted...
[Bug target/51244] [SH] Inefficient conditional branch and code around T bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #82 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Wed Dec 17 23:08:14 2014 New Revision: 218850 URL: https://gcc.gnu.org/viewcvs?rev=218850root=gccview=rev Log: gcc/ PR target/51244 * config/sh/sh_treg_combine.cc (is_conditional_insn): New function. (cbranch_trace): Add member rtx* condition_rtx_in_insn, initialize it accordingly in constructor. (cbranch_trace::branch_condition_rtx_ref): New function. (cbranch_trace::branch_condition_rtx): Use branch_condition_rtx_ref. (sh_treg_combine::try_invert_branch_condition): Invert condition rtx in insn using reversed_comparison_code and validate_change instead of invert_jump_1. (sh_treg_combine::execute): Look for conditional insns in basic blocks in addition to conditional branches. * config/sh/sh.md (*movsicc_div0s): Remove combine patterns. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.md trunk/gcc/config/sh/sh_treg_combine.cc
[Bug target/51244] [SH] Inefficient conditional branch and code around T bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #83 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Oleg Endo from comment #71) * The RTL pass does the treg combine only when there is a conditional branch. It should also handle conditional move insns (-mpretend-cmove). It does now. It also handles nott cbranch sequences by inverting the branch condition and deleting the nott insn.
[Bug c++/64346] New: gcc generates incorrect debug info for ctor/dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64346
Bug ID: 64346
Summary: gcc generates incorrect debug info for ctor/dtor
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dehao at gcc dot gnu.org
#cat a.cc
#include iostream
#include memory
class ABC {
public:
ABC() {printf(abc\n);}
~ABC() {printf(xyz\n);}
};
int foo() {
std::unique_ptrABC a(new ABC());
}
#g++4.8 a.cc -c -O2 -std=c++11 -g -fno-exceptions
#addr2line -e a.o -i -f 0x13
_ZN3ABCC1Ev
/usr/local/google/home/dehao/gcc/gcc-4_9/debug/a.cc:5
_Z3foov
/usr/local/google/home/dehao/gcc/gcc-4_9/debug/a.cc:10
#g++4.9 a.cc -c -O2 -std=c++11 -g -fno-exceptions
#addr2line -e a.o -i -f 0x13
_ZN3ABCC4Ev
/usr/local/google/home/dehao/gcc/gcc-4_9/debug/a.cc:5
_Z3foov
/usr/local/google/home/dehao/gcc/gcc-4_9/debug/a.cc:10
#g++4.9 a.cc -c -O0 -std=c++11 -g -fno-exceptions
#nm a.o |grep ABCC
W _ZN3ABCC1Ev
W _ZN3ABCC2Ev
n _ZN3ABCC5Ev
Note that for the gcc 4.9 version and later, without any optimization
_ZN3ABCC4Ev does not exists in the symbol table. So we expect either
_ZN3ABCC1Ev or _ZN3ABCC2Ev in the addr2line result.
[Bug c++/64346] gcc generates incorrect debug info for ctor/dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64346 dehao at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 CC||ccoutant at gcc dot gnu.org, ||davidxl at google dot com, ||jason at gcc dot gnu.org --- Comment #1 from dehao at gcc dot gnu.org --- This may be related to https://gcc.gnu.org/ml/gcc-patches/2013-11/msg02724.html Jason could you help take a look?
[Bug rtl-optimization/64157] [5.0 regression] FAIL: gcc.dg/torture/pr52429.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64157 tbsaunde at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||tbsaunde at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from tbsaunde at gcc dot gnu.org --- duping *** This bug has been marked as a duplicate of bug 64047 ***
[Bug target/64047] [5 Regression] ICE: Segmentation fault when compiling gcc.dg/torture/pr52429.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64047 tbsaunde at gcc dot gnu.org changed: What|Removed |Added CC||sch...@linux-m68k.org --- Comment #2 from tbsaunde at gcc dot gnu.org --- *** Bug 64157 has been marked as a duplicate of this bug. ***
[Bug c++/64346] gcc generates incorrect debug info for ctor/dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64346 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- _ZN3ABCC4Ev That is the internal name of the function (it demangles to ABC::ABC() anyways) and the symbol does not need to be in the symbol table at all. We are going to run into this more with ICF also. I think there might have been a RFC about how to handle the debugging for commoning of functions but it might be a while before that is implemented.
[Bug c++/64346] gcc generates incorrect debug info for ctor/dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64346 --- Comment #3 from dehao at gcc dot gnu.org --- For AutoFDO, we actually needs symbols from the symbol table because indirect call promotion needs the symbol name to find the right callee. You are right, ICF also causes trouble to AutoFDO profile.
[Bug c/64347] New: constructor priorities are not supported in avr-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64347
Bug ID: 64347
Summary: constructor priorities are not supported in avr-gcc
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cameron at tacklind dot com
In avr-gcc, if you try to add a priority to a constructor function, you get:
error: constructor priorities are not supported
Steps to reproduce:
# echo 'void init() __attribute__((constructor(TEST)));' test.c
# echo 'int main() {return 0;}' test.c
Compiles with no errors
# gcc test.c -D TEST=1000
# avr-gcc test.c -D TEST=
Does not compile
# avr-gcc test.c -D TEST=1000
[Bug ipa/63851] [5 Regression] 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 --- Comment #10 from howarth at bromo dot med.uc.edu --- (In reply to Dominique d'Humieres from comment #8) Results with the patch in comment 5 at https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg02164.html. Note that the test gfortran.dg/assumed_rank_10.f90 fails at run time when compiled with '-O2 -funroll-loops -m32'. Without '-funroll-loops' the test succeeds at run time. Also '-O1 -fipa-icf -funroll-loops -m32' produces a assumed_rank_10.exe which fails the execution test while '-O0 -fipa-icf -funroll-loops -m32' produces one which passes.
[Bug middle-end/62178] [5.0 regression] [AArch64] Performance regression on matrix matrix multiply due to r211211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62178 --- Comment #6 from amker at gcc dot gnu.org --- Author: amker Date: Thu Dec 18 02:53:42 2014 New Revision: 218855 URL: https://gcc.gnu.org/viewcvs?rev=218855root=gccview=rev Log: PR tree-optimization/62178 * tree-ssa-loop-ivopts.c (cheaper_cost_with_cand): New function. (iv_ca_replace): New function. (try_improve_iv_set): New parameter try_replace_p. Break local optimal fixed-point by calling iv_ca_replace. (find_optimal_iv_set_1): Pass new argument to try_improve_iv_set. gcc/testsuite/ChangeLog PR tree-optimization/62178 * gcc.target/aarch64/pr62178.c: New test. Added: trunk/gcc/testsuite/gcc.target/aarch64/pr62178.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c
[Bug middle-end/62178] [5.0 regression] [AArch64] Performance regression on matrix matrix multiply due to r211211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62178 --- Comment #7 from amker at gcc dot gnu.org --- Should be fixed.
[Bug target/58623] lack of ldp/stp optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58623 --- Comment #7 from amker at gcc dot gnu.org --- Hi Evandro, There is specific PR for this issue. But as we know, fwprop often corrupts optimizations on address expression, for below example: add rb, r1, r2 ldr rx, [rb] add rb, rb, #4 It's transformed into below by fwprop: add rb, r1, r2 ldr rx, [r1, r2] add rb, rb, #4 This corrupts post-increment opportunity. Though in different form, it's actually same issue as in ldp/stp. I think https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44883 describes the problem in some manner, and there might be other PR about it too.
[Bug tree-optimization/61931] Wrong Constant Folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61931
--- Comment #2 from Ishiura Lab Compiler Team ishiura-compiler at ml dot
kwansei.ac.jp ---
We are sorry for having reported an error program with undefined behavior.
We have redone minimization. The resulting program is as follows.
$ cat test.c
int a = 1;
int b = 0;
int c = 1;
int d = 1;
long long e = 2LL;
long long f = 1LL;
unsigned long long g = 0xLLU;
int main (void)
{
int h = 1;
int i = (1 / a) - 1;
int j = h (i = 1U);
long long k = 1LL (g + 3LLU);
long long l = k 1;
long long m = (b | l) / 3;
long long n = (a - m) | 1;
long long o = 1 - ((0 | n) ^ j);
long long p = 1 | (3 * f);
long long q = p (a = 0);
long long r = (e 2) % 3;
c = r = (q || d);
long long s = (1LL % d) * a;
if (o != -2LL) __builtin_printf (o = %lld\n, o);
if (s != 0LL) __builtin_printf (%lld, 0LL);
return 0;
}
$ arm-none-eabi-gcc-4.8.4 test.c -o test.out -O2 --specs=rdimon.specs
$ qemu-arm -L /usr/arm-linux-gnueabihf/ ./test.out
o = 164686225997822
$ arm-none-eabi-gcc-4.8.4 test.c -o test.out -O1 --specs=rdimon.specs
$ qemu-arm -L /usr/arm-linux-gnueabihf/ ./test.out
